User talk:Imagic

From OpenStreetMap Wiki
Jump to navigation Jump to search


Please rework your B1 text. Add that it is a proposal (far away from a general consensus) like others in the B table. Don't forget the traditional tags (e.g. highway, cycleway) like other examples. Don't forget that the page is mainly about "Bicycle", not mainly about "lanes". --Pieren 13:03, 3 May 2012 (BST)

It is not a proposal - it was already approved. See Lanes for the description and a link to the approved proposal. I'll add the other tags. --Imagic 15:04, 3 May 2012 (BST)
Well, the process of vote is very controversial in OSM project. 20 'yes' on a wiki do not say that a tag will be widely accepted. They are other proposals to tag lanes in details. Only time and contributors can say if this one will become the consensus. But my point was more about the main tags, anyway. --Pieren 15:24, 3 May 2012 (BST)
I fully agree with you, that the proposal process is somehow meaningless. But at least I expect it to "grant the right" to document it in the wiki. If it is used or not... only time will tell. As you see, I also added a note telling not to use the suffix if not needed. --Imagic 15:44, 3 May 2012 (BST)


Could you join us for discussion on Talk:Tag:highway=mini_roundabout#mini roundabouts which are not traversable, please? You probably have a point, we risk starting an edit war. Thanks! --achadwick 16:44, 10 May 2012 (BST)

Actually I don't join the discussion on purpose, because I don't want to start a personal war. Everything important is also told by others so I hope that reason succeeds. Although I'm afraid it will be a tough fight, because NE2 wants his tagging style approved, no matter if it causes problems or not. So I let the community decide. In the meanwhile I'll collect some photos for positive and negative examples of (mini)roundabouts. If the majority then agrees, I'll put those in the wiki. If not... well... the sun is shining outside so I guess I find something else to do ;-) --Imagic 17:13, 10 May 2012 (BST)

JOSM Style for Lanes Visualization

Screenshot JOSM Lanes Style with Lanes Tagging Scheme at Junction.jpg

I gave your style a chance to map some intersection of B 87, see the screenshot.

One thing I noticed is what seems to be an artificial shortcoming when placement=transition is used. As I understand it, a junction itself is all about transition, so it would be wrong to visualize lanes framed by bold white lines across one side to another. Using placement=transition on a segment however yields the impossibility to offset lanes, since it is intended to deduct a transition from pre- to post-connected way.

Consider the following two examples, in the first I may use a straight osm way and your style offsets the individual lanes nicely around it, placement=transition is not used. In the second one this will look ugly, since, for the transition segment, the three lanes will render centered around the osm way, instead of being offset like those in the pre-connected-way.

So a properly rendered transition segment will have to take the offset-values of pre- and post-connected ways into account, not just the in- or decrease of lane number count. Currently, if there are transition segments in between, the feature to offset lanes in a segment pre or post to the transition one, seems useless, since it does not connect well, visually. If there is a way to inherit the offset value from e.g. the pre-connected segment, the visual output might be more useful, I guess. Just a suggestion, though. Thanks for the work you put in already. --Cmuelle8 (talk) 16:20, 14 March 2013 (UTC)

First example (will render as shown):

 three lanes   # two lanes
---------------#--------------    <- this straight line 'holds' the OSM way, hash sign used to symbolize a node
 --->>          ______________

Second example (will not render like shown).  

 three lanes   # transition  # two lanes
---------------#-------------#--------------    <- this straight line 'holds' the OSM way
 --->>                       _______________

 1:2 (*)       # 1,5:1,5     #  1:1 (*)         <- offset values for segments

(*) denotes where placement effects offset
It is documented that the value transition is not supported by the style. This kind of computation can (currently) not be done within a JOSM style. The examples on the proposal page should make it clear what has to be done to properly support transition.
I was thinking for some optional(!) extra parameters for transition, something like transition(right_of:1,middle_of:2) but this makes tagging more complex (never a good idea), doesn't solve all problems and also can not be rendered within a style correctly. --Imagic (talk) 09:13, 26 March 2013 (UTC)
I can understand that placement=transition is too difficult to compute correctly, but what about supporting placement:start and placement:end? I could easily get the desired effect with those. StephenTX (talk) 16:29, 5 June 2017 (UTC)

change:lanes on not oneway roads

In the change:lanes proposal it says, that it is allowed to use change:lanes="no|no" for a road with two lanes (one for each direction), where all lane changes are forbidden. This seems not to be supported by your JOSM style.

Until now I used change:lanes:forward=no and change:lanes:backward=no instead, but because change:lanes="no|no" is easier and faster to tag, I ask you to add support for this version as well. Thank You. --Mapper999 (talk) 15:34, 4 February 2014 (UTC)

