Schade door undiscussed mechanical edits op footways

multimodaal · 2018-11-24 15:48:06

Bij mapwerk in de duinen stuitte ik op een footway die in OSM (in tegenstelling tot in het echt) niet toegankelijk was in de rendering en routering (en waar nu mijn naam aan hangt omdat ik de geometrie heb verfijnd).

Het ging om https://www.openstreetmap.org/changeset/56160591

Dit bleek het gevolg te zijn van schade door een grootschalige en schadelijke undicussed mechanical edit waarbij onder het mom van “needless tagging” zomaar alle foot=yes van footways is verwijderd op meer dan 1800 ways.
Nu stemt zo’n redenering op zich al droevig vanwege het grote onkunde op het gebied van de access-tag en verkeersregelgeving; uit de definitie van footway volgt weliswaar foot=designated (dat kan je “needless”noemen), maar NIET foot=yes.

Dat kan immers ook foot=permissive zijn of een andere waarde, zoals foot=customers. Foot=yesbeoogt aan te geven dat het een OPENBAAR voetpad is, en die informatie gooi je hiermee weg.
Waar de meeste gebruikers meer en sneller last van zullen hebben is dat er ook paden waren met de combinatie access=no of access=private en foot=yes. Op zich geen ideale tagging naar mijn idee, maar na het –zonder per geval te kijken en zonder lokale kennis- verwijderen van foot=yes is het niet beter geworden ,maar juist slechter:

Deze paden routeren nu dus niet meer en worden ook gerenderd als niet toegankelijk, ook niet voor voetgangers. Zie bijvoorbeeld
https://www.openstreetmap.org/way/210973041/history https://www.openstreetmap.org/way/88010524/history https://www.openstreetmap.org/way/508371523/history https://www.openstreetmap.org/way/376836104/history

Dit is in strijd met https://wiki.openstreetmap.org/wiki/Aut … of_conduct en met het principe van “Don't remove tags that you don’t understand “
https://wiki.openstreetmap.org/wiki/Goo … understand

Er is om goede redenen geen regel vastgelegd met “remove tags that you find in a default table”), zoals al uitgebreid is geconstateerd in https://forum.openstreetmap.org/viewtop … 84#p693284

Voor zover waarde van foot in tussentijd niet is teruggeplaatst of verbeterd (bijvoorbeeld "permissive" ipv "yes"), is deze changeset teruggedraaid in https://www.openstreetmap.org/changeset/64845766
Dit blijkt bovendien niet de enige vergelijkbare grootschalige schadelijke edit, ik zag zo snel ook nog bijvoorbeeld deze :

https://www.openstreetmap.org/changeset/56160165 (ca 1.750 wegen ) en
https://www.openstreetmap.org/changeset/56160412 (ca 850 wegen)

Martin, ik kan er met mijn verstand echt niet bij dat je hier ook nu nog je energie steekt in het hioer blijven uitdragen van je geheel eigen wijsheden dat je de meest basale access-tags NIET moet plaatsen (of zelfs moet verwijderen) juist om “verwarring te voorkomen” . Terwijl dat geheel voorbijgaat aan zowel onze verkeersregelgeving als de datastructuur van OSM. Het enige dat je hoeft te bedenken, is dat er een verschil is tussen [i ]“niet geconstateerd, maar wel aangenomen -dus mogelijk onjuist aangenomen” [/i ] en [i ] “ expliciet geconstateerd” [/i ]

Wat ik nog minder snap, is dat je de schade nog niet hebt gerepareerd in gevallen zoals hieronder, waarbij al eerder klip en klaar is gemaakt dat door jouw verwijderen van “needless tags” onder verwijzing naar een default-tabel, er schade is ontstaan zowel in de rendering als routering van een pad. In dit geval een highway=path op Schiermonnikoog die niet meer routeert en rendert voor fietsers na jouw verwijderen van tags.

https://forum.openstreetmap.org/viewtop … 97#p693097
https://www.openstreetmap.org/way/32022530/history
https://osmlab.github.io/osm-deep-histo … y/32022530

