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

2017-09-13 Thread Lukas Sommer
Hello.

The feature proposal for language information did not get enough
support. Voting is over. The proposal is closed as “rejected”.

The reasons for negative vote were various and did not go in only one
direction. I do not know how these different positons can be
reconciled. So I will do no further proposals.

Anyway this remains an issue in OSM: Rendering OSM data currently does
not work correctly for labels that are affected by Han unification
(and, to a minor degree, cyrillic). With much more than 1 billion
people living in the affected region of the world, I think this is a
really big issue. For correct rendering, you need two additional
informations for text labels:

1.) The language
2.) The script (only for Han)

BCP-47 combined both, but there might be other possibilities to
provide this information.

I would appreciate it a lot if someone else proposes a good solution
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/listinfo/tagging


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

2017-09-08 Thread Lukas Sommer
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

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


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

2017-09-08 Thread Lukas Sommer
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"

2017-09-05 Thread Lukas Sommer
It would likely yet help a lot if th editors would simply check if

- the number does not start with “+”
- the number (after the starting “+” sign) contains other characters
then digits, spaces (and maybe dashes).

This is quite simple and could nevertheless catch yet a lot of issues…

2017-09-05 16:51 GMT, marc marc <marc_marc_...@hotmail.com>:
> Hello,
>
> on the french-speaking mailing, a contributor noticed a high rate
> of incorrect value for the tag "phone". the most common error is using
> the national format number instead of the international format.
>
> A monthly project 'll maybe fix some of those errors.
> Some quality tool can help those fix.
>
> But the best would be to avoid the mistake when a user fill
> in the data in iD, josm or whatever.
>
> Is anyone aware of a kind of "preset" that can be used for phone ?
> Otherwise it would be useful to create with local communities a wiki
> page containing a list of valid prefixes example + 322xxx is valid,
> +331 also but 01 is not valid in France.
> Or using something like https://github.com/googlei18n/libphonenumber/
> https://github.com/googlei18n/libphonenumber/blob/master/FAQ.md#where-do-we-get-information-from-to-determine-if-a-number-range-is-valid
>
> Would it also be useful to put a corrective suggestion?
> for example 01 #+331
>
> Of course, I am not talking about the exact form of the list,
> nor the fact that some countries will have a list,
> while others not.
> nor the difficulty when a poi has several corresponding numbers
> attached several countries.
> I 'm talking about the general guideline.
>
> 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)

2017-08-30 Thread Lukas Sommer
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)

2017-08-05 Thread Lukas Sommer
Feature Proposal - RFC - Language information

URL: https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information

Definition: Describes the language of the text

I’ve tried to make a clearer proposal and avoid some confusions that
were discussed in the previous proposal.

Feel free 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

2017-06-07 Thread Lukas Sommer
Voting is over. 57% yes. I’ll try to make a different, better
proposal. One thing that has come up the the voting comments was about
the key that has been choosen. Rjw62 has proposed to use raither
language:name= and that seems reasonable also to me. In the
new proposal I’ll try also to explain 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 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
>


-- 
Lukas Sommer

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


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

2017-05-23 Thread Lukas Sommer
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2017-05-15 Thread Lukas Sommer
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 information for name
>
> URL:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name
>
> Definition: Describes the language in which the value name=* is (using
> the same code as Multilingual names).
>
> Feel free to ask questions if things are unclear!
>
> Best regards
>
> --
> Lukas Sommer
>


-- 
Lukas Sommer

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


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

2017-05-05 Thread Lukas Sommer
Feature Proposal - RFC - Language information for name

URL: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name

Definition: Describes the language in which the value name=* is (using
the same code as Multilingual names).

Feel free 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] Straw pole Temperature=objective default unit?

2015-04-09 Thread Lukas Sommer
 b) values would interpreted by region. Most of the world would be Celsius, 
 USA would be Fahrenheit. (Similar to defaults for speed on roads.)

Please note that speed limits are _not_ interpreted by regions.
http://wiki.openstreetmap.org/wiki/Key:maxspeed states that the unit
has to be added explicitly when it’s not km/h – independent of the
region where you are mapping.

Region-dependent interpretation of units is IMHO a quite bad idea.

2015-04-09 5:41 GMT, Bryce Nesbitt bry...@obviously.com:
 How it's entered into the database, and how it's displayed, are two
 separate things.  Humans 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 Sommer

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


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

2015-04-03 Thread Lukas Sommer
 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 unit is “kilometers” (e. g. distance).

 “Centimeters” isn’t in the current list of accepted units at
 http://wiki.openstreetmap.org/wiki/Map_Features/Units.

 A wide variety of formats are acceptable:

 The list that is following this statement doesn’t contain “km”. It
 seems to be only a list of some non-mandatory examples. So the
 statement sound like it’s up to the mapper to choose whatever unit he
 likes (and software has to find its way to deal with this situation).
 And that’s a very bad idea. We need a _defined_ list of accepted
 units. The worst thing we can do is promote that everybody uses
 whatever unit (and abbriviation) he wants. Map_Features/Units has such
 a list, and I see no reason to invalidate this.

 I think this template should or be deleted or be changed to reflect
 exactly what Map_Features/Units says. (But probably even a direct link
 to Map_Features/Units would be easier and clearer – so I don’t see any
 need for this template.)


 2015-04-03 6:49 GMT, Martin Vonwald imagic@gmail.com:
 This contradicts in many cases our current page
 http://wiki.openstreetmap.org/wiki/Map_Features/Units
 * The use of meters is discouraged
 * cm should not be used generally, maybe only on some specific tags
 * There should always be a space in front of the unit
 * Neither feet nor inches should be used, use feet'inch instead
 * It is not discouraged to not include the default unit

 regards,
 Martin




 2015-04-03 7:21 GMT+02:00 Bryce Nesbitt bry...@obviously.com:

 To try and make unit description consistent here is a proposed template.
 This would apply to tags like ele, est_width, circumference, height,
 width, maxwidth, minwidth, distance.  A separate table could be made for
 speed  weight.

 Use as follows:
 {{Unit_Tagging_Length|tag_name|furlongs}}

 The template is defined at:
 http://wiki.openstreetmap.org/wiki/Template:Unit_Tagging_Length

 Other unit pages include:
 http://wiki.openstreetmap.org/wiki/Category:Units

 --
 This particular summary promotes the notion of human centred tagging,
 with parsers left to make conversion to computer readable units.  It
 also
 promotes explicit numbers (e.g. 20 m) over implicit ones ( e.g. 20 ).
 Given the variety of unit styles already in the database, this seems to
 be
 the most pragmatic approach.

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





 --
 Lukas Sommer



-- 
Lukas Sommer

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


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

2015-04-03 Thread Lukas Sommer
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 unit is “kilometers” (e. g. distance).

“Centimeters” isn’t in the current list of accepted units at
http://wiki.openstreetmap.org/wiki/Map_Features/Units.

 A wide variety of formats are acceptable:

The list that is following this statement doesn’t contain “km”. It
seems to be only a list of some non-mandatory examples. So the
statement sound like it’s up to the mapper to choose whatever unit he
likes (and software has to find its way to deal with this situation).
And that’s a very bad idea. We need a _defined_ list of accepted
units. The worst thing we can do is promote that everybody uses
whatever unit (and abbriviation) he wants. Map_Features/Units has such
a list, and I see no reason to invalidate this.

I think this template should or be deleted or be changed to reflect
exactly what Map_Features/Units says. (But probably even a direct link
to Map_Features/Units would be easier and clearer – so I don’t see any
need for this template.)


2015-04-03 6:49 GMT, Martin Vonwald imagic@gmail.com:
 This contradicts in many cases our current page
 http://wiki.openstreetmap.org/wiki/Map_Features/Units
 * The use of meters is discouraged
 * cm should not be used generally, maybe only on some specific tags
 * There should always be a space in front of the unit
 * Neither feet nor inches should be used, use feet'inch instead
 * It is not discouraged to not include the default unit

 regards,
 Martin




 2015-04-03 7:21 GMT+02:00 Bryce Nesbitt bry...@obviously.com:

 To try and make unit description consistent here is a proposed template.
 This would apply to tags like ele, est_width, circumference, height,
 width, maxwidth, minwidth, distance.  A separate table could be made for
 speed  weight.

 Use as follows:
 {{Unit_Tagging_Length|tag_name|furlongs}}

 The template is defined at:
 http://wiki.openstreetmap.org/wiki/Template:Unit_Tagging_Length

 Other unit pages include:
 http://wiki.openstreetmap.org/wiki/Category:Units

 --
 This particular summary promotes the notion of human centred tagging,
 with parsers left to make conversion to computer readable units.  It also
 promotes explicit numbers (e.g. 20 m) over implicit ones ( e.g. 20 ).
 Given the variety of unit styles already in the database, 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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2015-04-03 Thread Lukas Sommer
 I'd ask the following be excluded ?
 cm (used in the clothing and foot ware trades ..not an OSM thing )
 cubits

I don’t think that there is a need to “exclude” some values (and
“allow” anything else). Insteat, I think there is a need to “allow”
some values (and exclude anything else).

2015-04-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 a working
 template. So please move it to the “Proposal/” namespace.

 2015-04-03 8:51 GMT, Bryce Nesbitt bry...@obviously.com:
 On Fri, Apr 3, 2015 at 1:25 AM, Martin Vonwald imagic@gmail.com
 wrote:

 +1 for the deletion (or at least move it to the proposal namespace). A
 simply direct link to Map_Features/Units should be enough.


 The majority 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



-- 
Lukas Sommer

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


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

2015-04-03 Thread Lukas Sommer
 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 a working
template. So please move it to the “Proposal/” namespace.

2015-04-03 8:51 GMT, Bryce Nesbitt bry...@obviously.com:
 On Fri, Apr 3, 2015 at 1:25 AM, Martin Vonwald imagic@gmail.com
 wrote:

 +1 for the deletion (or at least move it to the proposal namespace). A
 simply direct link to Map_Features/Units should be enough.


 The majority 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

2015-04-03 Thread Lukas Sommer
 The majority 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.

Map_Features/Units isn’t a big wiki page. It’s really short (3
sentences and some tables). Maybe for keys like “width” it could be
usefull to have only 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 think that there is a need to “exclude” some values (and
 “allow” anything else). Insteat, I think there is a need to “allow”
 some values (and exclude anything else).

 2015-04-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 a working
 template. So please move it to the “Proposal/” namespace.

 2015-04-03 8:51 GMT, Bryce Nesbitt bry...@obviously.com:
 On Fri, Apr 3, 2015 at 1:25 AM, Martin Vonwald imagic@gmail.com
 wrote:

 +1 for the deletion (or at least move it to the proposal namespace). A
 simply direct link to Map_Features/Units should be enough.


 The majority 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



 --
 Lukas Sommer



-- 
Lukas Sommer

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


Re: [Tagging] probable tag

2015-03-29 Thread Lukas Sommer
Use http://wiki.openstreetmap.org/wiki/Key:proposed

2015-03-29 1:38 GMT, Bryce Nesbitt bry...@obviously.com:
 By and large OSM maps things that are physically present.

 Once probable becomes under construction, there are tags for that:
 http://wiki.openstreetmap.org/wiki/Tag:highway%3Dconstruction



-- 
Lukas Sommer

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


