Re: [Tagging] landuse=grass => natural=grass

[Martin Koppenhoefer]

2014-09-18 11:44 GMT+02:00 Pieren :

> I think the consensus is to stay as simple as possible and use only
> one tag to say that there is grass on this piece of land.
>


I think the consensus is to describe any property you like in OSM. Using
only one tag to summarize a lot of aspects is hardly ever a good idea,
because it limits the way to use the data and makes contributors life more
complicated and not easier (because they have to weight a lot of aspects
instead of directly tagging what they see).

cheers,
Martin
___
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

[johnw]

On Sep 19, 2014, at 5:59 AM, Lukas Sommer  wrote:

> * 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?

Differentiated tagging is needed for differentiated rendering.  "junction" vs 
"Signal". a single signal icon needs to be rendered in Japan for intersections. 

> 
> * 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.

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.  

if that's the case:

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


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

[Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

Hi all,

I have been fixing some university tagging (Sheffield contained
hundreds of amenity=university!). For student accommodation, I have
been using

 for buildings:   building=residential + residential=university + operator=*
OR
 for sites:   landuse=residential + residential=university + operator=*

Note that the same scheme seems to me to work well for building and for landuse.

I thought this had been discussed on tagging recently, but I can't
find it, all I can find is the RFC for amenity=dormitory, currently
used 263 times. (I will add that "dormitory" is certainly a little odd
from a British English point of view, notwithstanding the comments
already made to the RFC.)

residential=university has been used by a few people (99 objects, says
overpass). 33 of these are building=residential, 53 are
landuse=residential.

It's clear I'm not the only one using this pattern, though it's not an
approach that's officially adopted as far as I know. To me it seems
very meaningful usage, compatible with existing tagging, and covers
the intended use of amenity=dormitory except for monasteries ;)

Thoughts?

Best
Dan

___
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

[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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Tobias Knerr]

On 19.09.2014 14:22 Dan S wrote:
>  for buildings:   building=residential + residential=university + operator=*
> OR
>  for sites:   landuse=residential + residential=university + operator=*
> 
> Note that the same scheme seems to me to work well for building and for 
> landuse.
> 
> I thought this had been discussed on tagging recently, but I can't
> find it, all I can find is the RFC for amenity=dormitory, currently
> used 263 times. (I will add that "dormitory" is certainly a little odd
> from a British English point of view, notwithstanding the comments
> already made to the RFC.)

That proposal now suggests amenity=student_accommodation, precisely
because of the oddness involved with the term "dormitory".

Personally, I prefer using the amenity key rather than building or
landuse. Landuse lacks the implication that this is one distinct
facility, and building values are not supposed to represent usage, but
how the building is built.


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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Martin Koppenhoefer]

2014-09-19 14:22 GMT+02:00 Dan S :

>
>  for buildings:   building=residential + residential=university +
> operator=*
> OR
>  for sites:   landuse=residential + residential=university + operator=*
>
> Note that the same scheme seems to me to work well for building and for
> landuse.



I am not sure if this "works". Have you been looking at current values for
the "residential" key? These are the ones with more than 100 uses:

rural 
78 141

-

urban 
12 698

-

garden 
3 805

-

gated 
884

-

apartments 
231

-

single_family

197

-

detached 
133



