[Tagging] Feature Proposal - Voting - Language information - Closed

that could reliably and correctly provide these informations in OSM, and I would love to see if one day in the future this might be implemented in OSM… -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - Evacuation Route

As key:evacuation_route is currently almost exclusively used on relations anyway, it might make more sense to deprecate this tag and instead define a new value for route=* on type=route relations (and than add all the refinements that you propose)… -- Lukas Sommer

Re: [Tagging] Elevation in Feet as part of Peak Names

The wiki page for https://wiki.openstreetmap.org/wiki/Key:ele says it has to be in meters, not in feets. -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] phone validity - phone "preset"

gt; The aim is not to forbid some values but to allow > common editor to guide the user to avoid a very common error. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - (Language information)

Voting at https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information is open. -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] (no subject)

to ask questions if things are unclear! Best regards -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Language information for name

better, more detailed, what missing language information means for Unicode text strings, and how an example use case could look like. However, it will take some time until the new proposal will be ready… 2017-05-23 18:02 GMT, Lukas Sommer <sommer...@gmail.com>: > There haven’t bee

[Tagging] Feature Proposal - Voting - Language information for name

There haven’t been further suggestionsn in the last time. So now voting is open for “Language information for name” at https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name -- Lukas Sommer ___ Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Language information for name

This is still in RFC phase. Current state after discussion at the Wiki talk page is using name:language (similiar structure like the yet existing name:left and name:right) as key. Lukas 2017-05-05 11:51 GMT, Lukas Sommer <sommer...@gmail.com>: > Feature Proposal - RFC - Language in

[Tagging] Feature Proposal - RFC - Language information for name

are unclear! Best regards -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Straw pole Temperature=objective default unit?

are messy. Unless the API starts validating entries, entries will vary in format, even if we officially say that 46 C is the official format. But software can parse and normalize numbers. That said: temperature=___ is a problematic tag regardless of the formatting of the data. -- Lukas

Re: [Tagging] For your comment: New template: Unit summary

It's not a contradiction, it's a proposal. So please move it to the “Proposal/” namespace. 2015-04-03 8:01 GMT, Lukas Sommer sommer...@gmail.com: The default unit is _not_ always “meters”. There are tags where the default unit is “meters” (e. g. width) and there are others where the default

Re: [Tagging] For your comment: New template: Unit summary

, this seems to be the most pragmatic approach. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging

Re: [Tagging] For your comment: New template: Unit summary

-03 9:16 GMT, Lukas Sommer sommer...@gmail.com: So please move it to the “Proposal/” namespace. That's not possible for a working template, Note the template is not USED, And it should also not be used, because it’s just your personal proposal for a discussion. So there is no need to have

Re: [Tagging] For your comment: New template: Unit summary

of existing tags have a summary of the Map_Features/Units embedded on their own pages. That's a good thing for tl;dr readers. -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] For your comment: New template: Unit summary

the part about distances (and not the part about weight). But dropping the rest of the content makes things confusing. 2015-04-03 9:25 GMT, Lukas Sommer sommer...@gmail.com: I'd ask the following be excluded ? cm (used in the clothing and foot ware trades ..not an OSM thing ) cubits I don’t

Re: [Tagging] probable tag

%3Dconstruction -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuel shops

neighborhood: https://commons.wikimedia.org/wiki/File%3ABarreled_fuel_shop.jpg -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] Smoothness possible values, straw poll.

So - I am against any of proposed changes. +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - traffic signals set

Hello. In the discussion about the proposal about type=traffic_signals_group it was suggested to use the term “set” instead of “group”. So I’ve adapted the wiki page of the proposal and I’ve moved it to http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_set -- Lukas Sommer

Re: [Tagging] Leaf type of palm for leaf_type

Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Leaf type of palm for leaf_type

and broadleaved. Mappers are mapping palms very frequently, and having this key name I think would reduce confusion. -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

this? May be a different name for this 'group'? Such as ? traffic signals set? On 26/02/2015 8:59 AM, Lukas Sommer wrote: Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17

[Tagging] Feature Proposal - RFC - (traffic signals group)

Hello. This is a request for comments for the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group The original author is Sanderd17. With the consent of him, I did some supplementing. Thanks to Sanerd17! Unlike the proposal “Proposed features/Traffic Signals” of

Re: [Tagging] building=yes on nodes?

, it is often necessary in HOT aerial mapping when we have low-resolution imagery to work from. Agree. As for the Wiki editing, I too hope it doesn't lead to a storm. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com -- Lukas Sommer

Re: [Tagging] building=yes on nodes?