Re: [Tagging] Fuel shops

2015-03-19 Thread Lukas Sommer
In Benin (Africa) these shops exist also – mostly only a table with
some big bottles with fuel.

2015-03-19 9:18 GMT, Dave Swarthout daveswarth...@gmail.com:
 I want to float an idea to get your reactions. Here in Thailand, and
 especially in rural areas, there are hundreds of shops that sell motor fuel
 in small quantities. Most of the population drive motorbikes which are used
 for every sort of transport imaginable. They have a tiny petrol tank,
 perhaps 4-5 liters, therefore a short range; they need frequent fill-ups.
 To meet this need local individuals have set up small sheds or kiosks from
 which they hand pump the small quantities needed. Some shops sell fuel by
 the liter bottle, often a whiskey bottle. Such shops are poorly marked,
 seldom have any signs indicating their presence and typically offer no
 other services. If you live in the area you will know where the fuel shop
 is, otherwise they're almost invisible

 At any rate, we're looking for a way to tag these fuel shops in such a way
 that they become visible in OSM (and on our GPS units), and will not be
 mistaken for a full size fuel service station. Current tagging practice is
 to tag them with amenity=fuel and a made up name, for example, Bike petrol
 or Drummed fuel. The people doing this are aware of the fact that such
 tagging isn't strictly correct, but they understandably want to be able to
 find those shops should they run out of fuel. One problem with this
 Thailand-centric approach, is that other data consumers are unaware of it.
 Another is that the informal names are multiplying rapidly and one mapper's
 drummed fuel is another's barreled fuel and another's Bike petrol. Where it
 will end is anyone's guess.

 I'm suggesting an addition to the values of the shop key: shop=fuel or
 perhaps shop=motor_fuel

 My goal is to standardize the tagging so that at some point these shops can
 be eventually rendered on Garmin compatible downloaded maps and hence made
 visible. I have done this for my custom Garmin maps and find it a real
 asset.

 Here is a photo of such a shop in my 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://lists.openstreetmap.org/listinfo/tagging


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

2015-03-14 Thread Lukas Sommer

 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

2015-03-14 Thread Lukas Sommer
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

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


Re: [Tagging] Leaf type of palm for leaf_type

2015-03-11 Thread Lukas Sommer
There are 533 413 elements with the “leaf_type” key. Only 83 of them
have the value “palm”. This are 0.0156 % and certainly not “widely
used” at all!

I suppose you want to make a mechanical edit to change the existing 13
056 elements with type=palm. But you would change the description of
leaf_type=*. You would destroy the clean description of a clean and
well-defined key. An important reasons for the introduction of
leaf_type=* was that the previous solutions were too complex, not well
coordinated, too detailed – and thought didn’t work well. leaf_type=*
is an effort to keep things simple and clear. It’s not good to break
this.

You should not change the description of leaf_type=*. You should use
leaf_type=broadleaved and – if you want – add some other tag to make a
more exact description.

2015-03-11 4:54 GMT, Bryce Nesbitt bry...@obviously.com:
 On Tue, Mar 10, 2015 at 9:01 PM, johnw jo...@mac.com wrote:

 There are places where there are an amazing mount of Palm trees, and
 confusing them with a broadleaf tree is not great. But is this the main
 way the species (or class or whatever) of tree is defined? I thought there
 was some species tag for this as well - or is it too difficult when
 mapping to know the type of tree beyond it’s leaf?

 There are species and genus tags, but many mappers won't be able to
 fill that those.   Palm on the other hand is easy,
 and makes a great map symbol also.

 ___
 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] Leaf type of palm for leaf_type

2015-03-10 Thread Lukas Sommer
“palm” is described explicitly as an example at
http://wiki.openstreetmap.org/wiki/Tag:leaf_type%3Dbroadleaved

So it this seems to me that this is just a special case of broadleaved.

I have doubts in adding a new value which is just a special case of an
existing value – in the same key. We loose the hirarchy.  Probably
this won’t reduce confusion, but rather increase confusion.

2015-03-10 20:41 GMT, Bryce Nesbitt bry...@obviously.com:
 I'm seeking comments on adding palm to the leaf types
 at http://wiki.openstreetmap.org/wiki/Key:leaf_type

 A rendering engine can equate palm 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)

2015-03-05 Thread Lukas Sommer
Okay. I’ve made some clarifications to the proposal (avoid confusion
with coordination of traffic signals along a length of road …).

The remaining problem is the tag value “type=traffic_signals_group”. I
agree that “group” is not the best choise. We could maybe switch to
“type=traffic_signals_set”. (I would avoid “intersection_set” because
the relation isn’t restricted to intersections, but could theretically
also be used for pedestrian crossings on straight road; probably there
is not so much need, but I don’t wont to exclude this use case.)

So our choise could be “type=traffic_signals_set”?

2015-02-26 6:28 GMT, Warin 61sundow...@gmail.com:
 Looks like this has already been discussed .. in 2008 to 2011.
 http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Set_of_Traffic_Signals
 No outcome for that ..
 Past discussion looks to have pointed to a relation ... the relation
 contains each node of traffic_light and can have a name= tag.

 I use 'set' because that is how they are called here in Australasia ..
 and it looks to be used in the UK too  ...

 http://www.tfgm.com/Corporate/Pages/UTC-fault-reporting-form.aspx



 On 26/02/2015 4:55 PM, John Willis wrote:
 If group is not a good word, then set is a good alternative.

 Javbw


 On Feb 26, 2015, at 8:33 AM, Warin 61sundow...@gmail.com
 mailto:61sundow...@gmail.com wrote:

 Hi,

 This could be confused with the coordination of traffic signals along
 a length of road or even a district wide coordination of traffic
 light signals.
 I think it needs some words that restrict it to a single intersection?

 And possibly some thought to where a length of road (many
 intersections) or a district wide coordination of traffic signals
 occurs? If the name 'traffic signals group' is taken what name would
 you give 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. With the consent of him, I did some
 supplementing. Thanks to Sanerd17!

 Unlike the proposal “Proposed features/Traffic Signals” of Lukas
 Schaus, this is _not_ about traffic light circuits, but just about
 grouping together all nodes with highway=traffic_signals that belong
 to a traffic signal system at one place. This could be useful in
 Japan, where traffic signal systems have namen. (Thanks to nyampire
 and javbw for suggestions and comments.) This could be useful for
 routing/turn-to-turn navigation engines to calculate better the time
 penalty for the traffic signal system.

 Best regards

 sommerluk

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

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


 ___
 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 - RFC - (traffic signals group)

2015-02-25 Thread Lukas Sommer
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 Lukas
Schaus, this is _not_ about traffic light circuits, but just about
grouping together all nodes with highway=traffic_signals that belong
to a traffic signal system at one place. This could be useful in
Japan, where traffic signal systems have namen. (Thanks to nyampire
and javbw for suggestions and comments.) This could be useful for
routing/turn-to-turn navigation engines to calculate better the time
penalty for the traffic signal system.

Best regards

sommerluk

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


Re: [Tagging] building=yes on nodes?

2015-02-20 Thread Lukas Sommer
Okay. I’ll adapt the few remaining building=* value wiki pages that do
not allow nodes  …

2015-02-17 0:32 GMT, Dave Swarthout daveswarth...@gmail.com:
 On Tue, Feb 17, 2015 at 1:30 AM, Dan S danstowell+...@gmail.com wrote:

 All building=* on nodes is fine. As others have pointed out, 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

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


Re: [Tagging] building=yes on nodes?

2015-02-16 Thread Lukas Sommer
I would like to return to the original question:

1.) I think it is confusing to have building=cowshed allowed on nodes,
but building=cabin not allowed. We should unify this. Either _all_
building=* keys can be used on nodes, or _none_.

2.) If we agree on 1.), would we opt to allow nodes or to disallow
nodes? After reading the previous comments, I would tend to allow it.

Best regards

Lukas

2015-02-16 12:12 GMT, fly lowfligh...@googlemail.com:
 Am 14.02.2015 um 23:06 schrieb Tobias Knerr:
 On 14.02.2015 22:11, SomeoneElse wrote:
 ... it also says that it shouldn't be used on relations, which would
 exclude perfectly valid multipolygons, such as this one:

 Multipolygons are a means to map areas. So they are covered by the area
 icon.

 The relation icon stands for relations that are not areas,
 just as the way icon stands for ways that are not areas.

 How about type=building ?

 It appears that again people are trying to use the wiki to tell other
 people how to map rather than describe how things tend to be mapped.

 Nobody is telling anyone not to use multipolygons.

 This is totally misleading as the type of the object is still a
 relation. Once we introduce an area object we might cover closed ways
 and multipolygones as one category. For now we depend on the object type
 or e.g. editor software already need to implement the area type to offer
 proper presets.

 cu fly

 ___
 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] building=yes on nodes?

2015-02-13 Thread Lukas Sommer
Hello.

The english wiki page key:building says that this key may not be used
on nodes. However, most (but not all) of the english wiki pages for
the individual values (like building=apartments) allow the usage on
nodes.

I’m not sure if it is useful to have a different policy for different
values 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2015-02-10 Thread Lukas Sommer
 i don't see the potential for confusion since this is a relation.
 Maybe you can elaborate why this could be a problem since
 i am not aware.

Without reading the documentation, I would expect to
type=traffic_signals to be something very similar to
highway=traffic_signals. But type=traffic_signals is not about traffic
signals, it’s more but about a way through a traffic signal system.

 The name does maybe not match to 100% the purpose
 but the relation is more than just about the phases.

Maybe another – longer and more descriptive – tag would be better.

Changing this during voting 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://lists.openstreetmap.org/listinfo/tagging


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

2015-02-09 Thread Lukas Sommer
I would strongly recommend to not use type=traffic_signals because we
have already a tag highway=traffic_signals. This would cause
confusion. Furthermore, type=traffic_signals does not describe well
what your prososal wants to do. With your relation, you don’t want to
represent traffic signals but you want to represent traffic signal
phases. Something like type=traffic_signals_phase would IMHO be
appropriate.

2015-02-09 15:47 GMT, fly lowfligh...@googlemail.com:
 Am 09.02.2015 um 15:35 schrieb Lukas Schaus:
 Hi,

 My proposal concerning the modelling of traffic signals is now open
 for voting.

 http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals#Voting

 You did not comment on my question about micromapping a junction and
 adding a highway=traffic_signal at the pedestrian crossing or the stop
 line for each direction separately. Have a look at the examples below
 [1],[2].

 For complete direction separated junctions like [3] we probable will not
 even need any relation.

 Please, consider this tagging style and show me how this will work
 together with your proposal.

 Altogether, I am not sure if this relation is needed at all but for sure
 not at the current base.

 Still would prefer simple tags on the nodes if possible.

 cu fly


 [1] https://www.openstreetmap.org/#map=19/48.10739/7.85080
 [2] https://www.openstreetmap.org/#map=18/48.06123/7.81258
 [3] https://www.openstreetmap.org/#map=19/47.98530/7.82814

 ___
 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)

2015-02-09 Thread Lukas Sommer
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=traffic_signals because we

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


Re: [Tagging] courtyards

2015-02-06 Thread Lukas Sommer
I didn’t know that courtyards have their own name ;-)

