Niet alles wordt in een mapcss geregeld. Zoals bijvoorbeeld oneway icon. Ik was op zoek naar de visualisatie van oneway=no en wilde dezelfde icons visualiseren, maar dan twee kanten op.
Maar ook hoe je snel de direction van een drawn way kan zien.
Edit, Preference (F12), de bovenste Display settings, tab OSM data.
Daar kan je namelijk: Draw oneway arrows, uitzetten.
De TIP is, zet aan, Draw direction arrows, met eventueel: Only on the head of the way.
Dit gebruik je bijvoorbeeld bij het zetten van traffic_signals, welke kant op de werking is, forward/backward of bij give_way, stop etc.
Dit wil je even snel kunnen zien in JOSM en niet eerst de way selecteren om dan de richting te zien.
Bij de volgende update zal ik dit gedeelte verwijderen uit de mapcss.
Voor verkeerslichten ziet de style dat als de weg eenrichtingsverkeer is, er geen direction tag nodig is, maar voor verkeersborden (voorrang verlenen en stop) lijkt dat niet op te gaan:
Ik heb bewust de vraagstelling alleen voor give-way en stop open laten staan, origineel aangepast met vraag ? " >? " of er een direction tag op moet. Was een node, ander kleurtje, waarbij je meer moest nadenken wat betekend dat.
Zo staat het in de originele style van âMichael Maierâ. title: âDirection for traffic signsâ;
Waarbij ik vond dat het een vast onderdeel moest worden van de ROAD extended style.
Ik heb dan ook de vraagstelling directer verwerkt in de style, zoals ik dat bij meerdere images doe, bijvoorbeeld bij yes " Y? " of bij else (andere value, niet uitgebeeld) " E? ", waarbij het vraagteken niet fout hoeft te zijn, misschien dat de tagging verbeterd kan worden, betere omschrijving (andere value), maar kan ook een verschrijving zijn, verkeerde spelling.
Bij mij stond de vraagstelling open of bij oneway, het in elke situatie zo is.
Bij eenrichtingswegen met uitzondering voor bepaalde groepen.
Hoe directer, de tagging, hoe beter. De werkingsrichting weergeven, wat is gewenst.
Wanneer element een direction value tag heeft op een oneway is dat niet verkeerd. Misschien wel gewenst.
Misschien moeten we traffic_signals wel toevoegen.
Of oneway uitsluiten.
Het gaat er mij ook om dat de stijl ergens aandacht vraagt met hints, hoe je ze oplost/negeert is een tweede.
Wat is hinderlijk, wat niet, afwegingen.
Bij traffic_signals wordt op basis van tag oneway geen mapcss beslissing genomen, betreffende jouw constatering.
Verandert naar versie 0.1.7, zie #1
Nu oneway=no op cycleway zichtbaar, een hint, legenda op zoom 27.
Legenda start op zoom 25 en voor sommige op 26 of 27
Verandering highway=street_lamp op node, voor lantaarnpalen waar tevens een verkeersbord getagd is, Sander H verkeersborden style na Road Extended Style aanzetten. Dan kom het verkeersbord bovenop de streetlamp image.
Ik gebruik vooral de âEnhanced Lane and road attributesâ style en dat werkt en sich prettig; maar met name de âwidthâ wilt nogal eens afwijken en dan is een restart van JOSM nodig.
Enig idee waarom de lane width van Enhanced soms verspringt?
Het gebeurt bij mij nu als ik even snel de PDOK Quick Ortho aanvink en dan weer terug ga naar de PDOK latest.
PDOK latest ligt goed. Die heb je als basis aan staan.
Zet je quick ortho aan, het nieuwe jaar, daar is de eigenschap van dat het niet overal goed ligt, wisselend, het is meer een inkijk laag, wat is er veranderd. Verspring je tussen deze twee lagen dan lijkt het of enchanced lane verspringt, in wezen verschuift je ondergrond. Op de ene plaats meer als het andere, vandaar jouw âsomsâ. Dat is een mogelijke verklaring.
Ik bedoel niet de offset oid; gebruik quick ortho inderdaad om even te kijken wat er veranderd is.
Wat ik bedoel is echt de breedte die Enhanced aangeeft. Bij het wisselen van kaartlaag is bij een weg van 5m breedt; de breedte van de style opeens kleiner. Heb het een paar keer gehad, dat ik dit niet doorhad; waardoor ik de breedte van de weg vergroot naar 7m om weer te matchen met BGT omtrekgericht. Start ik een volgnde keer weer op; dan valt dat weer op en mag ik het weer corrigeren.
