Re: [Tagging] amenity=bicycle_repair_station

[Bryce Nesbitt]

On Mon, Nov 9, 2015 at 7:59 PM, Andrew Guertin 
wrote:

> A quick search shows me there are 1922 total things mapped
> amenity=bicycle_repair_station, and of those 311 have a name tag. Assuming
> that all of the repair shops will have a name tag, and only some of the
> things with names are shops, this puts an upper bound of a few hundred
> incorrectly mapped shops. Of course, it could be hard to tell, as some
> shops could have outdoor tool stands...
>

The import that launched this tag included names (typically the nearest
building on campus).

A number of the things that are really repair shops don't have names.

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

Re: [Tagging] amenity=bicycle_repair_station

[Bryce Nesbitt]

On Mon, Nov 9, 2015 at 7:26 PM, Clifford Snow 
wrote:

> Bryce,
> I've found a couple of these. One was exactly where the node was placed.
> The other, in Omaha, was a substantial ways away. And I still have found
> any of the four at the University of Washington in Seattle. I'm concerned
> that the locations are not accurate enough to have a bot add a node.
>

This is distributed human mapping at it's finest.
Tool stands are too small to show up on an air photo: armchair mappers need
not apply.
The correctly mapped nodes are largely the result of map notes.

A typical map note says that a tool stand is probably nearby based on a
press release: could a boots-on-the-pedals cycle over and check it out?
Hundreds have.  It's worked great in the USA (not so much in the UK).

PLEASE delete stations that are really not there.  I know it's hard.  Turn
'em into a map note perhaps, but definitely don't leave them as broken
glass in OSM.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=residential_link

[Tod Fitch]

I am pretty sure that I am one of the mappers that have used residential_link 
as a highway value in cases where there was a separate way for making a right 
turn from one residential road to another.

If the two roads the connecting way links are tagged as residential I don’t see 
any other choice than to use residential_link. I don’t think that service works 
for that (and some routers only allow passage over a service way at the ends of 
a route so that would mess them up). And tagging it with a higher 
classification (e.g. tertiary_link) makes no sense to me either.

The only alternative would be to tag it as residential which seems to lose some 
meaning to me as the ones I can think of are too short to have residences on 
them.

-Tod
N76 on OSM