https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] building=yes on nodes?

here. Wouldn’t it be more useful to have to have the same rules for _all_ values of the key “building=*”? -- Lukas Sommer PS: By the way: In the german wiki, most pages for the individual values do _not_ allow usage on nodes. ___ Tagging mailing list

Re: [Tagging] Tagging Digest, Vol 65, Issue 47

is only possible when you have the agreement of all these who votes with “yes” so far. As in the meantime more people have voted, that get’s complicate … Best regards Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

I know that I’m a little late with this comment – I missed this while reading the proposal. Sorry. Maybe that’s something that can be changed in the prososal – if current voters agree? 2015-02-09 17:29 GMT, Lukas Sommer sommer...@gmail.com: I would strongly recommend to not use type

Re: [Tagging] courtyards

/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - temperature

normal live. So I think it’s important to have a clearly defined default unit, and this default unit should be °C. Nevertheless, I think it is a good idea to encourage people to tag “with” the unit. Lukas Sommer 2015-02-05 0:53 GMT+00:00 Dave Swarthout daveswarth...@gmail.com: For clarification

Re: [Tagging] Feature Proposal - RFC - traffic_signals (Lukas Schaus)

be better for traffic signal systems. Currently, I tend to come up with a proposal for a relation for traffic signal system names – which would not interfer with Lukas Schaus’ proposal. @Javbw Do you have some feedback from the japanese community? What do they think about the usage of a relation? Lukas

Re: [Tagging] patron saints