Ook al blijf je met je grote retorisch talent er een onnavolgbare andere mening op nahouden: schrap in je eigen planet-download gerust alle tags die je maar wilt, maar blijf alsjeblieft van de data in onze database af en herstel wat je hebt gesloopt! Dank alvast.

Martin Borsje · 2018-11-24 16:33:55

@Multimodaal,

Dank voor je bericht.
Je verwijst hier na reserach o.a naar een inderdaad deels slordig uitgevoerde edit van tien maanden geleden, waarvoor mijn excuses.
Je zegt zelf de changesets revert te hebben (voorzover mogelijk) dus verder handmatig reverten zal niet meer gaan of nodig zijn.

Deze dubbel-tagging (ik durf het woord needless niet te gebruiken) kan imho nog steeds tot verwarring leiden, wat ik genoemd heb. Ik snap niet wat het principeverschil is tussen het taggen van foot=yes op een path of footway en motor_vehicle=yes op een motorway. Extreem gezien kunnen we dan elke weg taggen als highway=* en alle toegestane en niet toegestane categorieën separaat met yes|no taggen? Wat is dan überhaupt de zin van default access?

Dat blijkbaar een aantal routeerders niet uitgaan van de default access van verschillende highways was mij onbekend; dit heb ik over het hoofd gezien en de eventuele schade hierdoor veroorzaakt spijt mij oprecht.

Ik heb foot=bicycle=designated teruggeplaatst op de betreffende highway 32022530

Als er meer zaken zijn waar je tegenaanloopt die gerepareerd dienen te worden (routes met name) dan laat het je me weten?

Nogmaals mijn verontschuldigingen dat blijkbaar deze edits een aantal routeerders van slag gebracht heeft.

Martin

Pieter - Ede · 2018-11-25 13:34:22

zomaar alle foot=yes van footways is verwijderd

Ik persoonlijk zou NOOIT foot=yes bij een footway zetten.
Volgens mij mag je als voetganger altijd overal lopen, tenzij het verboden is.
Footway impliceert volgens mij al dat het uitsluitend voor voetgangers is.
Ook een Path is, tenzij uitdrukkelijk anders vermeldt, volgens mij ook altijd toegestaan voor voetgangers.

Ik vraag me af welke programma persé foot=yes bij een highway=footway wilt hebben om een juiste route voor voetgangers uit te stippelen.

multimodaal · 2018-11-25 14:04:33

Hoi Martin, dank voor je sportieve reactie hier.

Martin Borsje wrote:

Je zegt zelf de changesets revert te hebben (voorzover mogelijk) dus verder handmatig reverten zal niet meer gaan of nodig zijn.

Zoals ook vermeld in reactie op je schrijven in https://www.openstreetmap.org/changeset/56160591 :

