Footway/cycleway, value traffic_island of key crossing:island

Key:footway

In onze beleving, vanuit Nederlandse begrippen, behoort dat deel op een traffic_island nog tot de OSM crossing? De oversteek.

De keuze is dan:
footway=traffic_island
of
footway=crossing met crossing:island=yes
of de combinatie
footway=crossing;traffic_island ( ; niet gebruikelijk)

key: footway=traffic_island
key: crossing:island

Ook gezien het feit, dat het traffic_island deel heel smal kan zijn.

Dan zou er ook een cycleway=traffic_island zijn.
key:cycleway
Dat lees ik hier niet.
taginfo NL geeft er 36

Kies je voor de ene methodiek of de andere?
Waarom zou de keuze bij footway, anders zijn dan bij cycleway?

Omdat footway=traffic_island met name voor (mindervalide) voetgangers van belang is. Een oversteekplaats bestaande uit twee keer 10 m is immers makkelijker en veiliger over te steken met een rollator dan in één keer 20 m. Dat kun je aangeven met óf één lange way met footway=crossing en crossing:island=yes, of door drie ways (crossing, traffic_island, crossing) zonder crossing:island=yes. Maar net hoeveel details je in wil tekenen dus.

crossing:island=yes zegt dus dat ergens op een footway=crossing een vluchtheuvel zit, maar maakt niet expliciet waar, terwijl je met footway=traffic_island de oversteekplaats opsplitst en het wel expliciet maakt.

Als het even kan teken ik bij grote kruispunten de voetgangersoversteekplaatsen los in, omdat het parallele fietspad andere tags en nodes heeft (verkeerslichten bijvoorbeeld). Dan vermeid je het probleem van cycleway=traffic_island volledig.

Maar cycleway=traffic_island zou wel kunnen: het heeft dan denk ik alleen nut wanneer dat fietspad door voetgangers gebruikt wordt en ze niet op hun eigen stoep kunnen oversteken. Het is nu inderdaad niet helemaal duidelijk wat nu de juiste aanpak is voor zulke oversteekplaatsen:

Een cycleway=crossing en cycleway=traffic_island slaan dan alleen op het gebruik door de voetgangers lijkt me. Voor fietsers en ander verkeer zijn deze tagwaarden niet bedoeld.

Dit is juist. Een deel zet de tag crossing:island=yes over de gehele oversteek, andere zetten de tag op het stuk waar de vluchtheuvel ligt, dan is het meer concreet. Gelijk aan het gebruik van footway=traffic_island

Vandaar ook de vraag aan iedereen.
Vindt je dat footway=crossing over de gehele oversteek gezet moet worden of niet?

crossing:island=yes hoort bij highway=crossing, op de nodes waar de oversteekplaats de straten/wegen kruist dus. Als de vluchtheuvels los getagt zijn kan crossing:island:no op de highway=crossing nodes gezet worden, maar meestal laat je die dan achterwege.

De wiki documenteert dit wel duidelijk toch?

crossing:island is een eigenschap van highway=crossing, en hoort volgens mij niet op de highway=footway. Eigenlijk heeft crossing:island=yes alleen zin in situaties waar gescheiden rijbanen niet los ingetekend zijn, bijvoorbeeld bij dit soort stukjes:

Meestal worden die wel los ingetekend door de Nederlandse mappers dacht ik.

1 Like

Nee.
De wiki is een kant opgeschreven.
Vanaf het begin 2017-2019(voting)
Dus op een way te gebruiken.
afbeelding

afbeelding

Kijk je naar de aangenomen proposal is het duidelijk ook de bedoeling het op een footway=crossing te zetten.

Tagging The crossing:island=* key can be used on a pedestrian crossing mapped as a node (highway=crossing) or a way (highway=footway + footway=crossing). Possible values are yes and no. It is recommended to further specify the type of the pedestrian crossing using the crossing=* key.

footway=traffic_island is in 2021 gedocumenteerd, als in use, niet als approved. Wat je zelf hebt gedaan.

Een tag en value ontstaat, ontwikkeld, veelal vanuit een gedachte bekeken, terwijl de methodiek ook voor andere op gaat en het dan logisch is ook voor andere te gebruiken. Dit wordt vaak niet meegenomen met een proposal.
Zo werd er bicycle=use_sidepath ontwikkeld, later dachten andere, dat geldt ook voor mofa en moped en foot, zo ontwikkelt het door. De methodiek. Je kan dan niet stellig zeggen, het is alleen voor foot bedoeld. De situatie oogt zo op de grond, dat een vluchtheuvel wordt doorsnede. Niet raar dat men het ook bij cycleway=crossing gaat gebruiken. Zo ontstaat een in_use tag, net als footway=traffic_island