I think this can be a useful new tag. And I think it makes sense to define explicitly some things in the documentation. Things like – use always (or use never) “Saint”: “Saint Paul” vs “Paul”. – write the name of the dedication always in the local language (Or always in latin? Could become very

Re: [Tagging] waterway=wadi problem

No! Flood prone means that they are expected to be flooded from time to time. Nothing about the design. So you would have to tag also each wadi, each river and each lake because this area is covered with water? Maybe the terms “designed” and “expected” are missleading. But the question is: How

Re: [Tagging] waterway=wadi problem

. Lukas Sommer 2015-01-20 4:09 GMT+00:00 johnw jo...@mac.com: I think using flood_prone on places designed to handle water (like a ford) is incorrect. The sections of a freeway that are closed off during flooding (a lane is closed because storm waters cannot properly drain away, or cuttings

Re: [Tagging] Feature Proposal - RFC - Cluster

What you propose is an algorithm that does a sort of “guess”. For doing some sort of guess, we don’t need to introduce a new relation. That could be done also without a relation. Introducing a new relation should lead to better data and more well-structured information. There should be a certain

Re: [Tagging] Tag destination vs. relation destination_sign

I’ll wait until monday with the change … Lukas Sommer 2015-01-16 12:35 GMT+00:00 fly lowfligh...@googlemail.com: Am 16.01.2015 um 09:31 schrieb Martin Vonwald: 2015-01-15 22:12 GMT+01:00 fly lowfligh...@googlemail.com mailto:lowfligh...@googlemail.com: Please, do not forget to mention

Re: [Tagging] Tag destination vs. relation destination_sign

signposts for being confusing. Thoughts? Lukas Sommer 2015-01-11 15:48 GMT+00:00 Martin Vonwald imagic@gmail.com: 2015-01-10 19:40 GMT+01:00 Lukas Sommer sommer...@gmail.com: +1. Key:destination for the simple cases the the relation for the complex cases seems fine for me. I'll wait until

Re: [Tagging] Power networks European codification scheme

not a direct EU instituion – and also some non-EU countries like Macedonia are members). Cheers Lukas Lukas Sommer 2015-01-15 10:08 GMT+00:00 François Lacombe fl.infosrese...@gmail.com: Hi Friedrich, Ok for the upper case. I would prefer ref:eu:eic since I'm not sure entsoe isn't used in any

Re: [Tagging] Tag destination vs. relation destination_sign

. If this is correct, the examples with the yellow and white signposts on the wiki page are confusing (tagging a motorway_link makes no sense here), and I would recommand to remove these three examples. Lukas Sommer 2015-01-10 17:40 GMT+01:00 Marc Gemis marc.ge...@gmail.com: I've asked this question

Re: [Tagging] Adding water=fishpond to the wiki

But we have also yet an existing tag water=pond for ponds. We would have to change the defination for this tag from “a pond” to “a pond – but not if this is a pond that serves for fishing” – sounds complicate … Lukas Sommer 2015-01-04 20:20 GMT+01:00 Janko Mihelić jan...@gmail.com: 2015-01-04

[Tagging] Cleanup flood tagging

related floods? – Only supplementary tagging of highway=*? Or independent OSM elements (areas)? Or both? Probably both makes sense. Suggestions? Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo

Re: [Tagging] Cleanup flood tagging

PS: About 57% of the key “flood_prone” is “flood_prone=yes”. About 42% of the key “flood_prone” is “flood_prone=no”. About 80% of the elements with the flood_prone key are in 15 km × 15 km area in Jakarta. Lukas Sommer 2014-12-28 20:32 GMT+01:00 Lukas Sommer sommer...@gmail.com: Hello. In OSM

Re: [Tagging] Adding values to usage=* key for power transmission

Maybe we could use a key with a namespace: “power:usage=*” or something else. Keeping is separate from the railway usage could give us more clairity. Lukas Sommer 2014-11-24 15:24 GMT+00:00 François Lacombe fl.infosrese...@gmail.com: Hi Rainer and thank you. I didn't spend time yet

Re: [Tagging] Adding values to usage=* key for power transmission

for this. cu Lukas Sommer 2014-12-01 23:38 GMT+00:00 François Lacombe fl.infosrese...@gmail.com: Hi Lukas, I don't like this : railway guys introduced usage without any namespace. Why should power introduce one ? usage=* is a common tag. The proposal isn't introducing power:location instead

Re: [Tagging] Various alt_name values?

Or would it be better – if a consens is difficult – to wait until a general resolution for the problem “one key with more than one value” has come up? Lukas Sommer 2014-11-29 5:03 GMT+00:00 Brian Quinion openstreet...@brian.quinion.co.uk: On 29 Nov 2014 00:26, Lukas Sommer sommer...@gmail.com

Re: [Tagging] Various alt_name values?

: ask software to stop using the not-accepted solution. Thoughts? Lukas Sommer 2014-11-27 15:21 GMT+00:00 Erik Johansson erjo...@gmail.com: On Wed, Nov 26, 2014 at 6:23 PM, Brian Quinion openstreet...@brian.quinion.co.uk wrote: On 25 November 2014 at 13:30, althio forum althio.fo...@gmail.com

Re: [Tagging] Various alt_name values?

Okay, so I would place a hint at the corresponding wiki page … Lukas Sommer 2014-11-23 18:46 GMT+00:00 Zecke z...@saeuferleber.de: Am 23.11.2014 18:20, schrieb Lukas Sommer: Would a feature proposal be a good way to get there? No need to do so. The semi-colon is the accepted way

[Tagging] Various alt_name values?

“alt_name_1=name1”+“alt_name_2=name2”. However, the discussion didn’t lead to something “official”. I think it could be useful to have a clear documentation on the wiki about which solution is the preferred one. Would a feature proposal be a good way to get there? Lukas Sommer PS: Me to, I would prefer

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions

We have finally 12 votes: 11 times “yes” and 1 time “no”. I think this could be considered as approved … Lukas Lukas Sommer 2014-11-02 7:57 GMT+00:00 Lukas Sommer sommer...@gmail.com: Hello. After commenting period, now is starting the voting for the junction (only) tagging at https

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions

Just as a reminder: Voting is still open at https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions Lukas Lukas Sommer 2014-11-02 7:57 GMT+00:00 Lukas Sommer sommer...@gmail.com: Hello. After commenting period, now is starting the voting for the junction (only

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions

The proposal is only about allow “junction=yes” on areas. All other stuff stays without changes. Lukas Sommer 2014-11-11 12:08 GMT+00:00 Richard Z. ricoz@gmail.com: On Tue, Nov 11, 2014 at 11:08:56AM +, Lukas Sommer wrote: Just as a reminder: Voting is still open at https

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions

this as area. Lukas Lukas Sommer 2014-11-11 13:51 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-11-11 14:45 GMT+01:00 Lukas Sommer sommer...@gmail.com: The proposal is only about allow “junction=yes” on areas. All other stuff stays without changes. Would you mind explaining

[Tagging] Feature Proposal - Voting - Tagging for complex junctions

Hello. After commenting period, now is starting the voting for the junction (only) tagging at https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] RFC Tagging for complex junctions

for the simple sections and move the existing nodes with junction=yes to highway=junction. However, I’m open for both solutions… Lukas Lukas Sommer 2014-10-21 16:00 GMT+00:00 fly lowfligh...@googlemail.com: Am 18.10.2014 08:45, schrieb Lukas Sommer: Hello. The combined proposal

[Tagging] RFC Tagging for complex junctions

://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions which takes into account the comments which have been made during the previous voting. Best regards Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Okay, we have 9 votes: - 5 times approve - 3 times oppose - 1 time obstain I suppose this is not enough? Lukas Sommer 2014-09-28 14:48 GMT+00:00 Lukas Sommer sommer...@gmail.com: Hello. After discussion and some modifications of the proposal, here a request for voting on “Tagging

Re: [Tagging] man_made=bridge

I like this proposal. I would add the requirement that the highways/railways/paths that go over a bridge have to share a node with the outline area. Lukas Sommer 2014-10-10 14:44 GMT+00:00 Mateusz Konieczny matkoni...@gmail.com: man_made=bridge as proposed on http://wiki.openstreetmap.org

Re: [Tagging] man_made=bridge

Second sentence in the section Tagging - Bridges with one level: Connect all OSM ways running over that bridge to the outline. Sorry, I missed this. Perfect! Lukas Lukas Sommer 2014-10-13 10:34 GMT+00:00 Martin Vonwald imagic@gmail.com: Hi! 2014-10-13 12:12 GMT+02:00 Lukas Sommer

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Hello all. At https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named there is still a proposal for complex junctions and traffic signal systems in voting process. Participation is appreciated ;-) Regards Lukas Lukas Sommer 2014-09

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Oh, sorry, Pieren was faster… ;-) Lukas Sommer 2014-09-30 12:34 GMT+00:00 Lukas Sommer sommer...@gmail.com: If there is a need to tag traffic signal names and junction names on the same node, then the logical solution is junction:name=* and traffic_signals:name=*. Or in different languages

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

