Heeft LiveNav ook andere kennis van het wegennet die het buiten OpenStreetMap ophaalt? Er is niets op de kaart tussen de brandweerpost op de Aldlânsdyk en deze wijk waar emergency=* van toepassing is namelijk.

Zou het iets te maken kunnen hebben met deze beperkingen op de Boksumerdyk?

maxaxleload=2.2
maxwidth=2

Dus: maximum toegestane breedte 2 meter en maximumasdruk 2.2 ton, zoals daar op de borden staat.

Ook in OsmAnd (app die OpenStreetMap-data gebruikt) wordt ik netjes over de Redbadwei gestuurd. De kaart die ik daar in heb is nog van 1 juni 2022, dus met de Redbadwei als unclassified.

Qua routering lijkt er niets mis te zijn:

osm.org/directions?engine=graphhopper_car&route=53.19066%2C5.81929%3B53.17940%2C5.77353#map=15/53.1824/5.7903

Jullie aanpassing verandert zoals E. de Wit al schrijft niets daaraan. Zowel unclassified als tertiary routeren voor alle verkeersdeelnemers.

De Redbadwei wordt straks inderdaad een tertiary, maar vervult die functie nu nog niet, daarom is het een unclassified. De aanduiding tertiary is enkel de plaats in de wegenhiërarchie.

Kun je het probleem nog reproduceren? Liep de database die jullie navigatie gebruikte achter?

Je kan namelijk wel via de Weverij gestuurd worden als je iets ten zuiden van Boksumerdyk 5 de bestemming plaatst:

osm.org/directions?engine=graphhopper_car&route=53.1907%2C5.8193%3B53.1748%2C5.7727#map=14/53.1756/5.8071

Maar als ik zelf de bestemming zoek op adres 'Boksumerdyk 5' dan wordt ik netjes via Redbadwei en Boksumerdyk gestuurd. Je moet om die optie via de Weverij te krijgen de bestemming een behoorlijk stuk naar het zuiden zetten over de weilanden.

(Magst du construction:man_made nicht? Dann ändern es auf proposed:man_made. Die Entität behalten, bitte.)

Je paste de naam van een stuk fietspad aan, maar niet van het stuk benoorden daarvan. Nu gaan de straatnamen zo vanuit het dorp gezien:

Kompagnonswei/De Boppeste/Kompagnonswei/De Boppeste

Dat kan niet kloppen. Vanuit het dorp heb je de Kompagnonswei, die ergens rond de Litswei overgaat in De Boppeste.

Der Neubau hat sich aber schon angefangen:

https://www.ndr.de/nachrichten/niedersachsen/oldenburg_ostfriesland/Weener-Symbolischer-Baustart-fuer-die-neue-Friesenbruecke,friesenbruecke364.html

Proposed oder construction, egal für welche man nimmt, dort wird etwas geplant oder gebaut mit der Nahme Friesenbrücke.

Wieso haben sie auch die mehrere construction=* ways entfernt?

Doe je het stukje weg erboven ook?

Usually true, but in this case the edits all seem local to Eastern Russia and China. The relation for the Far Eastern economic region crosses the date-line, which makes it look like the changeset crosses the whole world, but it doesn't. Any chance to that relation will cause changesets to look like this; it can't be helped.

Zou je dingen niet weg willen gooien als je ze aan wil passen? Zo gooi je ook de geschiedenis van het object in OpenStreetMap weg.

Het kunstwerk heeft geen officiële naam trouwens, maar staat bekend als zowel 'Paal' als 'Blauwe Paal'.

Mooi dat die nu doorloopt. Ik heb het fietspad en de wal iets verder uitgelijnd op basis van recent beeldmateriaal.

Weet je ook hoe deze bebord is? G13 waarschijnlijk?

Bij Dronryp laat je hem nu aansluiten op een wandelpad. Klopt dat, of komt deze op deze way uit?

osm.org/way/492116273

I'm not seeing anything weird with those plugins, and those actions on their own shouldn't cause such issues. This may have something to do with your specific runtime environment (Java version, environment variables, operating system, etc.).

I suggest you open an issue via the Report Bug form in the Help menu of JOSM. It helps to mention that this:

"EN 452: Москва => Берлин => Париж"

gets turned into:

"EN 452: Мо�ква => Берлин => Париж"

This is what is called a character encoding issue. The JOSM developer might know under which circumstances JOSM may cause that.

Your edits to this relation (and its reverse) have caused those tags to break a number of times. The chances of more of your edits having issues seems quite high, but may be harder to spot if it is only one letter that gets mangled.

Thanks. Relevant changeset with comments on this recurring problem: osm.org/changeset/122076941

Can you recall what you did in this case? Which actions? Can you reproduce this. without uploading the result? (ToniE repaired this relation here: osm.org/changeset/122111923)

What you did in this changeset will break tags in any relation with values in non-ASCII values; this is just a very visible relation spanning a large area. You may have broken quite a few lines of text in over 10,000 edits.

What exactly are you doing in JOSM? Some plugin? JOSM normally doesn't mess up text.

If you get mangled text during normal usage, you have found a serious bug in JOSM that should be reported.

That would just address a symptom, not the cause. This one gets many mappers' attention due to the size of the changeset; there are likely more relations this account thrashes which don't get spotted right away.

A tool that mangles Unicode has no place doing (semi-)automated edits here.

The tool also broke 'Paryż' (Paris) in name:pl, so even without Russian or ongoing connections beyond Poland this is an issue that must be fixed.

This changeset breaks the content of tags containing non-ASCII text (again). If you notice this: the DWG has been contact by me last week, and should be looking into it.

(The owner of this account does not read changeset comments.)

Zitten er bij OBS De Pipegaal meer scholen op dat terrein? Als het maar een school is, dan hoort amenity=school op de outline, en niet op de adresnode. landuse=education is dan niet nodig.

Looks like this problem is back (in the reverse of this train line) after a few edits that didn't break the text:

osm.org/changeset/121886764

This tool is breaking character encoding of valid tags again. Please fix this!