User talk:Imagic

Bicycle

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)

Mini-roundabout

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

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 https://dl.dropboxusercontent.com/u/240848/OSM/Cycleway1.png 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 https://dl.dropboxusercontent.com/u/240848/OSM/Cycleway2.png 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 http://wiki.openstreetmap.org/wiki/Talk:Exit_Info#Simpler_Exits). Zian (talk) 08:54, 12 November 2015 (UTC)

Key:shoulder

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)

Key:width

I see you support width:lanes=* however width=* should also be supported, where there is no shoulder and all the lanes are the same width then specifying the width of each individual lane is not that helpful over just specifying the carriageway width. --Aharvey (talk) 07:28, 7 May 2022 (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: "josm.openstreetmap.de/raw-attachment/wiki/Styles/Lane_and_Road_Attributes/icon.png";

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)

Key:change

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

Greetings,

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"

Hello,

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

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)

Upload

Hello! And thanks for your upload - but some extra info is necessary.

What is the source of https://wiki.openstreetmap.org/wiki/File:Simpleuklanes_middle.jpg ? Which imagery?

Which license is used by this imagery?

Mateusz Konieczny (talk) 06:16, 7 October 2021 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the author of image File:Alternating driving directions on four lanes.png ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ".

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self}} to publish under CC-BY-SA-4.0 license.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

Once you add missing data - please remove {{Unknown|subcategory=uploader notified January 2022}} from the file page.

--Mateusz Konieczny (talk) 10:35, 26 January 2022 (UTC)

aerial imagery not specified

Which aerial imagery was used for https://wiki.openstreetmap.org/wiki/File:Placement_Transition.jpeg image? Mateusz Konieczny (talk) 08:57, 4 March 2022 (UTC)

And https://wiki.openstreetmap.org/wiki/File:Simpleuklanes_middle.jpg ? Mateusz Konieczny (talk) 14:23, 30 July 2022 (UTC)

The same for https://wiki.openstreetmap.org/wiki/File:Both_Ways_Example_1.jpeg - which aerial imagery was used there? Mateusz Konieczny (talk) 14:26, 30 July 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Rautenweg Current.jpeg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you (except relatively rare cases) author can make it available under a specific free license.

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|Imagic}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, May}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 21:04, 30 May 2022 (UTC)