What would also be no problem, because you can give an individual name=* tag to each node with highway=traffic_signals and another name=* tag to the area. Lukas Sommer 2014-09-30 18:56 GMT+00:00 fly lowfligh...@googlemail.com: Am 30.09.2014 14:34, schrieb Lukas Sommer: If there is a need

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Can you please provide examples how to draw area for more complicated junctions? https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named Lukas Sommer 2014-09-29 3:14 GMT+00:00 Никита acr...@gmail.com: Not enough examples, I cannot

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

when we distinguish between th:junction_area and kr:junction_area - because here we have two values for the same feature. While the tagging has a certain focus on some asian countries, I would prefer to keep this country-independent. Lukas Sommer 2014-09-29 21:37 GMT+00:00 Никита acr...@gmail.com

[Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

. Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Oh, sorry, I missed this: https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named Lukas Sommer 2014-09-28 20:47 GMT+00:00 Mateusz Konieczny matkoni...@gmail.com: A link is missing. 2014-09-28 16:48 GMT+02:00 Lukas Sommer sommer

Re: [Tagging] Understanding links

to the mapper to decide) Example: If the main road is secondary, the frontage road must be one of “tertiary” or “unclassified” or “residential”. Could this be a useful guide? Lukas Sommer 2014-09-23 7:23 GMT+00:00 Satoshi IIDA nyamp...@gmail.com: If you got any communication loss during

Re: [Tagging] Understanding links

There is not much documentation on the wiki. The only thing that I found was a statement at http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice that says that highway=service is wrong, but everything else is okay. highway=service service=alley sounds really good to me - parallel to

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

No tags on the shared nodes - just shared nodes. What is IMHO a quite bad idea for two reasons: – It’s unlikely that there will be software supporting features when there is no tag. – You would introduce a concurrent solution to a node highway=traffic_signals. I do not think that it’s a good

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

So the nodes where the signals_area intersects the highways is where the signals would normally be mapped for complex intersections? Not exactly. It would be difficult to do so if you have really complex junctions with really many individual traffic signals and you want to catch all of them – a

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

with the walkways and other pedestrian oriented ways, as the signal would be part of their routing as well. Here, I agree. I assumed that people would do so automatically, but I’ll also add it on the wiki page. Lukas Sommer 2014-09-21 21:30 GMT+00:00 John Willis jo...@mac.com: It should be pretty

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

to _not_ tag the individual traffic signals for Japan. As described in the proposal, the area is simply drawn around the approximative area that is affected by the traffic signals. It encloses everything, but shares nodes only with the incoming and outgoing highways. Lukas Sommer 2014-09-20 16:45

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

Differentiated tagging is needed for differentiated rendering. junction vs Signal. a single signal icon needs to be rendered in Japan for intersections. But that is yet working perfectly with the current tagging! In Korea, we have yet thousands of nodes with junction=yes and name=*, and

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea and the existing highway=traffic_signals in Japan – just not only on nodes but extending it also also on closed ways (=areas) – should be fine. Okay, here I have to correct myself. It may be

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