In general, it seems a good idea to have a tag (apart from name=*) on
the inner line of the multipolygon. But I would avoid the key place=*
because this key is rather used for bigger features and seems to not
fit well. Maybe there is another key *=courtyard that fits better?

2015-02-06 22:14 GMT, Friedrich Volkmann b...@volki.at:
 Courtyards use to be mapped as inner members of building multipolygons. We
 can also use the multipolygon relation to assign a name to the bullding. If
 we want to assign a name to the courtyard, we must assign it to the way. But
 then we need some kind of physical tag in addition. Applications won't know
 what do do with the name when there aren't any other tags.

 Some courtyards are tagged place=locality or highway=pedestrian or
 leisure=park, but they all seem wrong. A place=locality wouldn't be that
 strictly delimited, and a park or pedestrian area need not occupy the entire
 courtyard.

 A courtyard really has nothing to do with leisure=*, and it is not a highway
 either. It's just a hole in a building. What key can we use for this?

 What about place=courtyard (an area spared by a buildng), analogous to
 place=island (an area spared by the ocean)?

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

 ___
 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 - RFC - temperature

2015-02-04 Thread Lukas Sommer
If we look how other units are treated in OSM
(http://wiki.openstreetmap.org/wiki/Map_Features/Units) than the keys
have always default units. Which one is the default unit differs from
key to key. For example, the default unit for width=* is “meter”,
while the default unit for distance=* is “km”. So the default unit is
not based on SI units, but on the commonly used unit for this
pourpose.

I suppose that in most countries of the world, °C is the common unit
for temperature in daily normal live. °F is only used in very few
countries. °K is only used in the scientific world, but not in daily
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, the Kelvin temperature scale is almost never used outside
 of a chemistry or physics lab. Absolute zero, the lowest possible
 temperature, is defined as 0 degrees Kelvin. That is approximately equal to
 minus 272 C and minus 460 F. Nobody working on OSM is likely to be
 specifying temperatures in degrees K.

 begin rant
 I also think Americans, and I am one, need to get over the use of degrees F
 and the old inch/foot/mile system. It's stupid and anachronistic to base the
 units of length on the length of the king's thumb, or whatever. Continuing
 to make exceptions for them is only perpetuating their intransigence.
 end rant

 This specification is getting quite complex, don't you think? I'm betting we
 will never see most of these fine gradations in temperature rendered on a
 map.

 my 2 cents


 On Thu, Feb 5, 2015 at 4:05 AM, Warin 61sundow...@gmail.com wrote:

 On 5/02/2015 1:02 AM, fly wrote:

 Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:

 
  1) I would discourage specification of the temperature without the
  scale indication. I have never lived in the US but I see from the Web
  that Americans like specifying temperature in degrees Fahrenheit
  without mentioning it (the same way as we in Europe use centigrade
  without underlying it). Taking into account the international nature
  of the OSM community, I foresee a significant risk that the map will
  get populated with invalid values. Warin is right about SI units, but
  SI is not even strictly followed in the technical and scientific
  community, not to mention the general public. Obviously, Americans in
  general ignore it by using inches, miles and degrees Fahrenheit :) I
  am afraid many people will not have heard about SI guidelines and will
  not have read the wiki page in significant detail.
 
  Therefore, for the sake of clarity, I suggest always specifying F or
  C with the temperature value.

 +1
 Units for temperature are really wired and obviously Kelvin which I
 would suspect to be the default is not really used in real live as
 Celsius has the better scale for real life usage.


 Matter of common use between C and K.
 The default of height is metres .. not feet. Don't know if there is any
 confusion over that? I do take your point over the default.. insisting on
 the unit may be a good way of ensureing that F is not confused with C. But
 I'd like to see other people ideas on this .. are they prepared to enter the
 unit (even thought it is abbreviated) every time they enter a temperature?

  2) I suggest clarifying the verbal specification of the temperature.
  - Replace chilled with cool (by analogy with warm) and also
  because chilled actually assumes that I know that the object was
  purportedly cooled down, which adds yet another uncertainty and is
  usually not very relevant;
  - remove the definition of substantially colder etc., because it
  doesn't add any clarity. I agree that it is important to distinguish
  between safe and unsafe situations, so let's just do that:
 
  freezing
  cold — may be unsafe to handle
  cool
  warm
  hot — may be unsafe to handle
  boiling
  adjustable — the object temperature can be changed by consumer/user
  variable — the object temperature can vary on its own
  ambient — the object always remains at ambient temperature (note that
  this may include the object being cold and warm, including being
  unsafe to handle, depending on the ambient temperature; think about
  water in Siberia rivers in January)

 Only two values I could live with are cold and hot. Generally these
 values are too ambiguous and an estimated value is much better.


 Chilled as in chilled water is in common use. The mapper may want to
 include it. I don't know how to render that to a map. What a mapper chooses
 to enter is up to them. I'm only rendering adjustable, hot and cold at this
 point anyway.

  3) For the numeric specification, I suggest adding:
  - above/below options
  - approximate value
  - range of temperatures (using above/below)
 
  E.g.
  temperature:circa = 80 C
  temperature:above[:circa] = 300 C
  temperature:below

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

2015-02-03 Thread Lukas Sommer
@Javbw Indeed the problem of the traffic signal system names is still
not solved.However I would keep this separate. Lukas Schaus wants to
represent traffic signal phases (and uses – also in the new proposal –
more than one relation per traffic signal system). The traffic signal
system and its name are a different topics, and I would not merge them
in the same proposal.

In the Tagging_for_complex_junctions_or_traffic_signals_that_are_named
propsal, the part of the area was a little bit disputed for the case
of the traffic signal systems. Various people suggested that a
relation would 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 Sommer


2015-02-03 2:30 GMT+00:00 johnw jo...@mac.com:

 I did a major update on my proposal regarding the mapping of traffic signals.

 As per the talk pageI’d like you to consider including (and documenting in 
 the proposal) rendering the name=* of the “signal” in this situation, as the 
 relation encompasses the entire set of signals - which in Japan, are named, 
 and represented with a singleTraffic_signals icon. Even without a name, the 
 single icon per complex intersection is preferred, as a signal icon at an 
 intersection - even a complex one, is the proper rendering for using relative 
 direction and counting “3 signals down is my business”, and other commonly 
 used relative directions in places with no street addressing system.

 http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals#rendering_traffic_signals_area_question

 thanks, Javbw
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] patron saints

2015-01-25 Thread Lukas Sommer
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 complicate ;-)

The clearer these things are defined from the very beginning, the more
useful will the tag be.

Cheers

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


Re: [Tagging] waterway=wadi problem

2015-01-21 Thread Lukas Sommer
 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 can we
distinguish between “normal water” and “flood water”.

I think rivers – also intermittent rivers – belong to the first
category. Also fords belong to the first category, because the
defination of the ford is that here you cross water (and the water can
be intermittent or not). This does no harm, thought it is quite
“normal”.

However, other objects like the house you are living in probably you
do not want to be filled with water. If it is filled with water, this
will not be a normal-life situation for you. If your house is for
example in the nice city of Cologne (Germany) near the river “Rhein”,
than perhaps at least a part of your house will be filled with water
one time each year. So your house can be filled with water in a very
regular way, nevertheless this is not nice for you. Your house belongs
to the second category.

I think the key flood_prone should be applied only for the second
category. The wiki page of the flood_prone key is not really clear.
But texts like

 Flooded roadways are often very dangerous to cross and many people die each 
 year as a result.

on the wiki page suggest the same thing. It’s not about the normal
ford, where you know that there maybe you have to cross water and that
normally you can do so without a big danger. It’s about the not-normal
situations.

 as this may help routing software to avoid potentially hazardous crossings if 
 there has been heavy rain.

This seems to be the original idea of the tag. And it’s useful. In
most western coutries, a heavy rain isn’t a big problem – there are
well-working sewerage systems. But I assure you that there are other
parts of the world where this is different. If you are living in
Abidjan (Ivory Coast) and you want to travel during the rainy season
during a rainfall than you know that there are many roads that are
impassable: Maybe 20% of the paved routes can’t be used because the
water reachs 1 or 2 meters. (But most roads are unpaved. And unpaved
roads are evern worser when it’s raining ;-)

 I'd hope that the flood_prone tag would be
 applied to an area

I think both tagging – on areas an on highways – can be useful. Both
tagging are also present in the database.

 and best if the frequency is noted e.g. once every 100
 years.

Agree. (Though – every 100 years is a very risky description. At
places where floods occure more often – for example once a year –
predictions tend to be more reliable.)

 Again no. A ford may be continuously under water. E.G. a road that goes
 through a river .. where the river normally flows across the top of the
 road.  Some fords may only have water in floods, others seasonally, and
 others continuously.

That is what I said ;-)

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


Re: [Tagging] waterway=wadi problem

2015-01-20 Thread Lukas Sommer
 The flood prone areas are not designed to let you cross a river

Yes. I think that is exactly the important point and a very good
description/criterion. flood_prone=yes for things that are _not_
designed to be flooded. And waterway=*, ford=* … for things that _are_
designed/expected to be flooded.
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 under train crossings with flood level markers because the road
 floods - both are flood prone, but their job isn’t to let you cross a
 waterway.

 Fords can be dangerous to cross in storms, but their job is to let you cross
 in the presence of water.  The flood prone areas are not designed to let you
 cross a river, they just end up being flooded because of inadequate
 drainage.

 a ford https://goo.gl/maps/aBWlg

 flood prone (with a warning sign with lights when it is flooded)
 https://goo.gl/maps/9aFXV

 doesn’t seeing a ford automatically mean it’s flood prone? it handles river
 crossings ^_^

 Javbw


 On Jan 20, 2015, at 8:38 AM, johnw jo...@mac.com wrote:

 Some part of road have
 concrete parts that are flood_prone during cyclone.

 How can we (or not) extend it to roads?



 access:conditional  = no @ flood


 I'm using flood_prone=yes. With surface=concrete.

 But I was looking for some method to unify intermittent aspects of rivers
 and roads that are related when roads are crossing river or vice versa.




 the ford=* key might be useful. They suggest to also tag depth=0 if it is
 usually dry year round. I think this is the tag you are looking for,
 especially since the road section is designed to be submerged (the concrete
 sections) which means it is a ford (as emergency or very large vehicles,
 like a bulldozer, could still cross on the road).


 In San Diego, there are several large roads that are built with fords, as
 access lost during flood conditions is merely an inconvenience.

 I think this applies to any roadway *designed* to let you cross a river by
 going through it, even if it is low/dry most of the time (otherwise,
 floodwaters would easily destroy the crossing).

 Also, because of the wadi problem, i will be making up a new “wash” proposal
 - as it seems wadi is completely generic now.


 Javbw


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



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


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


Re: [Tagging] Feature Proposal - RFC - Cluster

2015-01-16 Thread Lukas Sommer
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 gain in
information. This will work only if the relation proposal is really
clear. If not, probably it will happen the same things as with the
“site” relation (=there are “site” relations in the database, but
little software support for this).

I think that Никита has touched a very important question: Is there
inheritence? Means: Are tags on the relation also considered tags of
the members? And how to deal with conflicts? This is not as trivial as
it sounds. I’ll take some of your examples:

