These kind of junctions exist. If navigation tools provide the wrong instructions, then the issue lies with those tools.

You are just taking those which sit really close together, but you can't solve cases like this one without severely disrupting the layout of the ways:

osm.org/go/0GVMEvoGr?m=

(And you'd anger a lot of mappers if you did.)

TomTom could look at osm.wiki/Proposal:Junction%3Dintersection instead, and consider using that to collapse several nodes into a single logical intersection. But it really shouldn't be necessary to change anything. Just collapse the intersection in the navigation model if the distance falls below a certain threshold.

Why? Navigation tools should be able to handle this.

👍

Why? That oneway-limitation doesn't start until 60m in unless that changed really recently.

Duidelijk!

Ik zou landuse=meadow alleen gebruiken waar het echt om agrarisch gebruik gaat. Op bedrijventerreinen wordt zelden begrazing toegepast, en waar het gemaaide gras heengaat is meestal niet duidelijk (waarschijnlijk gewoon voor compostering). Het hoofddoel is daar in ieder geval niet hooi maken. Ik denk dat landuse=grass (of landuse=greenfield bij onontwikkeld terrein dat braaklicht voor uitbreiding) prima is daar.

Deze twee bijvoorbeeld:

way/678470162

way/392374620

Je besluit wel erg snel dat een stuk gras weidegrond is. Op bedrijventerreinen en rondom bouwprojecten wordt meestal niet gegraasd. Waar baseer je je aannames op?

Oh dat is al gedaan, de wijken van Stiens staan er al in met place-nodes en boundaries. :)

Landuses kunnen in sommige gevallen wel samen in een multipologoon, maar dan gaat het meestal om kleine stukjes waar ze een naam delen (vaak een projectnaam tijdens de bouw).

Grotere multipolyogonen hebben het nadeel dat ze bij bewerkingen snel breken omdat je bijna nooit het hele ding ingeladen hebt. Met name ID is daar niet zo handig in.

Maakte hij van meerdere losse vlakken een multipolygoon? Dat is wel vreemd. Wat probeerde je dat dat gebeurde?

Als je de landuses verder wil opknippen is JOSM wellicht handiger. Dat geeft wat meer controle bij complexere bewerkingen (en veel meer keuze in achtergrondlagen, waaronder de heel handige BGT).

Zal ik hem anders terugdraaien of lukt het zo?

Waarom maak je een mega multipolygon van die losse landuses? Dat is nergens voor nodig, deze delen geen naam of zo.

If you add memorials, please don't enter the names and inscriptions in ALL-CAPS as you did with the stolpersteine here. Capitalise the text following normal spelling conventions.

Cf.: osm.wiki/Names#Good_practice

amenity=shelter is niet voor privé-afdakjes in de tuin. Je kan gewoon building=roof gebruiken.

Je ziet de changeset verkeerd. Ik heb hem samengevoegd (merge) met de al bestaande node met het juiste adres. Dat leidt er inderdaad toe dat een van de nodes verwijderd wordt. Doorgaans wordt automatisch de oudste node behouden, dat was in dit geval die uit de BAG import.

Understood.

Oh. there was a second one as well:

way/1352899022

These stood out in TagInfo.

What's up with the weird access-tag here?

way/1352896892

If it's a private pool, just use access=private.

Teruggedraaid in:

changeset/164124231

Je kan dit topic gebruiken om hulp te vragen als je vastloopt:

https://community.openstreetmap.org/t/algemeen-openbaar-vervoer-nl-topic/7050

Wat is het doel van de 'te verwijderen' routes?

Tip: voeg aan de amenity=parking bij gebruik voor parkeerhavens ook even parking=street_side en orientation=perpendicular toe.

Ben je er wel eens geweest? Dit komt niet in de buurt van een volwaardige supermarket. Als mensen dat een supermarkt noemen (en niet een supermarktje), dan ligt de fout daar.

De wiki hanteert de stelregel dat je pas over een supermarkt spreekt wanneer je ook winkelwagentjes hebt en het aanbod breed genoeg is voor dagelijkse boodschappen:

shop=convenience