Ja, ik ben hier bekend. Lees deze changeset even door:

osm.org/changeset/122740824

Ik denk dat je met hetzelfde probleem als A. Postma bezig bent. De routering ging daar niet over het fietspad, maar over de boerenpaden daar ten oosten van.

motor_vehicle=no? Maar die is niet nodig op een highway=cycleway:

osm.wiki/OSM_tags_for_routing/Access_restrictions#Netherlands

Welk probleem probeer je op te lossen?

Zo lag hij:

https://postimg.cc/mcQ8cH21

Dat klopt, want de eenrichtingsweg komt grofweg uit op de rechterhelft van de (tweerichtings)straat.

Was dit je bedoeling? Je legt hem juist scheef:

https://postimg.cc/hfq6pcNB

Ik heb over dit probleem een draadje geopend hier:

https://forum.openstreetmap.org/viewtopic.php?pid=865837

Vul me aan als er niets klopt. Het lijkt me handig om dit gesprek daar voort te zetten: dit is een punt wat bredere aandacht verdient.

Maar werkt dat? Het zou het op deze weg oplossen, maar op andere plekken niet. Het zou landelijk wel een lastig punt zijn om overal emergency=yes toe te voegen waar wettelijke beperkingen gelden. Wij kunnen als mappers immers niet altijd inschatten of een wettelijke beperking ook een feitelijke beperking is. Soms kan de brandweerwagen er ook echt niet langs als er maxwidth=2 staat.

Ook zullen andere mappers niet snappen waarom emergency=yes op een wegdeel staat waar gewoon algemeen toegang op is. Het is tenslotten een tag uit de access-boom die niets met de tags die wettelijke beperkingen omtrent omvang en gewicht te maken heeft.

Als LiveNav iets met asdruk en maximum toegestane breedte doet, dan is dat op zich niet verkeerd, en soms zelfs wenselijk denk ik, zolang de gebruiker maar weet dat je het uit kan zetten en op eigen inzicht verder moet gaan. Dit kan dus ook een kwestie van documentatie en instructie zijn.

Als dat voor het testen handig is zouden we hier in dit specifieke geval de beide beperkingen wel weg kunnen laten voor een tijd. Ze waren er toch enkel voor die brug en tegen sluipverkeer. Dat kan nu niet meer met de fietsbrug. Ik ben wel benieuwd of het probleem dan nog gereproduceerd kan worden. Dan zou A. Postma ook bij de LiveNav-ontwikkelaars eens kunnen vragen of dit gewenst gedrag is.

Is dit een optie om de oorzaak van dit probleem te achterhalen A. Postma? Zie jij daar problemen mee E. de Wit?

De maximumbreedtebeperking zal inmiddels trouwens overbodig zijn, want die was er volgens mij vanwege de brug over de Zwette. Dat is nu een fietsbrug (dus auto's kunnen er al niet meer langs ongeacht hun breedte), maar ik heb nog niet gezien dat de gemeente de beperking heeft ingetrokken.

Als navigatie daar rekening mee houdt (bijvoorbeeld omdat een brandweerwagen 2,2 meter breed is), dan kan het kloppen dat je over boerenpaden wordt gestuurd waar geen wettelijke beperking op zit (wellicht wel een effectieve beperking, maar die is doorgaans onbekend). Dat lijkt me dan wel een instelling die je goed moet kennen en uit moet kunnen zetten: jullie mogen waarschijnlijk zulke beperkingen negeren onder bepaalde omstandigheden.

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.