I would like to support this as I also prefer the short variant, but up to now I can't see how to do that in a style. The processing capabilities of a style are very, very limited. --Imagic (talk) 06:41, 5 February 2014 (UTC)
On the other hand: why not? If I restrict this to the simple case change:lanes=no|no it is easily done! I added it to the style, but currently I can not update the online version, because I already added some new code, which relies on the latest version of JOSM (6808 or newer). I'll have to wait with the update until the next tested-version of JOSM is released. If you want to test the style in the meantime I can send it to you. Thanks for your feedback! --Imagic (talk) 07:12, 5 February 2014 (UTC)
Thanks for adding it to the style. Seems to work already in JOSM 6767. --Mapper999 (talk) 21:44, 5 February 2014 (UTC)
Yes, I added it yesterday later on to the online version also. The necessary code is short and isolated therefore it was quite easy to extract it from my working version. However I did not much testing, so please let me know if you encounter any problems. Thanks. --Imagic (talk) 07:50, 6 February 2014 (UTC)

destination:forward and destination:backward are shown on wrong side

I found another possible bug: On ways which are tagged with destination:forward or destination:backward the name of the destination should be shown on the side of the road where the cars are driving (right-hand traffic: forward on the right and backward on the left, left-hand traffic the other way round). At the moment it's shown on the wrong side of the road. --Mapper999 (talk) 12:42, 22 February 2014 (UTC)

Well known: item 5 of "Known limitations/bugs". In my offline version this is already fixed, but it needs a "latest" build of JOSM and therefore I will release it in a few weeks. --Imagic (talk) 14:46, 22 February 2014 (UTC)
This is now fixed with the latest version of the style. Please provide feedback. --Imagic (talk) 09:40, 3 April 2014 (UTC)
Great. Thank you! I looked at the few places where I found the bug and it looks good now.
Thanks for testing and your feedback.
I also like that you evaluate destination sign relations as well now. Is it wanted that there's only the first destination shown for the non-relation (e.g. "DesA", but all the destinations for the relations (e.g. "DesA;DesB;DesC")?
Yes, it is wanted, otherwise I thought it would be too confusing. The support for destination_sign is just a quick and dirty hack.
Is it possible to show more than one relation on the same way and maybe the direction of the relation, or is this a technical limitation of josm? --Mapper999 (talk) 19:38, 4 April 2014 (UTC)
Technical limitation. And currently I don't see any possible solution for this. I'll talk to the JOSM devs when I got the time. --Imagic (talk) 11:29, 7 April 2014 (UTC)

Possible bugs in Lane and road attributes

Hello Imagic, I have found 2 possible bugs,

  • see In this cycleway, there are "hearts" to show the direction of the way, while in other ways this is shown with far more subtle arrows. I don't know if this is a bug or a feature.
  • see The only thing I changed from the previous is adding a sidewalk on the right side. Suddenly the way is interpreted as having 2 lanes, which happens to be the case here, but is not explicitly stated in the way's tags. Adding either oneway=yes or lanes=1 to the way is rendered with 1 lane (and a sidewalk). It is strange that a bike path (highway=cycleway) with no lane tags is rendered as a lane with your plugin, while a "car highway" (highway=unclassified,primary,secondary etc) is rendered the same with and without the paint style, i.e. as a thin line.

IIVQ (talk) 19:46, 31 October 2015 (UTC)

Support for destination:street

Would you mind handling destination:streets exactly the same way you handle the destination tag? I've been advised that freeway ramps leading to streets should be tagged with destination:street and not destination (see Zian (talk) 08:54, 12 November 2015 (UTC)


Thanks for the JOSM lanes style, I'm interested in seeing shoulder=* showing up somehow... I wasn't sure if I could submit a merge request somehow? Aharvey (talk) 06:37, 26 September 2019 (UTC)

Deutsche Wikiseite zum Fahrspur- und Straßenattribute MapPaint-Stil

Hi, ich habe den Wikitext deines Fahrspur- und Straßenattribute MapPaint-Stils auf deutsch übersetzt. Kannst ja nochmal drüber schauen, ob dir das so gefällt, oder ob du noch bessere Ideen für die Übersetzung hast. --Klumbumbus (talk) 14:07, 9 April 2014 (UTC)

Vielen Dank! --Imagic (talk) 14:16, 9 April 2014 (UTC)

Junction area

> Although I don't see a reason why this should only be used for named junctions. If - for any reason - one wants to group together all the elements of a junction, why not use an area with junction=junction_area without any additional tag?

Ja, da stimme ich zu. Der Vorschlag ist halt aus einem konkreten Problem heraus entstanden. Die Möglichkeit mit unbenannten Kreuzungen habe ich etwas später hinzugefügt und ist deshalb nicht so prominent platziert, aber durchaus im Vorschlag enthalten:

Zitat vorvorletzter Absatz:

