Zebra crossing in Nederland - NDW

Tja dat is gewoon fout. Moeten wij nou zo ingewikkeld doen omdat er op sommige plekken fout getagd wordt? De dataverwerker moet toch al onderscheid tussen landen maken.

Klopt. Volgens mij is dat een keuze die we kunnen maken. Zou dus betekenen dat we zebra’s veranderen van marked naar zebra.

Klopt ook. Vandaar dat ik het heb over ‘de standaardsituatie’. Hier kan je secundair (via crossing:markings) de zebra taggen. Een dataverwerker zal altijd de keuze moeten maken waar die vanuit moet gaan. Ik ben er hier vanuit gegaan dat de verkeerslichten vaker aanstaan dan niet, dus dat je liever hebt dat die ‘gelezen’ worden dan andersom. Daarnaast kan dus via crossing:markings nog gecheckt worden of er ook een zebra is mocht het verkeerslicht uitstaan.

Samenvattend: we moeten een keuze maken. Daar zitten altijd nadelen aan, en waarschijnlijk ook werk om zaken te wijzigen. Ik pleit alleen voor een relatief simpel systeem, in plaats van dat we straks op elke simpele zebra 5 tags aan het plaatsen zijn.

Volgens mij zijn dots stippen als ik naar de plaatjes op de wiki kijk. Dus misschien moeten we hier onze eigen waarde in het leven roepen.
Overigens willen sommige wegbeheerders ze nog wel eens door elkaar halen. Dus zal je altijd nog naar de haaientanden moeten kijken.

Na een discussie van 120 berichten zie ik op meerdere plaatsen in NL dat Osmose nog niet meedoet met julllie tagging.
Zie: Osmose

Willen jullie hier naar kijken en mogelijk vertellen of Osmose er naast zit, of dat er iets anders niet correct is.
Het gaat om de term “crossing=pedestrian”

De blokken hebben geen wetskracht wat betreft voorrang. Er zullen wel ergens inrichtingsregels bestaan die dit voorschrijven.

1 Like

In het begin van de zebra-actie heb ik nieuwe zebra’s a;s crossing=zebra toegevoegd, ik heb daarmee crossing=zebra wereldwijd zowat verdubbeld, geloof ik. Mijn enige gedachte was: zo snel mogelijk zebra’s invoeren. Iemand wees mij erop dat crossing=zebra eigenlijk niet meer toegepast werd, dat het nu marked of unmarked en traffic_signals of uncontrolled moest zijn, en dat verschillende grote editors daar verschillende presets voor gemaakt hadden.
Vond ik vreemd, maar het werd mij duidelijk dat je niet alleen naar zebra’s moet kijken, maar naar crossings al of niet met markering (en ook welke markering dan) en al of niet gestuurd door verkeerslichten, en dat ook fietsoversteken eronder vallen, al dan niet met markering (en welke markering dan).

Vervolgens bleek de tagging extreem inconsistent en divers te zijn, waarbij telkens vooral meespeelt: welk van de twee zet je in crossing=*, de markering of de verkeerslichten, en welke vind je dan het belangrijkst? Blijkt dat daarover al sinds jaar en dag gebakkeleid wordt zonder uitkomst, omdat het twee verschillende aspecten zijn die in alle combinaties voorkomen, en geen van de twee is voor iedereen de belangrijkste.

En dat geldt ook voor niet-zebra kruisingen, wat er ook heel veel zijn, ook met verschillende markeringen, ook met of zonder lichten.

En daarom zet ik geen crossing=zebra|traffic_signals|controlled|marked|unmarked meer en wordt het altijd crossing:markings=zebra|dots|dashes en crossing:signals=yes|no.

Als op een groot kruispunt (bv twee wegen met aparte rijbanen en aparte fietspaden, deels met zebras op de fietspaden deel zonder, en deels controlled door de lichten en deels niet) een deel van de voetgangers- en fietscrossings al gemapt is, vaak incompleet en met verschillende tagcombinaties, dan probeer ik die consistent te mappen en te taggen. Dan is eigenlijk de enige mogelijkheid om alles met crossing:markings en, waar van toepassing en bekend, met crossing_signals=yes.