> On Nov 9, 2015, at 10:37 PM, Andrew Guertin  wrote:
> 
> A question recently came up as to whether highway=residential_link is a 
> meaningful tag or whether uses of it should be changed to some other value 
> (like highway=residential or highway=service).
> 
> This tag has no description in the wiki, though it is analogous to the other 
> highway=*_link types described on 
> https://wiki.openstreetmap.org/wiki/Highway_link .
> 
> There are only 23 current uses of the tag, but many others were recently 
> removed. By going through (by hand) the recent edits of an editor who removed 
> them, I've come up with a list of 58 more objects that used it [1]. If anyone 
> knows of a programmatic way of finding objects that previously used a tag, 
> I'd be interested to know it.
> 
> Of those 81 current and recent uses that I worked with,
> * They occurred in North America (36), South America (30), Europe (11), and 
> Australia (4)
> * 35 were added in 2015, 38 were added in 2014, and the remaining 8 were 
> added in 2010-2013
> * I count 33 unique users that added the tag
> * 19 of the uses had a value for name="*", 62 did not have a name
> 
> * Of the 36 North American uses, I personally think highway=residential_link 
> makes sense on 16 of them, while 12 should be a higher highway=*_link and 8 
> should not be a _link at all.
> 
> 
> highway=residential_link is not currently rendered in openstreetmap-carto, 
> and a request for adding it in February 2015 was declined 
> (https://github.com/gravitystorm/openstreetmap-carto/issues/1280), due to low 
> usage and being undocumented. That bug mentions that it is supported in 
> various routing apps, and it WAS supported in the HOT map style until that 
> support was removed recently.
> 
> 
> So the question is, should uses of highway=residential_link be edited away, 
> should they be left as-is (unless a different highway type is clearly 
> better), or should the tag be approved and documented?
> 
> 
> --Andrew
> 
> 
> 
> 
> 
> [1] Objects that previously used highway=residential_link. This list was 
> generated by hand, and might have some mistakes. Also, not all of these 
> necessarily should have used the tag.
> 
> 275610032, 275610033, 275610026, 275610025, 275355353, 269193467, 268796394, 
> 262798921, 262715792, 262287021, 259433293, 259433291, 259136210, 256321591, 
> 256321612, 256256231, 82529183, 256250694, 256250692, 255858772, 255734560, 
> 255734548, 255734547, 255734546, 255285030, 255282915, 255282916, 242373220, 
> 240563513, 238260570, 237128774, 222995985, 318225690, 219160095, 200773019, 
> 191613798, 183497432, 174739362, 174739436, 173790274, 152304285, 95348547, 
> 87908508, 87908510, 87908507, 83285340, 54356292, 54356293, 45812108, 
> 45812107, 39722340, 35248433, 148015236, 35242001, 35121698, 35121488, 
> 18820600, 6086632, 6107802,
> 
> 
> 
> On 11/09/2015 01:39 AM, GerdP wrote:
>> I think this should really be discussed in the tagging list.
>> I only know a discussion in Germany which came to the
>> conclusion that tags like unclassified_link, residential_link and
>> service_link make not much sense:
>> http://forum.openstreetmap.org/viewtopic.php?id=26083
>> The wiki doesn't mention those _link types as well, and my
>> understanding is that only major roads have a link (if link
>> in english means what we call "Abfahrt/ Auffahrt" in Germany,
>> I would describe it as a lane that allows to decrease/increase
>> speed.
> 
> 
> 
> ___
> 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] highway=residential_link

[Andrew Guertin]

A question recently came up as to whether highway=residential_link is a 
meaningful tag or whether uses of it should be changed to some other 
value (like highway=residential or highway=service).


This tag has no description in the wiki, though it is analogous to the 
other highway=*_link types described on 
https://wiki.openstreetmap.org/wiki/Highway_link .


There are only 23 current uses of the tag, but many others were recently 
removed. By going through (by hand) the recent edits of an editor who 
removed them, I've come up with a list of 58 more objects that used it 
[1]. If anyone knows of a programmatic way of finding objects that 
previously used a tag, I'd be interested to know it.


Of those 81 current and recent uses that I worked with,
* They occurred in North America (36), South America (30), Europe (11), 
and Australia (4)
* 35 were added in 2015, 38 were added in 2014, and the remaining 8 were 
added in 2010-2013

* I count 33 unique users that added the tag
* 19 of the uses had a value for name="*", 62 did not have a name

* Of the 36 North American uses, I personally think 
highway=residential_link makes sense on 16 of them, while 12 should be a 
higher highway=*_link and 8 should not be a _link at all.



highway=residential_link is not currently rendered in 
openstreetmap-carto, and a request for adding it in February 2015 was 
declined 
(https://github.com/gravitystorm/openstreetmap-carto/issues/1280), due 
to low usage and being undocumented. That bug mentions that it is 
supported in various routing apps, and it WAS supported in the HOT map 
style until that support was removed recently.



So the question is, should uses of highway=residential_link be edited 
away, should they be left as-is (unless a different highway type is 
clearly better), or should the tag be approved and documented?



--Andrew





[1] Objects that previously used highway=residential_link. This list was 
generated by hand, and might have some mistakes. Also, not all of these 
necessarily should have used the tag.


275610032, 275610033, 275610026, 275610025, 275355353, 269193467, 
268796394, 262798921, 262715792, 262287021, 259433293, 259433291, 
259136210, 256321591, 256321612, 256256231, 82529183, 256250694, 
256250692, 255858772, 255734560, 255734548, 255734547, 255734546, 
255285030, 255282915, 255282916, 242373220, 240563513, 238260570, 
237128774, 222995985, 318225690, 219160095, 200773019, 191613798, 
183497432, 174739362, 174739436, 173790274, 152304285, 95348547, 
87908508, 87908510, 87908507, 83285340, 54356292, 54356293, 45812108, 
45812107, 39722340, 35248433, 148015236, 35242001, 35121698, 35121488, 
18820600, 6086632, 6107802,




On 11/09/2015 01:39 AM, GerdP wrote:

I think this should really be discussed in the tagging list.
I only know a discussion in Germany which came to the
conclusion that tags like unclassified_link, residential_link and
service_link make not much sense:
http://forum.openstreetmap.org/viewtopic.php?id=26083
The wiki doesn't mention those _link types as well, and my
understanding is that only major roads have a link (if link
in english means what we call "Abfahrt/ Auffahrt" in Germany,
I would describe it as a lane that allows to decrease/increase
speed.




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

Re: [Tagging] amenity=bicycle_repair_station

[John Willis]

> On Nov 10, 2015, at 12:59 PM, Andrew Guertin  wrote:
> 
> amenity=bicycle_tool_stand

+1

Self_serve_bicycle_tool_stand is also good too, if you want to really drive the 
point home, though a bit long. 
Javbw. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=bicycle_repair_station

[Andrew Guertin]

On 11/09/2015 09:41 PM, Bryce Nesbitt wrote:

amenity=bicycle_repair_station has a problem: it's attracting lots of
active tagging
of shops offering bicycle repair.  For example:
http://www.openstreetmap.org/node/3772809894
and http://www.openstreetmap.org/way/337421757


That was not the intent.  amenity=bicycle_repair_station was meant for
unattended
tool stands, often outdoors, often 24/7, generally public.

I'm seeking support for a mechanical edit to a new tag name.
There are known automated clients of this tag, and I am in contact with
both.


I'd support a name change.

If you're looking for suggestions, perhaps

amenity=bicycle_tool_station or
amenity=bicycle_tool_stand

which avoids the problem by describing what it IS rather than what 
happens there, while hopefully also not sounding like a place where you 
can buy bicycle tools (which amenity=bicycle_tools might).



How do you plan to deal with the incorrectly tagged shops? Leave them as 
bicycle_repair_station? Give them a new tag of their own? Keep them in 
the automated edit and hope the new tag name just stops more from being 
added?


A quick search shows me there are 1922 total things mapped 
amenity=bicycle_repair_station, and of those 311 have a name tag. 
Assuming that all of the repair shops will have a name tag, and only 
some of the things with names are shops, this puts an upper bound of a 
few hundred incorrectly mapped shops. Of course, it could be hard to 
tell, as some shops could have outdoor tool stands...


--Andrew

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

Re: [Tagging] amenity=bicycle_repair_station

[Clifford Snow]

On Mon, Nov 9, 2015 at 6:41 PM, Bryce Nesbitt  wrote:

> amenity=bicycle_repair_station has a problem: it's attracting lots of
> active tagging
> of shops offering bicycle repair.  For example:
> http://www.openstreetmap.org/node/3772809894
> and http://www.openstreetmap.org/way/337421757
>
>
> That was not the intent.  amenity=bicycle_repair_station was meant for
> unattended
> tool stands, often outdoors, often 24/7, generally public.
>
> I'm seeking support for a mechanical edit to a new tag name.
> There are known automated clients of this tag, and I am in contact with
> both.


Bryce,
I've found a couple of these. One was exactly where the node was placed.
The other, in Omaha, was a substantial ways away. And I still have found
any of the four at the University of Washington in Seattle. I'm concerned
that the locations are not accurate enough to have a bot add a node. I'll
be on campus next week. If it isn't raining, I'll look again. Now that I've
seen a couple of the repair stations maybe I can spot these.

We are also in conversation with a state wide cycling group to do an OSM
presentation in 2016. I can certainly bring it up then.

If the mechanical edit only touches existing nodes, then I think you should
proceed.

Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] amenity=bicycle_repair_station

[Bryce Nesbitt]

amenity=bicycle_repair_station has a problem: it's attracting lots of
active tagging
of shops offering bicycle repair.  For example:
http://www.openstreetmap.org/node/3772809894
and http://www.openstreetmap.org/way/337421757


That was not the intent.  amenity=bicycle_repair_station was meant for
unattended
tool stands, often outdoors, often 24/7, generally public.

I'm seeking support for a mechanical edit to a new tag name.
There are known automated clients of this tag, and I am in contact with
both.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Named junctions

[John Willis]

> On Nov 9, 2015, at 9:38 PM, tomoya muramoto  wrote:
> 
> *You want to establish a new tag such as traffic_signals_area to solve 
> multiple signals rendering.
> *Opinions on the new tag are welcome from Japanese/Asian community because 
> rendering of traffic signal and its name is very important for (car) 
> navigation in Japan/Asia.

This is correct. 

We were also using this to solve multiple renderings of the name label as well 
(for named signals), but it could also be useful outside of Japan, like in 
Korea. 

However, Korea labels the junctions - they could be stop signs.  In Japan, the 
named item is always a set of signals. 

Perhaps we would need to do the same for signals and junctions separately, or 
it can be combined together. 

I don't care about the method, just that it is reliable. I believe the method 
will involve additional tagging for complex intersections, and may be optional 
for simple ones. 

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

Re: [Tagging] Named junctions

[Martin Koppenhoefer]

2015-11-09 14:14 GMT+01:00 Andrew Errington :

> It could be something like "when a named traffic light node is found,
> add it to a group with that name.  When it's time to label the map,
> decide how much space is available for the label, depending on the
> zoom level.  At low zoom, draw a single traffic light icon, centred on
> the average of the nodes in the group.  At medium zoom, draw a single
> icon and a label.  At high zoom, draw an icon for each node, and a
> single label in the centre".  This would also work for single named
> traffic lights (they are in a group of one).  Single unnamed traffic
> lights would work if they are alone (i.e. on a simple junction).
> Unnamed traffic lights close together would not work (because they can
> not be grouped by name), but there could be a pre-processing step that
> makes a group based on the nodes being close together, say within 10m
> of each other.
>



relying on name equality and distance is not very reliable to determine
where the desired junction objects are / how many of them are there (every
new node added with a missing name or a slightly differently spelled name
will create a new traffic-light/junction group)

A junction object for every relevant junction is more work initially, but I
guess it would be more stable. Also it would always lead to the same
results in different tools, compared to named junctions mapped implicitly
and being determined by attributes on single traffic lights, what would
require some processing which will likely be optimized differently in
different tools, because there will probably always remain edge cases that
don't work.

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

Re: [Tagging] Named junctions

[Andrew Errington]

Surely this is a rendering problem?

In other words, if there are many named traffic lights within a
certain distance of each other then only one symbol/name/whatever
should be rendered?  If the traffic lights are all tagged the same
then it ought to be even easier.

Adding an area with a tag is just a band-aid, plus it's a lot of work
for mappers.  If we can distil a rule from the data then the computer
can do all the work for us.  Unfortunately, writing software is also
hard, and we have to hope somebody else will do it, but having a clear
explanation of the task is a great help.

It could be something like "when a named traffic light node is found,
add it to a group with that name.  When it's time to label the map,
decide how much space is available for the label, depending on the
zoom level.  At low zoom, draw a single traffic light icon, centred on
the average of the nodes in the group.  At medium zoom, draw a single
icon and a label.  At high zoom, draw an icon for each node, and a
single label in the centre".  This would also work for single named
traffic lights (they are in a group of one).  Single unnamed traffic
lights would work if they are alone (i.e. on a simple junction).
Unnamed traffic lights close together would not work (because they can
not be grouped by name), but there could be a pre-processing step that
makes a group based on the nodes being close together, say within 10m
of each other.

A relation would also be a good solution.  Group the traffic lights
together and add them to a relation with the junction name.  Then
render icons and/or labels for each relation, based on the zoom level.
This would make the rendering code easier, but would be a lot of work
for mappers.

Andrew

On 09/11/2015, tomoya muramoto  wrote:
> Hi Javbw, I want to confirm your point.
>
> *You want to establish a new tag such as traffic_signals_area to solve
> multiple signals rendering.
> *Opinions on the new tag are welcome from Japanese/Asian community because
> rendering of traffic signal and its name is very important for (car)
> navigation in Japan/Asia.
>
> You showed another issue such as dual labels or default map localization,
> but I want to focus on the above issue at this time.
>
> I will post a mail to Japanese ML after some document translation finished
> such as traffic_signals_area.
>
> --
> I like Mapion too. But Mapion is not perfect.
>
> At first, check Yahoo map.
> http://maps.loco.yahoo.co.jp/maps?type=scroll&datum=wgs&mode=map&pointer=off&lat=35.4573089010882&lon=139.619295364418&z=19
> You will see an unnamed traffic signal just north of Tobe (戸部) station.
>
> However Mapion doesn't show it.
> http://www.mapion.co.jp/m2/35.45725737865473,139.61930034601284,19
> And Google map doesn't show it.
>
> And you will notice multiple traffic signals rendering on Mapion just east
> of that signal. Nothing is perfect. But at least we can make OSM better.
>
> muramoto
>
> 2015-11-09 20:28 GMT+09:00 Michał Brzozowski :
>
>> On Mon, Nov 9, 2015 at 11:59 AM, johnw  wrote:
>>
>> > Google Maps is actually two different sets of data: Google’s and a
>> Japanese
>> > GIS company, Zenrin. They have basically surveyed all of Japan building
>> by
>> > building, and everything is drawn area based (because the roads in
>> > Japan
>> can
>> > be such weird shapes and always change width suddenly).
>>
>> Frankly I don't find their road system to be that different to
>> necessitate areal representation, I guess it's more of a tradition
>> thing. But if you don't know, there is area:highway tagging scheme
>> developed by Marek Kleciak that allows to represent roads as areas, as
>> an extension to their linear representation. Note this is distinct
>> from area=yes highways that simply don't have any meaningful axis. If
>> there are resources available, people of Polish community (marimil)
>> could help set up a visualization layer for it.
>>
>> Michał
>>
>> ___
>> 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] Named junctions

[tomoya muramoto]

Hi Javbw, I want to confirm your point.

*You want to establish a new tag such as traffic_signals_area to solve
multiple signals rendering.
*Opinions on the new tag are welcome from Japanese/Asian community because
rendering of traffic signal and its name is very important for (car)
navigation in Japan/Asia.

You showed another issue such as dual labels or default map localization,
but I want to focus on the above issue at this time.

I will post a mail to Japanese ML after some document translation finished
such as traffic_signals_area.

--
I like Mapion too. But Mapion is not perfect.

At first, check Yahoo map.
http://maps.loco.yahoo.co.jp/maps?type=scroll&datum=wgs&mode=map&pointer=off&lat=35.4573089010882&lon=139.619295364418&z=19
You will see an unnamed traffic signal just north of Tobe (戸部) station.

However Mapion doesn't show it.
http://www.mapion.co.jp/m2/35.45725737865473,139.61930034601284,19
And Google map doesn't show it.

And you will notice multiple traffic signals rendering on Mapion just east
of that signal. Nothing is perfect. But at least we can make OSM better.

muramoto

2015-11-09 20:28 GMT+09:00 Michał Brzozowski :

> On Mon, Nov 9, 2015 at 11:59 AM, johnw  wrote:
>
> > Google Maps is actually two different sets of data: Google’s and a
> Japanese
> > GIS company, Zenrin. They have basically surveyed all of Japan building
> by
> > building, and everything is drawn area based (because the roads in Japan
> can
> > be such weird shapes and always change width suddenly).
>
> Frankly I don't find their road system to be that different to
> necessitate areal representation, I guess it's more of a tradition
> thing. But if you don't know, there is area:highway tagging scheme
> developed by Marek Kleciak that allows to represent roads as areas, as
> an extension to their linear representation. Note this is distinct
> from area=yes highways that simply don't have any meaningful axis. If
> there are resources available, people of Polish community (marimil)
> could help set up a visualization layer for it.
>
> Michał
>
> ___
> 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] Named junctions