not traffic_signals=* which seems to have either another meaning – highway=traffic_signal_system_area (quite long)? Lukas Sommer 2014-09-19 18:27 GMT+00:00 Lukas Sommer sommer...@gmail.com: Again, I do not see the point in introducing here a new tag. Using the existing junction=yes in Korea

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

, which can be practical. Means: Korea: – simple: junction=yes – complex: junction=junction_area Japan: – simple: highway=traffic_signals – complex: highway=traffic_signals_area I’ve updated the proposal page on the wiki. Lukas Sommer 2014-09-19 18:32 GMT+00:00 Lukas Sommer sommer...@gmail.com

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

So far, highway=traffic_signal is only defined for nodes and there are only few ways and fewer relations. Correct. Also in favour of separation I would prefer to use junction=* with name=* and only highway=traffic_signal with name if it is only a single light (e.g. the case with a named

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

=traffic_signals would also be problematic because in Japan you can have named traffic signals on straight road, for pedestrian crossing , and there is not any road junction. Lukas Lukas Sommer 2014-09-18 19:31 GMT+00:00 fly lowfligh...@googlemail.com: Am 18.09.2014 21:29, schrieb fly: Am

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

Would it not be more straight forward to use junction=traffic_signal in Japan and only use highway=traffic_signal for the real lights ? Hm, I’m not sure. It could separete clearly the individual traffic signals from the traffic signal system/the covered area. The downside would be that we

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

how do you tag a named junction with a traffic signal ? highway=traffic_signal + junction=yes + name=* means that name is for the junction or for the traffic signals ? For the junction! For a named junction with a (not named) traffic signal: junction=yes + highway=traffic_signals. (Quite

Re: [Tagging] English translations in non-english countries

Okay, I’ve tried to update the old wiki pages (multilanguage names etc.) Lukas Sommer 2014-09-15 10:47 GMT+00:00 johnw jo...@mac.com: Missed that in August. Great to see it is being discussed at any level. On Sep 14, 2014, at 12:21 AM, Satoshi IIDA nyamp...@gmail.com wrote: wow! https

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

Okay, I’ve tried to work out more in detail idea 4. Please considere https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named and make comments. Lukas Sommer 2014-09-02 4:50 GMT+00:00 Satoshi IIDA nyamp...@gmail.com: Hello from

Re: [Tagging] key:destination Signpost question

would volonteer to do so.) Lukas Lukas Sommer 2014-08-30 2:33 GMT+00:00 Paul Johnson ba...@ursamundi.org: On Fri, Aug 29, 2014 at 6:55 PM, Tobias Knerr o...@tobias-knerr.de wrote: On 29.08.2014 21:16, Paul Johnson wrote: Destinations are supposed to be relations, and the members are pretty

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

that this is very time-consuming ;-) Best regards Lukas Sommer 2014-08-25 15:21 GMT+00:00 Simon Poole si...@poole.ch: Am 25.08.2014 16:46, schrieb fly: . Did you have a look at the three existing proposals about complex junctions ? .. IMHO one of the nice aspects

[Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

. Particularly if you are mapping in one of the concerned countries please participate at the discussion at http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named Lukas Sommer ___ Tagging

[Tagging] How to tag road junction names and traffic signal names?

a clean and reliable tagging here, which is suitable for rendering and turn-to-turn navigation? Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag road junction names and traffic signal names?

is difficult for turn-to-turn navigation software. So, how can we solve this? Lukas Sommer 2014-07-24 15:29 GMT+00:00 Christian Quest cqu...@openstreetmap.fr: Have you looked at http://wiki.openstreetmap.org/wiki/Key%3Ajunction *junction*=yes http://wiki.openstreetmap.org/wiki/Tag:junction

Re: [Tagging] How to tag road junction names and traffic signal names?

the “name” tag in the relation and the nodes where the ways cross as members in the relation. – Could we maybe simply draw an area around the junction, sharing nodes with the incoming/outgoing ways? Less clean than a relation, but easier to use. Lukas Sommer 2014-07-24 16:07 GMT+00:00 Dan S

Re: [Tagging] tagging of a throughabout

Thanks for the clarification! 2014-06-30 9:11 GMT, Martin Koppenhoefer dieterdre...@gmail.com: 2014-06-29 19:11 GMT+02:00 Lukas Sommer sommer...@gmail.com: How do I tag correct a Hamburger roundabout/throughabout/cut-through (see http://en.wikipedia.org/wiki/Roundabout#Hamburger_roundabout

[Tagging] tagging of a throughabout

where appropriate). Am I right? Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging