2014-09-18 11:44 GMT+02:00 Pieren pier...@gmail.com:
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
On Sep 19, 2014, at 5:59 AM, Lukas Sommer sommer...@gmail.com 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
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 +
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
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
2014-09-19 14:22 GMT+02:00 Dan S danstowell+...@gmail.com:
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
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
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
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
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,
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
On Sep 20, 2014, at 6:37 AM, Lukas Sommer sommer...@gmail.com 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
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
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?
14 matches
Mail list logo
