Yes, I see your point.

I still would prefer to see somewhere a hint that the closure is due to construction, the combination of these tags is not normal and often indicating there is a bug in the data.

Hoi Kin,

Met deze wijzigingsset zijn de fietspaden langs de Vestdijk van oneway=yes naar oneway=no gegaan.

Dat verbaasd me beetje want de stoplichten op de kruising met de Bleekweg/Bleekstraat laten niet aan twee kanten stoplichten voor de fiets zien.

Klopt deze wijziging? Een tweerichtingenfietspad heeft of een middenstreep of borden die aangegeven dat fietsen in beide richtingen mag. Veel spookrijders op het fietspad niet ;-)

Groeten,

Martin.

As a side note, when it is open again, better add "bicycle=yes" as the proposed default access restrictions for Australia indicate motorway is by default bicycle=no, see osm.wiki/OSM_tags_for_routing/Access-Restrictions#Australia

Good you better know the situation on the ground so the revert makes sense.

Is there any way to make the reverted data more consistent, I guess the cycle lane is close for construction so how about "cycleway=construction"

It is always better to have information for the ground, but on the other hand it is also good to have information that is not inconsistent in saying "yes you can cycle" (cycleway=track/lane) and at the same time saying "bicycle=no".

Like said in the the commit message, the incoming ways do not have bicycle=no and therefore I made this change.

If you think the change is not improving things, please feel free to revert it, but also have a thought on how the data can be made consistent.

Thanks,

Martin.

Bedankt!

Met deze changeset is way/57930091 verwijderd maar nu mist er een gebouw, zie "99" op way/57930091#map=19/52.06651/5.19279

Er is wel way/282807525 maar die heeft alleen "building:part"

Als je dat niet doet gaan "optimitische" routeplanners nog steeds over deze weg plannen want is er tegenstrijdige informatie en in de "optimische" mode kies je dan die data die de ruimste toegang geeft/

Dan ook maar cycleway:right=lane verwijderen?

PDOK is the default imagery you can use in JOSM for the Netherlands; it is open source from the Dutch government, see https://pdokviewer.pdok.nl/

Good to see the image of the sign and that is different then for the Netherlands, we do no have such a sign, see osm.wiki/Overzicht_Nederlandse_Verkeersborden

I see also that the default access rights for NL are different then the UK, see osm.wiki/OSM_tags_for_routing/Access-Restrictions#Netherlands versus osm.wiki/OSM_tags_for_routing/Access-Restrictions#United_Kingdom

For NL, highway=cycleway implies bicycle=designated and highway=footway implies foot=designated so these are redundant tags but for the UK it is different.

A path like this is in Germany mapped as highway=path with foot=designated and bicycle=designated

So I think it is best up to a local person like you to make the decision what to do, I still think me changes improved things but that does not mean the end result is perfect.

Inmiddelsbbegrijp ik de achtergrond, bedank, ik wil ook wel die relaties aanmaken.

Zal eens kijken of ik de Wiki kan bijwerken

Inderdaad, wat je al aan gaf, de schuingedrukte naam verdwenen dus die zat inderdaad aan landuse=residential vast.

Goed, place tags dus of z'n relatie met een tag dus, niet erg logisch naar mijn idee maar wat me nog meer verbaasd is dat hier geen word van op de wiki is te vinden, of kijk ik op de verkeerde plek?

Is er nog een reden dat het niet direct in een relatie met tags is omgezet?

No problem, errors are made and any decent bicycle router would prefer the cycleway over the main road but better have this correct.

Still some problem to go ;-)

osmose.openstreetmap.fr/en/errors/?item=3032&class=30329

I think these changes improve the quality of the data, but it might not be perfect, please let me know if you do not agree.

For https://osmlab.github.io/osm-deep-history/#/way/171441196 I removed access=yes, cycleway=lane and motor_vehile=yes as they are redundant or not visible on PDOK imagery

The livingstreet change was done earlier.

https://osmlab.github.io/osm-deep-history/#/way/226074641 is only improving the tags so to be more correct, cycleway=yes does not make sense so bicycle=yes and foot=designated is not needed

De commit zit in https://github.com/gravitystorm/openstreetmap-carto/pull/2816 lijkt het.

Ik vraag me af of de schuingedrukte naam aan "landuse=residential" gelinkt is, ik zal eens was proberen om te zien hoe het zit.

Als je inderdaad gelijk hebt dat een place tag altijd op een node moet staan dan zou snel de wiki, place=*#Populated_settlements.2C_urban aangepast moeten worden want die zegt nu duidelijk dat de tag zowel op een node als een weg mag staan.

Het lijkt erop alsof dat een probleem was, maar niet meer is:

https://github.com/gravitystorm/openstreetmap-carto/issues/103

Ik vraag me ook af het wel zo is dat de renderer alleen place-tags afbeeldt, zie bijv. Hordijkerveld 2 maal in changeset/65513772#map=16/51.8774/4.5479

Taggen voor de renderer is volgens mij niet de bedoeling en z'n node volgt ook niet echt osm.wiki/Good_practice#Map_what.27s_on_the_ground in want op de plek van de node is niets speciaals, de grenzen van een wijk zijn wel duidelijk, misschien niet op de grond maar wel in officiële documentatie.

Met z'n place tag geef je de renderer ook minder vrijheid om de naam ergens in het gebied te plaatsen en ik denk dat dat niet goed is.

Wat betreft landuse=residential heb je een punt maar voor Kreekhuizen komt dit wel overeen.

Met deze wijziging is de place tag van de landuse=residential relatie naar een tag gegaan (in ieder geval voor Kreekhuizen), ik vraag me af waarom.

Zelf vindt ik een place tag beter thuis horen op een area dan op een node, dat is ook op de Wiki te vinden, place=*#Mapping_populated_places_as_areas