There are already at least 3 different systems (one for rural / urban and
one for the building typology (detached / single_family / apartments) and
one for gated communities (what's this, socio-economic aspect of urbanism
maybe?). Now you seem to be adding yet another one, "university" for
student's appartments (not really self explaining IMHO).

I would use a specific tag for the building typology (e.g.
building=dormitory or student_accomodation or similar if the building was
built as such) and another one if it is actually used as such (e.g. under
the amenity key as suggested by Tobias).

I don't see this as a case for adding a specific landuse value, but I do
agree that refining the generic "residential" into more differentiated
values by subtagging might be a general option (regardless of this
particular case of student accomodation), e.g. differentiate according to
density and

structure (open / closed, not sure about the precise term in English, for
reference see these two pictures:
open (=space between buildings)
http://de.wikipedia.org/wiki/Offene_Bauweise_%28Baurecht%29#mediaviewer/File:Offene_Bauweise.png
closed (buildings without space between them):
http://de.wikipedia.org/wiki/Geschlossene_Bauweise_%28Baurecht%29#mediaviewer/File:Geschlossene_Bauweise.png

the above distinction is still quite generic, both of these types also have
a lot of subtypes (ideally, then there are mixed cases).

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

Re: [Tagging] The "not-shops": industrial, industry, or business

[Michał Brzozowski]

I'm surprised nobody so far mentioned Mapbox's Maki icon set:

https://www.mapbox.com/maki/

Another thing maps based on OSM lack is clickability (like Google Maps
or Bing Maps). It's less CPU intensive than placing markers
afterwards. Maybe there's some clever way to embed clickable spots
information (just coordinates) into the tiles themselves.
Michał

On Thu, Sep 18, 2014 at 11:08 PM, John F. Eldredge  wrote:
> Agreed. The general-purpose renderings, at least those intended for
> small-screen use, should use a limited number of icons, and those should
> each apply to a range of related object types. Large-screen and printed maps
> can use a wider range of icon types, since there is room for a map legend.
> Special-purpose renderings can use more specific icons, but may need to
> either include a legend or provide a link to a legend.
>
>
>
> On September 16, 2014 1:32:29 AM CDT, Frederik Ramm 
> wrote:
>>
>> Hi,
>>
>> On 09/15/2014 07:43 PM, Bryce Nesbitt wrote:
>>>
>>>  Maybe this is running up on the limit of only rendering shop values with
>>>  100 instances?
>>
>>
>> I think that many people think too much information science ("how can I
>> compress the most information into the smallest room") and too little
>> cartography ("how can I make a map with a good user interface").
>>
>> A map icon is what, 32x32 pixels or so? A couple of millimeters on the
>> screen. As long as you stick to 20 POI icons, you will be able to select
>> icons that are instantly recognizable. Something with a film strip...
>> must be a cinema. Once you introduce 100 icons, your map becomes
>> unreadable without a legend. Yes you *can* devise a film-strip-and-pipe
>> icon denoting a cinema that uniquely shows crime dramas but you're
>> leaving the realm of the easy-to-use map (much like having 5 different
>> types of dash-dot patterns for various types of tracks).
>>
>> It appears to me that unless the user actively requests to drill down
>> deeper on something (and we have the technology to do that), we should
>> stick with a very small number of icons.
>>
>> Maybe we can find a way to actually detect that shop=bicycle;skateboard
>> is some kind of sports-related shop and display a generic
>> sports-related-shop icon, the same that we would use for shop=bicycle or
>> shop=skateboard alone.
>>
>> Bye
>> Frederik
>>
>
> --
> John F. Eldredge -- j...@jfeldredge.com
> "Darkness cannot drive out darkness; only light can do that. Hate cannot
> drive out hate; only love can do that."
> Dr. Martin Luther King, Jr.
>
> ___
> 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

[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

[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 :

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

[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 :

> 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 :
>
>>
>> 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

[johnw]

I don't know much about how the rendering system parses the tags. I thought t 
would be non-trivial for it to work out how to display signal icons without a 
new tag, so I thought a new tag might be necessary, and  gave my suggestion. 

I'm aware the current system is in use a lot for simple 1 node intersections, 
but as the number of complex intersections increases (?micro-mapping?), so will 
the need for a solution.

Javbw

On Sep 19, 2014, at 11:32 PM, Lukas Sommer  wrote:

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

___
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

[johnw]

On Sep 20, 2014, at 6:37 AM, Lukas Sommer  wrote:

> 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

Great solution ^_^

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

[John Baker]

Yeah sadly it is fairly complex to display different icons in different 
locations. Not something we will doing in OSM carto for a good while.

From: jo...@mac.com
Date: Sat, 20 Sep 2014 07:07:56 +0900
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions 
or traffic signals that are named

I don't know much about how the rendering system parses the tags. I thought t 
would be non-trivial for it to work out how to display signal icons without a 
new tag, so I thought a new tag might be necessary, and  gave my suggestion. 
I'm aware the current system is in use a lot for simple 1 node intersections, 
but as the number of complex intersections increases (?micro-mapping?), so will 
the need for a solution.
Javbw
On Sep 19, 2014, at 11:32 PM, Lukas Sommer  wrote:
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


___
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

[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).

Javbw




On Sep 20, 2014, at 8:10 AM, John Baker  wrote:

> Yeah sadly it is fairly complex to display different icons in different 
> locations. Not something we will doing in OSM carto for a good while.
> 
> From: jo...@mac.com
> Date: Sat, 20 Sep 2014 07:07:56 +0900
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions 
> or traffic signals that are named
> 
> I don't know much about how the rendering system parses the tags. I thought t 
> would be non-trivial for it to work out how to display signal icons without a 
> new tag, so I thought a new tag might be necessary, and  gave my suggestion. 
> 
> I'm aware the current system is in use a lot for simple 1 node intersections, 
> but as the number of complex intersections increases (?micro-mapping?), so 
> will the need for a solution.
> 
> Javbw
> 
> On Sep 19, 2014, at 11:32 PM, Lukas Sommer  wrote:
> 
> 
> 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
> 
> 
> ___ Tagging mailing list 
> Tagging@openstreetmap.orghttps://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