Re: [Tagging] Tagging of topographic areas with a name

2013-08-23 Thread Yuri D'Elia
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 yesterday was a lake called Seebergsee in
the alps.

The lake itself is comprised of a very small persistent lake which is
well delimited, and a marsh which is filled with water during 1/3 of the
year as the snow melts.

Independently of the tagging (which is well delimited in this case), the
name refers to the lake _and_ the marsh.

Maybe there's some waterway relation magic for this specific case, but
I'd rather use some consistent topological naming of areas also for
these cases.



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-18 Thread Yuri D'Elia
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 really
 boundaries, especially if the border lines are not clearly defined
 [..]
 
 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.

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 rather than
trying to overcomplicate things.

While I agree that rendering should follow tagging, I also go by the
idea that as long as the scheme is consistent, one could switch to an
improved one later quickly enough.

Also, the people involved with rendering should have a pretty decent
overview of how the tags are actually used, corner cases and the
limitations involved. This is as important as tagging itself IMHO (I was
rendering navteq data in the past, so I value a lot input from software
implementations).

I'm not sure if this list is followed by people involved with
styling/rendering OSM data itself? (please tell me if some other list
might be more appropriate).



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-12 Thread Yuri D'Elia
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 type=multipolygon:

http://wiki.openstreetmap.org/wiki/Multipolygon#Detailed_tagging

specifically:

* The relation has tags:
  Use the relation tagging. Ignore anything on the ways.

However, this is not what should happen for a lake group where each lake
name is independent (ie, the group is just a topological feature). And,
as I said before, unnamed lakes should not inherit the name of the group.

After re-reading the whole thread, I tend to agree with fly more, as a
boundary type seem to be much more appropriate:

type=boundary
boundary=topologic
natural=water
name=lake group name

the boundary relation has the advantage of not requiring a fake polygon
(as opposed to place=locality).

I have two examples of type=multipolygon which I introduced:

http://www.openstreetmap.org/browse/relation/3126464
http://www.openstreetmap.org/browse/relation/3126459

whole type=multipolygon relation simply broke the rendering (but
renderers here seem to be compliant).



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-08 Thread Yuri D'Elia
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 super-relation, with other relations as members. This is not
 allowed for multipolygon relations. It should rather be a
 type=collection relation. This is how water areas such as riverbanks use
 to be joined, and I use collection relations for sets of rocks etc. too.
 Don't expect dumb renderers like Mapnik to render superrelations, though.

Very good explaination.

 It seems to me that the closest tagging scheme might be a loose area
 with place=locality. Would that be a good idea?
 
 That depends on what the name belongs to. If it's the name of a lake,
 forest, or other physical feature, place=* would be just wrong.

After reading all the replies, it seems that if a group of lakes has a
name, I would probably use either a multipolygon (if feasible) or a
super-relation, with the appropriate natural tag.

Though for places without actual physical attributes, place=location
sounds reasonable.

It also looks like that the ThunderForest maps are correctly rendering
the place=location tag:

  http://www.opencyclemap.org/?zoom=11lat=46.5215lon=11.37205layers=000B

I will now convert this group to a super-relation.

My issue with normal multipolygons is also that smaller, unnamed lakes
inherit the name of the relation, which is incorrect.

 These proposals are somewhat obsolete, as natural=* has widely been
 accepted as the key for all geomorphological features. See
 http://wiki.openstreetmap.org/wiki/Key:natural, group 3. A valley is
 just the complement of a ridge or arete. Just draw a line along the
 valley and tag it with natural=valley.

I still have doubts about this. For the valley I'm speaking about the
whole region, which is an area.

By looking at your next pointer (about mountain_range), it looks like I
can follow the same scheme and use region_type=valley as a subtype.

 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.
 
 natural=mountain_range is already in use for the Alps. The mountain
 groups within the Eastern Alps are tagged place=region, see the members
 of relation 2113486.

This has been incredibly helpful!

