En ik zie dat jij het probleem al hebt opgelost, osm.org/changeset/115689343#map=19/52.01213/6.14836

Ik ga er nu naar kijken.

Als BGT inderdaad niet de werkelijkheid weer geeft dan is een revert correct.

Ik heb geen licensie voor AHN maar zie op http://mijndev.openstreetmap.nl/~allroads/NLOSMOK/OSMOKNL.html#map=18.66/52.0172/5.9816/0 waar je het over hebt. Weer wat geleerd want tot nu toe vroeg ik me af waarvoor het AHN handig zou zijn.

Nooit geweten dat BGT z'n consequente afwijking kan hebben, in mijn ervaring met BGT heb ik dat nooit meegemaakt.

Wel eens overwogen een melding via verbeterdekaart te maken hiervan?

Geen reacties (nog) op het topic...

Wat betreft verkeersborden is er de Verkeersbordenkaart, zie https://forum.openstreetmap.org/viewtopic.php?id=70487. Niet 100% betrouwbaar maar best goed.

Wat betreft robot wijzigingen zie ook osm.wiki/Automated_edits

Ja, ik vindt het ook opmerkelijk, sinds de update van JOSM waarbij het splitten van routes is verbeterd heb ik een tijdje de optie waarbij JOSM vraagt om extra segmenten te downloaden als je een route knipt op manual laten staan waardoor hij er elke keer om vroeg maar sinds ongeveer een maand heb ik gezegd dat hij het automatisch mag doen. Dat lijkt hier zogezegd niet goed gegaan te zijn maar ik ben bang dat dat niet reproduceerbaar is...

Sorry te horen dat deze changeset een probleem opleverde en bedankt dat je ze hebt opgelost. Wat mij betreft had je het ook aan mij kunnen melden, dan had ik het zelf kunnen oplossen.

> Mijn conclusie is dan ook dat je de verkeerde werkwijze volgt door de weg (Parklaan) niet op te knippen maar compleet nieuw te tekenen.

Waar baseer je die conclusie op? Ik heb wel degelijk de Parklaan op twee plekken doorgeknipt om een fietspad-bypass toe te voegen, duidelijk te zien op achavi als de gele segmenten.

Hoi,

Die consensus lijkt er te zijn binnen het Nederlandse deel van OSM. Internationaal is dat een ander verhaal

Een robot voor dit soort dingen wordt niet als een goed idee gezien, en daar zit naar mijn idee wat in. Ik wil wel eens wat bijwerken maar kijk dan gelijktijdig alle oneway na, ook in Haarlem was er een stuk weg dat niet eenrichtingsverkeer (meer) is terwijl het werk zo getagd was

Hoi multichill,

Ik was ik Haarlem bezig en kwam deze changeset tegen.

Twee opmerkingen:
* cycleway=opposite is niet meer van deze tijd, zie https://forum.openstreetmap.org/viewtopic.php?id=65612
* moped=yes op highway=residential is een beetje overbodig, zie osm.wiki/OSM_tags_for_routing/Access_restrictions#Netherlands

Groeten,

Martin.

Goed te weten, waren de lege delen langs de Lageweg ook van jou hand?

In plaats van eerst weg halen en inchecken en daarna weer toevoegen zou je natuurlijk er ook voor kiezen het allemaal in één changeset te doen, zo zijn er geen open vlakken.

Maar goed bezig, ja het water/groen kan zeker een update gebruiken!

Alweer even geleden maar ik fiets elke werkdag hier en een fietspad is het (nog) niet.

Gecorrigeerd in osm.org/changeset/114286997

Ik zie op osm.org/changeset/113462300 jou commentaar en daar ben ik het helemaal mee eens.

Der Bierpuncheur vraagt nu "shall I change it?" en ik zou daar ja op zeggen en vermoed dat daarmee het probleem opgelost gaat worden.

Ik had Mapillary bekeken en het verkeerslicht gezien, het zebrapad niet bewust waargenomen. Maar geen G11 bord en geen stoeprand en zoals je zegt zelfs de Mapillary track fietst over de kruising.

Met het zebrapad meegenomen valt de overweging meer in de richting van voetpad dus heb ik hem weer footway gemaakt.

osm.org/changeset/113624044

One more tip, I found this issue through Osmose, have once a while a look at http://osmose.openstreetmap.fr/en/byuser/Alex%20Holloway

Like clearly indicated "This doesn't means that this user is responsible for all these issues." but reviewing them can not harm.

You will see my list, http://osmose.openstreetmap.fr/en/byuser/emvee is also far from empty.

Greetings,

Martin.

Hi Alex,

Thanks for fixing, looks good now.

One minor comment: cycleway=no incombination with bicycle=no is a bit double, bicycle=no is enough.

Enjoy further OSM editing!

Greetings,

Martin.

I just removed bicycle=no, see https://overpass-api.de/achavi/?changeset=113474979

Hi,

After you adding the cycle lanes, osm.org/changeset/112988036 added bicycle=no to some of these ways, see http://osmose.openstreetmap.fr/en/issues/open?source=16390&item=3032&class=30329

As you are knowledge in here it seems can you have a look at these two roads and correct things?

Thanks!

Hi Alex,

It looks to me osm.org/way/48633372 does not make sense anymore after this change, see also http://osmose.openstreetmap.fr/en/issues/open?source=406560&item=3032&class=30329

Is bicycle=no correct or should it be bicycle=yes?

Greetings,

Martin.

Hoi Michael,

bicycle=no/foot=no op osm.org/way/328738356 lijkt me niet correct

Kan je dat aanpassen?

Groeten,

Martin.

Hoi,

Deze changeset triggert https://maproulette.org/challenge/23248/task/118698980.

Ik heb inmiddels al twee eerdere soortgelijke problemen opgelost die ook gedaan waren door jou m.b.v. Go Map!!

Het lijkt erop alsof Go Map!! de nodige foutjes maakt...

Groeten,

Martin.

Hi,

Welcome as OSM editor!

I had look at osm.org/way/28703110#map=19/50.63775/5.57796 but adding there bicycle=no makes no sense to me because:
1) there is cycleway=lane
2) the connecting ways also have cycleway=lane and no bicycle=no

On the other 3 roads I also doubt if adding access=no/bicycle=no/foot=no, motor_vehicle=yes is correct, is there a sign indicating this? If not these tags do not belong there.

Greetings,

Martin.