On 08/19/2013 11:51 PM, Masi Master wrote:
This is a bit away from the new valley mountain discus, but has a
connection to the first mail.
Tagging should be thought-out with possible examples, if we don't want
to change the tagging or live with a bad tagging.
Another example I had just
Il giorno 18/ago/2013, alle ore 15:54, Yuri D'Elia
wav...@users.sourceforge.net ha scritto:
Just for clarity, I was really hoping to find an already-established
tagging scheme for these features (named topological areas, valleys),
and bringing up the schemes I found in several other places
Il giorno 18/ago/2013, alle ore 17:29, Craig Wallace craig...@fastmail.fm ha
scritto:
This is already done for ridges, with natural=ridge.
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge
It is used a bit. Not sure if any renderers show it.
ridges are linear
I think something
Il giorno 18/ago/2013, alle ore 17:54, Christian Müller cmu...@gmx.de ha
scritto:
The term boundary does not make any implication on it's width.
it has no width at all, it is a line
A boundary may be defined on a nanometer, meter or kilometer scale.
what doesn't say anything about a
Il giorno 18/ago/2013, alle ore 17:54, Christian Müller cmu...@gmx.de ha
scritto:
The term boundary does not make any implication on it's width.
it has no width at all, it is a line
-1. It may be _represented_ by a line, as declared by an entity. Even though
the boundaries of territories
On Sun, Aug 18, 2013 at 8:17 AM, Volker Schmidt vosc...@gmail.com wrote:
At the risk that this is mapping for the renderer, but what
Wolfgang proposes is exactly how it is done on traditional paper maps. It
gives you the possibility to label some loosely defined entity, by creating
some
Am 17.08.2013, 17:13 Uhr, schrieb fly lowfligh...@googlemail.com:
On 16.08.2013 19:05, Masi Master wrote:
The problem is, that multipolygon don't work in 2 cases:
- The areas touch each other.
- The areas are multipolygons. A multipolygon as a member in a other
multipolygon is not allowed.
On 08/17/2013 05:47 PM, Wolfgang Zenker wrote:
* fly lowfligh...@googlemail.com [130817 17:13]:
On 16.08.2013 19:05, Masi Master wrote:
Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
not an area?
Boundaries describe an area but you are right that they are not
At the risk that this is mapping for the renderer, but what
Wolfgang proposes is exactly how it is done on traditional paper maps. It
gives you the possibility to label some loosely defined entity, by creating
some labelling along a non visible way.
However, there is a serious complication in
On 2013-08-17 16:47, Wolfgang Zenker wrote:
Maybe we should try a completely different approach. We could draw
a way along the approximate center line of the feature and tag it
with name=*, topo_feature=mountain_range|ridge|valley|...
A renderer that wants to display the name should draw it
On 16.08.2013 19:05, Masi Master wrote:
Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
not an area?
Boundaries describe an area but you are right that they are not really
boundaries, especially if the border lines are not clearly defined
The problem is, that
Hi,
* fly lowfligh...@googlemail.com [130817 17:13]:
On 16.08.2013 19:05, Masi Master wrote:
Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
not an area?
Boundaries describe an area but you are right that they are not really
boundaries, especially if the border
On Sat, Aug 17, 2013 at 5:47 PM, Wolfgang Zenker
wolfg...@lyxys.ka.sub.org wrote:
I'm under the impression this discussion is leading to ever more complicated
ideas, due to the problem that the features we want to name on the map
are not really clearly defined areas.
+1
Maybe we should try a
2013/8/17 Pieren pier...@gmail.com
Maybe we should try a completely different approach. We could draw
a way along the approximate center line of the feature
or we could simply admit that OSM project is currently unable to map
such big features with fuzzy borders...
+1, a way is surely
* Friedrich Volkmann b...@volki.at [2013-08-09 07:28 +0200]:
I also dislike the suggested special member roles: The positioning
of the label depends on the font size, the free space, the map
section and zoom level etc. and should therefore be determined by
the renderer.
I tend to think of
On Tue, Aug 13, 2013 at 11:15 AM, Phil! Gold phi...@pobox.com wrote:
I tend to think of label nodes as hints for the renderer that provide it
with information it cannot derive on its own. The canonical example, I
think, is a town where it makes sense to place the label over the town
center,
On 08/08/2013 11:54 PM, Martin Koppenhoefer wrote:
I guess in this case I can simply re-use the geometry in a new relation
with the proper valley name with type=multipolygon, place=region,
region:type=valley?
I'd use type=multipolygon natural=valley
I'm still not satisfied with
On 09.08.2013 07:34, Friedrich Volkmann wrote:
On 08.08.2013 21:15, fly wrote:
On 08.08.2013 01:24, Pieren wrote:
I really hate type=collection. One of the worst idea in OSM. All
relations are collections.
+100
Especially, if you read: Relations are not meant to be used as
collections
Il giorno 10/ago/2013, alle ore 18:17, fly lowfligh...@googlemail.com ha
scritto:
Please use boundaries and not multipolygons !
for valleys??
boundaries are linear objects (generally delimiting areas), multipolygons are
areas
cheers,
Martin
___
On 08.08.2013 01:24, Pieren wrote:
On Wed, Aug 7, 2013 at 10:19 PM, Friedrich Volkmannb...@volki.at wrote:
It should rather be a type=collection relation.
I really hate type=collection. One of the worst idea in OSM. All
relations are collections.
At least it is semantically correct, while
On 08/07/2013 10:19 PM, Friedrich Volkmann wrote:
On 06.08.2013 15:51, Yuri D'Elia wrote:
http://www.openstreetmap.org/#map=14/45.2466/6.0866
which has been tagged with a multipoligon relation.
Unfortunately, the relation has some problems:
- not rendered anywhere?
This is a
Il giorno 08/ago/2013, alle ore 17:47, Yuri D'Elia
wav...@users.sourceforge.net ha scritto:
Though for places without actual physical attributes, place=location
sounds reasonable.
thing is that place=locality is very generic, you don't get additional
information what the name refers to,
On 08/08/2013 07:15 PM, Martin Koppenhoefer wrote:
Though for places without actual physical attributes, place=location
sounds reasonable.
thing is that place=locality is very generic, you don't get additional
information what the name refers to, especially if tagged on a node
Understood.
On 08/08/2013 08:56 AM, Friedrich Volkmann wrote:
On 08.08.2013 01:24, Pieren wrote:
On Wed, Aug 7, 2013 at 10:19 PM, Friedrich
Volkmannb...@volki.at wrote:
It should rather be a type=collection relation.
I really hate type=collection. One of the worst idea in OSM. All
relations are
On 08/07/2013 10:19 PM, Friedrich Volkmann wrote:
Similarly, we have areas for entire mountain groups, which are
fundamental for a topographic map in the alps. Again, the boundaries of
such areas are not so important, but it's mostly used as an indication
for the name placement.
On 08.08.2013 01:24, Pieren wrote:
On Wed, Aug 7, 2013 at 10:19 PM, Friedrich Volkmann b...@volki.at wrote:
It should rather be a type=collection relation.
I really hate type=collection. One of the worst idea in OSM. All
relations are collections.
+100
Especially, if you read: Relations
On 06.08.2013 19:25, Yuri D'Elia wrote:
The message from fly, about about boundary=topologic/geographic though
would solve nicely valleys, mountain groups _and_ other topographic
features under a single umbrella, and it's quite easy to achieve.
to fly: Is this some form of official
Il giorno 08/ago/2013, alle ore 20:45, Yuri D'Elia
wav...@users.sourceforge.net ha scritto:
I guess in this case I can simply re-use the geometry in a new relation
with the proper valley name with type=multipolygon, place=region,
region:type=valley?
I'd use type=multipolygon
On 08.08.2013 19:39, Yuri D'Elia wrote:
At least it is semantically correct, while type=site relations are often
used for features on multiple sites.
[...]
What about type=site with the appropriate natural tag?
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
See my paragraph
On 08.08.2013 21:15, fly wrote:
On 08.08.2013 01:24, Pieren wrote:
I really hate type=collection. One of the worst idea in OSM. All
relations are collections.
+100
Especially, if you read: Relations are not meant to be used as collections
It is interesting that you agree by +100 although
On Tue, Aug 6, 2013 at 11:19 PM, fly lowfligh...@googlemail.com wrote:
On 06.08.2013 16:27, Yuri D'Elia wrote:
Fortunately, the boundaries of the area are not important in themselves.
Nobody renders valley or mountain group borders. But we *do* use such
boundaries for name placement.
I
Il giorno 07/ago/2013, alle ore 10:00, Eugene Alvin Villar sea...@gmail.com
ha scritto:
This solution can also apply to bodies of water that are not whole lakes or
rivers. We currently (I think) do not tag the extent (even if fuzzy) of seas,
bays, inlets, coves, fjords, and the like.
On Wed, Aug 7, 2013 at 10:42 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
Il giorno 07/ago/2013, alle ore 10:00, Eugene Alvin Villar
sea...@gmail.com ha scritto:
We currently (I think) do not tag the ***extent*** (even if fuzzy) of
seas, bays, inlets, coves, fjords, and the like.
The best way I can think of for drawing oceans, is to put a tag on all
natural=coastline ways that are bordering it. Something like
ocean:name:en=Atlantic ocean.
Janko
___
Tagging mailing list
Tagging@openstreetmap.org
2013/8/7 Janko Mihelić jan...@gmail.com
The best way I can think of for drawing oceans, is to put a tag on all
natural=coastline ways that are bordering it. Something like
ocean:name:en=Atlantic ocean.
If you look closely onto this you'll see that there are not only the oceans
but a whole
2013/8/7 Martin Koppenhoefer dieterdre...@gmail.com
If you look closely onto this you'll see that there are not only the
oceans but a whole hierarchy of names seas and oceans and parts of them,
so there is not only one name per coastline but a lot of them. Dependent on
the scale of your
On 06.08.2013 15:51, Yuri D'Elia wrote:
http://www.openstreetmap.org/#map=14/45.2466/6.0866
which has been tagged with a multipoligon relation.
Unfortunately, the relation has some problems:
- not rendered anywhere?
This is a super-relation, with other relations as members. This is not
On Wed, Aug 7, 2013 at 10:19 PM, Friedrich Volkmann b...@volki.at wrote:
It should rather be a type=collection relation.
I really hate type=collection. One of the worst idea in OSM. All
relations are collections.
Pieren
___
Tagging mailing list
Hi everyone.
I'm in the alps, and I've been mapping some areas in the region.
I have two questions regarding tagging where I couldn't find a decent
consensus on the wiki.
There are many areas in the region that go by a specific name. I have
two cases where a group of lakes (as a whole) is known
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
Similarly, we have areas for entire mountain groups, which are
fundamental for a topographic map in the alps. Again, the boundaries of
such areas are not so important, but it's mostly used as an indication
for the name placement.
I don't
On 08/06/2013 04:14 PM, Janko Mihelić wrote:
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
Similarly, we have areas for entire mountain groups, which are
fundamental for a topographic map in the alps. Again, the boundaries of
such areas are not so important, but it's mostly used as an
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
Might still be problematic. A forest, sometime lakes, rivers for sure
and many other big polygons will cross the boundary of the mountain group.
I wouldn't tag rivers or forests with those tags, just nodes or little
ways. Tagging everything
On 06.08.2013 16:27, Yuri D'Elia wrote:
On 08/06/2013 04:14 PM, Janko Mihelić wrote:
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
Similarly, we have areas for entire mountain groups, which are
fundamental for a topographic map in the alps. Again, the boundaries of
such areas are not so
On 08/06/2013 04:27 PM, Yuri D'Elia wrote:
Might still be problematic. A forest, sometime lakes, rivers for sure
and many other big polygons will cross the boundary of the mountain group.
It's kind of unfortunate, because a mountain group will span across
italian regions and include parts of
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
On 08/06/2013 04:27 PM, Yuri D'Elia wrote:
It's really a topographical information, and I feel like tagging objects
within or using relations might be really problematic. Just imagine what
kind of spotty tagging would you have for big
On 08/06/2013 07:04 PM, Martin Koppenhoefer wrote:
For other areas other data types might be more adequate:
Some years ago on the German ML there was this interesting idea to define
(fuzzy) areas (e.g. lower scale topographic regions like the European
Alps). You put existing objects (like
2013/8/6 Yuri D'Elia wav...@users.sourceforge.net
Ridges can also be quite complex. Also, many times they end way before
the end of the end of the hill or do not exist at all (flat top
mountains).
good point
Just to say that the geometry might not always be there.
Also, is there a
47 matches
Mail list logo