footway=traffic_island en footway=crossing gaan niet samen op 1 way, dus dan moet je de kruisende footway in 3 stukken hakken, 2 crossings en 1 island, zie ik dat goed?

Niet samen gaan, daar kan je het nog over hebben, wat niet kan is footway=traffic_island op het rijstrook /rijbaan deel zetten. Dat maakt het, dat je het in drie stukken moet knippen.

Hier, het samen gaan is ongebruikelijk, maar wel een methodiek, die vaker wordt toegepast met ; om twee zaken op een key uit te drukken.

Vandaar ook mijn vraag zien we in Nederland de hele oversteek als crossing?

Als er twee ways (rijbanen) gekruist worden door een footway of een cycleway die ook voetgangers over laat steken, zet ik highway=crossing op beide knopen. Maar vaak doe ik ook niks, want zo’n knoop is zowizo al een crossing.

Waarom? Het is vaak inderdaad één weg die je oversteekt, maar bij een beetje complex punt zijn dat al snel vier crossings met daartussen vluchtheuvels of andere vormen van ‘pauze’. Voor navigatiedoeleinden zijn dat inderdaad vier ‘oversteekacties’. Mensen die lange oversteekpunten willen vermeiden kunnen dat in theorie dan. footway=crossing markeert de delen waar je (meestal) omver gereden kan worden.

footway=crossing;traffic_island zou ik niet doen. De twee sluiten elkaar uit.

Begrijp mij goed, het gaat even niet, wat ik er van vindt, ik kan leven met footway=traffic_island.
Ik kijk alleen hoe er getagt is met de verschillende tags. Jij geeft je mening, prima aanvulling om tot inzicht te komen.
Het gaat er om hoe men die twee methodieken gebruikt. Vanuit welk motief/beleving tagt men.
Dat invoegen en de variatie van invoegen.

Dat stel ik hier ter discussie voor tagging op een way,
Het uitspreken/schrijven, wat de voorkeur heeft.
Vindt men dat op het traffic_island deel nog een crossing tag moet staan.
Vindt men dat op een rijbaan deel, way footway/cycleway een :island tag moet staan.
Dat is voor mij een constatering, als ik de huidige tagging op een way bekijk. Dan kan je de vraag stellen is dit correct.
Vindt men dat daar nog bijvoorbeeld crossing=uncontrolled moet staan, zou de combinatie met footway=traffic_island ook correct zijn.

Het creëren van bruikbare data, wanneer is het meer bruikbaar, als men op een bepaalde wijze tagt.

Als men hele stukken als crossing zet, hoe goed is dan de informatie om te gebruiken.
Aspecten als waar begint de crossing, net zoals bij een trap of een brug, niet op de kruisingsknoop.
Waar is het gemarkeerd, waar is het traffic_island, etc.

Trek je conclusie uit de volgende plaatjes.
Dit is de aanleiding tot mijn vraagstelling.


afbeelding



afbeelding


Nee, want de vluchtheuvel of het tussenstuk hoort niet bij het element waarop je crossing=* kan specificeren. Deze kan immers tussen twee verschillende typen ‘oversteekdelen’ liggen. In Nederland zelfs heel vaak, want het fietspad oversteken is vaak crossing=uncontrolled en de hoofdrijbaan een zebrapad of met verkeerslichten beveiligd deel.

Voor de rest is het een kwestie van hoe gedetailleerd je wil gaan. Als je een hele oversteek van kant tot kan intekent als footway=crossing, dan kun je geen details toevoegen aan de way, zoals crossing=marked. Splits je hem op, dan kan dat wel (nu of later). Persoonlijk zou ik footway=crossing achterwege laten als je deze niet opsplitst; je voegt dan niet wezenlijk meer informatie toe dan de highway=crossing node.

Teken je één highway=footway met footway=crossing voor de hele oversteek en zijn er pauzes tussen, dan kun je crossing:island=yes toepassen (maar dan weet je niet waar deze ligt, en hoe lang de losse oversteken zijn). Of je tekent ze los in en gebruikt crossing:island=yes niet:

(blokjes: footway=traffic_island, lijntjes: footway=crossing)

Als je de oversteekdelen los intekent, dan beginnen die uiteraard daar waar je het te kruisen vlak opstapt (zoals hierboven). Inderdaad net als bij trappen en bruggen.

Beide aanpakken zijn mogelijk; het is maar niet op welk detailniveau je bezig bent.