– “name=Schwedenhöhlen” + “natural=cave_entrance” on the relation.
“name=Schwedenhöhle 1…” + “natural=cave_entrance” on the nodes. Open
questions: What does the relation represent? A collection of cave
entrances? Or the caves themself? If it represents the caves themself,
the tag natural=cave_entrance does not seem to be too appropriate. If
it represents a collection of cave entrances, a rendering of the
general name might be useful. But it might be useful to render it
bigger than the individual names.

– “name=Schwedenhöhlen” on the relation. “name=Schwedenhöhle 1…” +
“natural=cave_entrance” on the nodes. You would have to go to the
nodes, interpretate them and use the same rendering style also for the
relation. Probably also not as trivial as it sounds. What, if not all
nodes does not have the same tag (example: a natural=cliff within this
group). Is this considered as error? Does this prevent the rendering?
Your proposal was was count: More natural=cave_entrance occurences
than natural=cliff occurences would make the relation render as a
natural=cave_entrance. For me, this does not look like an improvement
of the current data quality, but rather like a degradation of the data
quality. At least, I would suggest to treat such cases as “invalid”
relations which should be ignored by data consumers.

–  “name=Schönefelder Seen” + “natural=water” on the relation. No tags
at the member areas. Is the “name” tag propageted to the members? If
soo, we have the same problem like before: The name “Schönefelder
Seen” is not appropriate for them. If the “name” tag is _not_
propageted to the members, we have another problem: “natural=water”
has to be propageted to the members nevertheless; so we have some tags
that are propageted (natural=water) and others that are not propagated
(name=Schönefelder Seen), and we need rules how to determine which
tags are propageted and which tags are not propagated.

–  “name=Schönefelder Seen”  on the relation. “natural=water” at the
member areas. Members propagate their tags to the relation. So a
renderer can determine the color for rendering the name of teh
relation. Sounds easy for the “Schönefelder Seen”. But this solution
would create conflicts when applied to the caves, because the cave
relation members have also individual names, and these names would
conflict with the relation name.

All this is too complex for a catch-them-all algorithm. To get a good
rendering, you will probably need special algorithms for each type of
feature.

I understand that you want to have a simple and generic solution. But
I doubt that this will create any benefit in the real practice. And I
fear – if it is as generic as you propse – it will end up like the
“site” relation.

Your original idea was to give to give a common name to various
objects. So, logically, the relation could be limited for usage
together with the tag “name”: Something like type=common_name for
relations, together with name=* on the relation. The members have an
empty role. The members may not have any of the name*=* tags. All
members are requiered to have the same tags; otherwise the relation is
considered invalid. But even this is problematic: Imagine that you
have boat=yes at one of the “Schönefelder Seen” lakes and boat=no at
another of the “Schönefelder Seen” lakes. Imagine further a renderer
that renders the labels of lakes in different colours, depending if
the can be used by boats or not.

I think we need a special tagging for each of these features. But
type=cluster could help anyway. Introduce type=cluster for relations.
But use it only together with special tags like natural=group_of_lakes
– these special tags needs to be introduced also. type=cluster could
also be used together with the existing place=archipelago. So you
would have to make an own tagging decription for each feature (group
of lakes, group of cliffs …) and this leads to a clear documentation
and clear rules.

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


Re: [Tagging] Tag destination vs. relation destination_sign

2015-01-16 Thread Lukas Sommer
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 direction:lanes*.


 destination:lanes ;-)

 Thanks, yes.

 Was tagging directions and writing about destination:lanes.

 cu


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

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


Re: [Tagging] Tag destination vs. relation destination_sign

2015-01-15 Thread Lukas Sommer
To clarify the wiki a little bit more, I would also add to the
key:destination page a sentence like “Where to use? Use destination=*
on the highway (OSM way) after the position of the
signpost/groundwriting.” And I would remove (as explained above) the
three examples with the yellow/white 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 monday and if up to then nobody complains, I'll update the
 wiki as mentioned before.

 bg,
 Martin

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


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


Re: [Tagging] Power networks European codification scheme

2015-01-15 Thread Lukas Sommer
Hello.

I think it is a good idea to introduce a new key for this.

I would recommand not to use “EU” (or “eu”) within the key. While the
fundation of this organization was based on EU laws, it is not
directly part of the administration of the EU (not part of the
European Commision and also 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 other
 part of the world.
 Furthermore, the E of EIC stands for ENTSO-E.

 A more complete solution would be ref:eu:entsoe_eic


 Cheers

 François Lacombe

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux

 2015-01-15 7:18 GMT+01:00 Friedrich Volkmann b...@volki.at:

 On 14.01.2015 21:54, François Lacombe wrote:
  I think it would be great to introduce the key ref:EU:EIC to tag
  transmission power lines, power plant or transmission power substation
  with it.
  These codes seem to be unique all around Europe and they would allow us
  to
  sustainably identify a lot of features (instead of using the OSM ID
  only).

 Please no upper case letters in key names.
 And I am not sure about the EU part. Shouldn't it be ref:entsoe:eic (or
 just ref:eic) rather than ref:eu:eic?

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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



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


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


Re: [Tagging] Tag destination vs. relation destination_sign

2015-01-10 Thread Lukas Sommer
Looking at the description, I could imagine that the original idea was
to use key:destination on motorways and similar roads (primary WITH
primary_junction), because there you have normally no crossroads, but
only “y junctions” on oneways. So for motorways it is more likely that
there is only one version of the content of the signposts. But at
normal crossroads, it may be more likely that the signpost content for
one of the leaving ways is different (different content depending of
the road from which you are coming).

However, that’s just raw guess about the original intention. Also
unsure if all these assumtions are correct (on the ground).

 I suggest to remove the section When to use and instead add the
 following sentence (or similar): Instead of they key destination, one
 might also use the relation destination_sign, which is able to provide
 detailed information about the type and colour(s) of the road sign.

+1. Key:destination for the simple cases the the relation for the
complex cases seems fine for me.

Lukas

PS: In the wiki, Key:destination is used for “signposts or ground
writing”, but Relation:destination_sign only for signposts. I would
extend Relation:destination_sign also to ground writings. And in
general, I think it would be a good idea to harmonize the allowed tags
(key:distance, key:time) between key:destination and
relation:destination_sign.

PPS: As far as I understand, the key:destination is used on OSM ways
_after_ a signpost/groundwriting. 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 several months ago on the help-website [1]. When
 should I use destination and when the relation? Until now I did not get any
 answer. Only recently I noticed the sentence you are referring to. From then
 on, I followed this advice.

 So I'm interested to learn which is the preferred way of mapping. I didn't
 add too many destinations yet, and can easily remap what I did so far.


 regards

 m



 [1]
 https://help.openstreetmap.org/questions/35719/mapping-destination-on-a-primary-road

 On Sat, Jan 10, 2015 at 5:27 PM, Martin Vonwald imagic@gmail.com
 wrote:

 Hi!

 Currently it reads in the section When to use on the wiki page of the
 key destination [1]:
 Attention: Do not use them for mapping at highway=primary and
 highway=secondary (or smaller). In such cases, a destination sign relation
 is the recommended way for direction directives. 

 Also above that sentence a list of road types is given on which that key
 should be used and only on that road types.

 May I ask who exactly recommended the use of the relation destination_sign
 and who decided, that destination may only be used on a few type of roads?

 I suggest to remove the section When to use and instead add the
 following sentence (or similar): Instead of they key destination, one might
 also use the relation destination_sign, which is able to provide detailed
 information about the type and colour(s) of the road sign.

 That's the way I always thought about those two tagging schemes:
 destination is the simple variant and destination_sign the complex. I used
 both in the past, but only used the key lately.

 Best regards,
 Martin

 [1] https://wiki.openstreetmap.org/wiki/Key:destination#When_to_use

 P.S: I am aware, that I may simply ignore the wiki, but I don't want to
 lose any potential information, because someone thinks one must use
 destination_sign on e.g. highway=primary, but considers it as too
 complicated.

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



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


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


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

2015-01-04 Thread Lukas Sommer
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 19:55 GMT+01:00 Matthijs Melissen i...@matthijsmelissen.nl:


 I would use a subtag, like natural=water, water=pond, pond=fish_pond.

 The paradoxic effect of adding more detailed tags is that the data
 gets less useful to data consumers, because most data users won't add
 particular processing rules for fish ponds, while if we use a subtag,
 they could still use the rules for water=pond.


 But water=fishpond is already a subtag of natural=water. Most renderers (if
 not all) use natural=water. I'm not sure if subtagging water=pond adds
 anything useful to the equation.

 A pond is just a small lake, so that's a pretty vague tag to build upon.


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


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


[Tagging] Cleanup flood tagging

2014-12-28 Thread Lukas Sommer
Hello.

In OSM there seems to be concurrent 2 tagging systems for flood
tagging. And each of them seems to be incomplete.

Just to remember: There are several types of flood. I think the most
common types are:

– case 1: caused by heavy rainfall: “on flat or low-lying areas when
the ground is saturated and water either cannot run off or cannot run
off quickly enough to stop accumulating” (from Wikipedia article
“flood”). Typically various times during one year – and quite common
in some African countries during the rain season.

– case 2: caused by overflow of water of a riverbed: not directly
related to rainfall at this spot (rainfall can be hundrids of
kilometers upstream, causing a river overflow hundrids of kilometers
downstream). Typically maybe one per year or maybe each two or three
years…

In OSM we have flood_prone. The wiki descript fits most with “case 1”:
“ this is mostly applicable to roads that go under water after heavy
rains”; so combining it with highway=* on OSM ways (alternatively on
nodes within a highway) would be the typical use case. We have
currently 204 nodes and 10 582 ways.

In OSM we have also hazard_type=flood. The wiki description fits
mostly (but not exclusivly) with “case 2”. Tagging areas as
independent OSM elements seems to be the typical use case (no
combining with other objects). We have currently 1 node and 56 ways.

hazard_type=flood comes from OpenHazardMap – but OpenHazardMap wiki
page hasn’t been updated since one year. OpenHazardMap seems to focus
on landslide (hazard_type=landslide has 3 169 comparing with only 57
elements for hazard_type=flood).

Questions:

– Shouldn’t we deprecate one of these tagging? If so, which one?

– Shouldn’t we introduce a possiblility to distinguish river
overflowing floods and directly rainfall 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/tagging


Re: [Tagging] Cleanup flood tagging

2014-12-28 Thread Lukas Sommer
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 there seems to be concurrent 2 tagging systems for flood
 tagging. And each of them seems to be incomplete.

 Just to remember: There are several types of flood. I think the most
 common types are:

 – case 1: caused by heavy rainfall: “on flat or low-lying areas when
 the ground is saturated and water either cannot run off or cannot run
 off quickly enough to stop accumulating” (from Wikipedia article
 “flood”). Typically various times during one year – and quite common
 in some African countries during the rain season.

 – case 2: caused by overflow of water of a riverbed: not directly
 related to rainfall at this spot (rainfall can be hundrids of
 kilometers upstream, causing a river overflow hundrids of kilometers
 downstream). Typically maybe one per year or maybe each two or three
 years…

 In OSM we have flood_prone. The wiki descript fits most with “case 1”:
 “ this is mostly applicable to roads that go under water after heavy
 rains”; so combining it with highway=* on OSM ways (alternatively on
 nodes within a highway) would be the typical use case. We have
 currently 204 nodes and 10 582 ways.

 In OSM we have also hazard_type=flood. The wiki description fits
 mostly (but not exclusivly) with “case 2”. Tagging areas as
 independent OSM elements seems to be the typical use case (no
 combining with other objects). We have currently 1 node and 56 ways.

 hazard_type=flood comes from OpenHazardMap – but OpenHazardMap wiki
 page hasn’t been updated since one year. OpenHazardMap seems to focus
 on landslide (hazard_type=landslide has 3 169 comparing with only 57
 elements for hazard_type=flood).

 Questions:

 – Shouldn’t we deprecate one of these tagging? If so, which one?

 – Shouldn’t we introduce a possiblility to distinguish river
 overflowing floods and directly rainfall 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/tagging


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