Dat is gewoon de simpelste manier om elke crossing, ook zebra’s, ook fietscrossings, consistent te kunnen taggen, zonder te hoeven bepalen wat er belangrijker is: lichten of markering.

Wat er in crossing=* staat doet er dan eigenlijk niet meer toe, zolang het maar klopt. Hij kan ook ontbreken, en ook dat is al behoorlijk vaak het geval.

Twee is genoeg.

highway=crossing
crossing=zebra

of

highway=crossing
crossing:markings=zebra

Dat is het. Verdere tags voor meer bijzonderheden moet je altijd extra toevoegen.

Om tot 5 tags te komen kan je lichten taggen (1), eiland (2), tactile_paving (3), of het een officiële zebra is (4), of fietsen toegestaan is (5), iets over de stoeprand (6), maar dat moet niet en je kan dat bij allebei de bovengenoemde nogelijkheden doen.

Als je crossing=zebra doet, ga je dan ook niet-gestreepte oversteekplaatsen taggen met crossing=dashes?

1 Like

Mijn tagging. Als alles erin zit komt er omtagging aan, tot die tijd zou ik die check van osmose uitzetten!

De impliciete aanname hierbij is dat de crossing key mapt wat ook met crossing:markings gemapt kan worden maar dat is niet zoals ik het zie.

De crossing key geeft volgens mij aan:

  • Of je bij de oversteek moet wachten op verkeerslichten óf
  • Je zodra je de oversteek begint mag verwachten dat kruisend verkeer stopt óf
  • Je bij de oversteek geen voorrang hebt óf
  • De oversteek eigenlijk niet bestaat

En als ik (als een ander iemand) nu zeg dat dat niet waar is?

Eerder schreef je “dat het nu marked of unmarked en traffic_signals of uncontrolled moest zijn” waarom nu dan “crossing=pedestrian”?

1 Like

Dan zeg ik: ik vind dat niet, velen vinden dat niet, en kijk eens naar de praktijk van mapping en tagging van crossings, hoe het in OSM zit. Heb jij een betere verklaring?

Ik schreef dat mensen dat tegen mij gezegd hadden.

Ik ben het daar niet mee eens, ik tag nu crossing=pedestrian voor zebra;s die ik toevoeg in dit project, omdat dat het belangrijkste onderscheid in crossings is: wie of wat steekt er over. Het is een voetgangersoversteekplaats, of een fietsoversteek, al dan niet met bepaalde markeringen of lichten.
Lichten geef ik bij nieuwe zebra’s bijna niet aan, omdat ik het meestal niet met zekerheid of alleen met tijdrovend nakijkwerk kan verifiëren. Maar als ik het doe, dan in de crossing:signals tag.

Markings en signals zijn bijkomende kenmerken die je al of niet kan taggen, in alle mogelijke combinaties, waarmee je precies kan aangeven wat er te zien is.

Bij dots staat dat het dotted lines aangeeft, en het plaatje erbij is dit:

Lijkt er best wel op, toch?

(
Plus, vanuit het verkeer op de weg gerekend,

  • dat er op die plek fietsers, voetgangers of paarden kunnen oversteken
  • bij voetgangers, of je ervoor moet stoppen
  • binnen welke grenzen die overstekers zich bevinden
    )

1= of het verkeer door lichten geregeld wordt
2= of er zebrastrepen staan
3= welke tekens er anders op de weg staan om de oversteekbaan aan te geven, of geen tekens
4= crossing=no, alleen wanneer je daar domweg niet kan oversteken, terwijl je het wel zou verwachten.

De voorrang en het op groen wachten tag je niet rechtstreeks, daar heb je geen waarden voor; het volgt uit de zichtbare markings en verkeerslichten.

Ja kan simpelweg niet twee onafhankelijke kenmerken die massaal samen én alleen voorkomen, in één key stoppen. Dan krijg je een onoplosbare discussie over wat het belangrijkste is, Dát is wat de huidige tag-chaos bij oversteekplaatsen heeft opgeleverd. Tagchaos? Ja, totale tagchaos, waar geen zinnige data-user iets mee kan.

Ik stop met deze discussie over crossing=*. Er zijn fervente voorstanders van simpelweg crossing=zebra voor alle zebrapaden; er zijn voorstanders crossing=traffic_lights|uncontrolled, en er zijn voorstanders van crossing=marked|unmarked. Dat gaat niet samen.

De tagging laat dan ook een chaos, of laat ik het neutraal zeggen, een divers beeld zien. Niet alleen in Nederland, maar wereldwijd.

Mocht iemand daar iets aan willen opschonen, dan heb ik 1 dringend advies:

Zet allereerst de informatie die nu in de crossing key staat, in de betreffende crossing:* key. Dat kan je doen zonder het eens te hoeven zijn over wat het moet worden.
Daarna kan je met crossing=* doen wat je wil (ook weglaten of onveranderd laten), zonder informatieverlies.

2 Likes

Geheel mee eens, prima om voor extra kenmerken sub-keys te gebruiken.

Je kan inderdaad alles met alleen sub-keys doen en wat mij betreft is dat een goede optie.

Het probleem lijkt me dat mensen alleen sub-keys willen gebruiken maar ook de main crossing key en wat voor waardes moet je daar dan gebruiken?

Zo kwam ik bij mijn lijstje van vier, ja, ze vertellen niet alles maar volgen zo veel mogelijk de bestaande mapping, “plus” dingen gaan in sub-keys.

Aardig overzicht.

Waar ik niet van hou is de chaos groter maken en naar mijn idee doet crossing=pedestrian dat.

Zoals ik het zie is die informatie óf niet nodig óf al aanwezig:

  • geïsoleerde crossings, crossings op alleen één weg worden door worden niet voor voetgangers of fietsers gebruikt, voor een automobilist is verkeerslicht/zebra/gewoon voldoende.
  • echte crossings hebben altijd een kruisende weg en die geeft aan voor wie de kruising is bedoeld
  • Voor “meer tags is beter” personen kan je foot/bicycle/…=yes toevoegen

Dus wat mij betreft wordt NL global crossing=pedestrain verwijderd.

Wat betreft het laatste punt, het script geeft ook welke andere tags bij highway=crossing zijn gevonden:

14457   tactile_paving
 5394   kerb
 3855   button_operated
 2673   bicycle
 2547   traffic_signals:sound
 1430   traffic_signals:vibration
 1321   traffic_calming
  883   mofa
  504   horse
  498   moped
  424   traffic_sign
  358   supervised
  112   foot

Alleen deze tag dan, niet de rest want het zijn echte crossings.
Niet allemaal zebra’s; er zijn ook anders gemarkeerde crossings bij en crossings die geen markering of lichten hebben maar er wel instaan omdat lowerd kerbs of tactile_paving erop getagd zijn.

Geen probleem wb informatie over markering en lichtbesturing, als dat er is staat het al in de crossing:* tags. Dus er hoeft geen andere waarde in de crossing key. Als je dat zou willen kan je naar de crossing:* tags kijken, maar dan maak je weer een keuze die de bestaande chaos niet verbetert, en die zet je in een key die een categorie-indeling zou moeten geven, niet een mengsel van hoe het eruitziet en hoe het werkt. O ja, ik zou niet meer discussiëren, sorry.

Wel zullen best wel wat crossings in tagging precies gelijk worden aan sommige fietsoversteken. Dat onderscheid verlies je.

Ja, ik bedoelde alleen de crossing=pedestrian tag verwijderen, de node en de andere tags blijven zoals ze zijn.

Nee, je verliest geen informatie, hij wordt alleen wat moeilijker toegankelijk.

  1. Er zijn geen gevallen van geïsoleerde crossings voor fietspaden, alleen voetgangersoversteken worden op de kruisende weg gezet zonder dat er een voetpad kruist. Vind je een geïsoleerde crossings dan is het dus een voetgangersoversteek.
  2. Als er een pad kruist kan je aan de access van dat pad zien wat voor kruising het is.

Ik kom ze iedere dag tegen.
Edit: ik las niet goed. “geïsoleerde fietscrossings” je bedoelt crossings die niet op een kruising van de ways staan. Daar heb je gelijk in.

In JOSM staat er op fietskruisingen een wandelaar-logo. Ken jij toepassingen die naar de kruisende weg kijken of het om een fietsoversteek, een loopoversteek of een paardenoversteek is en daar de rendering, routing of naviagatie van af laten hangen? En dat ze dan daarbij vergelijken of bv het fietspad de overstekende weg is of juist de weg die overgestoken wordt door een voetpad?

VZIW moet je voor data users de info liefst op het object zelf taggen, de node dus, en niet verwachten dat ze het af gaan leiden uit andere dingen. Zelfs als het technisch kan (er is altijd wel iemand die roept dat dat helemaal geen probleem is, bv bij een route berekenen over een gebied) beoordelen de meeste data users het toch als niet haalbaar, in de afweging moeite/verwerkingstijd vs toegevoegde waarde.

Wat betreft de access tags op kruisingen:
bicycle=yes betekent wat mij betreft dat bijvoorbeeld een zebrapad óók toegestaan is voor fietsende fietsers. Daarmee wordt het geen fietsoversteek.

en foot=yes op een fietsoversteek zou betekenen dat voetgangers de fietsoversteek mogen gebruiken - maar dat mogen ze zowizo dus dat wordt weinig toegepast.

Handiger om de oversteek gelijk goed te benoemen en alleen de uitzondering te taggen. Maar als je het met specifieke tags zou willen indelen, dan bicycle=designated en foot=designated. Met crossing=bicycle zou bicycle=designated impliciet zijn, en met crossing=pedestrian zou foot=designated impliciet zijn, net als bij cycleway en footway.

Om weer even terug te komen om het simpel houden: Is crossing=zebra dan nu een acceptabele korte versie van crossing=uncontrolled + crossing:markings=zebra?

Ben het er wel mee eens met @emvee dat we geen nieuwe waardes moeten creëren als dat niet nodig is. Ben het ook eens met @Peter_Elderson dat dit 1 van de meest rommelige / onduidelijke tags is qua interpretatie van de waardes. De subtags zijn dan wel weer vrij helder. Om juist niet te veel versplintering te krijgen gaat mijn voorkeur toch uit naar de approved waardes die op de wiki staan voor crossing en dan waar gewenst verder specificeren.

Niet bij mij, zo ziet het (highway=crossing + crossing=uncontrolled + crossing:markings=dashes) er default uit:

Screenshot_20250104_223748

en met Road Extended die ik default heb aan staan:

Screenshot_20250104_223850

Jazeker, want een voetpad/fietspad/ruiterpad worden verschillend weergegeven in Josm en dat geldt ook als ze deel zijn van een oversteek. Road Extended laat ook cycleway=crossing zien:

Screenshot_20250104_224825

Om het nog maar eens te herhalen, access tags zijn alleen “nodig” op geïsoleerde kruising nodes en dan nog niet eens omdat ik geen router ken die bij houdt aan welke kant van de weg je loopt/rijdt en daarmee zijn geïsoleerde kruising nodes ongebruikt.

In principe kan een router ze tegenkomen en er iets mee doen, de navigatie kan ze noemen en detailweergaven tonen. (Vgl verkeersdrempels, die krijg ik van OsmAnd zelfs te horen als ik er te voet een nader.) Mits ze eenduidig getagd zijn. Die eis geldt ook voor renderers.

In Osmand krijg ik gesproken meldingen voor zebrabaden. Dat heb ik aangezet in mijn “auto” profiel maar staat uit bij mijn “voetganger” profiel.

1 Like

Ik heb inmiddels crossing=pedestrian verwijderd.

De huidige situatie: @Peter_Elderson is begonnen met het crossing=zebra maar kwam na verloop tot de conclusie dat crossing:markings=zebra beter was. Een groot deel van crossing=zebra in NL is van de hand van Peter.

Als je dit topic doorzoekt op “crossing=zebra” (search button rechts boven, zoek in dit topic) dan zie ik voldoende voorstanders van “keep it simple” crossing=zebra gebruiken.

Ik ben van plan de boel voor NL vast te leggen/op te schonen in drie stappen:

  1. Verwijder/vervang crossing_ref
  2. Verkeerslicht- en zebra-oversteken
  3. De rest

Voor elke stap een voorstel en een poll om te zien of er voldoende support voor is. Dat zal flink wat doorlooptijd vragen.