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

[johnw]

> in OSM we focus on ground truth and having a local (!) community taking care of the data and keeping it in shape.

The expected iconography differs between countries, as they are shown on maps differently in the different countries. At least comparing Japan to America, what they expect to be displayed and how it is represented differs greatly. We have to be flexible enough to let the rendering of one country differ from one to the next, if if follows the societal conventions of their maps. 

If we can't designate a single signal icon for the complex intersections in japan, and offer named signals as well, we are choosing to make an inferior map for Japanese users because it doesn't conform to the groups opinion on what it should be outside Japan. 

So the sentiment about local users and whatnot is just puffery.

Junctions naming in Korea happens to align better but "ground truth" is that people in Japan call them signals, publish maps with signals, show signals on signs, ads, billboards, and online - everything revolves around the consistent display of signals if we are going to render them. we will eventually have to clean up the multitude of signals rendered by OSM, and this is one reason why. 

This is a local tagging-rendering issue in search of a solution supported by the group  - a single (horizontal?) signal icon is required to be displayed per junction with a signal, regardless of the number of actual signal nodes that are needed for a complex intersection, and it has to have an optional name rendered with it.

Google conformed to this a few years ago, when they stepped up their mapping by importing and now improving zenrin's data. 
https://www.google.co.jp/maps/@36.4108183,139.3363032,17z?hl=en

Apple's initial map was crap, mostly because it was based on old OSM data using imports that were never cleaned up. 3 months later, AppleMaps got a significant overhaul (they also imported and are now improving a local dataset), and every month they get better, even for me out here in the sticks. They also initially didn't support the signal icon, and now fully support it.   PS - the Japanese post office icon is also used - another local custom we'll have to adapt to as well. Still waiting on the proper JR rail line rendering though. 



OSM will have to do it too.  What other way do you suggest that this be accomplished? Pushing it off is an option, but this is something that a rendered map from OSM will eventually be *required to display this in this particular fashion* in Japan. 

Javbw



On Sep 18, 2014, at 2:35 AM, fly <lowflight66 at googlemail.com> wrote:

> So far, highway=traffic_signal is only defined for nodes and there are
> only few ways and fewer relations.
> 
> 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
> 
> Am 17.09.2014 00:06, schrieb johnw:
>> Correct me if I'm wrong, but it sounds like the end goal is:
>> 
>> - to have junction names in korea, regardless of if they are traffic
>> lights, and the symbol used there doesn't imply traffic lights, just a
>> junction.
>> 
>> - In Japan, the old junction system evolved to be named traffic signals,
>> and the symbol used there a  (horizontal) "signal" - so the end goal is
>> to have the name and the signal icon shown over the intersection with
>> it's name. 
>> 
>> 
>> so the "complex solution" is to map the the junction, (with different
>> tags for Japan and Korea)  with the area's way sharing nodes with the
>> traffic signals.
>> 
>> - in Japan's case, the complex solution must only render a single
>> traffic icon, or it will ruin the purpose of using the intersection icon.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140919/0814b46c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AppleMap.jpg
Type: image/jpg
Size: 13918 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140919/0814b46c/attachment-0001.jpg>