2014-12-01 Thread Lukas Sommer
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 on the update done on the Pipeline proposal but be
 sure I will.

 What were the concern against network=* tag ?
 If they can be avoided with usage=* (or any common key) I'm ok to join you
 to use the same between power transmission and pipelines.


 Cheers

 *François Lacombe*

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux

 2014-11-24 15:57 GMT+01:00 Rainer Fügenstein r...@oudeis.org:

 hi,

 FL I knew usage=* and it can be the ideal key to indicate
 usage=transmission,
 FL usage=distribution,... on power lines or power cables.

 If I'm not mistaken, this key is intended to serve  the same purpose
 as the network=* key is in the pipeline proposal:

 https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension#Pipelines

 FL But it is currently and exclusively used for railway tagging.
 FL https://wiki.openstreetmap.org/wiki/Key:usage

 concerns against using the network=* key have been raised. it would
 make sense to join forces here and use a common key, be it usage=* or
 something else.

 cu


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



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


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


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

2014-12-01 Thread Lukas Sommer
Hm. I think the railway guys have a clearly defined list of possible values
(there are 6 possible values in the wiki). This way software can process
the data, because it is known which values are valid and which not.
Checking this would be much more difficult (for data comsumers, but also
for editors like JOSM or iD) if the list is less clear.

We have 330 361 elements with the “usage” key in the database. Almost all
of them (329 036) are combined with the “railway” key, so this is the
current state in the database. I agree with you if you say that “usage”
sounds like a very general key and not a railway specific key. So the
railway guys have just been a little faster than the power guys and
“occupied” this key. I would accept this and search another key to avoid
unnecessary conflicts. I don’t insist in “power:usage”. It can also be
something else, but I would introduce a new key 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 of location=* even if there is some specific values.

 Do you agree ?

 *François Lacombe*

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux

 2014-12-01 9:31 GMT+01:00 Lukas Sommer sommer...@gmail.com:

 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 on the update done on the Pipeline proposal but
 be sure I will.

 What were the concern against network=* tag ?
 If they can be avoided with usage=* (or any common key) I'm ok to join
 you to use the same between power transmission and pipelines.


 Cheers

 *François Lacombe*

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux

 2014-11-24 15:57 GMT+01:00 Rainer Fügenstein r...@oudeis.org:

 hi,

 FL I knew usage=* and it can be the ideal key to indicate
 usage=transmission,
 FL usage=distribution,... on power lines or power cables.

 If I'm not mistaken, this key is intended to serve  the same purpose
 as the network=* key is in the pipeline proposal:

 https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension#Pipelines

 FL But it is currently and exclusively used for railway tagging.
 FL https://wiki.openstreetmap.org/wiki/Key:usage

 concerns against using the network=* key have been raised. it would
 make sense to join forces here and use a common key, be it usage=* or
 something else.

 cu


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



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



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



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


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


Re: [Tagging] Various alt_name values?

2014-11-29 Thread Lukas Sommer
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 wrote:
 
  Okay. I’ll try a summary:
 
  We have the choise between two systems:
 
  – semicolon system
 
  – alt_name_1 system

 I added support for alt_name_1 because this kept coming up and people were
 actively abusing alt_name:1 because it happened to work (the :1 actually
 ends up interpreted as a language and while this could be fixed the
 combination of language and array using the same syntax adds a lot of
 complexity and confusion).

 ; is just a bad way of doing it without the ability to escape ; and
 universal editor support (which at this point is probably impossible). It
 also makes storage much more complex since it breaks key=value pairing.
 I'd say it was a bad idea and just about anything is better.

 alt_name[1] that colin suggested is interesting and potentially
 unambiguous. It also has the advantage of making sense to a coder and not
 requiring special support in editors for magic escape characters.

 --
 Brian

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


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


Re: [Tagging] Various alt_name values?

2014-11-28 Thread Lukas Sommer
Okay. I’ll try a summary:

We have the choise between two systems:

– semicolon system

– alt_name_1 system

(Other versions like alt_name:1 or alt_name1 seem to be not interesting and
have very little occurence in the database, probably errors during the HOT
imports).

Both have its advantages and disadvantages.

Having both systems at the same time in use does not make it easier: In the
database, we have currently about 2300 nodes and about 3000 ways with the
key “alt_name” and the character “;” in the value. We have also about 3800
nodes with “alt_name_” as part of the key. Almost all of them are in West
Africa and come probably from recent HOT activity. We have about 80 ways
with “alt_name_” as part of the key. (Roland Olbricht had done some
overpass stuff about this at
https://lists.openstreetmap.org/pipermail/talk/2014-September/070863.html)

On the wiki, we have alt_name_* since 2011 (introduced at
http://wiki.openstreetmap.org/w/index.php?title=Key:nameoldid=713311 on
the wiki – I could not find a discussion about that) but people did not use
this system, but they almost always used the semicolon system instead.
Until the HOT activity with the Ebola response …

In this current thread, both solutions have had supporters, but there has
been some more support for the semicolon system.

The current situation with two different, incompatible solutions is IMHO
not satisfying. So I would propose to

1.) do a formal voting (I would propose the semicolon system)
2.) after that: ask for support for this in Nomination (and maybe other
software on which the HOT people rely) for the voted and accepted solution
3.) as mid-term goal: fade out the usage of  the not-accepted solution
(maybe later even with a mechanical edit – not sure if this is easy)
4.) as long-term goal: 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
 wrote:
  I don't even know which keys are currently under use by Nominatim and
 other
  data consumers and how that could evolve in the future.

 At the moment nominatim supports

 alt_name_[0-9]+:language_code=name

 for alt names

 I've added this to the wiki


 +1

 This is also how I have done it when I've worked with names. I do not like
 semicolons at all.


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


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


Re: [Tagging] Various alt_name values?

2014-11-24 Thread Lukas Sommer
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 to separate multi
 values in cases where there's no other scheme defined.
 http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

 Cheers,
 Zecke

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

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


[Tagging] Various alt_name values?

2014-11-23 Thread Lukas Sommer
Some time ago, there was a discussion on the “talk” mailing list about how
to deal with the situation of more than one alt_name:

https://lists.openstreetmap.org/pipermail/talk/2014-September/070838.html

Most participants preferred the solution “alt_name=name1;name2” over
solutions like “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 “alt_name=name1;name2” over other solutions.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-11-17 Thread Lukas Sommer
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://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions

 Lukas Sommer

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


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

2014-11-11 Thread Lukas Sommer
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) tagging at
 https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions

 Lukas Sommer

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


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

2014-11-11 Thread Lukas Sommer
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://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions

 question - key:junction has many more possible values than just
 yes for the single point variant. Are those values also allowed
 for junction as area?

 Richard

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

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


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

2014-11-11 Thread Lukas Sommer
The most popular value for the key “junction” is “roundabout”, which can be
used on closed ways, but it hasn’t the meaning of an area, but it is simply
a closed way which is used together with “highway=*” and represents a road
in form of a circle. So this would probably conflict with interpreting 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 why you oppose more specific junction types in
 this proposal which apparently aims at mapping junctions in more detail?
 Before Richard has asked I had taken for granted that yes could have more
 specific values...

 cheers,
 Martin

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


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


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

2014-11-02 Thread Lukas Sommer
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://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC Tagging for complex junctions

2014-10-21 Thread Lukas Sommer
Yes, I’m aware of
https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction

However,
https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction
focuses on the tagging style of intersecting roads and proposes to not
connect them anymore and so avoid turn restrictions. But
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Tagging_for_complex_junctions
focuses on the junction area. I would prefer to keep both discussions
separate. (My first combined proposal for complex junctions and traffic
signals has shown that mixing up to much topics makes the discussion
harder.) However, I think both things are compatible.

