Schade door undiscussed mechanical edits op footways

multimodaal · 2018-11-25T13:04:33.000Z

Hoi Martin, dank voor je sportieve reactie hier.

Martin Borsje:

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-history/#/way/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-history/#/way/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-25T13:15:45.000Z

@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.

Pieter_Amsterdam · 2018-11-25T13:21:03.000Z

eggie:

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

Ben ik ook.

Martin_Borsje · 2018-11-25T15:48:29.000Z

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-25T17:32:34.000Z

… 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_Amsterdam · 2018-11-25T17:42:37.000Z

eggie:

… met inlezen moet ik nog steeds beginnen

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

Kogacarlo · 2018-11-26T12:59:09.000Z

eggie:

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-26T13:34:51.000Z

@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.

Allroads · 2018-11-26T13:55:32.000Z

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:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
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.

Kogacarlo · 2018-11-26T14:11:31.000Z

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.

eggie · 2018-11-26T14:14:20.000Z

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

Kogacarlo · 2018-11-26T14:20:21.000Z

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 )

Pieter_Amsterdam · 2018-11-26T14:23:53.000Z

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

Mattheus · 2018-11-26T14:37:53.000Z

eggie:

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:

ID
Potlatch
JOSM
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.

multimodaal · 2018-11-27T01:10:34.000Z

multimodaal:

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/viewtopic.php?pid=727512#p727512, raakt aan meerdere lastige OSM kwesties, dus veel tekst…

escada · 2018-11-30T06:23:59.000Z

Mattheus:

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:

ID

Potlatch

JOSM

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-30T12:43:40.000Z

escada:

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-11T15:17:50.000Z

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-11T19:28:02.000Z

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-11T21:19:09.000Z

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