JOSM mapcss , Road Extended JOSM (default) style.

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:

Is dat iets dat ontbreekt of hoort dat zo?

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.

Ik zal er eens verder over nadenken.

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.

0.1.8 28-7-2021
highway=busway toegevoegd
images aanpassing

@Allroads Gebruik je dit nog steeds?

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.

Ja, altijd en zet zo nu en dan op lane kruisingen enhanced lane aan om te kijken of de turn lanes goed staan. En of de placement tags kloppen.

1 Like

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. :man_shrugging:

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.

Mocht je dit nog steeds verder ontwikkelen; hierbij een paar verzoeken voor functionaliteit mocht dat lukken ;-):

  • Is het mogelijk om surface color weer te geven?
  • Is het mogelijk om sidewalk aan te geven?

Goed om deze style nog eens onder de aandacht te brengen, een must wat mij betreft als je met Josm werkt en met wegen/paden bezig bent.

Verder, ik heb wat toevoegingen:

Ook sidewalk voor fietspaden:

way[highway][sidewalk=right]::footway_sidewalk_layer {
    dashes: 2,10;
    width: 12;
    color: #d0d0d0;	
    offset: 0 - (prop("width", "default") / 2) - 2;
    major-z-index: 2.1;
    modifier: true;
}
way[highway][sidewalk=left]::footway_sidewalk_layer {
    dashes: 2,10;
    width: 12;
    color: #d0d0d0;	
    offset: (prop("width", "default") / 2) + 2;
    major-z-index: 2.1;
    modifier: true;
}
way[highway][sidewalk=both]::footway_sidewalk_layer {
    dashes: 2,10;
    width: 24;
    color: #d0d0d0;	
    major-z-index: 2.1;
    modifier: true;
}

busway toegevoegd, bus_guideway aangepast:

way[highway=bus_guideway] {
	dashes: 10,10;
	width: 4;
    color: #404040;
	casing-dashes: 10,10;
	casing-width: 1;
	casing-color:  #008080;	
}
way[highway=busway] {
	dashes: 10,10;
	width: 4;
    color: #404040;
	casing-dashes: 10,10;
	casing-width: 1;
	casing-color:  #ff0000;	
}