Concerning the tag: junction=yes or highway=junction or something
completely different? The tag junction=yes is ugly, but currently yet in
use for simple junctions. If we decide to use highway=junction for the
area, we should use it also 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 for complex junctions and complex traffic signal
  systems had less support than I hoped (5 of 9 votes).
 
  Initially, I was thinking it was a good idea to treat these two features
  together. However, this was obviously not a good idea. It made the
  discussion harder. These two subjects seem to be to different to be
  treated together. So it seems to be better to split this into two
  different proposals: one for complex junctions and one for complex
  traffic signals.
 
  Today I start RFC for the complex junction tagging. A new proposal page
  has been created at
 
 https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
  which takes into account the comments which have been made during the
  previous voting.

 Please have a look at the proposal for highway=junction [1]. It
 describes the same but with a different tag and the two proposal should
 be merged.

 Cheers fly

 [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction


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

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


[Tagging] RFC Tagging for complex junctions

2014-10-18 Thread Lukas Sommer
Hello.

The combined proposal for complex junctions and complex traffic signal
systems had less support than I hoped (5 of 9 votes).

Initially, I was thinking it was a good idea to treat these two features
together. However, this was obviously not a good idea. It made the
discussion harder. These two subjects seem to be to different to be treated
together. So it seems to be better to split this into two different
proposals: one for complex junctions and one for complex traffic signals.

Today I start RFC for the complex junction tagging. A new proposal page has
been created at
https://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://lists.openstreetmap.org/listinfo/tagging


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

2014-10-14 Thread Lukas Sommer
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 for complex junctions or traffic signals that are
 named“.

 This is an important feature in some regions in Asia (notably Japan and
 Korea), but may be useful also in other regions of the world.

 Lukas Sommer

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


Re: [Tagging] man_made=bridge

2014-10-13 Thread Lukas Sommer
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/wiki/Proposed_features/man_made%3Dbridge
 is in my opinion a good tagging scheme, I started work on displaying it in
 a
 default style (
 https://github.com/gravitystorm/openstreetmap-carto/issues/436 ).

 But I noticed that there was never a vote to recognize it as an approved
 tag.

 I plan on starting vote in the near future, so it may be a good idea to
 check this
 proposal for potential problems.

 See also https://github.com/gravitystorm/openstreetmap-carto/issues/436

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


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


Re: [Tagging] man_made=bridge

2014-10-13 Thread Lukas Sommer
 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 sommer...@gmail.com:

 I would add the requirement that the highways/railways/paths that go over
 a bridge have to share a node with the outline area.


 Second sentence in the section Tagging - Bridges with one level: Connect
 all OSM ways running over that bridge to the outline.

 Best regards,
 Martin

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


___
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

2014-10-10 Thread Lukas Sommer
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-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 for complex junctions or traffic signals that are
 named“.

 This is an important feature in some regions in Asia (notably Japan and
 Korea), but may be useful also in other regions of the world.

 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

2014-09-30 Thread Lukas Sommer
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: junction:name:th=* and
 traffic_signals:name:kr=*.

 Different names for junction and traffic signal are probably not a
 real-world case.

 Lukas Sommer

 2014-09-30 12:21 GMT+00:00 Janko Mihelić jan...@gmail.com:

 2014-09-29 23:45 GMT+02:00 Lukas Sommer sommer...@gmail.com:

 The case of Japan is different. In Japan, the name belongs to the
 _traffic signal_, and _not_ to the junction. We need to distinguish this,
 because they are usually differently rendered (traffic signal names usually
 with an icon and junction names usually without an icon).

 But what would we gain when we distinguish between th:junction_area and
 kr:junction_area - because here we have two values for the same feature.


 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: junction:name:th=* and
 traffic_signals:name:kr=*.



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



___
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

2014-09-30 Thread Lukas Sommer
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 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: junction:name:th=*
  and traffic_signals:name:kr=*.
 
  Different names for junction and traffic signal are probably not a
  real-world case.

 Once more cite a mail on the previous thread [1]

 Seems to be a real world example, which is mappable with nodes for the
 traffic_signals and an area for the junction.

 cu fly


 [1]

 https://lists.openstreetmap.org/pipermail/tagging/2014-September/019349.html


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

___
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

2014-09-29 Thread Lukas Sommer
 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 vote yes right now. Can you please provide
 examples how to draw area for more complicated junctions? For 3, 4 or 5
 roads? Example with roundabout (should we include inside area)? For
 junction with 2 or many roundabouts (how we should include all these small
 areas between _link roads)?

 Should we discourage usage of this tag(s) outside Korea and Japan? (I will
 vote yes for this part)

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


___
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

2014-09-29 Thread Lukas Sommer
The case of Japan is different. In Japan, the name belongs to the _traffic
signal_, and _not_ to the junction. We need to distinguish this, because
they are usually differently rendered (traffic signal names usually with an
icon and junction names usually without an icon).

But what would we gain 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:

  Thailand has official signs naming the junctions/intersections. These
 names are also used when you give directions.
 As Imagic suggested, it not best way to use different tags for close
 meanings, single tag will be better option:
 junction=th:junction_area
 junction=jp:junction_area
 junction=kr:junction_area
 ​
 This will allow both simple processing and custom rendering for each case.

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


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


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

2014-09-28 Thread Lukas Sommer
Hello.

After discussion and some modifications of the proposal, here a request for
voting on “Tagging for complex junctions or traffic signals that are named“.

This is an important feature in some regions in Asia (notably Japan and
Korea), but may be useful also in other regions of the world.

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

2014-09-28 Thread Lukas Sommer
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...@gmail.com:

 Hello.

 After discussion and some modifications of the proposal, here a request
 for voting on “Tagging for complex junctions or traffic signals that are
 named“.

 This is an important feature in some regions in Asia (notably Japan and
 Korea), but may be useful also in other regions of the world.

 Lukas Sommer

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



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


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


Re: [Tagging] Understanding links

2014-09-23 Thread Lukas Sommer
 As I understand it, the local access roads would be an unclassified road
with bollards or a kind of barrier at each end, and with trunk links, (or
one way unclassified roads?) that lead onto the actual new trunk road.

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.

I agree that *_link is not good. (Also because you can often use the
frontage road with smaller/slower cars than the main road.)

As frontage roads are quite common in some countries, I think it would be
useful to create a wiki page with some documentation and a best practice
guide.

Proposal for the content:

– frontage roads are never highway=*_link nor highway=service
– frontage roads have usually a lower level than the main road (which one
is up 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 the contact, I'll support it.
 But I think he/she is able to understand English.
 I saw he/she many time in wiki translation and other OSM related software
 translation acts.




 2014-09-23 2:25 GMT+09:00 fly lowfligh...@googlemail.com:

 Am 22.09.2014 15:06, schrieb johnw:
  I have a question on highway link roads.
 
  I came across some trunk_links that seemed really out of place today,
 but they were recently added by a tagger that usually knows what they are
 doing.
 
  https://www.openstreetmap.org/#map=19/36.30046/139.19574
 
  The frontage road for local access to the buildings along the road is
 marked as trunk link.
 
  As I understand it, the local access roads would be an unclassified
 road with bollards or a kind of barrier at each end, and with trunk links,
 (or one way unclassified roads?) that lead onto the actual new trunk road.
 
  This seems like an incorrect use of trunk_links for the frontage road
 along the buildings and maybe for the little entrance exit driveways that
 connect it to the trunk roads.

 +1

 I would tag the small links between the parallel highways with
 trunk_link and the outside highways look like residential/unclassified
 or even service.

 Looks like a tagging mistake, did you get into contact with the user ?

 cu fly


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




 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire

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


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


Re: [Tagging] Understanding links

2014-09-23 Thread Lukas Sommer
 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 the
 main road, narrow, and for local access only - at least in this instance
 (and a ton of others here)


Yes. I also do not see why we should exclude highway=service as a
possiblity.

It’s just raw guess, but maybe the intention of the statement at the wiki
page was not to exclude highway=service, but to avoid mixing up concepts.
Because sometimes frontage roads are called “service roads”, people might
think that this was the _only_ valid tagging for frontage roads. However,
in OSM highway=service is defined differently. So other values may be more
usefull – overall highway=residential. Probably the wiki statement would
just say this.


 as these scream local access and nothing more.


Sometimes you have frontage roads who mostly don’t give local access.
Example
http://www.openstreetmap.org/?mlat=39.47925mlon=-0.45146#map=17/39.47925/-0.45146
Here the mapper decided to use “tertiary”. The road has mostly
through-traffic. I would not make a strict rule for all cases, but just
leave this up to the local mappers to decide.

Wiki page at https://wiki.openstreetmap.org/wiki/Frontage_road
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-22 Thread Lukas Sommer

 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 idea to have
various ways to tag the same thing.




 Made a test to show you what I was thinking.
 https://www.openstreetmap.org/#map=18/36.32478/139.10396


And there, you see even more problems:

– At https://www.openstreetmap.org/#map=19/36.32487/139.10370, you do not
have a shared node between the highway and the area. But this would be
necessary to have a reliably hint for routing/turn-to-turn navigation
software, otherwise it will be hard to know there the area ends. This would
make a working routing solution quite unlikely.

– At https://www.openstreetmap.org/#map=19/36.32492/139.10357 you have the
area nearly in parallel to the footway. There will be other situations,
where it will be exactly parallel. This is not comfortable to edit.

– At https://www.openstreetmap.org/#map=19/36.32492/139.10347 you do not
have a shared node between the footway and the area. But footways are not
oneway. So a routing engine does not know when you enter the area
respectively when you leave it.

– At https://www.openstreetmap.org/#map=19/36.32440/139.10395 the footway
overlaps only slightly the area. There will be cases where it will not
overlap at all. How to decide reliably for software if this footway passes
through the junction or not?

– At https://www.openstreetmap.org/#map=19/36.32440/139.10395 you have a
shared node. But probably, when you are passing through the footway and go
from south to est, you do not pass over the traffic signals. (You would to
so only when you go from south to northwest, and the traffic signal node
should be at the intersection between the footway and the highway:
https://www.openstreetmap.org/#map=19/36.32445/139.10392 )

– The complicate roule when to share node and when not will in practice be
prone to errors. It’s to difficult.

– And: I still not see what you gain with this.

– And overall: It would mean that you may not add any of these areas to OSM
unless you know _exactly_ where the individual traffic signals are located.
So, in practice, either the tagging will hardly be used, or (what I think
is more likely) people will tag nevertheless the area, and just not comply
with the rule of the shared nodes.

– All in all, I do neither see this practicable nor do I see a gain.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-21 Thread Lukas Sommer
 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 zickzack that is not easy to draw and not practical to
maintain. The area is drawn just _around_ everything that is considered the
junction.

About the individual traffic signals. We recommand as current best-practice
to not map them if you use the area. Means: Don’t do both things. (But
maybe in the future this could be considered useful and it could be done
without breaking the tagging scheme just like every other normal traffic
signal with highway=traffic_signals on a node.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-21 Thread Lukas Sommer
 It should be pretty trivial to have the area share nodes with the highway
ways where the signals would normally be mapped.
 Like drawing a square around a tic-tac-toe board, but the shared nodes
are only on one side at a time.

Here, I strongly disagree. The defination on the proposal page is clear: We
do not want to have tags on the shared nodes. Only this way it is clear
what is within the area, and what is without. We should not give up this
possiblility. And your idea actually would give up this possiblilty.

Next problem with your idea: You need to have shared nodes not only for
incoming, but also for the outgoing oneways. And mostly there is no real
traffic signal _after_ you have passed a crossroad. Nevertheless you have
there a node. So later you won’t be able to know if on a specific node
there is really a traffic signal or not.

We don’t have any need to represent the individual traffic signals in the
border. It would make the usage far to complicate. And you would not gain
anything. If you want to mark individual traffic signals, use the existing
tagging. But don’t invent a new one – don’t make it unnecessarily
complicate!

 Also, I think It could also share nodes 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 trivial to have the area share nodes with the highway
 ways where the signals would normally be mapped. Like drawing a square
 around a tic-tac-toe board, but the shared nodes are only on one side at a
 time.

 Also, I think It could also share nodes with the walkways and other
 pedestrian oriented ways, as the signal would be part of their routing as
 well.

 Javbw


  On Sep 21, 2014, at 3:48 PM, Lukas Sommer sommer...@gmail.com wrote:
 
   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 zickzack that is not easy to draw and not practical to
 maintain. The area is drawn just _around_ everything that is considered the
 junction.
 
  About the individual traffic signals. We recommand as current
 best-practice to not map them if you use the area. Means: Don’t do both
 things. (But maybe in the future this could be considered useful and it
 could be done without breaking the tagging scheme just like every other
 normal traffic signal with highway=traffic_signals on a node.)
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging

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

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


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

2014-09-20 Thread Lukas Sommer
Okay, I’ve adapted the proposal wiki page.

We can propose to tag complex traffic signal areas _only_ using the area,
and not to tag the individual traffic signals. That makes it easier for
renderers to display only one icon per traffic signal area. However, I feel
we should not completly exclude for all time the possibility to tag also
the individual traffic signals – it is at least a valid information, even
if it is not necessary for traditional japanese maps. The individual
traffic signals are simple nodes that are located within the area. We would
not make it a rule, but just recommand 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 GMT+00:00 fly lowfligh...@googlemail.com:

 Am 20.09.2014 02:03, schrieb johnw:
  So the solution for a complex intersection is to have a signal_area area
  with an outline that intersects with all the nodes where the signal
  would affect the traffic? This would let the renderer use one icon, and
  still have the ways marked in the proper spot for the intersection,
  right? (assuming they will support signal_area).

 Not sure if the single traffic_signals node need to be parent of the
 area but they should be at least within the area as a hint for the
 renderer.

 Thanks for considering some extra tag(-combinations) for the area.

 cu fly


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

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


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

2014-09-19 Thread Lukas Sommer
 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
they are rendered just with their name (and without any icon) at osm.org.
Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874

In Japan, we have yet thousands of nodes with highway=traffic_signals and
name=*, and they are rendered with their name together with the icon at
osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446

(I know that the rendering style is not very “japanese”, but osm.org has
worldwide coverage and has to render something that fits best at least a
big part of the world. But this is a _rendering_ issue, not a _tagging_
issue.)

There is only a problem when you have to tag complex junctions or traffic
signal systems with dual carrigeways, because you want that the icon the
the name show up only _once_ per junction/traffic signal system, and not
_multiple_ times. That’s what is proposal is for.

is there a way to tell the renderer to not render it's icon if it is part
 of another area's way? that would allow the intersection tag to take over
 for the rendering of the signals for it's single icon.


I guess you want to say that we have to supress the rendering of individual
traffic signals (nodes with highway=traffic_signals) if these node are
located within the area element that marks the traffic signal system as a
hole. So we render only the area element and we get only _one_ icon and
name per traffic signal system.

Indeed that is exactly what is necessary, and I’ve made my proposal based
on this assumption.

I assumed that this is tecnically easy, but I’ll check this again…


 if that's the case:

 landmark=intersection  ?
 Intersection=signals for Japan, intersection=junction for korea, or other
 named junctions.


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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread Lukas Sommer
 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 useful to have a different
tag for the area instead of using the same on the node, especially for
editor software and checking software, but also other software.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread Lukas Sommer
Some random thoughts about names for the area tags:

junction=yes on nodes
For areas:
– something that contains “junction” and “area”
– junction=area ?

highway=traffic_signals on nodes
For areas:
– something that contains “traffic signal system” (also “system”!) and also
“area”
– maybe 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 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 useful to have a different
 tag for the area instead of using the same on the node, especially for
 editor software and checking software, but also other software.

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


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

2014-09-19 Thread Lukas Sommer
After thinking more about the tag name question: It may be useful to use
for the complex situation at least the same key as for their conterpart in
simple situations. This is intuitive (usability), and at the same time the
tags for the simple and for the complex situation are mutually exclusive,
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:

 Some random thoughts about names for the area tags:

 junction=yes on nodes
 For areas:
 – something that contains “junction” and “area”
 – junction=area ?

 highway=traffic_signals on nodes
 For areas:
 – something that contains “traffic signal system” (also “system”!) and
 also “area”
 – maybe 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 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 useful to have a different
 tag for the area instead of using the same on the node, especially for
 editor software and checking software, but also other software.



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


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

2014-09-18 Thread Lukas Sommer
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 junction and different separate names
 for the lights)

 This way we could add an additional junction=* to the nodes with named
 traffic_signal and once all lights are tagged separately only use
 junction=* for ways.
 Additionally we have a better hint for the renderer what to render and
 diversify between a named junction and single named traffic_signals.

 cu fly


Hm, I am not sure if I understand you correctly. You want to use
junction=yes not on nodes anymore, but only on areas – and change the
currently existing cases in OSM?

If so, I would disagree here. We have a yet existing tagging that works
well for both – named junctions and names traffic signals – as long as this
are simple junctions like
https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My
proposal keeps the existing tagging for simple junctions – and extends it
also to complex junctions. I am not convinced in changing the current
tagging practice for simple junctions and require changing a lot of yet
existing data in OSM. Currently I do not know of any situation where we
have at the same place on the ground a different junction name and a
different traffic signal name. It seems to me a barely theoretical problem.
Maybe that does not mean that such a situation is impossible to exist.
However, we should create our tagging scheme starting from the situation on
the ground, and this seems to be either junction names or traffic signal
names, but not both things at the same time. Replace an existing simple
practice with a new complicate practice just to solve a problem that does
probably not exist on the ground?

However, I think it is nevertheless a good idea to think about this case. I
would propose to leave the existing tagging for simple intersections as it
is (with tagging on a node). Moreover, for the rare case that we have a
junction and a traffic signal with different names, one of them could be
represented by an area around the other one (and same thing on complex
junctions/traffic signal systems). Thus, we keep a door open to tag two
different names, just for the case that sometime we really need it.
Nevertheless, we do not break compatibility with the current practice, and
we do not make things unnecessarily complicate for the real-world cases.

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


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

2014-09-18 Thread Lukas Sommer
Okay, if I get you right, you want to add to every element with the tag
highway=traffic_signals and the tag name=* also another new tag, either
– highway=junction
or
– junction=traffic_signals
and the presence or absence of this tag shall influence the rendering?

* Here, I still do not see your point. What would you gain in doing so? You
have more tags, which means more work. But can you do anything that you can
not do with the current, yet existing tagging?

* highway=junction is impossible because the OSM database does not allow
two tags with the same key on the same element.

* junction=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 18.09.2014 16:07, schrieb Lukas Sommer:
 
 
  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 junction and different separate
 names
  for the lights)
 
  This way we could add an additional junction=* to the nodes with
 named
  traffic_signal and once all lights are tagged separately only use
  junction=* for ways.
  Additionally we have a better hint for the renderer what to render
 and
  diversify between a named junction and single named traffic_signals.
 
  cu fly
 
 
  Sorry, was kind of confusing, try again:
 
  1. simple solution with only one node
  junction=yes/traffic_signal/*
  highway=traffic_signal (if the junction has lights)
  name=*
 
  2. area
  junction=yes/traffic_signal/*
  name=*
 
 
  Maybe also highway=junction [1] could be used.
 
  Renderer could use junction=* to determine the needed icon and we stay
  consistant with the use of traffic_signals.
 
  This makes detailed tagging possible while adding the information for
  renderers to
 
  Hm, I am not sure if I understand you correctly. You want to use
  junction=yes not on nodes anymore, but only on areas – and change the
  currently existing cases in OSM?
 
  No, no problem with junction=* on nodes but in long term only needed for
  rare situations and low detailed mapping
 
  If so, I would disagree here. We have a yet existing tagging that works
  well for both – named junctions and names traffic signals – as long as
  this are simple junctions like
  https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My
  proposal keeps the existing tagging for simple junctions – and extends
  it also to complex junctions. I am not convinced in changing the current
  tagging practice for simple junctions and require changing a lot of yet
  existing data in OSM. Currently I do not know of any situation where we
  have at the same place on the ground a different junction name and a
  different traffic signal name. It seems to me a barely theoretical
  problem. Maybe that does not mean that such a situation is impossible to
  exist. However, we should create our tagging scheme starting from the
  situation on the ground, and this seems to be either junction names or
  traffic signal names, but not both things at the same time. Replace an
  existing simple practice with a new complicate practice just to solve a
  problem that does probably not exist on the ground?
 
  Well, I just followed this thread:
 
  Am 16.09.2014 16:49, schrieb Satoshi IIDA:
  2014-09-16 23:38 GMT+09:00 fly lowfligh...@googlemail.com:
  The name belongs to the junction and not to the traffic_signal,
  am I wrong ?
  In Japan, Hokkaido region, there is 4 traffic_signals on 1
  junction.
  Each traffic_signals and 1 junction has different name.
 
  Indeed it is rare case.
  But I think we need Lukas's idea to support it.
 
  However, I think it is nevertheless a good idea to think about this
  case. I would propose to leave the existing tagging for simple
  intersections as it is (with tagging on a node). Moreover, for the rare
  case that we have a junction and a traffic signal with different names,
  one of them could be represented by an area around the other one (and
  same thing on complex junctions/traffic signal systems). Thus, we keep a
  door open to tag two different names, just for the case that sometime we
  really need it. Nevertheless, we do not break compatibility with the
  current practice, and we do not make things unnecessarily complicate for
  the real-world cases.
 
  Ok, here we are common.
 
  Hope my thoughts are better understandable this time.
 
  Cheers fly
 

 forgot the link

 [1] https://wiki.openstreetmap.org/wiki/Proposed_features/highway=junction

 ___
 Tagging mailing list
 Tagging@openstreetmap.org

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

2014-09-16 Thread Lukas Sommer

 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 introduce a new tag, and if you are a contributer and you want just add
such a name to OSM, you have to deal with two different taggings:
– highway=traffic_signals + name=* for simple cases (as currently)
– junction=traffic_signal + name=* for the complex cases.
Not sure, but it seems to be more complicate?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-16 Thread Lukas Sommer
 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 common on Korea – on the ground, not in the
database.)

For a named traffic signal with a (not named) junction: simply
highway=traffic_signals.


 And can we imagine a
 case where the junction and the traffic signals are both named (and
 possibly differently) ?


Good point. That would be difficult… Currently I do not know of such a
case. Further thoughts about this?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-15 Thread Lukas Sommer
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://github.com/gravitystorm/openstreetmap-carto/issues/803
 My previous text should be insisted (past, at that time).
 I'll follow the current issue, thanks!



 2014-09-14 0:02 GMT+09:00 Matthijs Melissen i...@matthijsmelissen.nl:

 On 13 September 2014 15:41, Satoshi IIDA nyamp...@gmail.com wrote:
But a few insists the bilingual RENDERING on osm.org or on other
  alternative (apps or tiles or so).

 This suggestion is in fact currently under discussion:
 https://github.com/gravitystorm/openstreetmap-carto/issues/803

 -- Matthijs

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




 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging



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


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


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

2014-09-15 Thread Lukas Sommer
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 Japan,

  @Lukas are the names of the traffic signals/junctions actually used in
  addresses (and in principal would be a suitable value for addr:place in
 an address)?
 No.
 We realize the name of traffic signal only for routing and navigation on
 local district.
 It is very separated concept from place (residence of human kind) tag or
 addr:* (postal delivery) tag.

 The name of traffic signal is not used as addressing system.
 And if there are very dense traffic signals, occasionally the names are
 like...
 XZY Conter(Chuo), XZY North, XZY West, or so.

 # XZY is the name of place or district, like Roppongi or Akihabara.


 Following maybe off topic...
 Hence, some JP mappers had proposed place=locality for old/famous name
 for mountain path crossing.
 e.g. XZY tsuji (辻, crossing) or XZY Touge (峠, peak).

 They may be acceptable, because we realize them as old/famous place name.
 But I do not feel that it would not suite for modern traffic_signal system.




 2014-08-26 6:34 GMT+09:00 Jean-Marc Liotier j...@liotier.org:

 On 08/25/2014 11:09 PM, Lukas Sommer wrote:

 In Ivory Coast, you have addresses like “in front of the XYZ crossroad”
 or “from XYZ crossroad 50 m towards the big fueling station”. Rather a sort
 of instructions for getting somewhere than an address in the european
 sense. Obviously “from XYZ crossroad 50 m towards the big fueling station”
 will be applied to various houses (usually, when you have arrived, you make
 a phone call to the person that you want to meet, and the person comes to
 the road to search you and help you with the last part of the way – I can
 guarantee you that this is very time-consuming ;-)


 That said, people in quite a few African countries have a postal address
 (PO box in most cases) distinct from the address of their residence, so the
 problem of shoehorning directions in the standard address fields of
 European-designed software is side-stepped more often than not.



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




 --
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire

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


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


Re: [Tagging] key:destination Signpost question

2014-08-30 Thread Lukas Sommer
  the tag
 is used directly (e.g. destination=Exampletown) on the ways leading away
 from a bifurcation, and/or in the form of destination:lanes (e.g.
 destination:lanes=Exampletown|
 Foobarcity) on the way leading towards the
 bifurcation.

Thanks for this explication! I was always in doubt where exactly
“destination=*” had to be applied and the description on the wiki is not
really easy to understand (and the examples IMHO make the things even more
unclear instead of making them clear). Your explication is clear and easy
to understand. Maybe we could add you explication to the wiki? (I 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
  clear.
 http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members

 I believe Kristen was talking about Key:destination, which is what
 should replace exit_to.


 I honestly don't see how this fixes any problems exit_to had given that 1)
 I'd be surprised if there's not a major US city that doesn't have a
 bifurcated split of equal priority making two or more ramps in otherwise
 ambiguous directions, and 2) many large cities have left exits (Tulsa's
 interstate 244 has many on the eastside) and 3) there's even center exits.
  Westbound US 26 at OR 8 has OR 8 leaving the roadway from the number 3
 lane, with lanes 1, 2 and 4(!) continuing through on 26, and a few miles
 east, US 26 East makes a hard right turn, where I 405 North and Market
 Street are a left and a center exit respectively...

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


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


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

2014-08-25 Thread Lukas Sommer
@Simon

 are the names of the traffic signals/junctions actually used in
 addresses (and in principal would be a suitable value for addr:place in
 an address)?

Hm, I’m not sure (I’m not familiar with the group of addr:* keys). At least
they are places in the sense that they have a defined location.

In Japan and in Korea, I’m not sure how this is handeled.

In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or
“from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of
instructions for getting somewhere than an address in the european sense.
Obviously “from XYZ crossroad 50 m towards the big fueling station” will be
applied to various houses (usually, when you have arrived, you make a phone
call to the person that you want to meet, and the person comes to the road
to search you and help you with the last part of the way – I can guarantee
you 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 of variant 4 (using an area) is that it
 really doesn't collide with however the routing aspects of the junction
 are mapped.

 @Lukas are the names of the traffic signals/junctions actually used in
 addresses (and in principal would be a suitable value for addr:place in
 an address)?

 Simon


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


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


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

2014-08-24 Thread Lukas Sommer
Hello everyone.

In some countries (Japan, Korea…), people orient themselves in the local
area using the names of road junctions or traffic signals rather then the
names of streets.

I have documented the current tagging practice for simple junctions at the
following new wiki pages:

http://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names

http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes

Furthermore, some more text has been added here:

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29

Feedback and/or corrections are welcome.

The current tagging practice works well for simple junctions, but makes
problems on complex junctions. Therefore, the proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
has been created. 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-07-24 Thread Lukas Sommer
How to tag road junction names and traffic signal names?

Background:
In some countries (Japan, Korea, Ivory Coast…) people orient themselves in
the local area using the names of road junctions (like crossroads or
roundabouts) or traffic signals rather then the names of streets. While
street names also exist, they are not important for orientation. (Note:
This is about orientation in the local area, thus different from the names
of motorway junctions who’s names serve for orientation at large distances.)

Use case:
This information is necessary for rendering maps and can be useful for
turn-to-turn navigation.

Current situation:
We have the tags highway=traffic_signals (for traffic signals on road
junctions or at straight roads – typical for Japan) and junction=yes (for
road junctions with or without traffic signals – typical for Ivory Coast)
in use at OSM. Both tags are almost exclusively used on nodes. They can be
used together with name=*. This works quite well for simple crossroads
(example: http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png
)

Shortcomings of the current situation:
It isn’t defined how to tag more complex cases. This should be made clear –
also because we want to have a suitable rendering for this in
openstreetmap-carto (
http://github.com/gravitystorm/openstreetmap-carto/issues/374).

Ideas for road junction names (countries like Ivory Coast):
Example: http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_2.png
is a junction in Ivory Coast. How can we tag the junction? If we make a
node at the red point (centre of the junction), this will be fine for
rendering (rendering the name at the position of the red point), but not as
easy for turn-to-turn navigation because the point is not part of a way. We
could also tag the four nodes where the ways cross. This will be fine for
turn-to-turn navigation, but not as easy for rendering (sorting out
duplicates because you should render the name only once, not four times).
Furthermore, you have to provide the same information four times (and you
can make a spelling mistake four times). You could also use a new relation
type, which contains the four nodes where the ways cross. This is a clean
solution, but complicates to use for beginners, and complicate for a quite
simple task like adding a name of a junction. We could also make an area
(closed way) around the junction area, sharing nodes with all incoming and
outgoing ways. This would be less “clean” tagging than a relation would,
but it is much easier to use for beginners, and be still quite easy to
process for rendering and (I think) also routing. (PS: Another type of
“complex junctions” are roundabouts like
http://www.openstreetmap.org/#map=19/5.35590/-4.07360 in Ivory Coast. You
will not use the name=* tag on the way that makes up the roundabout itself
because this would render like in western countries as a label of the
street itself. Instead, you need something different that renders bigger –
so the tagging should also provide a solution for this use case.)

Ideas for traffic signal names (countries like Japan):
On the ground, each traffic signal in complex crossroads seems to have its
own sign showing the name. Searching a little bit around, I’ve found at
http://gis.19327.n5.nabble.com/Crossroad-names-td5754463.html
 As theory, the names of Japanese traffic signals are given to each
 signals, not to a junction.
 (and basically, the signals on a same junction has same names)
However, rendering each name four times may not be very nice. Google and
Bing display the name only once (
http://tools.geofabrik.de/mc/#18/34.3847/132.4542num=4mt0=mapnikmt1=google-mapmt2=bing-mapmt3=geofabrik-topo),
in the middle of the crossroad. They even display the traffic signal icon
only once. Currently, in OSM there seem to be for Japan the name at each of
the nodes where the ways cross. How can we get 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?

2014-07-24 Thread Lukas Sommer
Yes, I know that junction=yes works fine for simple crossroads. My question
is: How should we map complex junctions like
http://www.openstreetmap.org/node/2351057522#map=19/5.34399/-4.00300 Using
just an unconnected node like in this example (even after removing the
wrong place=hamlet tag) maybe 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%3Dyes can
 be useful for a simple junction node that has a name
 http://wiki.openstreetmap.org/wiki/Key:name=*
 http://wiki.openstreetmap.org/wiki/Tag:name%3D* tag

 I'm using that in the OSM-FR rendering... and even deal with
 traffic_signals icon shift to display both icon+name. ;)



 2014-07-24 16:42 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com:


 2014-07-24 15:24 GMT+02:00 Lukas Sommer sommer...@gmail.com:

 Current situation:
 We have the tags highway=traffic_signals (for traffic signals on road
 junctions or at straight roads – typical for Japan) and junction=yes (for
 road junctions with or without traffic signals – typical for Ivory Coast)
 in use at OSM. Both tags are almost exclusively used on nodes. They can be
 used together with name=*. This works quite well for simple crossroads
 (example:
 http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png)

 Shortcomings of the current situation:
 It isn’t defined how to tag more complex cases.




 maybe the junction key can be used more universally (with different
 values), we are already using it also with junction=roundabout, only that
 it could be disputed that junction=roundabout is covering the whole
 junctions (the entries and exits you often have to a roundabout could be
 seen as part of the junction for instance). More in-use values can be found
 here: http://taginfo.openstreetmap.org/keys/junction#values
 Some of them maybe aren't junctions (what kind of junction is
 approach?), others are diverging from our standard mantra (no
 abbreviations), like spui or ddi and might merit retagging?

 cheers,
 Martin

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




 --
 Christian Quest - OpenStreetMap France

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


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


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

2014-07-24 Thread Lukas Sommer
junction=yes will probably be rendered by openstreetmap-carto soon.

However:

– Can we accept a simple (not connected) node with junction=yes and name=*
in spite of the problems in turn-to-turn navigation?

– Is using a relation for this to complicate? But it would be a clean
solution to have 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 danstowell+...@gmail.com:

 If place=hamlet is wrong, I believe place=locality is often used as a
 generic tag for nodes indicating named locations. Not really a
 solution but a simple option.

 Dan

 2014-07-24 17:01 GMT+01:00 Lukas Sommer sommer...@gmail.com:
  Yes, I know that junction=yes works fine for simple crossroads. My
 question
  is: How should we map complex junctions like
  http://www.openstreetmap.org/node/2351057522#map=19/5.34399/-4.00300
 Using
  just an unconnected node like in this example (even after removing the
 wrong
  place=hamlet tag) maybe 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 can be useful for a simple junction node that has a name=*
  tag
 
  I'm using that in the OSM-FR rendering... and even deal with
  traffic_signals icon shift to display both icon+name. ;)
 
 
 
  2014-07-24 16:42 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com
 :
 
 
  2014-07-24 15:24 GMT+02:00 Lukas Sommer sommer...@gmail.com:
 
  Current situation:
  We have the tags highway=traffic_signals (for traffic signals on road
  junctions or at straight roads – typical for Japan) and junction=yes
 (for
  road junctions with or without traffic signals – typical for Ivory
 Coast) in
  use at OSM. Both tags are almost exclusively used on nodes. They can
 be used
  together with name=*. This works quite well for simple crossroads
 (example:
  http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png)
 
  Shortcomings of the current situation:
  It isn’t defined how to tag more complex cases.
 
 
 
 
  maybe the junction key can be used more universally (with different
  values), we are already using it also with junction=roundabout, only
 that it
  could be disputed that junction=roundabout is covering the whole
 junctions
  (the entries and exits you often have to a roundabout could be seen as
 part
  of the junction for instance). More in-use values can be found here:
  http://taginfo.openstreetmap.org/keys/junction#values
  Some of them maybe aren't junctions (what kind of junction is
  approach?), others are diverging from our standard mantra (no
  abbreviations), like spui or ddi and might merit retagging?
 
  cheers,
  Martin
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging
 
 
 
 
  --
  Christian Quest - OpenStreetMap France
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging
 
 
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging
 

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

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


Re: [Tagging] tagging of a throughabout

2014-06-30 Thread Lukas Sommer
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.2Fthroughabout.2Fcut-through
 for a description).



 I would probably tag this in analogy to a Y-shaped junction, a
 T-junction or a cloverleaf interchange: map the individual roads. End.

 It is not a roundabout, so there are no additional generally approved tags.
 Of course you could also add a junction=hamburger_roundabout, why not. (The
 only risk is that the next armchair mapper, improving the map remotely,
 would probably change this to roundabout because hamburger-roundabout is
 not in his canon of acceptable tags).

 cheers,
 Martin



-- 
Lukas Sommer

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


[Tagging] tagging of a throughabout

2014-06-29 Thread Lukas Sommer
Hello.

How do I tag correct a Hamburger roundabout/throughabout/cut-through (see
http://en.wikipedia.org/wiki/Roundabout#Hamburger_roundabout.2Fthroughabout.2Fcut-through
for a description).

My thoughts: The OSM wiki describes a roundabout at
http://wiki.openstreetmap.org/wiki/Tag:junction=roundabout with these
points:

– where the traffic goes around a non-traversable island (or a void in case
of elevated roads) in the middle

– the traffic on the roundabout has right of way.

Both conditions are not true for hamburger roundabouts/throughabouts. So I
would say that a hamburger roundabout – in spite of its name – is not a
roundabout, but a traffic circle (see
http://wiki.openstreetmap.org/wiki/Tag:junction=roundabout#Possible_misinterpretations
for details).
Consequently they are not tagged with junction=roundabout, but like normal
roads or carriageways (and using turn restrictions where appropriate).

Am I right?

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