I assume this is the data that is being used to render the topographic
map at dianacht.de? (http://geo.dianacht.de/topo/)



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-08 Thread Yuri D'Elia
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.



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-08 Thread Yuri D'Elia
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 collections.
 
 At least it is semantically correct, while type=site relations are often
 used for features on multiple sites.
 
 You can think of type=collection as an abbreviation of
 type=bare_and_general_collection. All other relations have special
 members (e.g. inner/outer in multipolygons) or at least special meanings
 (type=route).
 
 type=cluster has also been suggested. I would be ok with it, but it
 would require a proposal to make it more popular.
 

What about type=site with the appropriate natural tag?

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

I was just looking at the wiki, and type=collection seems to be pretty
frowned upon.



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-08 Thread Yuri D'Elia
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.
 
 natural=mountain_range is already in use for the Alps. The mountain
 groups within the Eastern Alps are tagged place=region, see the members
 of relation 2113486.

So, I was looking about using place=region for valleys.

At least for the valleys I was looking into, it seems that Italy already
has a boundary=administrative multipolygon for most of them, although
in rare cases some natural features are more detailed than the
administrative boundary.

Let's take this for example:

http://www.openstreetmap.org/browse/relation/47143

where the administrative boundary matches exactly with the actual valley.

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?



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


[Tagging] Tagging of topographic areas with a name

2013-08-06 Thread Yuri D'Elia
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 by a name, but
then each single lake has also his own lake.

I found an existing example in France, Les 7 Eaux:

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? I would expect that when the scale is high
enough, and there's no place to render the lake names, the name of the
relation is shown. But it's not. On the contrary, unnamed lakes simply
take the name of the relation.

- sometimes I not only have lakes, but I might have other features
inside that area, that are logically part of the same known spot. Is a
relation still a good idea in that case?

It seems to me that the closest tagging scheme might be a loose area
with place=locality. Would that be a good idea?

I did a test, here:

http://www.openstreetmap.org/#map=15/46.4696/10.7590

but again, no renderers seem to pick up this important information (the
name - the boundary itself is not important!), which would be especially
important for a topographic and landscape map.

A related question is the name of the valleys.
I saw several proposed tags in the wiki:

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region
http://wiki.openstreetmap.org/wiki/Proposed_features/Valley

but not really an official tagging scheme. Valley names are very
important features for a topographic map.

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.

Thanks!


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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-06 Thread Yuri D'Elia
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 indication
 for the name placement.

 I don't know about the others, but I've been thinking about this one, and
 there's a simple solution. Drawing a big polygon around the whole mountain
 is not very effective. There are no clear boundaries for a mountain. But
 what we can do is put a tag like mountain=* on all natural=peak nodes.
 Maybe even on alpine_huts and other features. That way some software could
 find arbitrary boundaries using that data and SRTM data.
 
 Maybe valleys can be solved in the same way.

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 several valleys. Of course,
likewise, valleys have the same problem. It's not a hierarchical
information either.

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 mountain groups. Huts
and peaks would definitely not be enough for a decent boundary.

But also drawing big areas is kind of ugly :(.

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'm thorn.



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


Re: [Tagging] Tagging of topographic areas with a name

2013-08-06 Thread Yuri D'Elia
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 several valleys. Of course,
 likewise, valleys have the same problem. It's not a hierarchical
 information either.
 
 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 mountain groups. Huts
 and peaks would definitely not be enough for a decent boundary.
 
 But also drawing big areas is kind of ugly :(.
 
 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'm thorn.

I'm attaching a crude osm file I edited quickly to demonstrate the problem.

Valleys usually end exactly at the mountain ridges. Valleys also end at
the border of a mountain region or at the border of another valley.
Between valleys, the border is purely arbitrary (it's mostly determined
by geographic properties).

In the alps I would expect a mosaic which is essentially totally filled
with valleys. A relation would be great to re-use existing geometry, but
some new boundary type will also be needed to mark the end where's no
additional geometry can be reused.

I also created two (inexact) mountain groups. Mountain groups actually
form a complimentary mosaic, as you see in the file. A mountain group
would start at the middle of a valley (which I didn't do in the example,
but you get the point) and end at another one. The only exception might
be where you have very large valleys, like the Val D'Adige, where the
group doesn't start in the middle exactly (but doing so wouldn't exactly
be wrong either). For mountain groups I do not see any existing
geometry that could be reused, except occasionally for the nodes where
the valleys cross. A new boundary type is definitely needed, and the
edges could be shared with a mountain group relation.

?xml version='1.0' encoding='UTF-8'?
osm version='0.6' upload='true' generator='JOSM'
  node id='-385' action='modify' visible='true' lat='46.6430679777813' lon='11.052495557349316' /
  node id='-366' action='modify' visible='true' lat='46.49188168894685' lon='11.043871730621769' /
  node id='-347' action='modify' visible='true' lat='46.459302571583' lon='10.36979709656485' /
  node id='-345' action='modify' visible='true' lat='46.348707668264105' lon='10.364026723600112' /
  node id='-343' action='modify' visible='true' lat='46.31049752324693' lon='10.494821428967915' /
  node id='-341' action='modify' visible='true' lat='46.356644089129794' lon='10.727664750611696' /
  node id='-339' action='modify' visible='true' lat='46.42752467234013' lon='10.91235837302667' /
  node id='-337' action='modify' visible='true' lat='46.59815137198975' lon='11.092740082077869' /
  node id='-335' action='modify' visible='true' lat='46.601607818458966' lon='10.867083282707044' /
  node id='-333' action='modify' visible='true' lat='46.61197583489281' lon='10.763597361976476' /
  node id='-332' action='modify' visible='true' lat='46.60802634834044' lon='10.573873173970435' /
  node id='-321' action='modify' visible='true' lat='46.83957020991874' lon='10.644301092245405' /
  node id='-319' action='modify' visible='true' lat='46.805147933633975' lon='10.724790141702512' /
  node id='-317' action='modify' visible='true' lat='46.82088656606407' lon='10.826838757978491' /
  node id='-315' action='modify' visible='true' lat='46.930928039250446' lon='11.023030816030195' /
  node id='-313' action='modify' visible='true' lat='46.8955821746472' lon='11.125798084533468' /
  node id='-311' action='modify' visible='true' lat='46.81252599107442' lon='11.23718917976429' /
  node id='-308' action='modify' visible='true' lat='46.697313033657714' lon='11.088428168714096' /
  node id='-306' action='modify' visible='true' lat='46.67315605116175' lon='11.047464991758245' /
  node id='-304' action='modify' visible='true' lat='46.62678384457391' lon='10.862771369343271' /
  node id='-303' action='modify' visible='true' lat='46.641587804517854' lon='10.611243089789806' /
  node id='-223' action='modify' visible='true' lat='46.39911725379921' lon='10.983395899954589' /
  node id='-221' action='modify' visible='true' lat='46.4202488648184' lon='11.004914609498558' /
  node id='-219' action='modify' visible='true' lat='46.436595031792024' lon='10.971137954815664' /
  node id='-213' action='modify' visible='true' lat='46.644455683599396' lon='11.210808472618753' /
  node id='-211' action='modify' visible='true' lat='46.52888351182877' lon='11.30495191439448' /
  node id='-209' action='modify' visible='true' lat='46.476944108594104' lon='11.358850831441648' /
  node id='-207' action='modify' visible

Re: [Tagging] Tagging of topographic areas with a name

2013-08-06 Thread Yuri D'Elia
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 nodes, ways or relations) into a
 relation with the roles inside or outside and some algorithm would
 calculate an area that includes all inside and excludes all outside
 objects. You won't have to be very precise with this, as this kind of rough
 information is only required on lower scales where some kilometers more or
 less won't change anything, just a few nodes should suffice to define
 something as huge as the Alps, and you could reuse (preferably simple and
 stable like peak-nodes) existing geometry.

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

Calculating a concave hull from points, especially where you have nested
geometry is very messy process (I used to do it as a gis developer in
the past). I wouldn't really expect decent results even for name
placement.

 +1, usually you will have a river or stream there, as it is the locally
 lowest point (i.e. the needed geometry is already there). An argument
 against reusing rivers to define mountain groups is that they often add a
 lot of complexity and you'd usually not need the borders of a mountain
 group with the precision this allows for (adding relations augments
 complexity and raises the barrier for other mappers to edit).

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). Just to say that the geometry might not always be there.

Also, is there a tagging scheme for the lowest point/depression of a
valley? (I was looking for it recently).



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