Er zijn nodes met informatie in relatie tot de tekenrichting van een weg. Bv ‘traffic_signals:direction =forward’. Ik heb altijd begrepen dat deze nooit op het begin of eindpunt van een highway geplaatst moeten worden omdat dan niet in alle gevallen duidelijk is wat er bedoeld wordt. Bijvoorbeeld omdat er 2 wegen op dat punt samen (kunnen) komen met tegenstrijdige richtingen. Of als er meer dan 2 wegen op de eindnode eindigen. En ik vermoed dat het voor data consumers ook veel lastiger is om dit juist te verwerken omdat er naar richting van meerdere wegen gekeken moet worden en er een keuze gemaakt moet worden bij tegenstrijdige richtingen zijn.
Onder het kopje “tagging” in de wiki van key traffic_signals:direction lees ik ook dat je beter niet op een eindnode kan plaatsen.
Ik kwam best veel nodes op eindpunten tegen met tags als forward/backward/ up,down/ left/right , direction etc.
Hier een kaartje met een aantal van deze punten.
Voor de groene punten is m.i. nog af te leiden wat er bedoeld wordt maar voor de rode is het minder duidelijk voor een data consumer.
NB Als je van zo’n weg de richting omdraait dan waarschuwt JOSM en vraagt of je bv de forward wilt wijzigen in een backward. Maar JOSM suggereert niet om ook de weg aan de andere kant om te draaien waardoor er wegen op de node uit komen met tegengestelde richting en dat kan niet de bedoeling zijn lijkt mij.
Ja, bekend probleem, ook Josm laat het ook zien onder Info:
Dit is precies z’n plek waar ik het gepast vindt, het “oplossen” met een aparte node maakt het niet beter.
Wat wel nodig is is dat de richting van de wegen met elkaar overeen komt, ik heb voor bovenstaande node één weg omgedraaid maar josm komt met precies dezelfde melding. Dat had wat mij betreft wel een warning of error mogen zijn.
Is dat zo? Both klinkt mij als beiden(=2) dus voor welke 3 mogelijke richtingen geldt dan dat ik zowel een "table"omhoog als naar beneden moet nemen? Het fietspad had toch ook op gelijke hoogte met de ‘table’ op de weg aan kunnen sluiten? En in dat geval zul je, komend vanaf het fietspad, alleen maar een table naar beneden kunnen nemen. Of moet het in zo’n geval anders getag worden oid?
Hier nog een voorbeeld van both. Wat betekent het op zo’n kruising? Wordt er met both dan bedoeld dat je komend van alle richtingen een table op en af rijdt? Hoe zou je iets dergelijks moeten taggen als de table alleen relevant is in noord/zuid richting maar niet in oost/west richting (omdat die richting al verhoogd ligt)?
Het is geen probleem, zolang de verschillende wegen dezelfde richting hebben.
Twee knopen dicht bij elkaar leggen kan juist wel een probleem zijn. Als het in werkelijkheid één punt is, dan vervormt het de werkelijkheid. @emvee’s voorbeeld van komgrenzen komt veel voor en als ik dat zie dan voeg ik het ook samen tot één knoop, want als de komgrens en de maximumsnelheidsverandering op verschillende knopen liggen, wordt het juist problematisch voor dataconsumenten.
Uit eigen ervaring: dit is helemaal niet moeilijk. De direction geeft aan of een richting van een weg beïnvloed wordt door een knoop:
bij forward wordt een richting van een weg beïnvloed als hij naar de knoop toe loopt;
bij backward andersom;
bij both (of geen waarde) worden beide richtingen van een weg beïnvloed.
Als je het op deze manier interpreteert, maakt het helemaal niet uit hoeveel wegen er aan de knoop vastzitten.
Volgens mij doet de iD-editor dit ook op zo, want die heeft er geen probleem mee om de genoemde voorbeelden consistent met deze logica te renderen.
Daarom tag ik de traffic_calming=table bij voorkeur op de way. Als het fietspad geen opgang heeft krijgt dat stuk geen traffic_calming=table bij de kruisingsnode komt het op een way met traffic_calming=table en heeft het alleen een afgang. Of cycleway loopt verder zonder tags. Zo ook bij footway. En zo zijn er ook T kruisingen waarbij een van de rijbanen geen opgang heeft. Zo maak je onderscheid.
De werkelijkheid, ik zie dan nogal wat groen punten bij een B6 haaientand, waar plaats je de node, highway=give_way midden op de haaientand, immers er wordt ook road_marking=give_way aangegeven, dan is er nog de overgang van surface zo van paving_stones naar asphalt die voor of achter deze haaientand ligt en dan is er de cycleway=crossing, met zijn crossing:markings, waar begint die dan. En al deze overgangspunten kunnen wel eens meer als 50 centimeter uit elkaar liggen.
Dan geen één punt. Kijkend naar de werkelijkheid, de ligging.
Ik maak er ook wel eens een punt van als de haaientand aan de bovenkant een scheidings- overgangsnode raakt, of leg hem er voor 30 cm … 1 meter of verder. Bij een stopstreep leg je de road_marking ook midden op de streep, hetzelfde geldt dan eigenlijk voor een haaientand. Die veelal zo’n 50 cm is, of kleiner.
Groene punt, bij styling, reden dat dit mijn aandacht trekt, is de richting goed aan te geven. Zie haaientanden boven.
Eerder, maakte ik er meer een losse node van, wiki advies niet op begin- eindnode volgend, nu heb ik deze criteria. En dat is wel eens best lastig.
Waar stopt belijning, waar ligt een overgang, wat is crossing, niet alle BGT belijning is een ander wegdek overgang.
Dat deel omgedraaid. En moet je kiezen.
Kies je
Dan draait, dat deel van de way om naar oost, maar ook de symbolen.
Styling technisch, staat de symbolen nu verkeerd t.o.v. wegdek haaietanden.
Ik heb ze tot nu toe gezet op basis van visueel zicht op de haaientand met preset
Was het verkeerd dan draaide ik het om, en op basis van een redenatie, way naar knoop. Paste ik de hele sectie aan betreffende richting way.
Pijltje omhoog geeft forward aan, naar beneden backward.
Dan kijkend naar
Hier komen twee pijltjes bij elkaar na omdraaien en do not apply changes. Het is
Bij een traffic_sign=city_limit komt eigenlijk altijd een knip aan een kant een zone:traffic=NL:urban en aan de andere kant een zone:traffic=NL:rural is dat belangrijker dan die direction zetten?
Ik begrijp inmiddels dat data consumers het wel kunnen verwerken en niet tegen technische problemen aan lopen maar ik vraag mij wel af of het altijd juist geinterpreteerd wordt. Of misschien beter… of het wel juist getagd is.
Als ik het goed begrijp dan zal een router denken dat er op deze node voorrang verleend moet worden zelfs als je op het fietspad blijft dus zonder de hoofdweg over te steken. Mijn gevoel zegt dat dit niet de bedoeling van de mapper is geweest en het voorkomen had kunnen worden door de node niet op het eind van een weg te plaatsen.
En zo zijn er nog meer punten te vinden waar het wellicht “mis” gaat zoals bv dezewaar een fietser m.i. vanaf de parallelweg het fietspad op mag fietsen zonder voorrang te verlenen.
Voorlopig is mijn conclusie dat het over het algemeen beter/handiger is om dit soort nodes niet op een begin of eind van een highway te plaatsen.
Ik heb nog wel een paar vragen.
Bij traffic_sign= city_limit (Tag:traffic_sign=city_limit - OpenStreetMap Wiki) zie ik veel forward/backward maar in de wiki vind ik hier niets over. Het is m.i. bedoeld om een grens aan te geven. Of zou het de bedoeling zijn om aan te geven wanneer je de bebouwde kom in/uit rijdt aan te geven?
Daar waar de bebouwdekom van het ene dorp overgaat in de bebouwde kom vanhet andere dorp kan “name:forward and name:backward. ”aangegeven worden. Wellicht heeft dit voor verwarring gezorgd? Of zou het de bedoeling zijn om aan te geven wanneer je de bebouwde kom in/uit rijdt aan te geven.
Direction =both op node met richting keuze
Is het juist dat met “both: bedoeld wordt dat het voor alle richtingen geldt en dus ook als er meer dan 2 wegen aan z’n node vast zit? Zo ja waarom gebruiken we dan niet gewoon “all” ipv “both”?
Ik heb een nieuw kaartje gemaakt. Alle nodes op 2 wegen die in de zelfde richting lopen laat ik nu maar buiten beschouwing omdat die vermoedelijk nergens een issue opleveren. En ik heb e.e.a. wat opgesplitst.
Voor zover ik het begrijp wordt traffic_sign=city_limit gebruikt om begin en/of einde van de bebouwde kom aan te geven. Van de wiki: “a sign that indicates the road is crossing a boundary of the urban area”. Vet door mij
De key city_limit=* gaat over het “bord” [1] zelf. En wel om aan te geven dat het dubbelzijdig of enkelzijdig is. wiki: city_limit
Enkelzijdig: alleen begin of eind bebouwde kom. Alleen te gebruiken op eenrichtings wegen/rijbanen. Met respectievelijk de waarde begin voor begin bebouwde kom en end voor einde bebouwde kom. NL borden H1 en H2
Dubbelzijdig: een bord aan beide zijden van de houder. Daarbij zie ik twee opties die ik niet teruglees in de wiki. Een combinatie van een begin en een einde bebouwde kom bord of een combinatie van 2 begin bebouwde kom borden. In het tweede geval komt den volgens mij de name:forward en name:backward tagging in het spel. De city_limit tag kan hierbij worden weggelaten (dit word gezien als de default) of de waarde both krijgen.
direction zou moeten worden gebruikt bij dubbelzijdige borden om aan te geven in welke richting de bebouwde kom ligt. Van de wiki: “should be specified for double-sided city-limit signs to clarify which traffic direction enters city limits.” Vet door mij
Maar hier wordt het al penibel. Gebaseerd op het voorgaande zou een dubbelzijdig bord op de grens van twee bebouwde kommen dus niet moeten worden voorzien van de direction key omdat beide richtingen de bebouwde kom in gaan. En zou welke bebouwde kom waar is dus moeten worden afgeleid van de name:forward en name:backward tagging.
Meer precies denk ik de combinatie van houder en bord ↩︎
Ja, deze zijn incorrect. Prima het nieuwe kaartje te zien, ik vermoed dat dit o.a. deze twee nodes omvat, eens kijken hoeveel fout-positieve gevallen ik nog kan vinden.
De vraag is dan hoe het wel op te lossen, misschien kan je aangeven voor de plek die ik eerder heb gegeven hoe jij het zou oplossen.
Ik dacht het zo correct op te lossen.
Cycelway placement=transition, een verspringen toch op dezelfde weg uitgekomen, gebruikmakend van een give_way en dan rechts af slaan.
Goeie vraag maar het antwoord heb ik niet. In eerste instantie zou ik kunnen zeggen dat ik een forward/backward niet zou taggen op een traffic_sign=city_limit (want wat betekent dit? In de wiki staat hier niets over). Maar als het een node zou zijn tussen 2 bebouwde kommen dan moet je iets doen met name:forward, name:backward en hoe moet dat dan als je niet op een eindnode wil taggen? Daar heb ik de oplossing niet voor.Wellicht zijn dit de uitzonderingen op de regel dat je het best niet op het eind van een weg zo’n node plaatst.
Het doet me ook denken aan een oude discussie over de Ekris (ik kan dat draadje niet meer vinden). Daar was een toegangsverbod (ik dacht een C06) die alleen maar gold voor 1 richting. Toen is wel eens gesuggereerd om een heel klein stukje weg op te knippen en op dat kleine stukje maar de beperking te taggen maar echt fraai is dat ook weer niet. Er staat mij bij dat in die oude discussie al de conclusie getrokken was dat richtingen op nodes nooit echt lekker werkt maar dat we wel een oplossing zouden moeten vinden voor dit soort situaties.
Met ervoor krijg je soms zulke verschuivingen, wel op te lossen door op de geselecteerde way en dan L te drukken. Of eerst die node recht te leggen en dan bij de way op L drukken.
Dit kwam omdat iemand anders, die node van beging crossing een stukje heeft verplaatst. Of de way heeft verschoven in zijn geheel, wat hier het geval was.