The usage of the complex tagging scheme (areas) may also be useful without a name. Think of a routing/turn-to-turn navigation engige that can give instructions like “at the second crossroad turn to the right” or “at the fourth traffic signal turn to the left”.

Zitat Ende

Wenn der Vorschlag angenommen wird, würde ich natürlich auch die Nutzung ohne Name im Wiki dokumentieren.

Und ich dachte mir, dass ich alles gelesen hatte ;-) Perfekt, ich wünsche dir, dass das Proposal angenommen wird - wir brauchen endlich eine Lösung um Elemente einer Kreuzung zusammenzufassen. Danke! --Imagic (talk) 18:41, 28 September 2014 (UTC)

Icon für Lane and road attributes style

Hallo, ich habe ein Icon für den Kartenstil Lane_and_Road_Attributes erstellt: [1] (Lizenz: PD oder CC0, wie du willst)

Könntest du das bitte in den Stil unter meta { } integrieren, damit es in JOSM an den verschiedenen Stellen angezeigt wird?

icon: "";
Erledigt. Ich habe das Icon direkt in den Anhang mit den sonstigen Bildern gepackt. --Imagic (talk) 14:16, 1 October 2014 (UTC)
Danke. Bei mir erscheint das Icon zwar im Mappaintstil-Dialog auf der rechten Seite, aber nicht in der Toolbar, wenn ich den Stil dort ablege. Ich habe schon alle Cacheeinstellungen diesbzezüglich geleert und den Stil komplett neu hinzugefügt. Hat leider noch nicht geholfen. Hast du eine Idee, woran das liegen könnte? --Klumbumbus (talk) 15:53, 2 October 2014 (UTC)
Leider nein. Ich wusste bis vor kurzem nicht einmal, dass man ein Icon definieren kann. --Imagic (talk) 16:05, 2 October 2014 (UTC)
Habe ein ticket erstellt. --Klumbumbus (talk) 17:43, 5 October 2014 (UTC)
Fehler wurde behoben. --Klumbumbus (talk) 11:07, 7 October 2014 (UTC)
Danke für alles. --Imagic (talk) 11:13, 7 October 2014 (UTC)

turn:lanes - Spuren in Fahrtrichtung gesehen von links nach rechts kennzeichnen

Moin; danke für deine E-Mail. Ich bin da anderer Meinung und denke, dieser Fakt gehört ganz oben in die Einleitung, deswegen habe ich diese Bearbeitung auch vorgenommen. Aber prominent auf der Diskussionsseite reicht mir auch ... deswegen habe ich mal die Diskussionsseite zum Artikel angelegt mit entsprechender Überschrift. Das reicht (hoffentlich nicht nur für mich) zum Auffinden. Für mich geht da eindeutig Benutzerfreundlichkeit vor Logik. Selbst auf der englischen Seite steht diese Info zumindest etwas eher ... Gruß, Schusch -- Schusch (talk) 00:15, 13 December 2014 (UTC)


Hi, I don't see how a link to a redirect is more useful than links to definition of tags and subtags: [2]. Is it just because of the lanes tag? This can be fixed like this: change:lanes:backward=* --Jgpacker (talk) 12:49, 11 January 2015 (UTC)