[Michał Brzozowski]

On Mon, Nov 9, 2015 at 11:59 AM, johnw  wrote:

> Google Maps is actually two different sets of data: Google’s and a Japanese
> GIS company, Zenrin. They have basically surveyed all of Japan building by
> building, and everything is drawn area based (because the roads in Japan can
> be such weird shapes and always change width suddenly).

Frankly I don't find their road system to be that different to
necessitate areal representation, I guess it's more of a tradition
thing. But if you don't know, there is area:highway tagging scheme
developed by Marek Kleciak that allows to represent roads as areas, as
an extension to their linear representation. Note this is distinct
from area=yes highways that simply don't have any meaningful axis. If
there are resources available, people of Polish community (marimil)
could help set up a visualization layer for it.

Michał

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

Re: [Tagging] Named junctions

[Martin Koppenhoefer]

2015-11-09 11:59 GMT+01:00 johnw :

> This “necessity” to show signals is common among Japanese maps and
> properly localized maps. I want OSM to be just as good.



I can understand this desire, and given what was said in this respect, it
seems reasonable / indispensable for your region to show these particular
infos. BUT: there has to be a different tag to do it,
highway=traffic_signals is not the tag that is useful in this case, because
it is not a tag for a junction, but it is a tag for a node with a single
traffic lights instance (wiki: "Description: A traffic signal for
regulating circulation." and used only on nodes).

What you want / should have are entities which represent a junction, and
which has a "traffic_signals" attribute in case it is a junction that is
considered by the locals (and shown on common maps) as a junction with
signals. This would enable the style sheet maintainers to come up with a
dedicated solution adapted for Japanese navigation needs.

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

Re: [Tagging] Named junctions

[johnw]

> On Nov 8, 2015, at 7:17 PM, tomoya muramoto  wrote:
> 
> As for me, signals rendering seems not to be a big problem

I was looking around at the other maps, and the one I really like the look of 
is Mapion. 

http://www.mapion.co.jp/m2/36.396593778361435,140.5346977118126,15 


Mapion completely changes it’s rendering colors as you zoom in, and the signal 
icons are clear, but a bit later than I remember. 

Google Maps is actually two different sets of data: Google’s and a Japanese GIS 
company, Zenrin. They have basically surveyed all of Japan building by 
building, and everything is drawn area based (because the roads in Japan can be 
such weird shapes and always change width suddenly). 

Google uses their detailed base map for all higher zooms in Japan (in places 
with people actually living there).  This switch to Zenrin’s data happened 5-7 
years ago (I think) - Google Maps was always much better in Japan than the US 
because of this use of a third party data company with an insanely complete 
hand drawn map (the survey people walk neighborhoods once a year with a 
clipboard and draw changes). 

You can see the switch between the Google data and the Zenrin data between 
these two links. 

https://www.google.co.jp/maps/@36.4025147,140.5836863,16.93z 
 End of google 
data (z16)

https://www.google.co.jp/maps/@36.4025454,140.5838747,17.02z 
 Start of Zenrin 
street survey (z17) 

This level of detail is something google has been working to catch up with in 
the rest of their maps. But since Zenrin keeps improving the basemap and 
location database, it is still the best at high zoom. 

Signal icons are displayed in Google’s Z16 in Japan. 

Google has yet to display signals in San Diego.  (z 17) 
https://www.google.co.jp/maps/@32.7199724,-117.1657039,17.01z 
 

Of the stop light infront of the Googleplex.
https://www.google.co.jp/maps/@37.4219383,-122.0850782,17.86z 


This “necessity” to show signals is common among Japanese maps and properly 
localized maps. I want OSM to be just as good. 

Properly showing one icon per signal is my goal, and these other mapping 
software illustrate what I eventually expect to see (signal wise) in OSM. 

Javbw


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