Ik heb alleen deze eerste changeset (56160591) teruggedraaid en dan alleen voor het foot=yes betreft in die gevallen waar dat niet in de tussentijd is verbeterd (ik zag gevallen waar bijvoorbeeld foot-permissive was toegevoegd en die wilde ik niet weer overschrijven met foot=yes, zoals https://osmlab.github.io/osm-deep-histo … 414199123).

Het verzoek ziet op de overige, nog niet herstelde tags en met name op de overige gelijksoortige changesets, waarvan ik er toevallig twee ben tegengekomen, maar ik weet niet hoeveel meer er nog zijn.
Gelet op de "regioale aanpak" (west- en noord-Nederland) vermoed ik dat er ook dergelijke changesets in oost- en noord Nederland zijn

Als je het terugdraaien niet zelf kan/wil doen, dan zou ik het waarderen als je hier een link naar de betreffende changesets, zodat ik of andere mappers dat kunnen repareren.

Gelet op de verstreken tijd zal je dat niet met de revert-plugin moeten doen, maar handmatig, waarbij eerst de wegen worden uitgesloten die in de tussentijd al wel weer een waarde voor foot=* gekregen (dat kan ook iets anders dan "yes" zijn)

Ik heb foot=bicycle=designated teruggeplaatst op de betreffende highway 32022530

Dank!

Een paar maanden geleden (maar na de verwijderen van de tags) is deze way opgesplitst vanwege een wandelroute, dat deel werd daarmee ook tagloos voor foot en bicycle. Hier zijn de tags nog niet teruggeplaatst, zou je zo goed willen zijn dat ook te doen, want ik neem aan dat het regime hier hetzelfde is?
https://www.openstreetmap.org/way/612199241

Waar ik het zelf meest benieuwd naar ben, aangezien je aangaf dat je bron survey is, wat voor borden staan daar nu?

Gelet op het type pad en de beheerder zou ik er -zonder er te zijn geweest- wel een aardige flesje om durven te verwedden dat het een G13 pad is en dat de oorspronkelijke tagging als cycleway beter is dan die als path

https://www.openstreetmap.org/changeset/57651991
https://osmlab.github.io/osm-deep-histo … y/32022530

Ik voel een tripje naar Schier aankomen

Als er meer zaken zijn waar je tegenaanloopt die gerepareerd dienen te worden (routes met name) dan laat het je me weten?

Dank, zal ik doen als ik daar tegenaanloop.
Maar hoop, ook omdat het bewuste verwijderingen zijn geweest, dat je dat ook zelf het initiatief zal nemen tot reparatie of in ieder geval het hier vermelden van de changesets, zodat anderen niet actief hiernaar hoeven te zoeken.

Deze dubbel-tagging (ik durf het woord needless niet te gebruiken) kan imho nog steeds tot verwarring leiden, wat ik genoemd heb

Ik zal op het inhoudelijke punt apart reageren in het draadje dat daar al langer over loopt en hier een link plaatsen naar die post.

eggie · 2018-11-25 14:15:45

@Pieter,
Zelf ga ik ook uit van de default tags, maar er zijn mappers die steeds opnieuw weer beginnen met access=no en vervolgens foot=yes taggen op een footway. Het resultaat is dat het gewoon routeert.
Wanneer dan foot=yes wordt verwijderd blijft access=no over met als resultaat dat geen routering meer plaats vindt.
Mappers die met iD beginnen beginnen heel vaak met access=no hetgeen volgens mij onwenselijk is, maar het gebeurt nu eenmaal.
Daarom kun je beter behoudend zijn in het verwijderen van access-tags.

Last edited by eggie (2018-11-25 14:17:06)

Pieter - Ede · 2018-11-25 14:21:03

eggie wrote:

Daarom kun je beter behoudend zijn in het verwijderen van access-tags.

Ben ik ook.

Martin Borsje · 2018-11-25 16:48:29

Changeset reverten ging natuurlijk niet meer
De betroffen highways waren inderdaad alle vrijwel zonder uitzondering met iD gemapt:

highway=path|cycleway|footway
access=no (dus eerst alles op slot zetten)
foot=yes (dan weer selectief openen)
etc.

Als je dan foot=yes weghaalt van highway=footway AND access=no, dan....

Heb dat (grotendeels) hersteld.

Kwam ook nog een highway=motorway & horse=no tegen

Maar de mensen die hw=footway, access=no, foot=yes taggen mogen zich ook wel eerst een beetje inlezen...

eggie · 2018-11-25 18:32:34

... met inlezen moet ik nog steeds beginnen

Het is wel zaak om nieuwe mappers op een vriendelijke manier met de neus de goede kant op te krijgen.

Pieter - Ede · 2018-11-25 18:42:37

eggie wrote:

... met inlezen moet ik nog steeds beginnen

En tegen de tijd dat je klaar bent ben je het eerste weer vergeten

Kogacarlo · 2018-11-26 13:59:09

eggie wrote:

access=no en vervolgens foot=yes taggen op een footway. Het resultaat is dat het gewoon routeert.

Hier snap ik geen bal van. Volgens mij is de router fout.
Waar is de access=no dan voor in dit geval?

eggie · 2018-11-26 14:34:51

@Kogacarlo.. Die is nergens goed voor, maar zo wordt er geredeneerd. "We zetten de boel op slot en daarna geven we aan wat er wel overheen mag". Dat lijkt me ongewenst, maar het gebeurt. Misschien zet editor iD de mapper wel op het verkeerde been.
Zonet nog een startende mapper erop gewezen .. Begin in principe nooit met access=no behalve bij een algeheel verbodsbord.

edit Neem aan dat bij een C1 bord je dan weer toevoegt foot=yes.
Gesloten in beide richtingen voor voertuigen, ruiters en geleiders van rij- of trekdieren of vee

Maar op een regulier voetpad dus niet.

Last edited by eggie (2018-11-26 14:37:33)

Allroads · 2018-11-26 14:55:32

Het extra moeten toevoegen van *=yes werkt vaak negatief door voor deze groepen, simpelweg omdat het wordt vergeten, oorzaak kennis van verkeersregels en op wie het betrekking heeft of dat ze vanuit 1 vervoersvorm aan het denken zijn.
Daarom is er ook gekozen voor bij C1:
https://wiki.openstreetmap.org/wiki/NL: … verklaring
vehicle=no & horse=no & traffic_sign=NL:C1
De kans dat vee gaat routeren acht ik zeer klein.
Gesloten in beide richtingen voor voertuigen, ruiters en geleiders van rij- of trekdieren of vee.

Last edited by Allroads (2018-11-26 14:56:29)

Kogacarlo · 2018-11-26 15:11:31

Bij bord C1

zou ik inderdaad vehicle=no zetten.
Geen gedoe met access-tags.

Ik ben het eens met het verwijderen van foot=yes van footways. Maar dan moet een eventuele access=no meeverwijderd worden.

Last edited by Kogacarlo (2018-11-26 15:16:43)

eggie · 2018-11-26 15:14:20

In dat geval kunnen we access=no beter helemaal vergeten. Bij art. 461 zetten we immers access=private

Kogacarlo · 2018-11-26 15:20:21

Dat ligt er aan. Als ergens grootschalig hekken worden neergezet om een gebied of een weg af te sluiten (bijvoorbeeld om een rotonde aan te leggen) zou ik access=no gebruiken. (en er vervolgens zelf gaan wandelen natuurlijk want ik ben mapper en ik moet alles in de gaten houden )

Last edited by Kogacarlo (2018-11-26 15:37:18)

Pieter - Ede · 2018-11-26 15:23:53

In de haven en op waterstaatskunstwerken heb je art 461 gebieden. Dat kan je natuurlijk 'private' zetten, maar dat is niet (helemaal) correct.
Het is in veel gevallen eerder 'destiny' maar dat zullen de routers wel weer fout doen, bovendien is dat in Duitsland een wat ruimer begrip dan hier geloof ik.
Je zou dus kunnen kiezen voor access=no

Last edited by Pieter - Ede (2018-11-26 15:25:01)

Mattheus · 2018-11-26 15:37:53

eggie wrote:

Misschien zet editor iD de mapper wel op het verkeerde been.

De OSM is bedoeld voor jan en alleman. De mapper-in-spé krijgt geen opleiding, maar is wel bevoegd om te mappen. De OSM biedt hiervoor 4 programma's aan:

1. ID
2. Potlatch
3. JOSM
4. Merkaartor

Een ieder is bevoegd om te mappen, maar niet iedereen is even bekwaam om dat te doen. De OSM houdt rekening met die bekwaamheid en biedt d.m.v. de diverse programma's mogelijkheden aan die verschillen van uiterst gebruiksvriendelijk tot iets minder gebruikersvriendelijk. De gebruikersvriendelijke varianten nodigen uit om diverse opties te gebruiken, bv. 'gebruik toegelaten voor'.

Helaas blijken enkele mappers die zichzelf uiterst bekwaam vinden, weinig tolerant te zijn. D.m.v. mechanische edits worden de z.g. onnodige tags verwijderd. Dit soort weinig flexibele mappers strijkt tegen de haren van de dagelijkse leiding van de OSM in, die juist probeert iedere belangstellende bij de OSM te betrekken.

Last edited by Mattheus (2018-11-26 16:56:48)

multimodaal · 2018-11-27 02:10:34

multimodaal wrote:

Hoi Martin, dank voor je sportieve reactie hier.
[...]
Ik zal op het inhoudelijke punt apart reageren in het draadje dat daar al langer over loopt en hier een link plaatsen naar die post.

Staat op https://forum.openstreetmap.org/viewtop … 12#p727512, raakt aan meerdere lastige OSM kwesties, dus veel tekst..

escada · 2018-11-30 07:23:59

Mattheus wrote:

De OSM is bedoeld voor jan en alleman. De mapper-in-spé krijgt geen opleiding, maar is wel bevoegd om te mappen. De OSM biedt hiervoor 4 programma's aan:
1. ID
2. Potlatch
3. JOSM
4. Merkaartor

Deze programma's (en ook Vespucci, OsmAnd, maps.me enz) worden door onafhankelijke teams gemaakt. Niemand die hen controleert. Het zou niet de eerste keer zijn dat een beslissing van de makers van iD (of maps.me) de wind van voren krijgt.
Dus het is een goede zaak dat ervaren mappers correcties uitvoeren op tags die door foute code of beslissingen in die programma's is gekropen.

Mattheus · 2018-11-30 13:43:40

escada wrote:

Dus het is een goede zaak dat ervaren mappers correcties uitvoeren op tags die door foute code of beslissingen in die programma's is gekropen.

Dat ben ik helemaal met je eens. Er valt geen speld tussen te krijgen.

Maar ik kijk naar wat de topicstarter schrijft: "verwijderen van “needless tags” onder verwijzing naar een default-tabel, er schade is ontstaan zowel in de rendering als routering van een pad"

Als een ervaren mapper probeert zijn minder ervaren collega's op een dergelijke manier probeert te corrigeren, is er iets goed mis.

Als ik de voorbeelden op de Engelse wiki bekijk hoe ik een pad moet taggen, zie:

https://wiki.openstreetmap.org/wiki/Path_examples

dan krijg ik het gevoel dat er niet zo zwaar wordt getild aan een overbodige tag. Ik krijg de indruk dat het beter is dat er een tag te veel dan een tag te weinig wordt gebruikt. Als ik wil kijken naar Nederlandse voorbeelden en dus het Nederlandse deel van de wiki voor pad opzoek, staat er: Deze pagina bevat geen tekst, zie

https://wiki.openstreetmap.org/wiki/NL:Path_examples

Persoonlijk maak ik me drukker om foute tags, dan om overbodige tags. De OSM is niet altijd betrouwbaar. Als ik een fietstocht maak in een onbekend gebied, kijk ik eerst hoe de wegen/paden zijn. Vorig jaar maakten mijn vrouw en ik een fietstocht. Er viel me niets bijzonders op aan de wegen en paden, dus wij op weg. Op een bepaald moment moesten we linksaf slaan. Volgens de OSM was dat een minor road (highway-unclassified), max snelheid 60 km/u. Helaas kon ik de weg niet als zodanig herkennen. Ik zei tegen mijn vrouw: "ik weet niet of dit wel klopt." Toch de weg in gefietst. We zagen dat we naar een boerderij gingen. Bij de boerderij versperde een slagboom de doorgang. Mijn vrouw sloeg toen automatisch rechtsaf het boerenerf op. Ik ging rechtdoor. We moesten door de berm om langs de slagboom te kunnen.

Deze weg is gemapt door een uiterst ervaren mapper. Het was een oprit naar de boerderij die halverwege de oprit stond. De weg is dus fout gemapt en lang niet volledig gemapt.

We kunnen allemaal fouten maken en ik neem het de ervaren mapper niet kwalijk. Maar een foute tag vind ik aanzienlijk erger dan een overbodige tag. Als iemand een overbodige tag constateert, verwijder hem. Neem (eventueel) contact op met de mapper die dat heeft gedaan, zodat beiden ervan kunnen leren. Maar om zo'n ophef hierover te maken op dit forum? Een Engelsman zou zeggen: "There's no need to make such a song and dance about it".

smootheFiets · 2020-12-11 16:17:50

Ik ben net nog een van deze footway's tegengekomen, die stond bijna drie jaar per abuis op slot: https://www.openstreetmap.org/way/28191282/history (foot=yes verwijderd in CS 56160412)
We zijn dus nog niet af ervan!

Martin Borsje · 2020-12-11 20:28:02

Scherp opgemerkt!

Wel grotendeels Ik zie nu ook rare tagging voor ik het veranderd had: hw=footway, access=no, foot=yes met de changeset note "wordt gebruikt bij fietsroutes, maar is een voetpad" Dus inderdaad de combinatie highway=footway AND foot=yes is zinloos, maar domweg over access=no gelezen (of gestruikeld). Overigens is het DTeelde in 2018 ook niet opgevallen dat access=no de weg de facto op slot zet toen hij een edit uitvoerde

Geim · 2020-12-11 22:19:09

Misschien moeten we wel een mechanical edit uitvoeren om overal access=no te verwijderen

Martin Borsje · 2020-12-12 09:24:58

Strak plan! Ik neem aan dat jij dat dan wel even doet!

P.S. Voor hen zonder sarcasmefilter: breng mensen niet op slechte ideeën

Geim · 2020-12-12 09:29:59

Effe zonder dollen, ben druk bezig om met Overpass naar access=no in mijn omgeving te zoeken en controleren of deze terecht zijn. 80% niet. En van de overige 20% is 3/4 discutabel.

#1 2018-11-24 15:48:06

Schade door undiscussed mechanical edits op footways

#2 2018-11-24 16:33:55

Re: Schade door undiscussed mechanical edits op footways

#3 2018-11-25 13:34:22

Re: Schade door undiscussed mechanical edits op footways

#4 2018-11-25 14:04:33

Re: Schade door undiscussed mechanical edits op footways

#5 2018-11-25 14:15:45

Re: Schade door undiscussed mechanical edits op footways

#6 2018-11-25 14:21:03

Re: Schade door undiscussed mechanical edits op footways

#7 2018-11-25 16:48:29

Re: Schade door undiscussed mechanical edits op footways

#8 2018-11-25 18:32:34

Re: Schade door undiscussed mechanical edits op footways

#9 2018-11-25 18:42:37

Re: Schade door undiscussed mechanical edits op footways

#10 2018-11-26 13:59:09

Re: Schade door undiscussed mechanical edits op footways

#11 2018-11-26 14:34:51

Re: Schade door undiscussed mechanical edits op footways

#12 2018-11-26 14:55:32

Re: Schade door undiscussed mechanical edits op footways

#13 2018-11-26 15:11:31

Re: Schade door undiscussed mechanical edits op footways

#14 2018-11-26 15:14:20

Re: Schade door undiscussed mechanical edits op footways

#15 2018-11-26 15:20:21

Re: Schade door undiscussed mechanical edits op footways

#16 2018-11-26 15:23:53

Re: Schade door undiscussed mechanical edits op footways

#17 2018-11-26 15:37:53

Re: Schade door undiscussed mechanical edits op footways

#18 2018-11-27 02:10:34

Re: Schade door undiscussed mechanical edits op footways

#19 2018-11-30 07:23:59

Re: Schade door undiscussed mechanical edits op footways

#20 2018-11-30 13:43:40

Re: Schade door undiscussed mechanical edits op footways

#21 2020-12-11 16:17:50

Re: Schade door undiscussed mechanical edits op footways

#22 2020-12-11 20:28:02

Re: Schade door undiscussed mechanical edits op footways

#23 2020-12-11 22:19:09

Re: Schade door undiscussed mechanical edits op footways

#24 2020-12-12 09:24:58

Re: Schade door undiscussed mechanical edits op footways

#25 2020-12-12 09:29:59

Re: Schade door undiscussed mechanical edits op footways

Board footer