Have you tried your links? Have a look at the old (and current) version here: old version with correct links
And now have a look at your version here: broken links
For example the first link: instead of one link to change:lanes=* you now have two links, one to change=* and one to lanes=*. The second one has nothing to do with change:lanes. --Imagic (talk) 15:26, 11 January 2015 (UTC)
They work exactly the way they are meant to work. As I suspected, the issue you see is about the current lack of compatibility between the key lanes=* and change:lanes=*. Have you tried the link I created in the beginning of this section? (hint: it's different than the one I put in the change:lanes page) --Jgpacker (talk) 15:53, 11 January 2015 (UTC)
The key "lanes" has absolutely nothing at all to do with a suffix. --Imagic (talk) 17:08, 11 January 2015 (UTC)
Yes, I already understood this before. Let me rephrase this. How about making the links like this?: change:lanes:backward=*, which is a more informative version than the way it is right now. --Jgpacker (talk) 17:20, 11 January 2015 (UTC)
Better, but still not correct. ":backward"also is not a key. If you want to link to the each part of the key, you would have to link to change=*, to Lanes and to Forward_&_backward,_left_&_right, --Imagic (talk) 17:46, 11 January 2015 (UTC)

Feature request: Duplicate display of psv / bicycle designated for motorcycle designated in JOSM Style for Lanes Visualization

Many thanks for this style.

Would it be possible to duplicate the code for psv / bicycle designated rendering (ie: motorcycle:lanes:forward=designated|yes?

Here is a use case: NSW Bus lanes, way 302595370

many thanks, Sam. Samuelrussell (talk) 02:58, 4 April 2016 (UTC)

Kartenstil: Fahrspur- und Straßenattribute - sidewalk ohne lanes

Ich finde den Stil sehr praktisch zum Bearbeiten von Straßenattributen, habe allerdings ein kleines Problem mit der Darstellung von kleineren Straßen in Wohngebieten.

Eine Angabe von sidewalk:* führt dazu, dass die Straße mit zwei Fahrspuren und einem Trennstreifen angezeigt wird. lässt sich der Stil vielleicht beim nächsten Update dahingehend anpassen, dass der Trennstreifen nur angezeigt wird, wenn lanes:* als key hinterlegt ist?

Auch wenn als Breitenbeschreibung zusätzlich zum sidewalk:* nur width:* festgelegt ist, werden zwei Fahrspuren angezeigt, selbst wenn keine Fahrbahnmarkierung vorliegt.

- EricPoehlsen (talk)

Lanes and Road Attributes mappaint style - Imperial units support


It appears your Lanes and Road Attributes mappaint style does not correctly support imperial units, such as width=30', as documented in Key:width. What renders with such usage is a tiny road segment of small width.

Can you look into this please? :) --Omgitsgela (talk) 19:17, 11 August 2018 (UTC)

Lane and Road Attributes: support for "cycleway=lane"


I am mapping cycleways here in the US, and in my area the predominant style is "cycleway=lane" rather than "cycleway=track". Looking at TagInfo, both are prevalent, and "lane" is more common (this holds for "cycleway:left" as well).

Could you add support for "lane" to the attributes? I made these changes in testing it myself, they are perhaps verbose but they worked:

› diff -u orig.mapcss Styles_Enhanced_Lane_and_Road_Attributes-style.mapcss                                                                                                                  
--- orig.mapcss	2019-11-05 13:54:42.203946963 -0800
+++ Styles_Enhanced_Lane_and_Road_Attributes-style.mapcss	2019-11-05 13:46:49.430392871 -0800
@@ -2307,9 +2307,9 @@
     /* Explicitely no cycletrack on the left side? */
     temp_allow_cycleway_left: eval((has_tag_key("cycleway:left") && (tag("cycleway:left")="no"))?false:prop(temp_allow_cycleway_left));
     /* Cycletrack on the left side */
-    temp_cycleway_left: eval(((has_tag_key(cycleway) && ((tag(cycleway)="track") && prop(temp_allow_cycleway_left))) ||
-                                (has_tag_key("cycleway:left") && (tag("cycleway:left")="track"))) ||
-                                (has_tag_key("cycleway:both") && (tag("cycleway:both")="track"))
+    temp_cycleway_left: eval(((has_tag_key(cycleway) && ((tag(cycleway)="track" || tag(cycleway)="lane") && prop(temp_allow_cycleway_left))) ||
+                                (has_tag_key("cycleway:left") && (tag("cycleway:left")="track" || tag("cycleway:left")="lane"))) ||
+                                (has_tag_key("cycleway:both") && (tag("cycleway:both")="track" || tag("cycleway:both)="lane"))
     /* Sidewalk on the left side? */
@@ -2329,9 +2329,9 @@
     /* Explicitely no cycletrack on the right side? */
     temp_allow_cycleway_right: eval((has_tag_key("cycleway:right") && (tag("cycleway:right")="no"))?false:prop(temp_allow_cycleway_right));
     /* Cycletrack on the right side */
-    temp_cycleway_right: eval(((has_tag_key(cycleway) && ((tag(cycleway)="track") && prop(temp_allow_cycleway_right))) ||
-                                (has_tag_key("cycleway:right") && (tag("cycleway:right")="track"))) ||
-                                (has_tag_key("cycleway:both") && (tag("cycleway:both")="track"))
+    temp_cycleway_right: eval(((has_tag_key(cycleway) && ((tag(cycleway)="track" || tag(cycleway)="lane") && prop(temp_allow_cycleway_right))) ||
+                                (has_tag_key("cycleway:right") && (tag("cycleway:right")="track" || tag("cycleway:right")="lane"))) ||
+                                (has_tag_key("cycleway:both") && (tag("cycleway:both")="track" || tag("cycleway:both")="lane"))
     /* Sidewalk on the right side? */

Parking lanes

Parking lane mockup.png

Hello! Thank you very much for writing the Lanes and road attributes JOSM map style, it has been a great help in mapping street lanes in my city! Are you still maintaining this style? Might I make a suggestion: to add support for parking:lane=*. I think it wouldn't have problems fitting with satellite imagery, since just as multilane road lane widths are roughly 2.5-3 m the world over, parking spaces everywhere seem to be roughly in the vicinity of 5 x 2 m. It would look much better than the current parking lanes map style, which is poorly visible in the mass of lines and colors surrounding the way's line when Lanes and road attributes map style is enabled. I have added a mockup of how the style might look. Looking forward to hearing from you! Rostaman (talk) 03:04, 13 September 2020 (UTC)