Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-18 Thread Ture Pålsson via Tagging


> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson :
> 
> I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try 
> to get a demo up… :-)
> 
> Having said that, as a renderer implementer, I have a slight preference for 
> the relation method. It is s implyeasier to join things on numeric id than to 
> join them by adjacency.

I don’t remember whether this has already been mentioned, but it just occurred 
to me:

One problem with merging adjacent areas for labelling purposes, is when the 
areas share no tags, except the name. For example, it is not unusual to have a 
natural=wetland sharing some boundary with a natural=water, where the name 
applies to the entire wet area. So you can’t just merge adjacent 
natuarl=wetland, you also have to remember to merge natural=water with adjacent 
natural=wetland, if their names match. And natural=riverbank. And 
landuse=reservoir ( :-) ). And the gods of cartography knows what else.

I am now leaning a bit heavier towards the ”relation” alternative…

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-16 Thread Jeremy Harris

On 16/12/2020 08:41, Ture Pålsson via Tagging wrote:

 Maybe it would be better to use a convex
hull...

and then polylabel, and then have all the labels repel each other
while being attracted to that point?

Preferably this springy attract/repel should account for the
text outline rather than the text centre-point.
--
Cheers,
  Jeremy

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-16 Thread Ture Pålsson via Tagging

2020-12-15 08:48  Anders Torger a écrit:


However I'll soon go through these edits again and then I will add multipolygon 
for the split, and if your renderer takes that into account we should end up 
with a single multipolygon. I think in the case of Muddus it will work in all 
cases, ie we won't hit the corner case described above which should be very 
rare. So I think this naming concept is okay as a stepping stone until we can 
move forward on this issue. I hope we can make a point though that this is not 
a acceptable as a long-term solution.


I'm drifting away from tagging into renderer implementation territory
now, but this thread is large anyway, so what the heck... :-) 


Your last edits actually caused some headaches for my renderer, because
you added in some "satellite" bits of bog that were not (I think)
previously included. The renderer insists on putting a label on each
disjoint area, so I ended up with a handful of them. 


So I resorted to the old "buffer and join" hack, adding a 100-meter
buffer around each area and ST_Union:ing the result (isn't it fun when
you realize you have all the plumbing in place and can do new things by
just adding a few lines of code?). Now the map looks like this:
http://lab3.turepalsson.se/~ture/rijmmoahpe-20201216.pdf . The red
outlines show the areas that the renderer is actually considering when
placing the labels. 


The label placement for Aleldusáhpe near the top of the map looks...
less than ideal. I suspect that this is because I use (an implementation
of) the Mapbox polylabel [1] algorithm, and it gets derailed by the
small holes inside the areas. Maybe it would be better to use a convex
hull... or just a bigger buffer. Label placement is a black art... 


Links:
--
[1] https://github.com/mapbox/polylabel___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Ture Pålsson via Tagging

2020-12-15 23:38 skrev Martin Koppenhoefer:


Take a look back what I mentioned 3 days ago in my first answer: "...If we want to map all 
those "meta areas" with names we would do well to think about additional ways of 
delimiting space (i.e. different kind of geometry objects), e.g. a fuzzy border could be 
represented by providing different points for which it seems undisputed that they are in or out of 
the area in question. This would be very lightweight for all mappers, because it avoids clear lines 
which are confusing when they do not correspond with something observable."


This reminds me of my friend's somewhat tongue-in-cheek suggestion,
which I mentioned in another thread, that a fuzzy area should be mapped
as a function that takes a point as input and returns a number in [0,
1]; 0 for "definitely outside", 1 for "definitely inside". 


Here's an off-the-charts complicated idea for doing that, just to get us
started: 


A fuzzy area is mapped as a relation, type=fuzzy_area. Some tag on that
relation ('code', perhaps) contains a program written in a small
stack-based language offering geometric operators, such as distance,
intersects, touches, etc. The program will get a point as input on the
top of the stack, and should consume it and leave a number on top of the
stack. Geometric constants needed by the program (points, lines, areas)
are supplied as members (nodes, ways, multipolygon relations) of the
relation. If the 'code' tag is missing, all members should be nodes, and
the result will be computed using a default algorithm (which remains to
be defined) using those points. 


1/2 :-)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread stevea
To share a local varietal, we have "Henry Cowell Redwoods State Park" and we 
have "Henry Cowell Redwoods State Park (Fall Creek Unit)," slightly 
non-contiguous but managed together.  In the real world (too) this sort of 
"grouping between things that belong together or are part of a same thing" can 
be tricky (in naming, categorizing...).

It appears California "decided to choose to at least do something about 
this..." (in this case) and threw a dart at the board, which stuck.  This is 
but one example of "grouping, naming, categorizing..." but it illustrates 
"throw a dart, locally, if nothing else has been done" and it might stick.  
We're doing that here.  Some darts haven't even yet been thought of.

A natural area grouping naming concept is an excellent starting place, even 
discovering that "there isn't one" (in OSM) doesn't mean one couldn't be spun 
up.  It could, sounds like it should.  It sounds like it's in the earlier 
stages of happening, here, now, offline with some (many?), in imaginations at 
least.  Good.

Lather, rinse, repeat.

(Like my oldest sister the artist says, "start with a concept.")

> On Dec 15, 2020, at 2:25 PM, Martin Koppenhoefer  
> wrote:
> 
> Am Di., 15. Dez. 2020 um 08:51 Uhr schrieb Anders Torger :
> The simple answer is that this naming concept is fundamentally broken, and 
> that we need to have some other concept, such as fuzzy areas.
> 
> 
> I agree that there isn't really a concept for naming larger (natural) areas. 
> In OSM you can map areas of the same kind of thing and add the names for the 
> smallest entities (e.g. forest) to it, but you cannot add a name for several 
> parts of a forest together (when the parts themselves have names). Naming 
> works for administrative entities, countries, cities etc, but not for 
> geographic entities. 
> 
> Cheers
> Martin
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Martin Koppenhoefer
Am Di., 15. Dez. 2020 um 10:42 Uhr schrieb Anders Torger :

> We should probably not have all these possible generalized areas in our
> db. Just as we probably shouldn't have a bedrock map in the db either, at
> least not until it can manage layers.
>
> But we could simply pick one criteria, document the definition of the
> "fuzzy area" and have that. Some criteria that is useful as a basis for
> making general-purpose maps. I don't think it's a problem to have fuzzy
> areas in the database as long as they can be identified as such and there
> is a clear definition of what they mean and what the concept of fuzziness
> is. Renderers shouldn't generally not render the border of these areas, and
> if they do for some particular illustration (to show where Black Forest is
> for example) they should make them really blurry and fuzzy.
>



Take a look back what I mentioned 3 days ago in my first answer: "...If we
want to map all those “meta areas” with names we would do well to think
about additional ways of delimiting space (i.e. different kind of geometry
objects), e.g. a fuzzy border could be represented by providing different
points for which it seems undisputed that they are in or out of the area in
question. This would be very lightweight for all mappers, because it avoids
clear lines which are confusing when they do not correspond with something
observable."

If you want to map something with a "fuzzy border", you should not map a
non-fuzzy border and declare it "fuzzy" by adding tags. The data type
should implicitly represent the fuzzyness. fuzzy is not the same as fuzzy.
If you were to draw fuzzy borders with lines, I would expect at least 2
lines: one the is in and one that is out of the fuzzy object, the border
would be the space in between, it's width (fuzzyness) could variate
depending on the location. But the concept of using just nodes still seems
more elegant and less invasive compared to this.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Martin Koppenhoefer
Am Di., 15. Dez. 2020 um 15:59 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Re: “ a couple of islets with a collective name”
>
> We have a tag for that: place=archipelago for a group of islands.
>
> There isn’t a common tag for a group of lakes with one name, probably
> because this is only common in some countries, especially near the Arctic
> region. We’ve talked about this issue before but did not find an existing
> tag.
>
> I would suggest a tag like natural=lake_group to be added to a
> multipolygon which includes each of the lakes, similar to how archipelagos
> are mapped.
>


you could make a relation type=group, add a name and the lakes to it, and
would not need a new tag.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Martin Koppenhoefer
Am Di., 15. Dez. 2020 um 08:51 Uhr schrieb Anders Torger :

> The simple answer is that this naming concept is fundamentally broken, and
> that we need to have some other concept, such as fuzzy areas.
>


I agree that there isn't really a concept for naming larger (natural)
areas. In OSM you can map areas of the same kind of thing and add the names
for the smallest entities (e.g. forest) to it, but you cannot add a name
for several parts of a forest together (when the parts themselves have
names). Naming works for administrative entities, countries, cities etc,
but not for geographic entities.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Joseph Eisenberg
Re: the Great Lakes -

Very large archipelagos, like "Indonesia" or "The Phillipines" or "The
British Isles", shouldn't be mapped as multipolygons because they would be
ridiculously huge. Generally the tag place=archipelago is used for small to
mid-sized groups of islands. Now, it is possible to map place=island
features as nodes and then select each node to make a relation, but mapping
islands as multipolygons seems to be preferred by most mappers, and that
type of relation is much more common and established than any of the
options for groups of islands.

Similarly, the Great Lakes are too big for mapping as a single
multipolygon, and each has its own name which is the locally-verifiable
feature.

A superrelation [which added each individual lake (or island) relation as a
member rather than individual ways] might be possible even for large lakes
and large island chains, since it wouldn't break every time 2 mappers tried
to edit the coastline/lakeshore at the same time. But there is no
established relation type for this, and handling relations-of-relations is
a huge pain for editing the map as well as for database users.

I suppose if there were a well-defined type of relations which only allowed
one level of relations to be nested inside of it (that is, all members had
to be a valid multipolygon) it might be usable, but it would still get
confusing.

-- Joseph Eisenberg

On Tue, Dec 15, 2020 at 9:12 AM Brian M. Sperlongano 
wrote:

> Wouldn't it be more consistent to keep it in the same key, and call it
> place=lake_group?  Or even place=lakes?
>
> Would this be used for something like the Great Lakes in USA/Canada or is
> that too large of a feature?
>
> On Tue, Dec 15, 2020, 12:05 PM stevea  wrote:
>
>> +1.  Joseph's suggestion is a fine example of "OSM can and does coin new
>> tags on occasion."  Adding a nice boost, there is a suggestion that
>> "similar" tagging be used as an example of how to define / use / document
>> the new tag.  Great!
>>
>> On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg 
>> wrote:
>> > Re: “ a couple of islets with a collective name”
>> >
>> > We have a tag for that: place=archipelago for a group of islands.
>> >
>> > There isn’t a common tag for a group of lakes with one name, probably
>> because this is only common in some countries, especially near the Arctic
>> region. We’ve talked about this issue before but did not find an existing
>> tag.
>> >
>> > I would suggest a tag like natural=lake_group to be added to a
>> multipolygon which includes each of the lakes, similar to how archipelagos
>> are mapped.
>>
>> ___
>> 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] How to put a name tag on an area with more than one type?

2020-12-15 Thread stevea
That's a good question, Brian.  On its face, it would be more consistent to 
keep this in the place=* key.  I like both of your choices, as the concept 
doesn't really have a single word to describe "lakes" in the plural as distinct 
from the singular (as archipelago does for island).  The community can continue 
to discuss which might be better and why.

On Dec 15, 2020, at 9:09 AM, Brian M. Sperlongano  wrote:
> Wouldn't it be more consistent to keep it in the same key, and call it 
> place=lake_group?  Or even place=lakes?
> 
> Would this be used for something like the Great Lakes in USA/Canada or is 
> that too large of a feature?

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Brian M. Sperlongano
Wouldn't it be more consistent to keep it in the same key, and call it
place=lake_group?  Or even place=lakes?

Would this be used for something like the Great Lakes in USA/Canada or is
that too large of a feature?

On Tue, Dec 15, 2020, 12:05 PM stevea  wrote:

> +1.  Joseph's suggestion is a fine example of "OSM can and does coin new
> tags on occasion."  Adding a nice boost, there is a suggestion that
> "similar" tagging be used as an example of how to define / use / document
> the new tag.  Great!
>
> On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg 
> wrote:
> > Re: “ a couple of islets with a collective name”
> >
> > We have a tag for that: place=archipelago for a group of islands.
> >
> > There isn’t a common tag for a group of lakes with one name, probably
> because this is only common in some countries, especially near the Arctic
> region. We’ve talked about this issue before but did not find an existing
> tag.
> >
> > I would suggest a tag like natural=lake_group to be added to a
> multipolygon which includes each of the lakes, similar to how archipelagos
> are mapped.
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-15 Thread stevea
+1.  Joseph's suggestion is a fine example of "OSM can and does coin new tags 
on occasion."  Adding a nice boost, there is a suggestion that "similar" 
tagging be used as an example of how to define / use / document the new tag.  
Great!

On Dec 15, 2020, at 6:56 AM, Joseph Eisenberg  
wrote:
> Re: “ a couple of islets with a collective name”
> 
> We have a tag for that: place=archipelago for a group of islands. 
> 
> There isn’t a common tag for a group of lakes with one name, probably because 
> this is only common in some countries, especially near the Arctic region. 
> We’ve talked about this issue before but did not find an existing tag.
> 
> I would suggest a tag like natural=lake_group to be added to a multipolygon 
> which includes each of the lakes, similar to how archipelagos are mapped.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread stevea
That is stated even better than I meant to state.  Yes, JOSM's relation editor 
is "the best there is."

On Dec 15, 2020, at 1:21 AM, Peter Elderson  wrote:
> 
> stevea :
> (Personally, I find JOSM’s relation editor to be one of its most elegant 
> features for a data structure as relatively complex as a relation. 
> 
> I am not qualified to judge elegance, but I find JOSM's relation editor the 
> best there is. I don't think relations are very complex data structures, but 
> the construct is versatile. It's what people do with them that makes it 
> complex. But hey, the same goes for the node, the way and the area.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Joseph Eisenberg
Re: “ a couple of islets with a collective name”

We have a tag for that: place=archipelago for a group of islands.

There isn’t a common tag for a group of lakes with one name, probably
because this is only common in some countries, especially near the Arctic
region. We’ve talked about this issue before but did not find an existing
tag.

I would suggest a tag like natural=lake_group to be added to a multipolygon
which includes each of the lakes, similar to how archipelagos are mapped.

-Joseph Eisenberg

On Tue, Dec 15, 2020 at 5:07 AM Anders Torger  wrote:

> I'll make a small change to my naming strategy: use one multipolygon per
> natural tag set, and thus minimize the number of same-named polygons.
>
> Normally, when naming entities which has all the same natural tags but
> separate areas, such as a couple of ponds or islets with a collective name
> (common), it's made as a single multipolygon with several outers. I've
> heard that there are renderers that actually already today then render a
> single text label.
>
> As natural tags differ in this wetland a single multipolygon is not
> possible. However one can make one polygon per set of natural tags. For
> this Rimmjoáhpe wetlend I then get away with two multipolygons, thus
> greatly reducing the number of text labels rendered in some renderers,
> while still being compatible with the other method of keeping every
> adjacent polygon on their own.
>
> It also makes it easier to keep all parts together when editing as a
> multipolygon is also a relation.
>
> /Anders
>
> On 2020-12-15 09:52, Anders Torger wrote:
>
> Yes we actually have some of that up here too. I've chosen generally not
> to map it though as one cannot really verify it on the satellite photos,
> and here in the vast nature in north it's not really reasonable to visit
> all these places on foot so one have to rely on satellite photos for large
> parts of the nature.
>
> I'm quite sure that overlapping polygons is not how one is supposed to do
> it though. Soggy forests should have its own natural type, in Swedish we
> call it "sumpskog", and the best fitting OSM tag for that seems to be
> "natural=wetland; wetland=swamp".
>
> By the way, I've pushed an update of the Rimmjoáphe wetland now, removed
> the relation and made a multipolygon to span the river.
>
> On 2020-12-15 09:03, Ture Pålsson via Tagging wrote:
>
>
> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
>
> And about wetlands, couldn't those be just rendered on top of forests so
> we didn't have to make these complex multipolygons?
>
>
> It does make sense to have overlapping wetland and forest, though. To take
> a swedish example: down here in 08-land (note to non-Swedes: Stockholm,
> telephone area code 08 :-) ), we get very little open bog, but a fair
> amount of soggy forest.
>
>
> ___
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Anders Torger
I'll make a small change to my naming strategy: use one multipolygon per 
natural tag set, and thus minimize the number of same-named polygons.


Normally, when naming entities which has all the same natural tags but 
separate areas, such as a couple of ponds or islets with a collective 
name (common), it's made as a single multipolygon with several outers. 
I've heard that there are renderers that actually already today then 
render a single text label.


As natural tags differ in this wetland a single multipolygon is not 
possible. However one can make one polygon per set of natural tags. For 
this Rimmjoáhpe wetlend I then get away with two multipolygons, thus 
greatly reducing the number of text labels rendered in some renderers, 
while still being compatible with the other method of keeping every 
adjacent polygon on their own.


It also makes it easier to keep all parts together when editing as a 
multipolygon is also a relation.


/Anders

On 2020-12-15 09:52, Anders Torger wrote:

Yes we actually have some of that up here too. I've chosen generally 
not to map it though as one cannot really verify it on the satellite 
photos, and here in the vast nature in north it's not really reasonable 
to visit all these places on foot so one have to rely on satellite 
photos for large parts of the nature.


I'm quite sure that overlapping polygons is not how one is supposed to 
do it though. Soggy forests should have its own natural type, in 
Swedish we call it "sumpskog", and the best fitting OSM tag for that 
seems to be "natural=wetland; wetland=swamp".


By the way, I've pushed an update of the Rimmjoáphe wetland now, 
removed the relation and made a multipolygon to span the river.


On 2020-12-15 09:03, Ture Pålsson via Tagging wrote:

15 dec. 2020 kl. 08:26 skrev Anders Torger :
And about wetlands, couldn't those be just rendered on top of forests 
so we didn't have to make these complex multipolygons?
It does make sense to have overlapping wetland and forest, though. To 
take a swedish example: down here in 08-land (note to non-Swedes: 
Stockholm, telephone area code 08 :-) ), we get very little open bog, 
but a fair amount of soggy forest.


___
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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Anders Torger
When I started using JOSM, which is not so long ago, I hated it. If one 
is used to graphic software from say Adobe etc, many things in the user 
interface feel backwards. But now when I've got into it, one can really 
work effectively. When I started I didn't really understand the 
multipolygon concept fully either, so the error messages I got was 
really cryptic, but now when I understand all these things JOSM works 
great.


What I do miss in JOSM though is advanced tools for managing 
multipolygons, there are some splitting and joining and some additional 
tools as plugins, but these are generally limited in scope, so I often 
end up having to hand-edit the ways and relations when making more 
advanced splits/joins/geometry upgrades. For that the relation editor 
works very well though, but one really needs to know what one's doing 
:-).


If one is a programmer and want to contribute to OSM mapping efficiency 
as the OSM map becomes more and more detailed, I believe developing more 
advanced and complete multipolygon tools for JOSM is a good bet.


In iD, areas with multipolygons can be very hard to edit, unless you 
know how they are constructed so you can go in and hand-edit tags. So 
they can be a bit of a pain, but they are unavoidable if we want 
detailed mapping, and as the map develops we get more and more into this 
space.


/Anders

On 2020-12-15 10:21, Peter Elderson wrote:


stevea :

(Personally, I find JOSM's relation editor to be one of its most 
elegant features for a data structure as relatively complex as a 
relation.


I am not qualified to judge elegance, but I find JOSM's relation editor 
the best there is. I don't think relations are very complex data 
structures, but the construct is versatile. It's what people do with 
them that makes it complex. But hey, the same goes for the node, the 
way and the area.

___
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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Anders Torger
We should probably not have all these possible generalized areas in our 
db. Just as we probably shouldn't have a bedrock map in the db either, 
at least not until it can manage layers.


But we could simply pick one criteria, document the definition of the 
"fuzzy area" and have that. Some criteria that is useful as a basis for 
making general-purpose maps. I don't think it's a problem to have fuzzy 
areas in the database as long as they can be identified as such and 
there is a clear definition of what they mean and what the concept of 
fuzziness is. Renderers shouldn't generally not render the border of 
these areas, and if they do for some particular illustration (to show 
where Black Forest is for example) they should make them really blurry 
and fuzzy. Sure one can always come up with arguments regarding 
verifiability, but in general I think they are quite weak. If we want 
this feature we can have it. If we don't want it, we can make up 
arguments against it.


Often I see in discussions on this list that people not really say if 
they actually want a feature or not. They just put forward criticism on 
a certain implementation, without ever clarifying their standpoint on 
the feature as such. It does not apply to you Martin of course (you have 
clearly shown you want this feature, we're just discussing method, which 
is great), I just want to mention that I think we should all strive to 
do that, clarify our standpoint for or against a feature rather than 
just covering under technical arguments, sometimes increasingly strained 
and formulaic.


Anyway, one can also argue that it is a problem from an editing 
standpoint to have these fuzzy areas overlay other areas increasing the 
clutter. While I think the argument has some merit, I think that is 
easily solved with a filter, already today supported in JOSM, and easily 
added to iD. As the areas are fuzzy it does not really matter if other 
natural polygons are edited and adjusted without adjusting the fuzzy 
area, they don't need (and probably shouldn't) share nodes with the 
underlying nature, so it's not a problem if they aren't visible at the 
same time per default.


Although I argue for having these in the main database, I'm not really 
against to having it in a different database, that would technically 
work as well. I just see it as unlikely to catch on. If we have it in a 
separate database we could do it even if the majority of the OSM 
community isn't on board with the concept at all. OSM-Carto wouldn't 
render it, and as a result I think a major part of the mappers wouldn't 
even know that it exists. Just like it's unreasonable to think that 
mappers would know about naming concepts that render incorrectly in 
OSM-Carto (the Rijmmoáhpe wetland example).


I also think that having concepts to name nature is important enough to 
serve the making of maps that it really should be in OSM main database. 
OSM can already name much of nature and mappers contribute to that, it 
just falls a bit short on these more complex cases. The concept of fuzzy 
areas has already been softly introduced with bays and straits. I see no 
reason why we shouldn't develop that capability further.


Another challenge with having it in a different database is that of 
management and availability. It's strange to suddenly need two databases 
to render just common general-purpose maps, and who's going to make sure 
that it's available? I think that using the current OSM infrastructure 
is a safer bet.


/Anders

On 2020-12-15 09:50, Martin Koppenhoefer wrote:


sent from a phone

On 15. Dec 2020, at 06:11, Graeme Fitzpatrick  
wrote:


If I look at a map eg 
https://en.wikipedia.org/wiki/Black_Forest#/media/File:Relief_Map_of_Germany,_Black_Forest.png, 
it tells me that the Balck Forest is a more or less oval-shaped area 
in Southern Germany. Why can't we draw a similar rough oval in OSM & 
call it Black Forest?


have a look at this overview:

https://de.wikipedia.org/wiki/Naturräumliche_Gliederung_des_Schwarzwaldes#Grobe_Gliederung

these areas are not directly observable on the ground, yes, they are 
made (I suppose) by scientists according to certain criteria, but you 
will probably get different answers if you asked a biologist, a 
geologist or a linguist. And according to the scale that they are 
working in.


Shall we really aim at having all these possible generalized areas and 
classifications as nested polygons in our db? Seems obvious that we 
can't.


Cheers Martin

___
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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Peter Elderson
stevea :

> (Personally, I find JOSM’s relation editor to be one of its most elegant
> features for a data structure as relatively complex as a relation.
>

I am not qualified to judge elegance, but I find JOSM's relation editor the
best there is. I don't think relations are very complex data structures,
but the construct is versatile. It's what people do with them that makes it
complex. But hey, the same goes for the node, the way and the area.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Anders Torger
Yes we actually have some of that up here too. I've chosen generally not 
to map it though as one cannot really verify it on the satellite photos, 
and here in the vast nature in north it's not really reasonable to visit 
all these places on foot so one have to rely on satellite photos for 
large parts of the nature.


I'm quite sure that overlapping polygons is not how one is supposed to 
do it though. Soggy forests should have its own natural type, in Swedish 
we call it "sumpskog", and the best fitting OSM tag for that seems to be 
"natural=wetland; wetland=swamp".


By the way, I've pushed an update of the Rimmjoáphe wetland now, removed 
the relation and made a multipolygon to span the river.


On 2020-12-15 09:03, Ture Pålsson via Tagging wrote:


15 dec. 2020 kl. 08:26 skrev Anders Torger :
And about wetlands, couldn't those be just rendered on top of forests 
so we didn't have to make these complex multipolygons?


It does make sense to have overlapping wetland and forest, though. To 
take a swedish example: down here in 08-land (note to non-Swedes: 
Stockholm, telephone area code 08 :-) ), we get very little open bog, 
but a fair amount of soggy forest.


___
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] How to put a name tag on an area with more than one type?

2020-12-15 Thread Martin Koppenhoefer


sent from a phone

> On 15. Dec 2020, at 06:11, Graeme Fitzpatrick  wrote:
> 
> If I look at a map eg 
> https://en.wikipedia.org/wiki/Black_Forest#/media/File:Relief_Map_of_Germany,_Black_Forest.png,
>  it tells me that the Balck Forest is a more or less oval-shaped area in 
> Southern Germany. Why can't we draw a similar rough oval in OSM & call it 
> Black Forest?


have a look at this overview:

https://de.wikipedia.org/wiki/Naturräumliche_Gliederung_des_Schwarzwaldes#Grobe_Gliederung

these areas are not directly observable on the ground, yes, they are made (I 
suppose) by scientists according to certain criteria, but you will probably get 
different answers if you asked a biologist, a geologist or a linguist. And 
according to the scale that they are working in.

Shall we really aim at having all these possible generalized areas and 
classifications as nested polygons in our db? Seems obvious that we can’t.

Cheers Martin 


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread stevea
A little less “my way is the right way” (complaining, plain and simple) and a 
little more “ah, OSM does what OSM does, I understand how I can both contribute 
AND make use of it,” please.  Lots of us do this (both) and actually improve 
the map while we’re at it!  (Map data, map documentation via wiki, map syntax 
via proposals, map renderers…).

Examples of “my way is the right way” in a recent post:

• (A renderer) doesn’t render wetland names at all (strange for a map with 
topology)
• You won’t find any renderer (except Ture’s) that does what I want
• “Well-established methods” don’t make sense
• A renderer needs to (have, see, make, do, calculate, merge)….
• However, it’s strange (in two different ways!) having an algorithm that needs 
“activation”
• I don’t think anyone believes (something), that’s just a standard argument to 
neutralize criticism
• A data project that keeps saying “we’re a data project, you want rendering? 
Go write a renderer” isn’t exactly ideal for (me) making progress
• My opinion is that having limited and “soft advice” wiki of how geodata 
should be interpreted and rendered is a bad idea

At this point, I’m tempted to repeat “so, then, don’t use OSM, it doesn’t seem 
to be what you are looking for.”  However, the OP continues:

• “It” (you folks making this happen for me) could STILL work if an existing 
renderer simply decided to become my "wish slave” renderer rather than what I 
will disparage by calling “an example” or than “the one that you folks have 
chosen to call Standard” which I declare “does some things wrong.”  (Defects to 
spec are one thing, and good to track and fix as bugs or feature requests, then 
improvements.  THIS is something entirely different!)
• My wishes mean that you folks need to PROPERLY render “the concepts which is 
supposed to work.”  Oh, and if it DID work, as I wish it were to work, you 
folks might discover how inefficient your present algorithm is and how 
wrong-headed is your approach to “how data is arranged.”  Hey, the least you 
guys could do is allow a new concept (it’s fuzzy, sorry) to be introduced.  I 
mean, REALLY!  It’s so RISKY to “design data arrangement concepts without 
having an own renderer to test them with.”

At this point, I say (exhausted) “the data arrangement has been 
crowdsource-crafted by millions over decades” and “we DO have 'our own 
renderers' (to test them with).”  Wow!

Still, the OP continues:

• Hey, we have to (tag for the renderer, something we are clearly admonished 
not to do) to get specific tagging for the renderer!  I’m jumping up and down!
• Couldn’t you just make wetlands (for me, yes me, that’s me) the way that _I_ 
want them?  What’s wrong with you folks that you won’t or don’t?  I actually 
have to use YOUR data structures and read YOUR documentation to do this YOUR 
way!  Harumph!  Why can’t you simply read my mind and do it the way that I like?
• What I do is spend far more time spending time than what you do (or so — 
which only resounds as, effectively, selfish and/or whining)
• Imagine how much easier (for you) it would be if you "simply do” what _I_ 
want you to do
• Your tools are crude (for me to use).

(Personally, I find JOSM’s relation editor to be one of its most elegant 
features for a data structure as relatively complex as a relation.  But I 
digress).  Continuing the bleating:

• You need to do certain mapping operations by doing certain map operations, 
which I hereby complain about being too simplistic
• You could STILL “save yourselves” by doing things my way (after a hazy, 
unproven technique is sketched, while inventing “layers,” a concept that is 
nearly 100% unlikely to be ratified in OSM anytime soon)
• You must convert and generalize asap, because vector tiles will save us
• I have noticed that my fellow mappers in my country here DO pay attention to 
the admonishments to not map for the renderer, so I suppose “everybody” finds 
this a difficult to grasp concept.  (Nope).
• You sure ought to look into making things easier.  (For me).
• You sure ought to “think twice” about improvements that I don’t like, as it 
makes it more difficult (for me) to edit.

Whew, I need a shower!

CONSTRUCTIVE criticism to improve OSM is welcome.  Simply dumping on the 
project like I have summarized above wears out that welcome.  Not in a good way.

A couple hours ago, I was impressed with the direction of this thread, as I 
thought it was taking a turn of “people can improve OSM, people DO improve 
OSM.”  Then, the thread started to veer off the road again.  Keep it 
constructive, people, please!

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Ture Pålsson via Tagging

> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
> 
> And about wetlands, couldn't those be just rendered on top of forests so we 
> didn't have to make these complex multipolygons? 

It does make sense to have overlapping wetland and forest, though. To take a 
swedish example: down here in 08-land (note to non-Swedes: Stockholm, telephone 
area code 08 :-) ), we get very little open bog, but a fair amount of soggy 
forest.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 Thread Ture Pålsson via Tagging

> 15 dec. 2020 kl. 08:26 skrev Anders Torger :
> 
> And about wasting mapper's time. What about that we have to punch holes and 
> make river areas for rivers nowadays? Punch holes for waters in forest areas? 

Anecdote: When I first started toying with rendering about ten years ago, I had 
problems with lakes disappearing under forests. I thought it was completely 
unrealistic to expect mappers to punch holes in forests for lakes, especially 
as everything looked fine on osm.org , so I added a rule that 
smaller areas always render on top of larger areas. Then the map at osm.org 
 changed to requiring holes, and for a very long time most 
lakes in Sweden had little trees growing on them on osm.org . 
I think most of them have been multipolygon-ized by now.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger

Impressive work!

I had missed myself that the river flows through. To tie it together I 
would have made a multipolygon with two outers one on each side of the 
river, and I think I've already done that in some other wetland with the 
same issue. However that is not a fool-proof solution, as in some case 
you could have only bog on one side of the river and only marsh on the 
other, making it impossible to tie it together with a multipolygon.


The simple answer is that this naming concept is fundamentally broken, 
and that we need to have some other concept, such as fuzzy areas.


However I'll soon go through these edits again and then I will add 
multipolygon for the split, and if your renderer takes that into account 
we should end up with a single multipolygon. I think in the case of 
Muddus it will work in all cases, ie we won't hit the corner case 
described above which should be very rare. So I think this naming 
concept is okay as a stepping stone until we can move forward on this 
issue. I hope we can make a point though that this is not a acceptable 
as a long-term solution.


Your example also demonstrates the importance of having a reference 
renderer that actually renders correctly. I would not have discovered 
that I've forgot to tie the wetland together if it weren't for that your 
renderer actually implements the algorithm. A proper reference render 
gives better geodata, as it allows mappers to with their own eyes see 
what's correctly represented or not.


/Anders

On 2020-12-15 06:22, Ture Pålsson wrote:


14 dec. 2020 kl. 22:30 skrev Anders Torger :

Cool! It would be really nice to see a demo :-)


Rijmmoáhpe renders sort of reasonably now at 
http://lab3.turepalsson.se/map . (On the generated PDF, not on the 
"slippy map". And it's a bit hard to find, since my low-zoom tiles are 
so bad!). Or check my PDF at 
http://lab3.turepalsson.se/map/download/ecb7556.pdf .


It still gets two labels because the area is split in half by 
Rijmmojåhko flowing through it.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger

Some more points after a night's sleep:

I just remembered, another issue with opentopomap is that it doesn't 
render wetland names at all, which may be a bit strange for a map with 
topology. But we could look at some other map, geofabrik for example, 
and of course it renders the same way as OSM-Carto. I don't think you 
will find any renderer, except Ture's which just implemented it in this 
thread that does this.


The thing is that this "well-established method" doesn't make much sense 
as far as I can understand. A renderer needs for each area with a name 
label scan for all adjacent areas to see which have same names. If names 
are the same it needs to calculate the area to figure out dominant 
nature type and then merge to a new area so it knows where to place the 
label. But sure, it's far from impossible. It's however strange having 
this algorithm that needs activation all the time (scanning for adjacent 
names) for still quite rare cases, and it's even more strange to leave 
it undocumented and expect that "other renderers" will implement it. But 
I'm not dumb (oh well, maybe a little) I really don't think that anyone 
believes that other renderers would implement it, it's just a standard 
argument to neutralize criticism of OSM-Carto's limited rendering. The 
answer is *always* that "some other renderer will do it properly". It's 
not exactly ideal for making progress.


I think that having limited and "soft advice" wiki documentation of how 
geodata should be interpreted and rendered is a bad idea. However I 
think it could still work *if* OSM-Carto took on the role as being a 
reference renderer rather than just an "example renderer" which does 
some things right, and other things wrong. That does not mean that 
OSM-Carto needs to have the best most advanced cartography (although it 
would be nice), it just means that it needs to properly render the 
concepts which is supposed to work. If it did, maybe we would find out 
that the algorithm for doing so is unreasonably expensive, and we would 
need to change how data is arranged or introduce a new concept (I think 
fuzzy areas is the real answer here). I think it's really risky to 
design data arrangement concepts without having an own renderer to test 
them with.


And about wasting mapper's time. What about that we have to punch holes 
and make river areas for rivers nowadays? Punch holes for waters in 
forest areas? And about wetlands, couldn't those be just rendered on top 
of forests so we didn't have to make these complex multipolygons? 
Managing multipolygons in complex nature is by far what I spend most 
time with. And imagine how much easier it would be to draw if 
multipolygons were allowed to have inners that touches outers. Now when 
you need to pull up an inner towards the outer edge, you need to change 
the shape of the whole outer multipolygon to go around. The tools 
available in JOSM for managing multipolygons is still very rudimentary. 
Split and join tools only work for the simplest cases, so you generally 
need to do these operations manually by cutting ways, making new ways 
and hand-edit the multipolygon relation. 
Simple-to-draw-but-hard-to-render multipolygons could still be converted 
to render-friendly polygons in a middle layer. Conversion and 
generalization is required regardless as soon as we move to vector 
tiles.


Personally I don't have that big issue with those multipolygons, 
although not very effective it's kind of fun to make and manage these. 
But I do note that my fellow mappers in Sweden still typically just 
ignore that forest is drawn on top of their lakes and overall that the 
multipolygon concept is just difficult to grasp for many. So if we are 
really serious about "not wasting mappers' time", we should surely look 
into ease of editing, and think twice before we introduce a new drawing 
rule that makes it more difficult to edit.


/Anders

On 2020-12-14 22:25, Anders Torger wrote:

I certainly agree that we should not waste mapper's time, but in this 
case it was mainly actually to make it easier for myself with JOSM to 
find my way back to all small pieces in a fragmented landscape. Not 
having this relation makes editing a fair bit harder as you can't 
really see which parts belong to the same (name labels are really not 
that visible in JOSM) and you need to click your way through or create 
a filter on the name, but since you don't want it I will remove it. It 
will probably lead to more work for me rather than less, but I won't 
invent something that everyone is against. It's a value in keeping it 
simple too. So we can put that to the side, don't worry there will be 
no relations.


Opentopomap has some interesting features, but also it's own family of 
problems. The largest problem (except for limited server capacity) I 
think is that it renders borders between same tag areas, which causes 
lots of borders of technical polygon splitting visible, which exists 
everywhere in the map 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread stevea
Fascinating thread, fascinating activities it seems to have given rise to!  I 
applaud this dialog as I enjoy it.

> On Dec 14, 2020, at 9:22 PM, Ture Pålsson via Tagging 
>  wrote:
>> 14 dec. 2020 kl. 22:30 skrev Anders Torger :
>> 
>> Cool! It would be really nice to see a demo :-)
> 
> Rijmmoáhpe renders sort of reasonably now at http://lab3.turepalsson.se/map . 
> (On the generated PDF, not on the ”slippy map”. And it’s a bit hard to find, 
> since my low-zoom tiles are so bad!). Or check my PDF at 
> http://lab3.turepalsson.se/map/download/ecb7556.pdf .
> 
> It still gets two labels because the area is split in half by Rijmmojåhko 
> flowing through it.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Ture Pålsson via Tagging

> 14 dec. 2020 kl. 22:30 skrev Anders Torger :
> 
> Cool! It would be really nice to see a demo :-)

Rijmmoáhpe renders sort of reasonably now at http://lab3.turepalsson.se/map 
 . (On the generated PDF, not on the ”slippy 
map”. And it’s a bit hard to find, since my low-zoom tiles are so bad!). Or 
check my PDF at http://lab3.turepalsson.se/map/download/ecb7556.pdf 
 .

It still gets two labels because the area is split in half by Rijmmojåhko 
flowing through it.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Ture Pålsson via Tagging


> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson  (that’s me!):
> 
> I think it would be good to keep the set of possible values for the ’type’ 
> tag small, so I’d like to propose another level of indirection; something like
> 
>  type=named_area, named_area=natural, natural=wetland, name=Peter’s Pot

After having slept on it, make that

type=named_area, natural=wetland, wetland=Peter’s Pot

I.e, skip the named_area=natural bit. I’m not too fond of OSM:s ”rootless” tag 
structure, but we seem to be doing ok with it everywhere else…___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Graeme Fitzpatrick
On Mon, 14 Dec 2020 at 21:41, Frederik Ramm  wrote:

>
> What I don't like in OSM is naming for large geographic areas,


Thanks for the explanation, Frederik, but I'd like to make a couple of
points

like "the Alps", "the Black Forest", or "the Bay of Biscay", for two
> reasons:
>
> First, there can be any number of such areas.


Why is that a problem?

Are you concerned that somebody may mistake the Black Forest in Southern
Germany with the (hypothetical!) Black Forests in the US & Australia?

Or that different people may map it in different spots? If you've mapped
the Black Forest roughly north-south, then I map something E-W in the same
area & also call it the Black Forest, somebody is going to notice & ask me
why? & if I can't come up with a good explanation, it's going to be
reverted.

Second, these areas are usually ill-defined: There are some places that are
> clearly in the Black Forest, and some that are clearly not in the
> Black Forest, but there's not one boundary line - there's fuzziness.


So? If I look at a map eg
https://en.wikipedia.org/wiki/Black_Forest#/media/File:Relief_Map_of_Germany,_Black_Forest.png,
it tells me that the Balck Forest is a more or less oval-shaped area in
Southern Germany. Why can't we draw a similar rough oval in OSM & call it
Black Forest? If someone then extends it so that Stuttgart or Zurich are
included, once again, it will be spotted & corrected.

We name towns & cities all the time, with a nice, neat line saying that
this area is part of this town, & outside this line isn't. But what about
that house 300 m down the road - is it part of the town or not?

OSM is not good with fuzziness; OSM forces us to have an exact point or
> line or polygon for something.


I would have said that everything in the natural world is "fuzzy", indeed,
everything that's not an exact geometric man-made object eg a building or
fence, will almost certainly be?

I know that I've mapped woodland areas previously & the boundary doesn't
run along the exact edge of the treeline - yes, most of the trees are
inside the line, with only a "few" outside it, but how could it be done any
better? I could very carefully go along with a million points, twisting &
turning to get every tree, but then next week, one of them falls down, so
it's then got to be corrected!

For fuzzy labels, you need a different system that should exist outside of
> OSM's current data types.


Does it have to be outside?

Either by adding a new fuzzy data type to OSM (no need to assemble 1000
> ways with a total of 20,000 points to exactly describe the outline of the
> Alps if all you want is a nice big lettering in approximately the right
> spot),


& that's (I think) exactly what Anders wants, & I'll go along with him!

It doesn't have to be "exact", just so long as somebody can look at the map
& say that that area there is the "Whatever"!

Thanks

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
I agree with Mateusz that the wiki IS the project's standard document for
the meaning of tagging (from the perspective of data consumers) and how to
tag (from the perspective of mappers).  Note that both perspectives are
important.  But to address the specific point, there is no standard
document for renderer implementers, because there is no such thing as a
standard renderer implementation.  A renderer (something that turns data
into a map) is just one of very many ways to use and visualize geospatial
data.

I know you did not intend to criticize the volunteers that make this
project happen, but consider that when you dismiss the wiki as "no
documentation", it can be interpreted as dismissing the hard work of
countless people that volunteered their time to develop (and translate!) a
large and complex documentation base.  Most software developers find
documentation to be a chore and the last thing they deal with.  That is why
as someone who has the skills, time, and interest to contribute, I've
expended considerable effort improving the wiki's tagging documentation,
and when I've found gaps or problems, I've worked to draft and advance
proposals to address the deficiencies.  I saw a need and began filling it,
and my contributions to that documentation are something I am proud of.

For a project that provides its only product for free, it should be obvious
why the OSM Foundation has a small budget and can't afford to hire more
than a cursory staff for the most critical needs.  Consider changing your
perspective to "what am I able to contribute to make this project
stronger?" rather than "here are the things that are wrong".

As the author of a product that consumes OSM data, I am grateful to all of
the programmers, mappers, and technologists that have built the various
pieces of this ecosystem without which my product wouldn't exist.  It would
be awfully presumptuous of me to complain that this thing provided to me
entirely for free is in some way lacking, and I'm glad I am able to "give
back" in this small way.

This is just a gentle reminder that when you speak of "OSM", you are not
speaking to some big corporate entity with a glass lobby, a receptionist,
and someone to answer the phone -- you are speaking to a loose tribe of
individual volunteers that are collaborating on a free map of the world.

On Mon, Dec 14, 2020 at 4:15 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 14, 2020, 22:03 by and...@torger.se:
>
> Ok, understood. However as far as I know OSM lacks a standard document
> for render implementors to actually know how data should be interpreted.
>
> In part it is https://wiki.openstreetmap.org/ in part it is decision of
> authors of map style how they want map data to be intererpreted.
>
> The only reason I get here is when the OSM wiki doesn't have answers
>
> Yes, you are raising some very interesting cases (for example case of
> mountain
> and peaks named separately).
>
> Even here there are various answers and ideas circulating
>
> This is whole point of tagging mailing list for features with no known
> good way of tagging them. (or where it is not documented)
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger

Cool! It would be really nice to see a demo :-)

I would be fine with your naming scheme, however you'll have to rely on 
the adjacent rendering as I will be removing all relations per request. 
As said I actually had them mostly for make my editing easier (without 
them it becomes harder to manage all tiny parts in JOSM), so it was a 
mistake by me to mention possible advantages for renderers too, but as 
I'm also a programmer it's hard not to think about those things in 
parallel.


That it requires an merge-adjacent despite different natural tags and 
instead matching name makes me think that your renderer will probably be 
the first one implementing this, despite the claims that this is an 
established method... but I hope I'm wrong.


/Anders

On 2020-12-14 19:06, Ture Pålsson via Tagging wrote:

14 dec. 2020 kl. 15:49 skrev Anders Torger :


Okay, but why does the OSM-Carto renderer, and all other renderers 
known to man(?) make multiple text labels then, when it should be a 
single one? Look at the result, it looks horrible. Do you really think 
this is the way it should be done, also long-term? Also note that the 
tags do differ, otherwise it would be a single multipolygon, it's both 
wetland=bog and wetland=marsh.


I have implemented the merge-adjacent-areas scheme in my renderer.
I’ll try to get a demo up… :-)

Having said that, as a renderer implementer, I have a slight
preference for the relation method. It is s implyeasier to join things
on numeric id than to join them by adjacency.

I noticed that you have tagged the ”name” relation as (if I remember 
correctly)


  type=natural, natural=wetland, name=Rijmmoáhppe

I think it would be good to keep the set of possible values for the
’type’ tag small, so I’d like to propose another level of indirection;
something like

  type=named_area, named_area=natural, natural=wetland, name=Peter’s 
Pot


And having said all *that*, on the subject of adjacent-areas vs.
relations, again as a renderer implementer, I very much prefer when
there is one way rather than two of doing something. First of all, if
there are two ways, I need to write code for both of them. Second,
some things invariably end up being tagged with *both* schemes
(adjacent areas with name tags *and* a relation) which means that I
need to detect that case to eliminate duplicate labels. So if a
majority of mappers find relations too hard to use, I think I would
vote for the adjacent-areas method, even though using a relation seems
”cleaner”.



___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
I certainly agree that we should not waste mapper's time, but in this 
case it was mainly actually to make it easier for myself with JOSM to 
find my way back to all small pieces in a fragmented landscape. Not 
having this relation makes editing a fair bit harder as you can't really 
see which parts belong to the same (name labels are really not that 
visible in JOSM) and you need to click your way through or create a 
filter on the name, but since you don't want it I will remove it. It 
will probably lead to more work for me rather than less, but I won't 
invent something that everyone is against. It's a value in keeping it 
simple too. So we can put that to the side, don't worry there will be no 
relations.


Opentopomap has some interesting features, but also it's own family of 
problems. The largest problem (except for limited server capacity) I 
think is that it renders borders between same tag areas, which causes 
lots of borders of technical polygon splitting visible, which exists 
everywhere in the map if you like it or not. The development also seems 
to have stopped, so any issues it has now won't probably be fixed.


And does it render this "well-established method" by automatically 
finding adjacent parts and showing only one label. I'm still waiting for 
the result, but I would be *very* (happily) surprised if it does.


If OSM had been a normally managed project there would be numbered 
releases of a well-defined specification how OSM data should be 
interepreted by renderers. When there is no such thing, how can we 
expect that other renders should solve things, without documentation?


There's so often reference to "other renderers" that does things right, 
but where's the examples? There may be one renderer that make some 
things right, but then others wrong (like opentopomap)... that there 
really is no showcase renderer under the control of OSM itself I 
personally think is the largest waste of mapper's time we do. I see 
people skipping things, guessing, making "creative" incorrect mappings 
just because OSM-Carto is so limited in what it can do. Not only 
beginners, also experienced mappers. Just one example, some are so fed 
up of that OSM-Carto cannot remove text of rivers inside lakes so they 
cut up the river and remove the name instead. If OSM-Carto quality and 
feature set would go up and the documentation (for mappers) with it, so 
would the geo data, of that I'm convinced.


/Anders

On 2020-12-14 21:45, Joseph Eisenberg wrote:

Re; "Don't adjust your mapping to what you believe is most convenient 
for data users"


I know this recommendation is unpopular with some mappers, because many 
of us just want to see a good-looking map, and if it takes duplicating 
relations and extra mapping work we will do it.


But remember that your time as a mapper, even though you give it to 
OpenStreetMap freely, is actually valuable and should never be wasted 
on doing things that can be solved by better software on the database 
user end of things.


We should never ask 10,000 mappers to spend 10 hours a year each to add 
something to the database which saves 10 hours of work for a database 
user.


Sometimes this means that the rendering on openstreetmap.org [1] won't 
look perfect, but we can expect better results in the future with more 
advanced renderers. Consider for example how OpenTopoMap has really 
great natural=peak and natural=saddle rendering, which uses elevation 
and topography to adjust the rendering to look good with the contour 
lines and different zoom levels. This is somewhat complex, but it was 
done by an open-source, free map style.


Once upon a time I planned to add prominece=* tags to all the peaks in 
my area so I could get good rendering results, but the solution which 
OpenTopoMap uses is much better: it's fully automated and fast. Adding 
the topographic prominence to every natural=peak to get better 
rendering is a huge waste of mapper time, when you can instead 
calculate it (or better yet the topographic isolation) at the time of 
rendering.


Similarly mappers shouldn't map a huge relation which includes all 
parts of the water in a long river, since it is much easier to map and 
maintain smaller closed ways for each short part of the river water. If 
database users need one big area, they can pre-process the data to 
create the polygons: don't make life harder for mappers to save the 
database users a few CPU cycles.


Your time is priceless, fellow mappers. The time of database users is 
usually a business expense.


-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann  
wrote:



Anders Torger  hat am 14.12.2020 15:49 geschrieben:

Okay, but why does the OSM-Carto renderer, and all other renderers 
known

to man(?) make multiple text labels then, when it should be a single
one?


OSM-Carto renders labels primarily based on the following constraints:

* due to the requirement of real time updates more complex operations 
are severely 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Mateusz Konieczny via Tagging



Dec 14, 2020, 22:03 by and...@torger.se:

> Ok, understood. However as far as I know OSM lacks a standard document 
> for render implementors to actually know how data should be interpreted.
>
In part it is https://wiki.openstreetmap.org/ in part it is decision of
authors of map style how they want map data to be intererpreted.

> The only reason I get here is when the OSM wiki doesn't have answers
>
Yes, you are raising some very interesting cases (for example case of mountain
and peaks named separately).

> Even here there are various answers and ideas circulating
>
This is whole point of tagging mailing list for features with no known
good way of tagging them. (or where it is not documented)

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
Ok, understood. However as far as I know OSM lacks a standard document 
for render implementors to actually know how data should be interpreted. 
And if OSM-Carto does it wrong (albeit due to technical limitations), 
how can we expect that anyone else would do it right? Unfortunately I 
think the answer is that there is no documentation, and no other data 
consumer will do it correct. I may be wrong though, it would be great to 
know if there is any renderer out there that understands that it is a 
single entity and merge the labels.


I actually don't enjoy being on this list creating havoc or plaguing you 
or anyone else with my daft questions, and I suspect people here doesn't 
enjoy my company much either :-), but don't worry this thread is nearing 
the end and I'll crawl back under my rock again and go back to mapping, 
which is what I truly want to do. But OSM in its current state with the 
way the docs and technical platform is made really begs for this to 
happen as soon as someone like me starts to make high detail mapping, 
and wants answers instead of just skipping, guessing or simplifying when 
tagging challenges arise.


The only reason I get here is when the OSM wiki doesn't have answers, 
and on top of that I get pretty much random answers on OSM Help (which 
seems to be standard), and I need to go here to just get to know how one 
should map certain features, if it even is possible. Even here there are 
various answers and ideas circulating and it's not hard to see the 
cracks in the facade and different ideas even among "high ranking" OSM 
people. The truth is that OSM is not really ready for this type of 
mapping, and that's fine, but it seems to be ultra-sensitive to touch on 
the subject that maybe actually something in the technical platform 
needs development to meet the long-standing goals of OSM.


I also react on the lack of vision and what seems to be a technical dead 
end of the platform. The way you express it makes it seem like OSM is 
dependent on external software providers. Forgive me for my ignorance, 
but don't we have "own" programmers? I know this isn't a traditional 
open-source project (which I'm used to contributing to), but aren't 
there at least some programmers that develop the technical platform 
according to the vision OSM has? Or do we just pick ready-made tools 
that are designed in other projects for other uses and we have no power 
to influence? If it's the latter I'm really worried...


There are levels regarding "high quality cartography". We don't need to 
jump directly to the highest level with smartly scaled/shaped and sorted 
text labels. I would to start with be satisfied with correct rendering, 
and rendering multiple text labels where there by definition should be 
one I consider incorrect. If even that is "too expensive" no meet the 
goal(?) of "low quality low price", well, then I'm speechless.


I've heard big words come out from the OSM foundation, about striving to 
provide the best geodata. Really motivational, making it enjoyable to 
contribute as a mapper. However when I see how the technical platform 
works today, and which features that are missing and on top of that get 
on this list and see the lack of interest and/or capacity to do anything 
about it I see a whole different story.


/Anders

On 2020-12-14 19:41, Christoph Hormann wrote:

Anders Torger  hat am 14.12.2020 15:49 geschrieben:

Okay, but why does the OSM-Carto renderer, and all other renderers 
known

to man(?) make multiple text labels then, when it should be a single
one?


OSM-Carto renders labels primarily based on the following constraints:

* due to the requirement of real time updates more complex operations
are severely restricted.  Clustering features, aggregating the
clusters geometry-wise and labeling the aggregates are such
operations.
* we want the relationship between the data in the database and the
rendering results to be intuitively understandable for the mapper so
they can derive useful feedback from the map.  That also limits the
complexity of data processing we can use.
* like all zoomable interactive maps OSM-Carto has to deal with the
problem that high quality labeling is zoom level dependent.  At the
same time having different approaches to labeling at different zoom
levels adds a lot of complexity to the style - and OSM-Carto is
already one of the most complex map styles in existence.  Hence
compromises are made that look better on some zoom levels than on
others.

As far as other map styles are concerned - i have said that before:
high quality cartography is expensive and the bulk of the digital map
market is low quality and low price - hence requires low costs.  And
the willingness to engage in strategic investment in methods for high
quality cartography in the wider OSM ecosystem as well as in the open
source GIS sector is so far rather small.

What can you do as a mapper:  Produce an accurate representation of
the geography that is non-complex in 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Joseph Eisenberg
Re; "Don't adjust your mapping to what you believe is most convenient for
data users"

I know this recommendation is unpopular with some mappers, because many of
us just want to see a good-looking map, and if it takes duplicating
relations and extra mapping work we will do it.

But remember that your time as a mapper, even though you give it to
OpenStreetMap freely, is actually valuable and should never be wasted on
doing things that can be solved by better software on the database user end
of things.

We should never ask 10,000 mappers to spend 10 hours a year each to add
something to the database which saves 10 hours of work for a database user.

Sometimes this means that the rendering on openstreetmap.org won't look
perfect, but we can expect better results in the future with more advanced
renderers. Consider for example how OpenTopoMap has really great
natural=peak and natural=saddle rendering, which uses elevation and
topography to adjust the rendering to look good with the contour lines and
different zoom levels. This is somewhat complex, but it was done by an
open-source, free map style.

Once upon a time I planned to add prominece=* tags to all the peaks in my
area so I could get good rendering results, but the solution which
OpenTopoMap uses is much better: it's fully automated and fast. Adding the
topographic prominence to every natural=peak to get better rendering is a
huge waste of mapper time, when you can instead calculate it (or better yet
the topographic isolation) at the time of rendering.

Similarly mappers shouldn't map a huge relation which includes all parts of
the water in a long river, since it is much easier to map and maintain
smaller closed ways for each short part of the river water. If database
users need one big area, they can pre-process the data to create the
polygons: don't make life harder for mappers to save the database users a
few CPU cycles.

Your time is priceless, fellow mappers. The time of database users is
usually a business expense.

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann  wrote:

>
>
> > Anders Torger  hat am 14.12.2020 15:49 geschrieben:
> >
> > Okay, but why does the OSM-Carto renderer, and all other renderers known
> > to man(?) make multiple text labels then, when it should be a single
> > one?
>
> OSM-Carto renders labels primarily based on the following constraints:
>
> * due to the requirement of real time updates more complex operations are
> severely restricted.  Clustering features, aggregating the clusters
> geometry-wise and labeling the aggregates are such operations.
> * we want the relationship between the data in the database and the
> rendering results to be intuitively understandable for the mapper so they
> can derive useful feedback from the map.  That also limits the complexity
> of data processing we can use.
> * like all zoomable interactive maps OSM-Carto has to deal with the
> problem that high quality labeling is zoom level dependent.  At the same
> time having different approaches to labeling at different zoom levels adds
> a lot of complexity to the style - and OSM-Carto is already one of the most
> complex map styles in existence.  Hence compromises are made that look
> better on some zoom levels than on others.
>
> As far as other map styles are concerned - i have said that before: high
> quality cartography is expensive and the bulk of the digital map market is
> low quality and low price - hence requires low costs.  And the willingness
> to engage in strategic investment in methods for high quality cartography
> in the wider OSM ecosystem as well as in the open source GIS sector is so
> far rather small.
>
> What can you do as a mapper:  Produce an accurate representation of the
> geography that is non-complex in structure, is easy for you to map and
> maintain and that is consistent with how others map things and don't adjust
> your mapping to what you believe is most convenient for data users.
>
> --
> Christoph Hormann
> https://www.imagico.de/
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 15:49 geschrieben:
> 
> Okay, but why does the OSM-Carto renderer, and all other renderers known 
> to man(?) make multiple text labels then, when it should be a single 
> one? 

OSM-Carto renders labels primarily based on the following constraints:

* due to the requirement of real time updates more complex operations are 
severely restricted.  Clustering features, aggregating the clusters 
geometry-wise and labeling the aggregates are such operations.
* we want the relationship between the data in the database and the rendering 
results to be intuitively understandable for the mapper so they can derive 
useful feedback from the map.  That also limits the complexity of data 
processing we can use.
* like all zoomable interactive maps OSM-Carto has to deal with the problem 
that high quality labeling is zoom level dependent.  At the same time having 
different approaches to labeling at different zoom levels adds a lot of 
complexity to the style - and OSM-Carto is already one of the most complex map 
styles in existence.  Hence compromises are made that look better on some zoom 
levels than on others.

As far as other map styles are concerned - i have said that before: high 
quality cartography is expensive and the bulk of the digital map market is low 
quality and low price - hence requires low costs.  And the willingness to 
engage in strategic investment in methods for high quality cartography in the 
wider OSM ecosystem as well as in the open source GIS sector is so far rather 
small.  

What can you do as a mapper:  Produce an accurate representation of the 
geography that is non-complex in structure, is easy for you to map and maintain 
and that is consistent with how others map things and don't adjust your mapping 
to what you believe is most convenient for data users.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Ture Pålsson via Tagging
14 dec. 2020 kl. 15:49 skrev Anders Torger :
> 
> Okay, but why does the OSM-Carto renderer, and all other renderers known to 
> man(?) make multiple text labels then, when it should be a single one? Look 
> at the result, it looks horrible. Do you really think this is the way it 
> should be done, also long-term? Also note that the tags do differ, otherwise 
> it would be a single multipolygon, it's both wetland=bog and wetland=marsh.

I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try to 
get a demo up… :-)

Having said that, as a renderer implementer, I have a slight preference for the 
relation method. It is s implyeasier to join things on numeric id than to join 
them by adjacency.

I noticed that you have tagged the ”name” relation as (if I remember correctly)

  type=natural, natural=wetland, name=Rijmmoáhppe

I think it would be good to keep the set of possible values for the ’type’ tag 
small, so I’d like to propose another level of indirection; something like

  type=named_area, named_area=natural, natural=wetland, name=Peter’s Pot

And having said all *that*, on the subject of adjacent-areas vs. relations, 
again as a renderer implementer, I very much prefer when there is one way 
rather than two of doing something. First of all, if there are two ways, I need 
to write code for both of them. Second, some things invariably end up being 
tagged with *both* schemes (adjacent areas with name tags *and* a relation) 
which means that I need to detect that case to eliminate duplicate labels. So 
if a majority of mappers find relations too hard to use, I think I would vote 
for the adjacent-areas method, even though using a relation seems ”cleaner”.



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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger

On 2020-12-14 15:22, Christoph Hormann wrote:

Anders Torger  hat am 14.12.2020 14:01 geschrieben:

But i already explained that the fact that in OSM we add name tags to
parts of roads, waterways, wetlands, forests or woods does not mean
these are somehow separate from other features with the same name
tags.  Names of physical geography features in OSM are - as explained
- local names.  A polygon tagged natural=wood + name=foo means that
this is an stretch of land covered with trees that locally is referred
to with the name 'foo'.  If you took a walk on a route that crosses
such polygon you can correctly say that today's hike took you through
'foo'.  However if your walk crossed five natural=wood polygons with
name=foo you *cannot* say based on this that your walk took you
through five 'foo' or through five parts of 'foo'.  The splitting of
the wood into five polygons is part of the data model we use, it does
not represent any 'five-ness' is the verifiable reality.


Okay, but why does the OSM-Carto renderer, and all other renderers known 
to man(?) make multiple text labels then, when it should be a single 
one? Look at the result, it looks horrible. Do you really think this is 
the way it should be done, also long-term? Also note that the tags do 
differ, otherwise it would be a single multipolygon, it's both 
wetland=bog and wetland=marsh.


Why have I got the recommendation, by no lesser than Frederik Ramm 
(which I afterwards have figured out is a Geofabrik guy so he's probably 
pretty influential), to NOT split forests, "one feature should be one 
polygon":


https://help.openstreetmap.org/questions/77436/is-it-okay-to-split-forest-into-multiple-parts-with-arbitrary-seams

I've got suggestions of 4 - 5 different ways to handle these type of 
situations including drawing a new polygon on top of everything and not 
just care about JOSM warnings or OSM-Carto results. Probably all these 
suggestions coming from OSM contributors much more experienced than I 
am. As a newcomer I don't know who anybody is, what authority each of 
these posts have. So I think I have some right to be confused... and 
indeed I have got suggestion in this list to actually use a relation by 
at least one contributor, I don't remember from who now but I guess I 
can dig it out from the thread somewhere.



"Verifiable" is tricky in terms of names of natural features as we all
know, as many of those haven't defined borders. [...]


I think you have a pretty fundamental misunderstanding here.


I don't think so based on verifiability definition on the osm wiki, 
where borders are indeed discussed. But that's an irrelevant meta 
discussion, I'll leave it at that. Fuzzy areas do lack full 
verifiability as you cannot get a clear definition "is this inside or 
outside the area". As Frederik has pointed out in a different post this 
leads to some issues. I hope we can overcome those though.


/Anders

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
Yes, I agree in full, and I forgot to add in that post that I believe 
the long-term solution for this wetland and other natural features like 
it is indeed to use some fuzzy-area feature. For some reason (I wonder 
why...?) I've got the sense that such a feature could be debated for 
years to come without actually come into fruition so I'm grateful for 
any ugly-hack-stepping-stone I can use meanwhile, so I can just get on 
with my mapping without having to leave out lots of valuable 
information. Then I, or someone else, can come back later and update the 
tagging when there's a better method.


About fuzzy areas:

These fuzzy areas could actually exist today, and straits and bay areas 
do exist and do even render. Personally, I think it's acceptable to just 
put them on top, as one can filter them out in JOSM very easily when 
working with other stuff, and I suppose a fuzzy area filter wouldn't be 
too complicated to implement in iD either.


That the areas is fuzzy can be defined through the type of area (ie bay, 
strait) or one could add an extra tag "fuzzy". As the renderers will 
only show the name tag, any end user will not see the exact extent of 
the fuzzy area, so I don't think it's a problem.


Or, we have them in a different database. While I personally think it 
would be overkill, if that's the only way forward so be it. But if so I 
think it's required that OSM-Carto makes use of it, otherwise it will be 
so unsatisfactory to contribute to it that regular mappers won't do it, 
and then the project will eventually fade out and die, and give the 
naysayers fuel to say that noone really wanted that feature anyway.


I've heard "tagging for the renderer" argument for these type of areas 
and that a single point (like place=locality) would actually be better. 
However, the way I see it, it's the other way around. When placing a 
point you actually do tag for the renderer, the renderer doesn't get any 
freedom where to place the name label. There's also lots of issues 
figuring out which names to show when zooming out, so all just disappear 
at an early stage making rural areas look rather empty... when placing 
an area you just specify the actual area (in a rough way), and then 
based on that information the renderer can place its name label wherever 
it wants. Advanced renderers could shape the text accordingly, when 
zooming in it could show more than one label off center, etc.


I'm no cartography expert, but I think that the common way others do it 
is to manually place labels at points, and sometimes as bendy lines, so 
this way to automatically render names from fuzzy areas instead of 
placing them manually would be a progressive design choice, but I think 
it could be "the right way"(tm). If we instead come up with a name label 
placement strategy better developed than the overly generic 
place=locality, sure I'd be fine with that too, it makes my mapping work 
quicker although with less information. Anything that works...


I also agree that it is obvious that these features do exist in the real 
world, and I think we should strive to make a platform that is able to 
document that even if those natural features are not squarely defined. 
There are issues and challenges, but if the will is there, they can be 
handled.


/Anders

On 2020-12-14 14:31, Brian M. Sperlongano wrote:

It sounds like what we are asking for is the ability to tag a rough 
polygon in the approximate area where a label should be placed for a 
known but not strictly bounded toponymic feature (mountain range, water 
body, etc).  That would give a hint to renderers as to the location and 
most importantly, size, of a label for such features.  This would also 
solve the current problem of tagging large coastline-bounded marine 
features, such as seas, bays, straits, etc., without creating overly 
complex polygons resulting from re-use of the coastline ways.  It would 
also fix the inability to tag such basic features as oceans.  When you 
type "Atlantic Ocean" into any map other than OSM, it shows you the 
ocean.  When you type it into openstreetmap.org [1], it shows you a 
super-close zoom-in to a single node - not very helpful.


It is reductio ad absurdum to say that features like "Pacific Ocean", 
"Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a 
project that aims to create a map of the world simply because these 
features don't have a fence or sign around them to indicate their exact 
boundary.  Features exist in approximation in the real world, and it is 
a perfectly valid opinion to want those things to appear, also in 
approximation, on the map.  These things are verifiable because people 
know what these toponyms mean and represent.  If it is possible to 
write a wikipedia article on "Indian Ocean", it is possible to draw a 
rough polygon in openstreetmap which means "this is roughly where the 
Indian Ocean is, and renderers should consider drawing a label".


Note that this is not "tagging 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 14:01 geschrieben:
> 
>  
> To make a specific answer to "what additional verifiable local 
> knowledge" this relation is intended to cover, is that the wetland is a 
> single named entity, not multiple entities named the same.

But i already explained that the fact that in OSM we add name tags to parts of 
roads, waterways, wetlands, forests or woods does not mean these are somehow 
separate from other features with the same name tags.  Names of physical 
geography features in OSM are - as explained - local names.  A polygon tagged 
natural=wood + name=foo means that this is an stretch of land covered with 
trees that locally is referred to with the name 'foo'.  If you took a walk on a 
route that crosses such polygon you can correctly say that today's hike took 
you through 'foo'.  However if your walk crossed five natural=wood polygons 
with name=foo you *cannot* say based on this that your walk took you through 
five 'foo' or through five parts of 'foo'.  The splitting of the wood into five 
polygons is part of the data model we use, it does not represent any 
'five-ness' is the verifiable reality.

> "Verifiable" is tricky in terms of names of natural features as we all 
> know, as many of those haven't defined borders. [...]

I think you have a pretty fundamental misunderstanding here.  Name tagging of 
physical features like wetlands in OSM have practically no issue with 
verifiability because the name tag specifies the name locally used for a 
feature that exists independent of the name.  

You however seem to be talking about abstract concepts that constitute 
themselves through the name and that exist only through the fact that it is 
referred to with some name in communication and that are neither tied to 
physical geography features that exist independent of humans (like a forest, 
lake, wetland etc.) or cultural geography features that constitute themselves 
from independently observable human activities (like shops, addresses or bus 
stops for example) beyond mere communication.

Such concepts are not mappable in OSM due to the lack of independent 
verifiability.  The world of such features does not represent a consistent 
independently observable reality.  Human communication as the foundation of 
this world is inherently inconsistent and self-contradicting.  You would end up 
with a Wikipedia-like paradigm of "reliable sources" and a constant struggle 
for cultural dominance and opinion leadership w.r.t. such features in the OSM 
database.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger


I should have added that a long-term solution is probably some sort of 
collective concept to handle fuzzy natural areas, and then this wetland 
will also be named as a fuzzy natural area, although less fuzzy than 
your typical natural fuzzy area :-). But how long will that take to get 
realized, when a single tag can take years? I'd like to have some 
placeholder tagging for later upgrading so the data can be effective now 
rather than potentially never. So to me lots of small names all over the 
wetland and a relation to be able to find them later is indeed an ugly 
but still an acceptable stepping stone, and not the least a good 
reminder than something needs to be done.


/Anders

On 2020-12-14 14:01, Anders Torger wrote:

To make a specific answer to "what additional verifiable local
knowledge" this relation is intended to cover, is that the wetland is
a single named entity, not multiple entities named the same.

And here's some elaboration. This is 4 km wide wetland, in the real
world named as a single entity, but it does consist of both bog and
marsh, in the screenshot named each separate part as you suggested:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

"Verifiable" is tricky in terms of names of natural features as we all
know, as many of those haven't defined borders. Wetlands maybe so, but
even in this case, are the small satellite wetlands part of Rijmmoàhpe
or not? Noone knows, it was never defined. That's the way these names
work. Does that mean that these type of names should not be in OSM at
all? You tell me. I just try to contribute geodata to make maps for
outdoor use. If OSM is not the platform, let me know.

I'm not particularly experienced in how OSM use relations and why the
are so "obnoxious" as Mateusz put it, but I have worked with arranging
data in many projects and to me this is an obvious case of data that
should be arranged as a container with all its parts. I also think
that it would make it much easier to fix the renderer, it can easily
get all parts for the single name, and as a added bonus get to know
the "master type" (instead of having to go through all parts calculate
the area to figure out which nature that is dominant to get the tag
styling right). Etc.

I didn't add it thinking about any renderer though, it was actually
for myself to more easily keep track of all parts when editing on
JOSM. With a parent relation I just need to click on one, and then on
the parent relation to get all selected. Otherwise I need to create a
filter on the name or something, so to me it's also more efficient for
the mapper.

And in the end I think that the individual parts should not have name
tags at all, it should only be on the parent relation. The reason we
put it on the individual parts now is to me obviously just because
there is no renderer support available anywhere for naming these type
of natural entities, and probably will stay that way for the
foreseeable future.

Having a relation on these new features makes them easy to find in the
database and one can upgrade the tags later. I suppose it's much more
complicated to make a filter to find parts named the same with shared
borders, I don't really know how to do it in JOSM (but maybe one
can?).

So that's my reasons, but if you think they're bad I'll remove the
relation. I would like to hear how you want to solve the problem
instead though. As you see on the screenshot, the current situation is
far from optimal with lots of tiny name tags where there should be
only one.

/Anders

On 2020-12-14 13:28, Christoph Hormann wrote:

Anders Torger  hat am 14.12.2020 07:59 geschrieben:


I'll gladly answer questions, but I think you need to rephrase. I
suppose it is some hidden critique in there, but I honestly do not
understand the question. It would be better for me if you put words 
on

the critique instead of wrapping it in a question.


There is no critique in there, i have not formed an opinion on the
concept, i like to understand the reasoning behind this.  Hence the
question.

The premise is that in OSM we record verifiable local knowledge about
the geography of the world.  And we try to record that in a form that
is most efficient for the mapper.  Hence the question what additional
verifiable knowledge you intend to record with the additional data
structures you propose to create that is not yet in what we already
record today.

--
Christoph Hormann
https://www.imagico.de/

___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Brian M. Sperlongano
It sounds like what we are asking for is the ability to tag a rough polygon
in the approximate area where a label should be placed for a known but not
strictly bounded toponymic feature (mountain range, water body, etc).  That
would give a hint to renderers as to the location and most importantly,
size, of a label for such features.  This would also solve the current
problem of tagging large coastline-bounded marine features, such as seas,
bays, straits, etc., without creating overly complex polygons resulting
from re-use of the coastline ways.  It would also fix the inability to tag
such basic features as oceans.  When you type "Atlantic Ocean" into any map
other than OSM, it shows you the ocean.  When you type it into
openstreetmap.org, it shows you a super-close zoom-in to a single node -
not very helpful.

It is reductio ad absurdum to say that features like "Pacific Ocean",
"Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a
project that aims to create a map of the world simply because these
features don't have a fence or sign around them to indicate their exact
boundary.  Features exist in approximation in the real world, and it is a
perfectly valid opinion to want those things to appear, also in
approximation, on the map.  These things are verifiable because people know
what these toponyms mean and represent.  If it is possible to write a
wikipedia article on "Indian Ocean", it is possible to draw a rough polygon
in openstreetmap which means "this is roughly where the Indian Ocean is,
and renderers should consider drawing a label".

Note that this is not "tagging for the renderer" (which is often code for
"tagging that I don't like"), these are real, major features that actually
exist in the real world and their absence makes OSM weaker.

On Mon, Dec 14, 2020 at 8:04 AM Anders Torger  wrote:

> To make a specific answer to "what additional verifiable local
> knowledge" this relation is intended to cover, is that the wetland is a
> single named entity, not multiple entities named the same.
>
> And here's some elaboration. This is 4 km wide wetland, in the real
> world named as a single entity, but it does consist of both bog and
> marsh, in the screenshot named each separate part as you suggested:
>
>
> https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
>
> "Verifiable" is tricky in terms of names of natural features as we all
> know, as many of those haven't defined borders. Wetlands maybe so, but
> even in this case, are the small satellite wetlands part of Rijmmoàhpe
> or not? Noone knows, it was never defined. That's the way these names
> work. Does that mean that these type of names should not be in OSM at
> all? You tell me. I just try to contribute geodata to make maps for
> outdoor use. If OSM is not the platform, let me know.
>
> I'm not particularly experienced in how OSM use relations and why the
> are so "obnoxious" as Mateusz put it, but I have worked with arranging
> data in many projects and to me this is an obvious case of data that
> should be arranged as a container with all its parts. I also think that
> it would make it much easier to fix the renderer, it can easily get all
> parts for the single name, and as a added bonus get to know the "master
> type" (instead of having to go through all parts calculate the area to
> figure out which nature that is dominant to get the tag styling right).
> Etc.
>
> I didn't add it thinking about any renderer though, it was actually for
> myself to more easily keep track of all parts when editing on JOSM. With
> a parent relation I just need to click on one, and then on the parent
> relation to get all selected. Otherwise I need to create a filter on the
> name or something, so to me it's also more efficient for the mapper.
>
> And in the end I think that the individual parts should not have name
> tags at all, it should only be on the parent relation. The reason we put
> it on the individual parts now is to me obviously just because there is
> no renderer support available anywhere for naming these type of natural
> entities, and probably will stay that way for the foreseeable future.
>
> Having a relation on these new features makes them easy to find in the
> database and one can upgrade the tags later. I suppose it's much more
> complicated to make a filter to find parts named the same with shared
> borders, I don't really know how to do it in JOSM (but maybe one can?).
>
> So that's my reasons, but if you think they're bad I'll remove the
> relation. I would like to hear how you want to solve the problem instead
> though. As you see on the screenshot, the current situation is far from
> optimal with lots of tiny name tags where there should be only one.
>
> /Anders
>
> On 2020-12-14 13:28, Christoph Hormann wrote:
> >> Anders Torger  hat am 14.12.2020 07:59 geschrieben:
> >>
> >>
> >> I'll gladly answer questions, but I think you need to rephrase. I
> >> suppose it is some hidden critique in 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
To make a specific answer to "what additional verifiable local 
knowledge" this relation is intended to cover, is that the wetland is a 
single named entity, not multiple entities named the same.


And here's some elaboration. This is 4 km wide wetland, in the real 
world named as a single entity, but it does consist of both bog and 
marsh, in the screenshot named each separate part as you suggested:


https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

"Verifiable" is tricky in terms of names of natural features as we all 
know, as many of those haven't defined borders. Wetlands maybe so, but 
even in this case, are the small satellite wetlands part of Rijmmoàhpe 
or not? Noone knows, it was never defined. That's the way these names 
work. Does that mean that these type of names should not be in OSM at 
all? You tell me. I just try to contribute geodata to make maps for 
outdoor use. If OSM is not the platform, let me know.


I'm not particularly experienced in how OSM use relations and why the 
are so "obnoxious" as Mateusz put it, but I have worked with arranging 
data in many projects and to me this is an obvious case of data that 
should be arranged as a container with all its parts. I also think that 
it would make it much easier to fix the renderer, it can easily get all 
parts for the single name, and as a added bonus get to know the "master 
type" (instead of having to go through all parts calculate the area to 
figure out which nature that is dominant to get the tag styling right). 
Etc.


I didn't add it thinking about any renderer though, it was actually for 
myself to more easily keep track of all parts when editing on JOSM. With 
a parent relation I just need to click on one, and then on the parent 
relation to get all selected. Otherwise I need to create a filter on the 
name or something, so to me it's also more efficient for the mapper.


And in the end I think that the individual parts should not have name 
tags at all, it should only be on the parent relation. The reason we put 
it on the individual parts now is to me obviously just because there is 
no renderer support available anywhere for naming these type of natural 
entities, and probably will stay that way for the foreseeable future.


Having a relation on these new features makes them easy to find in the 
database and one can upgrade the tags later. I suppose it's much more 
complicated to make a filter to find parts named the same with shared 
borders, I don't really know how to do it in JOSM (but maybe one can?).


So that's my reasons, but if you think they're bad I'll remove the 
relation. I would like to hear how you want to solve the problem instead 
though. As you see on the screenshot, the current situation is far from 
optimal with lots of tiny name tags where there should be only one.


/Anders

On 2020-12-14 13:28, Christoph Hormann wrote:

Anders Torger  hat am 14.12.2020 07:59 geschrieben:


I'll gladly answer questions, but I think you need to rephrase. I
suppose it is some hidden critique in there, but I honestly do not
understand the question. It would be better for me if you put words on
the critique instead of wrapping it in a question.


There is no critique in there, i have not formed an opinion on the
concept, i like to understand the reasoning behind this.  Hence the
question.

The premise is that in OSM we record verifiable local knowledge about
the geography of the world.  And we try to record that in a form that
is most efficient for the mapper.  Hence the question what additional
verifiable knowledge you intend to record with the additional data
structures you propose to create that is not yet in what we already
record today.

--
Christoph Hormann
https://www.imagico.de/

___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 07:59 geschrieben:
> 
>  
> I'll gladly answer questions, but I think you need to rephrase. I 
> suppose it is some hidden critique in there, but I honestly do not 
> understand the question. It would be better for me if you put words on 
> the critique instead of wrapping it in a question.

There is no critique in there, i have not formed an opinion on the concept, i 
like to understand the reasoning behind this.  Hence the question.

The premise is that in OSM we record verifiable local knowledge about the 
geography of the world.  And we try to record that in a form that is most 
efficient for the mapper.  Hence the question what additional verifiable 
knowledge you intend to record with the additional data structures you propose 
to create that is not yet in what we already record today.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger

Hello Frederik,

good and clearly communicated points! I very much appreciate that, and I 
agree with the issues you describe. Those are indeed real problems.


However, these fuzzy regions also exist on a small scale, and in my case 
it's always been about that. The features I'm mapping now are not the 
scale of "The Alps" or even the Black Forest, it's a named wetlands, 1-5 
km wide, a single mountain, a slope, a hill, a heath, a small bay or 
strait in a lake, etc. These names are everywhere, with more or less 
defined borders (often less).


Maybe there should be one system of fuzzy areas to handle both of these 
cases, or maybe there should be two, maybe small scale geography could 
be in OSM and large scale should be outside. I don't know.


What I do know is that any institutionally made map has these names and 
that these are important for outdoor maps, just like names on lakes, and 
if we want OSM to be able to provide data for rendering high quality 
maps these names must be available somewhere and somehow. I hope that I 
don't need to argue that these names do have a place in maps, actually I 
think they are quite important for certain types of maps. I understand 
that probably outdoor maps is not a priority for most commercial uses of 
OSM, so it may not be much money in supporting this. I guess what people 
want to know on average is the nearest café in an urban area, not a 
guide in a remote national park. So I could also accept that OSM is not 
the place for storing geodata for outdoor maps, as long as it's clearly 
stated.


It does feel like the normal OSM tagging process isn't really fit for 
making progress in this space, as this may require some strategic 
decisions implementing and making use of new technical platforms. So the 
first thing I'd like to see is that we get a consensus on a goal that we 
actually *want* these type of features, and then the exact solution can 
be discussed.


As it is now we seem stuck at status quo, and I just see lots of passive 
opposition, my ideas of implementation are indeed probably not the 
greatest so I understand they get criticism and fairly so, but in the 
end I just stand there back at square one with the same problem and no 
solution in sight. There are indeed some good efforts to try to solve 
this for "The Alps" and similar names large scale names: 
https://github.com/dieterdreist/OpenGeographyRegions . Maybe this also 
could be used for small scale names I don't know, but these type of 
projects have little chance of catching on without coordinated support 
from a renderer and "official" OSM wiki docs with usage recommendations 
so mappers actually get to use it and contribute and eventually see the 
result.


/Anders

On 2020-12-14 12:39, Frederik Ramm wrote:

Hi,

On 14.12.20 12:20, Anders Torger wrote:

My sense is that OSM community do want naming in nature as well, but
only if it can be made very simple. Unfortunately that is not always
compatible with reality, and here we are...


Personally I think naming is desirable for clear features. This 
mountain

peak, this protected tree, this lake.

What I don't like in OSM is naming for large geographic areas, like 
"the

Alps", "the Black Forest", or "the Bay of Biscay", for two reasons:

First, there can be any number of such areas. Anyone can invent
something. I can speak of the Alps, or the French Alps, or the Northern
French Alps, or the Vanoise Massif, I can group some regions at will 
and

make up a new name. These are not administrative boundaries where it is
clear which of them exist "as a region" and and which don't. Of course
everyone knows what I mean when I say "Germany north of Oldenburg" but
that doesn't mean that "Germany north of Oldenburg" is a name that
should be on the map, or a polygon we need in OSM. If I issue a tourist
guide for, say, "Vanoise et Maurienna", does that then make "Vanoise et
Maurienna" a region? How many people need to issue a tourist guide for
this to happen?

Second, these areas are usually ill-defined: There are some places that
are clearly in the Black Forest, and some that are clearly not in the
Black Forest, but there's not one boundary line - there's fuzziness. 
OSM
is not good with fuzziness; OSM forces us to have an exact point or 
line

or polygon for something. For fuzzy labels, you need a different system
that should exist outside of OSM's current data types. Either by adding
a new fuzzy data type to OSM (no need to assemble 1000 ways with a 
total

of 20,000 points to exactly describe the outline of the Alps if all you
want is a nice big lettering in approximately the right spot), or by
keeping these cartography options in a separate system altogether.

Bye
Frederik


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Frederik Ramm
Hi,

On 14.12.20 12:20, Anders Torger wrote:
> My sense is that OSM community do want naming in nature as well, but
> only if it can be made very simple. Unfortunately that is not always
> compatible with reality, and here we are...

Personally I think naming is desirable for clear features. This mountain
peak, this protected tree, this lake.

What I don't like in OSM is naming for large geographic areas, like "the
Alps", "the Black Forest", or "the Bay of Biscay", for two reasons:

First, there can be any number of such areas. Anyone can invent
something. I can speak of the Alps, or the French Alps, or the Northern
French Alps, or the Vanoise Massif, I can group some regions at will and
make up a new name. These are not administrative boundaries where it is
clear which of them exist "as a region" and and which don't. Of course
everyone knows what I mean when I say "Germany north of Oldenburg" but
that doesn't mean that "Germany north of Oldenburg" is a name that
should be on the map, or a polygon we need in OSM. If I issue a tourist
guide for, say, "Vanoise et Maurienna", does that then make "Vanoise et
Maurienna" a region? How many people need to issue a tourist guide for
this to happen?

Second, these areas are usually ill-defined: There are some places that
are clearly in the Black Forest, and some that are clearly not in the
Black Forest, but there's not one boundary line - there's fuzziness. OSM
is not good with fuzziness; OSM forces us to have an exact point or line
or polygon for something. For fuzzy labels, you need a different system
that should exist outside of OSM's current data types. Either by adding
a new fuzzy data type to OSM (no need to assemble 1000 ways with a total
of 20,000 points to exactly describe the outline of the Alps if all you
want is a nice big lettering in approximately the right spot), or by
keeping these cartography options in a separate system altogether.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
Yeah, you may be right, but I see it like this: in cases where "complex" 
naming is a reality, complex schemes are unavoidable, if we want to 
support it at all. It's not like one would use the most complex method 
in every case, just where it's needed. To use an old saying, Einstein I 
think: "make it as simple as possible, but no simpler". Now we are at 
some places making it so simple that it becomes incorrect.


I haven't really figured out if the OSM community as a whole actually 
want to support these types of things though. It's quite meaningless to 
fight for a tiny feature in this space if the whole concept of naming 
nature is frowned upon. That there are so many features still missing or 
poorly defined in this space after so many years does indicate that it 
has least hasn't been a priority. It's called open*street*map after 
all...


My sense is that OSM community do want naming in nature as well, but 
only if it can be made very simple. Unfortunately that is not always 
compatible with reality, and here we are...


/Anders

On 2020-12-14 11:39, Mateusz Konieczny via Tagging wrote:


Relations are quite obnoxious in regular editing and also
during actually using the data.

Dec 14, 2020, 08:07 by and...@torger.se:

Why is the relation problematic (honest question)?

I was starting to think that some sort of naming relation could be the 
answer, ie you put both peaks in a relation with for example type=name; 
natural=mountain; name=Kebnekaise.


In addition one should write clearly that peak serves dual purpose both 
as naming peaks and mountains. Today on the wiki the peak is clearly 
defined as only the summit, but it's often used as naming mountains 
where the peak is nameless.


What we also could have is fuzzy naming areas, which we would need in 
some way or another at some point anyway, so you would have an area 
covering the mountain with name=Kebnekaise. I would have no problem 
with that, but it seems to that it must be in a separate database as it 
just too controversial to be in the main database.


/Anders

On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:

Dec 13, 2020, 19:58 by and...@torger.se:

Do you have a suggestion of how to map Sweden's highest mountain, 
Kebnekaise?


The mountain is called Kebnekaise, it has two peaks, one is called 
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north 
peak").
I admit that I have no good idea, if I would run into such case and 
failed to find a better idea

(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary 
position between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.


(The mountain_range tag is a great tag, but I note that its status is 
just "in use", it's not an approved tag :-O.)
It is perfectly fine to use tags that never went through tagging 
proposal, though
I am not going to endorse this one. Tagging mountain ranges seems to 
poorly fit OSM
with multiple different opinions where mountain range starts/ends and 
inability to

verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.

___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Mateusz Konieczny via Tagging
Relations are quite obnoxious in regular editing and also
during actually using the data.


Dec 14, 2020, 08:07 by and...@torger.se:

>
> Why is the relation problematic (honest question)?
>
>
> I was starting to think that some sort of naming relation could be the 
> answer, ie you put both peaks in a relation with for example type=name; 
> natural=mountain; name=Kebnekaise.
>
>
> In addition one should write clearly that peak serves dual purpose both as 
> naming peaks and mountains. Today on the wiki the peak is clearly defined as 
> only the summit, but it's often used as naming mountains where the peak is 
> nameless.
>
>
> What we also could have is fuzzy naming areas, which we would need in some 
> way or another at some point anyway, so you would have an area covering the 
> mountain with name=Kebnekaise. I would have no problem with that, but it 
> seems to that it must be in a separate database as it just too controversial 
> to be in the main database.
>
>
> /Anders
>
>
> On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:
>
>
>>  
>>  
>>  
>> Dec 13, 2020, 19:58 by and...@torger.se:
>>
>>>
>>> Do you have a suggestion of how to map Sweden's highest mountain, 
>>> Kebnekaise?
>>>
>>>
>>> The mountain is called Kebnekaise, it has two peaks, one is called 
>>> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>>>
>>>
>> I admit that I have no good idea, if I would run into such case and failed 
>> to find a better idea
>> (hopefully one will come) I would invent a new way to tag that.
>>  
>> natural=mountain? Main problem is where to put it - node at arbitrary 
>> position between peaks?
>> Node at location of highest peak? Area? Relation? All of that is sadly 
>> problematic.
>>
>>>
>>> (The mountain_range tag is a great tag, but I note that its status is just 
>>> "in use", it's not an approved tag :-O.)
>>>
>>>
>> It is perfectly fine to use tags that never went through tagging proposal, 
>> though
>> I am not going to endorse this one. Tagging mountain ranges seems to poorly 
>> fit OSM
>> with multiple different opinions where mountain range starts/ends and 
>> inability to
>> verify it by survey.
>>  
>> All tags were in some stage rarely used before becoming heavily used,
>> only some cases went through a proposal process.
>>
>> ___
>> 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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
Sorry for perhaps adding further complexity, but if you haven't noted, 
one thing that crawls under the surface when it comes to names in nature 
is this "holy" principle:


https://wiki.openstreetmap.org/wiki/Verifiability

Names of natural features often don't have strict borders. Wetlands as 
in this example is typically quite defined, but there are cases also in 
Muddus when the wetland is so large that it has one name in one end and 
another name in the other. So I have to split the wetland at some point 
I find "suitable". That is not verifiable, there's never been a defined 
border, and another mapper could choose a slightly different split line. 
I don't see it as a big issue, as long as renderers don't render and 
outline these borders, but I can "read between the lines" that some on 
this list do.


However fuzzy borders like this is not some narrow special case. Names 
in nature is very often this way, and many names have survived from 
times when the civilization weren't even much bothered by such borders 
at all. In lakes and sea we have a lot of these too of course, and there 
the fuzzy areas bay and strait actually do exist and serves the 
cartography well, but not without protests... I've seen desire to have 
these removed completely.


I think OSM should either strive support nature naming as it works in 
reality (and document how to tag), or make a clear statement that names 
of this type should not exist in the database. I think the latter would 
be sad, but at the same time I find it extremely frustrating to get what 
I experience as "passive opposition" when I bring up these kind of 
needs.


A clear statement would be nicer. On the verifiability page above there 
actually are is an example of fuzzy areas and that those can be accepted 
(hamlet used as an example). Nature naming is not discussed though.


/Anders

On 2020-12-14 10:41, Anders Torger wrote:

For reference, here's Rijmmoáhpe again, a wetland which is about 4 km 
across, consisting of both bog and marsh:


https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

It's located in Muddus national park, Sweden.

I'm quite sure the recommendation Christoph refers to is simply to put 
names on each separate part, which is seen in the screenshot. It's 
unclear to me if this is seen by Christoph and others as a final and 
good solution, or just as "the best we can do for the moment". So I 
hope to get a clarification on that.


Personally I see it as "the best we can do for the moment", but think 
that it of course should be rendered as a single name, and as such the 
name tag should not really be on each separate part, but on a relation. 
Sure a renderer could trace around and scan for neighboring areas with 
the same name and automatically, calculate the area of each part to 
find out the dominant nature type (required for name tag styling), and 
place a single name, but to me it does not seem like a proper way to 
arrange geo data for a single named natural entity.


So what I have done in addition is to create a relation with 
type=natural; natural=wetland; name=Rijmmoáhpe with all the parts as 
members (role field unset). If that is just too controversial, I can 
skip that and leave with just naming the parts. I planned to do that at 
first, but as some of these natural features are quite heavily 
fragmented in small pieces just for a management point of view in JOSM 
I found this relation to be practical thing to have, so I added it.


There's a whole family of unanswered questions regarding to names of 
nature. If Martin's fuzzy area concept was accepted and used 
https://github.com/dieterdreist/OpenGeographyRegions maybe many of 
these features would use that instead. Or maybe if place=locality 
concept on points was developed and diversified that could be used 
instead. I don't have any strong opinions on which method to use, I 
just want to be able to map with high detail and high quality and use 
any method that works.


On 2020-12-14 10:05, Ture Pålsson via Tagging wrote:

13 dec. 2020 kl. 16:15 skrev Christoph Hormann :
I am trying to understand what the issue is with the recommendation for 
mapping you have received from multiple sides here.
Just to clarify, could you summarise what that recommendation is, for 
the Rijmmoáhpe case? The thread has become a little unwieldy (partially 
my fault... sorry about that!).


___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Anders Torger
For reference, here's Rijmmoáhpe again, a wetland which is about 4 km 
across, consisting of both bog and marsh:


https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

It's located in Muddus national park, Sweden.

I'm quite sure the recommendation Christoph refers to is simply to put 
names on each separate part, which is seen in the screenshot. It's 
unclear to me if this is seen by Christoph and others as a final and 
good solution, or just as "the best we can do for the moment". So I hope 
to get a clarification on that.


Personally I see it as "the best we can do for the moment", but think 
that it of course should be rendered as a single name, and as such the 
name tag should not really be on each separate part, but on a relation. 
Sure a renderer could trace around and scan for neighboring areas with 
the same name and automatically, calculate the area of each part to find 
out the dominant nature type (required for name tag styling), and place 
a single name, but to me it does not seem like a proper way to arrange 
geo data for a single named natural entity.


So what I have done in addition is to create a relation with 
type=natural; natural=wetland; name=Rijmmoáhpe with all the parts as 
members (role field unset). If that is just too controversial, I can 
skip that and leave with just naming the parts. I planned to do that at 
first, but as some of these natural features are quite heavily 
fragmented in small pieces just for a management point of view in JOSM I 
found this relation to be practical thing to have, so I added it.


There's a whole family of unanswered questions regarding to names of 
nature. If Martin's fuzzy area concept was accepted and used 
https://github.com/dieterdreist/OpenGeographyRegions maybe many of these 
features would use that instead. Or maybe if place=locality concept on 
points was developed and diversified that could be used instead. I don't 
have any strong opinions on which method to use, I just want to be able 
to map with high detail and high quality and use any method that works.


On 2020-12-14 10:05, Ture Pålsson via Tagging wrote:


13 dec. 2020 kl. 16:15 skrev Christoph Hormann :
I am trying to understand what the issue is with the recommendation 
for mapping you have received from multiple sides here.


Just to clarify, could you summarise what that recommendation is, for 
the Rijmmoáhpe case? The thread has become a little unwieldy (partially 
my fault... sorry about that!).


___
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] How to put a name tag on an area with more than one type?

2020-12-14 Thread Ture Pålsson via Tagging

> 13 dec. 2020 kl. 16:15 skrev Christoph Hormann :
> 
> I am trying to understand what the issue is with the recommendation for 
> mapping you have received from multiple sides here.

Just to clarify, could you summarise what that recommendation is, for the 
Rijmmoáhpe case? The thread has become a little unwieldy (partially my fault… 
sorry about that!).


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger

Why is the relation problematic (honest question)?

I was starting to think that some sort of naming relation could be the 
answer, ie you put both peaks in a relation with for example type=name; 
natural=mountain; name=Kebnekaise.


In addition one should write clearly that peak serves dual purpose both 
as naming peaks and mountains. Today on the wiki the peak is clearly 
defined as only the summit, but it's often used as naming mountains 
where the peak is nameless.


What we also could have is fuzzy naming areas, which we would need in 
some way or another at some point anyway, so you would have an area 
covering the mountain with name=Kebnekaise. I would have no problem with 
that, but it seems to that it must be in a separate database as it just 
too controversial to be in the main database.


/Anders

On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:


Dec 13, 2020, 19:58 by and...@torger.se:

Do you have a suggestion of how to map Sweden's highest mountain, 
Kebnekaise?


The mountain is called Kebnekaise, it has two peaks, one is called 
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north 
peak").


I admit that I have no good idea, if I would run into such case and 
failed to find a better idea

(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary 
position between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.


(The mountain_range tag is a great tag, but I note that its status is 
just "in use", it's not an approved tag :-O.)


It is perfectly fine to use tags that never went through tagging 
proposal, though
I am not going to endorse this one. Tagging mountain ranges seems to 
poorly fit OSM
with multiple different opinions where mountain range starts/ends and 
inability to

verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
I'll gladly answer questions, but I think you need to rephrase. I 
suppose it is some hidden critique in there, but I honestly do not 
understand the question. It would be better for me if you put words on 
the critique instead of wrapping it in a question.


I think it's fairly obvious that if the common method to tie together 
several separate entities that has a single name is to make a single 
multipolygon-relation with several outers, there should also be a 
relation for a single named entity with multiple natural types. It can't 
be a multipolygon, so it must be something else.


Naming single entity natural features split into several sub-types is 
currently not a supported feature by OSM, although it is very hard to 
get people to actually say that (some do on this list, some don't). And 
after that it's very hard to get a statement if this missing feature is 
desirable to implement, or if OSM is not the place for this type of 
detailed geo data.


I find that you are one of those that are very mysterious about what you 
actually think ;-), but seems to strive for status quo, so I assume that 
you think that the thing I need here is already supported sufficiently 
well, but I don't know, as you haven't said.


/Anders

On 2020-12-13 20:37, Christoph Hormann wrote:

Anders Torger  hat am 13.12.2020 20:08 geschrieben:

[...] I think to actually have them all
tied together in a unit is still a good idea, [...]


That does not answer my question.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
Like every Swede I have climbed the mountain, so I do have some local 
knowledge :-). There is an arete there, that's correct, but it's not 
named. Kebnekaise is the name of the mountain. It's Sami lands, as far 
as I understand the names of the mountains came first, then the names of 
the peaks came much later when people got interested in mountaineering, 
hence often anonymous names like "the grand peak", "the south peak" etc. 
In the past noone had time to entertain themselves with climbing 
mountains for fun :-).


If we go to lower mountains in Sweden then peaks generally fit better as 
then people were closer around and hence say 90% of the time the 
mountain name is also the peak name. But sometimes there's a situation 
when the mountain has more than one peak, none of which is named, but 
the mountain is named. There's also situations where there are multiple 
nearby small peaks with separate names, and then the all have a group 
name, without really being a huge massif (the example I'm thinking about 
all small peaks are within 5 km on a single mountain).


/Anders

On 2020-12-13 21:30, Joseph Eisenberg wrote:

Currently the features with the tag "name=Kebnekaise" are 2 ways which 
extend north-south and to the west from these two peaks and are also 
tagged natural=arete (an arete is a knife-edged ridge formed between 2 
glaciers).


https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C 
https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C


Is this correct based on your local knowledge of the area?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Joseph Eisenberg
Currently the features with the tag "name=Kebnekaise" are 2 ways which
extend north-south and to the west from these two peaks and are also tagged
natural=arete (an arete is a knife-edged ridge formed between 2 glaciers).

https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C
https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C

Is this correct based on your local knowledge of the area?

If in fact Kebnekaise is the name of the ridges or aretes, then this is a
good way to represent the name of the "mountain" which in this case appears
to be a thin ridge between glaciers.

Note that Opentopomap handles this fairly well:
https://www.opentopomap.org/#map=14/67.90026/18.50553 and
https://www.opentopomap.org/#map=13/67.90113/18.46716

I believe OpenTopoMap also renders natural=mountain_range ways:
https://www.opentopomap.org/#map=12/38.4613/-4.1566

OpenTopoMap uses a special script to assign an isolation value to each
peak: that is, how far is it away from another natural=peak (or
natural=volcano) with a larger elevation value? If it is a long way, the
peak will be rendered even at low zoom levels (large scales), for example:
https://www.opentopomap.org/#map=7/67.900/18.479

This hasn't been implemented in the OpenStreetMap-Carto style because it is
somewhat complicated and might have performance problems and there are
issues with using more pre-processing of the raw data when it comes to
mapper feedback, but the code used by OpenTopoMap is here:
https://github.com/der-stefan/OpenTopoMap/pull/129 and
https://github.com/der-stefan/OpenTopoMap/pull/130  if anyone else wants to
implement this for their own maps.

-- Joseph

On Sun, Dec 13, 2020 at 12:14 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 13, 2020, 19:58 by and...@torger.se:
>
> Do you have a suggestion of how to map Sweden's highest mountain,
> Kebnekaise?
>
> The mountain is called Kebnekaise, it has two peaks, one is called
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
> I admit that I have no good idea, if I would run into such case and failed
> to find a better idea
> (hopefully one will come) I would invent a new way to tag that.
>
> natural=mountain? Main problem is where to put it - node at arbitrary
> position between peaks?
> Node at location of highest peak? Area? Relation? All of that is sadly
> problematic.
>
> (The mountain_range tag is a great tag, but I note that its status is just
> "in use", it's not an approved tag :-O.)
>
> It is perfectly fine to use tags that never went through tagging proposal,
> though
> I am not going to endorse this one. Tagging mountain ranges seems to
> poorly fit OSM
> with multiple different opinions where mountain range starts/ends and
> inability to
> verify it by survey.
>
> All tags were in some stage rarely used before becoming heavily used,
> only some cases went through a proposal process.
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Mateusz Konieczny via Tagging



Dec 13, 2020, 19:58 by and...@torger.se:

>
> Do you have a suggestion of how to map Sweden's highest mountain, Kebnekaise?
>
>
> The mountain is called Kebnekaise, it has two peaks, one is called 
> "Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north peak").
>
>
I admit that I have no good idea, if I would run into such case and failed to 
find a better idea
(hopefully one will come) I would invent a new way to tag that.

natural=mountain? Main problem is where to put it - node at arbitrary position 
between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly 
problematic.

>
> (The mountain_range tag is a great tag, but I note that its status is just 
> "in use", it's not an approved tag :-O.)
>
>
It is perfectly fine to use tags that never went through tagging proposal, 
though
I am not going to endorse this one. Tagging mountain ranges seems to poorly fit 
OSM
with multiple different opinions where mountain range starts/ends and inability 
to
verify it by survey.

All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Christoph Hormann


> Anders Torger  hat am 13.12.2020 20:08 geschrieben:
> 
> [...] I think to actually have them all 
> tied together in a unit is still a good idea, [...]

That does not answer my question.

-- 
Christoph Hormann 
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
A common established method to name natural features with separated 
parts is as a multipolygon with several outers. There is one object that 
ties them all together.


In this case a multipolygon is not possible, since the member types 
differ and "outers" share segments. I think to actually have them all 
tied together in a unit is still a good idea, it is one entity, not 
multiple entities named the same. If this ever gets supported by a 
renderer the logical way would be to have the name only on the relation 
and no name on the separate parts.


/Anders

On 2020-12-13 16:15, Christoph Hormann wrote:

Anders Torger  hat am 13.12.2020 15:28 geschrieben:

So what I've settled for (for now) is as follows:
- same name on each part (the only way to get the data useful *today*)
- a new relation with all parts as members (role unset), type=natural, 
natural=wetland, name=


I am trying to understand what the issue is with the recommendation
for mapping you have received from multiple sides here.

So what exactly is the verifiable knowledge that is supposed to be
represented by your new relation type that is not already recorded in
the mapping of physical features?


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
Do you have a suggestion of how to map Sweden's highest mountain, 
Kebnekaise?


The mountain is called Kebnekaise, it has two peaks, one is called 
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north 
peak").


Currently it's mapped with the two peaks where one is called "Kebnekaise 
Sydtoppen" and the other "Kebnekaise Nordtoppen". Not really correct, 
but perhaps the least bad way to do it? When zooming out, on a regular 
map you see the Kebnekaise name big over the mountain, but the names for 
Sydtoppen and Nordtoppen is removed. I'd love something like a 
possibility to put the peaks in a relation and put the mountain name in 
the relation in cases like this.


Kebnekaise is not the only example, it's quite common with Swedish 
mountain that the peaks themselves have quite anonymous names like those 
on Kebnekaise, "Stortoppen" (the great peak) is another common name of 
the highest peak on a Swedish mountain, where the mountain itself has a 
different (and unique) name. You don't want to see the anonymous 
"Stortoppen"-name when you zoom out the map. OSM-Carto has "solved" 
these name prominence issues by removing all names pretty much 
immediately, rendering overview maps useless.


One problem with the current peak tag is that the renderer has no 
information about the size of the mountain. A peak even if really high 
can be a small local peak on top of a large plateau.


(The mountain_range tag is a great tag, but I note that its status is 
just "in use", it's not an approved tag :-O.)


/Anders

On 2020-12-13 18:54, Joseph Eisenberg wrote:

1) To tag a named "Torp" it sounds like there are several different 
correct options, depending on what currently exists at the location.


If there is a single family home or a couple of homes used as 
residences, it would be a place=isolated_dwelling mapped as a node at 
the centre.


If it is still used as a farm, then place=farm can be used on a node 
instead. This is treated as similar to place=isolated_dwelling by many 
data users. It is also possible to map the area of the farmyard (around 
the buildings) as landuse=farmyard and add the name to this feature, if 
the name is only for the actual farm buildings and not for all the 
surrounding areas.


For a named settlement with more than 2 families (but smaller than a 
village), place=hamlet on a node would be appropriate. I'm not sure if 
a torp is every that large?


If the torp is no longer inhabited, you can use a lifecycle tag to show 
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or 
abandoned:place=hamlet show that a former farm or small settlement are 
now abandoned and no longer inhabited.


2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is 
a great way to tag these.


But it's true that some "mountain" names are not the name of a peak. In 
this case there are a couple other tags in use: natural=ridge is used 
with a linear way which is drawn along the ridgeline. This works for 
many named single ridges. 
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge - example here: 
https://www.opentopomap.org/#map=15/41.76382/-123.18038 - 
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C


Sometimes a named "mountain" is not a single ridge but a whole range of 
connected ridges. In this case we usually call it a "mountain range" in 
English, and there is a somewhat uncommon tag for this 
natural=mountain_range which I've used to map some ranges in my area. 
This tag is harder to use. In some cases the best option is to use it 
on a node at the center of the mountain range, in others it is possible 
to use it on a linear way along the highest line of ridges at the 
center of the mountain range. 
https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range - 
example: 
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C
While we can all disagree on how far down into the valley the mountain 
extends, everyone agrees that the highest peak is part of the mountain, 
so mapping peaks of a mountain as a node is 100% verifiably to be 
correct. In some cases a linear way is also verifiable for a ridge or a 
linear mountain range.


-- Joseph Eisenberg

On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging 
 wrote:


13 dec. 2020 kl. 15:21 skrev Paul Allen :

I'm probably misunderstanding this, but torp doesn't seem to be a type 
of

building.  The tag building=torp says that this building IS a torp (as
opposed to a house, or a shop, or a garage, or a shed, or a barn).
If you feel a need to indicate that a building was once part of a torp,
building=torp isn't the way to do it.
You're right; I was extremely sloppy with terminology there. A torp is 
(or rather was) a small farm, usually either part of a bigger farm and 
farmed by a tenant, paying rent to the bigger farm in the form of work, 
or farmed by a soldier (paying rent by, well, being a soldier). Today, 
most of them are 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Joseph Eisenberg
1) To tag a named "Torp" it sounds like there are several different correct
options, depending on what currently exists at the location.

If there is a single family home or a couple of homes used as residences,
it would be a place=isolated_dwelling mapped as a node at the centre.

If it is still used as a farm, then place=farm can be used on a node
instead. This is treated as similar to place=isolated_dwelling by many data
users. It is also possible to map the area of the farmyard (around the
buildings) as landuse=farmyard and add the name to this feature, if the
name is only for the actual farm buildings and not for all the surrounding
areas.

For a named settlement with more than 2 families (but smaller than a
village), place=hamlet on a node would be appropriate. I'm not sure if a
torp is every that large?

If the torp is no longer inhabited, you can use a lifecycle tag to show
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or
abandoned:place=hamlet show that a former farm or small settlement are now
abandoned and no longer inhabited.

2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is a
great way to tag these.

But it's true that some "mountain" names are not the name of a peak. In
this case there are a couple other tags in use: natural=ridge is used with
a linear way which is drawn along the ridgeline. This works for many named
single ridges. https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge -
example here: https://www.opentopomap.org/#map=15/41.76382/-123.18038 -
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C

Sometimes a named "mountain" is not a single ridge but a whole range of
connected ridges. In this case we usually call it a "mountain range" in
English, and there is a somewhat uncommon tag for this
natural=mountain_range which I've used to map some ranges in my area. This
tag is harder to use. In some cases the best option is to use it on a node
at the center of the mountain range, in others it is possible to use it on
a linear way along the highest line of ridges at the center of the mountain
range. https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range -
example:
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C

While we can all disagree on how far down into the valley the mountain
extends, everyone agrees that the highest peak is part of the mountain, so
mapping peaks of a mountain as a node is 100% verifiably to be correct. In
some cases a linear way is also verifiable for a ridge or a linear mountain
range.

-- Joseph Eisenberg


On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
>
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
>
>
> You’re right; I was extremely sloppy with terminology there. A torp is (or
> rather was) a small farm, usually either part of a bigger farm and farmed
> by a tenant, paying rent to the bigger farm in the form of work, or farmed
> by a soldier (paying rent by, well, being a soldier). Today, most of them
> are either completely gone or used as summer houses, very probably not with
> the original building.
>
> I suppose what I wanted to say was:
>
> * place=locality is used about all sorts of things, both inhabited and
> uninhabited, and is pretty much useless.
>
> * There are many places around Sweden (and probably the rest of the world
> as well!) where there is just forest (or fields) today, that have a name
> because they were, at some time, a torp (or some other kind of settlement).
> To render these in ”swedish topo-map style” (i.e, italics), some sort of
> tagging is needed to say ”this place has a name because it used to be a
> farm/torp/whatever, but today there is nothing here”. (I suppose some would
> argue that these should not be in OSM at all, because they are very hard to
> verify on the ground).
>
> * There are also isolated dwellings, hamlets, villages, suburbs and
> airport car parks (comparing old and present-day maps around
> Stockholm-Arlanda airport is quite fun) whose names refer to long-gone
> torps, but those can be tagged according to their present-day usage.
>
> And I’d like to apologize to Anders for derailing this thread by bringing
> up the subject at all! It was intended as an illustration of the
> uselessness of locality, but I got a bit carried away. Trying to render
> consistent maps from inconsistent OSM data does that to you. =)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Christoph Hormann


> Anders Torger  hat am 13.12.2020 15:28 geschrieben:
> 
> So what I've settled for (for now) is as follows:
> - same name on each part (the only way to get the data useful *today*)
> - a new relation with all parts as members (role unset), type=natural, 
> natural=wetland, name=

I am trying to understand what the issue is with the recommendation for mapping 
you have received from multiple sides here.

So what exactly is the verifiable knowledge that is supposed to be represented 
by your new relation type that is not already recorded in the mapping of 
physical features?

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Ture Pålsson via Tagging

> 13 dec. 2020 kl. 15:21 skrev Paul Allen :
> 
>  I'm probably misunderstanding this, but torp doesn't seem to be a type of
> building.  The tag building=torp says that this building IS a torp (as
> opposed to a house, or a shop, or a garage, or a shed, or a barn).
> If you feel a need to indicate that a building was once part of a torp,
> building=torp isn't the way to do it.
> 

You’re right; I was extremely sloppy with terminology there. A torp is (or 
rather was) a small farm, usually either part of a bigger farm and farmed by a 
tenant, paying rent to the bigger farm in the form of work, or farmed by a 
soldier (paying rent by, well, being a soldier). Today, most of them are either 
completely gone or used as summer houses, very probably not with the original 
building.

I suppose what I wanted to say was:

* place=locality is used about all sorts of things, both inhabited and 
uninhabited, and is pretty much useless.

* There are many places around Sweden (and probably the rest of the world as 
well!) where there is just forest (or fields) today, that have a name because 
they were, at some time, a torp (or some other kind of settlement). To render 
these in ”swedish topo-map style” (i.e, italics), some sort of tagging is 
needed to say ”this place has a name because it used to be a 
farm/torp/whatever, but today there is nothing here”. (I suppose some would 
argue that these should not be in OSM at all, because they are very hard to 
verify on the ground).

* There are also isolated dwellings, hamlets, villages, suburbs and airport car 
parks (comparing old and present-day maps around Stockholm-Arlanda airport is 
quite fun) whose names refer to long-gone torps, but those can be tagged 
according to their present-day usage.

And I’d like to apologize to Anders for derailing this thread by bringing up 
the subject at all! It was intended as an illustration of the uselessness of 
locality, but I got a bit carried away. Trying to render consistent maps from 
inconsistent OSM data does that to you. =)

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger

Thanks.

I also think that only having them tied by name is not a good concept.

So what I've settled for (for now) is as follows:

- same name on each part (the only way to get the data useful *today*)
- a new relation with all parts as members (role unset), type=natural, 
natural=wetland, name=


I don't intend this to be a final solution, but if that ever comes, 
having some sort of relation there makes it much easier to find and 
upgrade the tags.


I'm unfortunately not in capacity to work with a pilot project, so this 
have to be done by "someone else" :-/. I also think that a "pilot 
project" should not really just look at one particular problem like 
this. There's a family of problems around mapping nature with high 
detail, and providing data that can be used to generate maps at 
different zoom levels. These are not unique to Sweden, but it's just 
basic cartography. The reason I stumble into these is not because I'm 
mapping in Sweden, it's because I'm mapping with high detail and have 
good data sources with access to those names (and also personal 
experience of using them and maps with them as I engage in outdoor 
activities).


Norway has already come far with high detail land cover mapping here in 
rural north, much longer than we have in Sweden. They also have named 
nature, much of the naming is actually of the same type as this is part 
of Sami lands. How have our Norwegian friends solved the naming problem? 
Easy: by not putting any names in the map, except for lakes and stuff 
that is supported by OSM today.


And this is of course what happens, and it's so frustrating. The 
inability of the OSM community to identify, implement and document basic 
cartography features leaves the geo data of lower quality than it could 
have been if these features would have been readily available for 
mappers to use *now*.


It simply does not work that if a mapper needs a basic feature, he or 
she should then personally engage into OSM politics for many years(!) to 
*maybe* see it implemented. So instead most mappers just think "well, 
maybe I just skip that" and you don't get to hear about it and we can 
still pretend that noone actually needs the feature it's not 
realistic to think that OSM mappers in general should be persons deeply 
invested in how OSM community is organized and just jump right into the 
processes whenever needed. I think what mappers want to do is to map, 
and see their data on display *now*.


I'm not blaming anyone, it's just an observation. I'm myself part of the 
OSM community, and I just said that I don't have the capacity to pull 
any strings in this type of pilot project, so I'm just as much to blame 
as any other. But now I'm at least putting the data in, so if someone 
eventually fixes this, the tags can be upgraded accordingly if needed.


Before I did just like the typical mapper, I just skipped the names that 
couldn't be mapped properly, regardless of their importance. Now I try 
to put them in, in some way or another.


/Anders

On 2020-12-13 12:26, Peter Elderson wrote:


My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some 
kind of collective, you need a way for data users to know that all the 
parts together have a name.
Tagging the same name on all parts makes the name a free text id 
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have 
too many of those already.
Tagging all parts with a truly unique Id in a special key could do the 
trick, but who issues/manages the unique ids?


Putting the parts as members in a relation achieves the same: a unique 
Id common to all the parts; the name tag and possible other common 
attributes go on the relation.
This gives renderers the exact extent of the total area, and the 
extents of the subareas, which can have names and other attributes of 
their own.
Since an MP does not cover all possible layouts, you would need a 
different type of relation. Maybe an existing type can be used, or a 
specialised type can be defined.


I would think a pilot project could test the concept for mappers, 
renderers and other data users. If succesful, showcase. If not, 
document and delete.


Peter Elderson

Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :


Hello,

I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about getting involved in 
a
process for change, but I came to realize that it's not feasible for 
me

in my current life situation, so I've decided to continue be a normal
mapper as before, doing what I can do with features that exist today.

Anyway, if to be a mapper at all, I still like to solve some of my
naming issues in the best/least bad ways possible today. I'm currently
mapping a national park in Sweden, Muddus. It's in Laponia and 
consists

of mighty wetlands and old forest. These wetlands are named, like is
common in Sweden 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Paul Allen
On Sun, 13 Dec 2020 at 12:56, Ture Pålsson via Tagging <
tagging@openstreetmap.org> wrote:

>
> In many cases, the buildings are long gone and just the name remains. I
> *thought* that those places were still labelled in upright letters in the
> ”official” maps, but it turns out that I was wrong — in the present-day
> online-only version of those maps, those names that have lost their
> buildings have turned italic.
>

If the places have lost their buildings, that is what place=locality is
for.  As for
the label being italic or upright depending upon national sensibilities,
that is
why many countries have their own carto.  Sweden has its own carto at
http://openstreetmap.se/ although that has been down every time I've tried
it
in the past couple of weeks.  I don't know if that's recent or is a
continuation of it going down in April.  It may be worth your while
trying to find out why it's down and what it would take to fix it.


> Which is good for us, because it means we could still map building=torp
> where there actually is a building, and something else (historic=torp?
> historic=farm, farm=torp?) where there isn’t. :)
>

 I'm probably misunderstanding this, but torp doesn't seem to be a type of
building.  The tag building=torp says that this building IS a torp (as
opposed to a house, or a shop, or a garage, or a shed, or a barn).
If you feel a need to indicate that a building was once part of a torp,
building=torp isn't the way to do it.

As for historic=farm, the tag historic doesn't mean old (use start_date=*)
or disused (use disused:landuse=farm or add disused=yes).  If the
building is under the protection of a recognized heritage
organization (in Sweden it's the Riksantikvarieämbetet) then add
heritage=* and associated tagging.

Note that one person will probably chime in with a view of historic=*
that makes it applicable to anything more than 1 second old and
therefore meaningless.  I prefer the wiki definition which means it
is for things that are notable rather than just old: historic, not
historical.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
We have these in the north as well, often old soldier settlements. Many 
are are still inhabited today, but the original building most often long 
gone. We also have those that are abandoned with little sign of that 
there ever being a building there.


Strangely enough, sometimes the names for the abandoned places have more 
relevance today than those still inhabited. The inhabited places have 
modern addresses which are generally used instead, while the abandoned 
places can be used by hunters or other outdoor people for navigating in 
the landscape. But it varies place to place.


I have use place=locality for some of these as I've seen others use it, 
but I haven't had time to give it much thought. It seems like we're 
trying to move away from place=locality and try to be more specific, 
which probably is a good idea.


Currently I'm focusing mostly on nature.

/Anders

On 2020-12-13 11:10, Ture Pålsson via Tagging wrote:


12 dec. 2020 kl. 16:18 skrev Anders Torger :
Indeed, place=locality seems to be a dead end, it's been misused quite 
much and there's talks about removing it from OSM-Carto, and you can't 
render good maps from it, so it's technically a poor concept as well.


Around where I live (Stockholm), most place=locality seem to refer to 
old "torp" [1] and other (at least historically) inhabited places. At 
least the classic "Terrängkartan" (the "official" paper maps of Sweden, 
sadly no longer in production) rendered those differently from pure 
terrain names (upright vs. italic font).


Here in the lake Mälaren valley almost every square meter has been 
farmed at some point, so most names refer to settled places (or 
archaeological traces of them). Up north where I grew up, and where 
Anders seems to be mapping, you get a lot more names that refer to 
bogs, slopes, mountains and that sort of thing.


It would be nice to have that distinction in OSM, too.

[1] https://en.wikipedia.org/wiki/Torp_(architecture)

___
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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Martin Koppenhoefer


sent from a phone

> On 13. Dec 2020, at 12:30, Peter Elderson  wrote:
> 
> Tagging all parts with a truly unique Id in a special key could do the trick, 
> but who issues/manages the unique ids? 


wikidata?
wikidata:part=Q123?


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Ture Pålsson via Tagging

> 13 dec. 2020 kl. 11:40 skrev stevea :
> 
> Thank you, Ture:  an excellent example and a great brief overview.  From my 
> perspective (if I were more of an OSM beginner), I might ask about the 
> example of "torp:"  might creating a tag like building=torp seem like it's on 
> a good track?  Maybe not, as the value is a Swedish word, but there is an 
> historical cognate in British English (more OSM-like for tagging purposes) of 
> "thorpe" (maybe with an e at the end, maybe not) which came from, but doesn't 
> really mean the same thing all by itself in English, 

In many cases, the buildings are long gone and just the name remains. I 
*thought* that those places were still labelled in upright letters in the 
”official” maps, but it turns out that I was wrong — in the present-day 
online-only version of those maps, those names that have lost their buildings 
have turned italic. Which is good for us, because it means we could still map 
building=torp where there actually is a building, and something else 
(historic=torp? historic=farm, farm=torp?) where there isn’t. :)


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread stevea
Peter, I think (but am not 100% certain) that super-relations are the data 
structure you look for, the "different type of relation."  It isn't QUITE a 
"different type" but rather a method of gathering relations together that 
structures them "sensibly," so, for example, a renderer can make sense of them. 
 We do this with the distinction between "plain" multipolygon relations and 
boundary relations, for example.  (The latter have some additional members in 
the relation with distinct "roles" and that makes them act — display — with 
certain behavior in the renderer).

Pilot projects are a good idea, but they need to be exceedingly clear and 
concise in what they are testing or developing (or both, and really, both in a 
back-and-forth is what works best in the long term).  So, "it's time to be 
specific!"

If renderer authors / developers were to chime in here with their 
understandings / implementations of how "names of areas in super-relations" are 
understood and rendered, that would be helpful.  In fact, that seems like it is 
what is being "wished for," even if not explicitly:  a full explanation of how 
to best "name complex natural=* areas in multiple multipolygons."  If we don't 
get that dialog here, we can achieve the same results with experimentation and 
time.

This (the wondering how things get rendered, or thinking that developing 
something new could get rendered, and importantly HOW this happens) can be a 
difficult topic in OSM.  It often frustrates, confuses and doesn't seem (to me) 
like it is talked about frequently enough.  However, "mapping, then rendering" 
is part of the wondrous magic of OSM.  I understandable that so much "that's 
really amazing" could easily give rise to "other things should be realized as 
just as amazing, too."  However, that's not how it works:  no matter how 
wonderful technology is, we always wish it could be something better.  But it 
doesn't GET better until we develop a path to get us there.  That starts with 
clear explanations, good intentions, skilled people and time.  This project 
does amazing things as we give ourselves these simple ingredients.

SteveA

> On Dec 13, 2020, at 3:26 AM, Peter Elderson  wrote:
> 
> My answer only targets the question in the subject.
> 
> No matter whether you put the same name on all parts, or on or some kind of 
> collective, you need a way for data users to know that all the parts together 
> have a name. 
> Tagging the same name on all parts makes the name a free text id needing 
> uniqueness - for me a bad choice. 
> Yet another polygon around the area, don't like that. I think we have too 
> many of those already. 
> Tagging all parts with a truly unique Id in a special key could do the trick, 
> but who issues/manages the unique ids? 
> Putting the parts as members in a relation achieves the same: a unique Id 
> common to all the parts; the name tag and possible other common attributes go 
> on the relation. 
> This gives renderers the exact extent of the total area, and the extents of 
> the subareas, which can have names and other attributes of their own. 
> Since an MP does not cover all possible layouts, you would need a different 
> type of relation. Maybe an existing type can be used, or a specialised type 
> can be defined.
> 
> I would think a pilot project could test the concept for mappers, renderers 
> and other data users. If succesful, showcase. If not, document and delete.
> 
> Peter Elderson

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread stevea
Anders, once again, our posts crossed each other!

Thank you for the example – Nominatim helped me find their location 
immediately!  The rendering of swamp distinct from bog "happens to my eyes," 
quite nicely.  I only MIGHT see the problem with the naming being "repeated" — 
it might be correct, it might be incorrect, it might be "different from a 
preference you expect."

Using JOSM, I took a look at the underlying data.  A westerly object, 
relation/11998254 (a typical way of referring to an object in OSM in a realm 
like a mail-list) seems to make perfect sense:  a multipolygon relation tagged 
natural=wetland + wetland=bog + name=Rijmmoáhpe.  A smallish, center-oriented, 
similar relation (same tags), relation/11998257 also has apparently correct 
tagging, except that it also has name=Rijmmoáhpe.  Easterly, similar 
relation/11998253, too.

As I examine the topology (complexities of outers and inners that make the 
combination of all of these together in to one single relation difficult or 
impossible), I think I understand how this presents difficulties.

I might suggest that such topologically complex objects in OSM be handled with 
a super-relation (in this case, a relation of the three relations) where all 
three of the current relations might have their name=Rijmmoáhpe tag removed, 
but the super-relation includes the name and the natural=wetland + wetland=bog 
tags.  Other combinations (of tags on relations, relation objects, or the 
super-relation) might make more sense.  This either does or gets close to 
tagging for the renderer, and I feel I would have to experiment a bit to get 
the desired effect in Carto (I don't know exactly what you are trying to 
achieve along those lines that is different from how Carto renders now).

Regarding "hard to keep track of all parts big and small," I might recommend 
good facility with a quality editor.  When things ARE in a relation, it's hard 
to beat JOSM for keeping track of the parts, I feel its relation editor is 
excellent:  straightforward and visually understandable.  (Quietly, I will say 
I do NOT feel iD's relation editor is even close to this level of facility for 
relation editing; I seem to always be confused editing relations with iD, so I 
have stopped doing so).

You mention "naming problems for which there is no documented way to do."  I'd 
like to understand better what you mean by this, as I believe other readers on 
this list would, too.  Again, I am sorry you find this frustrating and 
apologize if you find you are repeating yourself.  It may be that "drawing out" 
(extracting) what you mean and mean to do (have OSM render) are still underway 
and we will eventually better understand what you believe is "wrong."

"Least bad" is appreciated.  However, I think you may be using "how this 
renders in Carto" for at least a PART of why you say that.  I think it is 
better to understand that the tagging that it takes for that to happen might 
not be the best for OSM, the best for Carto, or both.  This is why we say 
"don't tag for the renderer," because (largely speaking) OSM is a data project. 
 The renderers do their best, but the "feedback loop" that it takes for data 
and renderings to harmonize is a long-term, ongoing process.  It has its 
complexities, it has simultaneous new proposals and tagging happening.  It has 
good mappers trying to pay attention and learn new things and stop doing things 
old ways (which used to work, but are either being phased out or no longer 
work).

When you say "stumble into the same issues," again, I'm sorry if you feel you 
are repeating yourself, I don't know exactly what the issues are.  Or, rather, 
we (on this mail-list) are learning them (well) only now, in that "drawing out" 
process.  When you say "looks horrible," I honestly don't know what you mean.  
"Naming nature" in OSM seems possible to me. It could be that we have to be 
specific with complex topologies.  It could be that we need to fix something, 
but I'm not sure yet.  If you see how our relation:multipolygon wiki takes 
great pains to describe these mathematically complex topics in detail, I think 
you'll agree that this is fairly "tightly" defined:  for example, "valid 
multipolygon conditions" are strict.  When you strictly follow these 
definitions (including name=* tags), does Carto have "issues"?  If so, we want 
to know!

In the meantime, let us know what is "horrible" about these renderings, given 
the tagging.  I disagree with you that "mappers won't map things that don't 
show up on any renderer" because I do that all the time, knowing that OSM is a 
DATA project, not about a particular renderer looking a certain way.  Sure, it 
would be helpful if renderers "read your mind" and "didn't look horrible," but 
they don't, so they can't.  Instead, I'm asking you to be more descriptive, so 
we can both understand what might be done to assuage your sense that OSM is 
"broken."  In a broad sense, it isn't.  (It is broken in minor 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Peter Elderson
My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some kind of
collective, you need a way for data users to know that all the parts
together have a name.
Tagging the same name on all parts makes the name a free text id
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have too
many of those already.
Tagging all parts with a truly unique Id in a special key could do the
trick, but who issues/manages the unique ids?
Putting the parts as members in a relation achieves the same: a unique Id
common to all the parts; the name tag and possible other common attributes
go on the relation.
This gives renderers the exact extent of the total area, and the extents of
the subareas, which can have names and other attributes of their own.
Since an MP does not cover all possible layouts, you would need a different
type of relation. Maybe an existing type can be used, or a specialised type
can be defined.

I would think a pilot project could test the concept for mappers, renderers
and other data users. If succesful, showcase. If not, document and delete.

Peter Elderson


Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger

Thanks.

There are quite many abandoned tags for grouping things together, so 
site is in good company. It seems like site is mostly used for 
human-made features though, so I'm not sure it's suitable for natural 
features. For now I don't have the intention that the "natural" relation 
is going to be used by any renderer though, it's just to make it easy in 
JOSM to find all parts belonging to it. If some official method appears 
in the future it will be easy to do search and replace.


/Anders

On 2020-12-13 11:58, Hidde Wieringa wrote:

I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many 
renderers, but the information will exist in OSM in a structured way 
for future renderers.


Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
_Hidde Wieringa_

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

On 13-12-2020 11:28, Anders Torger wrote: Here's a real example of how 
this naming scheme ends up looking:


https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to 
keep track of all parts big and small if there is no relation, so I 
added it as a help for the mapper. I set type=natural (to indicate that 
it's a natural object) and natural=wetland (to indicate what type of 
natural it is, without having to deduce from its members) and name on 
that relation. Nothing official, but at least easy to filter out and 
find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble 
into the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just don't 
exist. It's the usual problem: mappers won't map things that don't show 
up on any renderer (or displays horribly like this), and renderers 
won't implement functions for things that aren't mapped. The OSM way is 
that mappers should take the lead and renderers will eventually follow 
(maybe). I think that process works really poorly today (the main 
reason being that OSM is just too large and diverse now for the 
original processes to work, in global scope every feature becomes just 
a tiny special interest not worth considering). That we still lack 
these cartography features 14 years into the project is witness to 
that. We need a render engine to take the lead, and more well-defined 
standard of how to arrange the data. I've got 4 - 5 different 
suggestions of how to put a name on this wetland. Imagine if all those 
naming schemes gets used, what a mess to implement a renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:
I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger
It was just an example. Peak is "close enough" for now, and you can 
argue that it works for both mountain and individual peaks. That would 
be okay, but the problem with that is that there is no information for 
the renderer which peaks that should be shown when zoomed out. Some 
renderers just filter out the highest peak (I think opentopomap does 
that), which does work in say 80% of the cases, but sometimes the 
highest peak has a specific name, and the whole mountain is named 
something else.


It's frustrating to see that many OSM folks seems to be "surprised" 
about these things, like it would be something super unique maybe only 
existing in Sweden. It's not. It's just basic cartography of natural 
features all over the world. I was for a while surprised that there's 
not more urgency to fix these type of issues, but once I've learnt about 
how the community works, I'm no longer as surprised, but it's still 
frustrating.


I'm not going to make a wiki entry. I'm just a mapping contributor 
within the current framework, not an OSM developer, and I don't intend 
to become one. I've done my due diligence of OSM and concluded that its 
more about politics than about solving technical problems, and those 
things leads to me burning out.


What I can do is contribute to the map. And I do. I'm a quite advanced 
mapper, including writing my own custom software tools to be able to map 
faster (not automated mapping, but aided manual mapping). When I stumble 
across things that I don't know how to map, I ask questions at OSM Help, 
and if the answer is not satisfactory there, I turn to here. I'm now 
actively involved in the small Swedish OSM community and we discuss how 
to best map things within the existing OSM feature set, and I try to 
come up with reference methods. I've lately been involved in following 
up vandalism. But my engagement ends there, I don't have the capacity to 
do more.


If the only way to cater mapper's needs is for those individual mappers 
to navigate and penetrate OSM politics to what it has grown to today, I 
think we're stuck. I takes a special type of effort and dedication which 
few people posses, and unfortunately I'm not one of them. You will 
probably hear some rumbling frustration from my mapping efforts from 
time to time, but that's it.


/Anders

On 2020-12-13 01:14, stevea wrote:

Anders, I didn't see this until after I sent my reply.

I believe this list here is interested in what you call "missing
features," as a list.  I look at them as challenges of ours or
frustrations of yours which can either be explained or solved.  You
might not like the explanations.

For example, if you were to expound upon differences between
"mountain" (as Anders, or Sweden understands it) and natural=peak (as
OSM understands it), we're listening.  You might be prompted to "make
a proposal for mountain" or "write a wiki for how your first
mountain=whatever or whatever=mountain tag you recently started to
enter (because it is well thought-out, defined, follows sensible rules
about 'what it is' and 'how it is tagged'...)" is now extant, and so
on.

To solve such frustrations doesn't necessarily include this or that
about mountaineering.  This is called reducing the map consumer's
perspective, as you simply "tag well and accurately using a syntax
expressing what you mean."  If there is no such tagging, we might
support it (as new tagging and/or a new proposal) and maybe someday it
will be rendered.  This is (partly) how our map data have grown, it is
how our map data continue to grow.

SteveA

___
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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Hidde Wieringa
I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many renderers, 
but the information will exist in OSM in a structured way for future 
renderers.


Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site


On 13-12-2020 11:28, Anders Torger wrote:

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png 



I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to 
keep track of all parts big and small if there is no relation, so I 
added it as a help for the mapper. I set type=natural (to indicate 
that it's a natural object) and natural=wetland (to indicate what type 
of natural it is, without having to deduce from its members) and name 
on that relation. Nothing official, but at least easy to filter out 
and find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble 
into the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just 
don't exist. It's the usual problem: mappers won't map things that 
don't show up on any renderer (or displays horribly like this), and 
renderers won't implement functions for things that aren't mapped. The 
OSM way is that mappers should take the lead and renderers will 
eventually follow (maybe). I think that process works really poorly 
today (the main reason being that OSM is just too large and diverse 
now for the original processes to work, in global scope every feature 
becomes just a tiny special interest not worth considering). That we 
still lack these cartography features 14 years into the project is 
witness to that. We need a render engine to take the lead, and more 
well-defined standard of how to arrange the data. I've got 4 - 5 
different suggestions of how to put a name on this wetland. Imagine if 
all those naming schemes gets used, what a mess to implement a 
renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:

I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
 See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is a topic of some confusion among mappers.
For example, I don't believe Carto rendering is perfectly predictable
without first knowing "size of all overlapping polygons."  This can
make "accurate" (or pleasing) natural tagging challenging or
unpredictable in some circumstances.  I believe at least some of what
is rendered has to do with the size (and order entered?) of
overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable
tagging them, as accurately as I know how, using OSM's wiki to
describe tagging. 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread stevea
Thank you, Ture:  an excellent example and a great brief overview.  From my 
perspective (if I were more of an OSM beginner), I might ask about the example 
of "torp:"  might creating a tag like building=torp seem like it's on a good 
track?  Maybe not, as the value is a Swedish word, but there is an historical 
cognate in British English (more OSM-like for tagging purposes) of "thorpe" 
(maybe with an e at the end, maybe not) which came from, but doesn't really 
mean the same thing all by itself in English, more of a suffix in a 
village-name (like Scunthorpe or Maplethorp).  Looking at a picture of a "torp" 
in Sweden, and as a native (US) English speaker, I imagine a new tag for this 
might look something like building=summer_house or building=swedish_cottage or 
something along those lines that identify it as a quite-specific thing (as a 
distinct value of the building key).  So, this can be done in OSM:  such things 
do happen.

Regarding "bogs, slopes, mountains..." I hear loud and clear that there are 
challenges with the latter two.  The first, "bog" seems straightforward:  
natural=wetland + wetland=bog (and this combination does seem to be rendered in 
Carto in a specific way, distinct from wetland=marsh; the wikis display these 
differences, even at different zoom levels).

For slopes, I have noticed that "natural=ridge" has begun to render in Carto 
recently, but that's not quite the same as slope, but might begin to help if 
you must use a tag that renders today.  For mountains, I understand that this 
is NOT the same as natural=peak, so I think this mail-list would be interested 
to hear how a natural=peak and a mountain (as understood in Sweden, or perhaps 
"meant" on a map that calls such a thing what it calls it in Swedish on a map 
like Terrängkartan).  It seems those distinctions could be made in the form of 
an (early) wiki (if such tagging began, because it was well-formed enough to 
quickly draw up a wiki for it) or a proposal, which also seems it could be 
straightforward to write and gain approval.  There was a tag for natural=arete 
("a thin, almost knife-like, ridge of rock which is typically formed when two 
glaciers erode parallel U-shaped valleys") which became approved and then began 
to render.  (I had never heard of this, but when I read the wiki, I thought 
"OK, that simply means I've never heard of this, but it's real, so let's define 
it, document it and tag it).  So, this process is established and can happen 
for "swedish_mountain" (I'm making up an obviously unreal tag, but calling it 
in Swedish or maybe an equivalent-to-British-English word if that's possible) 
can open up possibilities for OSM can be the map Anders dreams of.  I think it 
can.  With explanation, some process being followed and some time, it can.

Yes, it IS nice when OSM has distinctions where distinctions are actually 
distinctions in the real world.  Let's make them together as a community so we 
can all share them!

SteveA

> On Dec 13, 2020, at 2:10 AM, Ture Pålsson via Tagging 
>  wrote:
> 
> 
>> 12 dec. 2020 kl. 16:18 skrev Anders Torger :
>> 
>> Indeed, place=locality seems to be a dead end, it's been misused quite much 
>> and there's talks about removing it from OSM-Carto, and you can't render 
>> good maps from it, so it's technically a poor concept as well. 
> 
> Around where I live (Stockholm), most place=locality seem to refer to old 
> ”torp” [1] and other (at least historically) inhabited places. At least the 
> classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
> in production) rendered those differently from pure terrain names (upright 
> vs. italic font).
> 
> Here in the lake Mälaren valley almost every square meter has been farmed at 
> some point, so most names refer to settled places (or archaeological traces 
> of them). Up north where I grew up, and where Anders seems to be mapping, you 
> get a lot more names that refer to bogs, slopes, mountains and that sort of 
> thing.
> 
> It would be nice to have that distinction in OSM, too.
> 
> [1] https://en.wikipedia.org/wiki/Torp_(architecture)
> 
> 
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-13 Thread Anders Torger

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.


I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to keep 
track of all parts big and small if there is no relation, so I added it 
as a help for the mapper. I set type=natural (to indicate that it's a 
natural object) and natural=wetland (to indicate what type of natural it 
is, without having to deduce from its members) and name on that 
relation. Nothing official, but at least easy to filter out and find.


In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble into 
the same issues.


As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just don't 
exist. It's the usual problem: mappers won't map things that don't show 
up on any renderer (or displays horribly like this), and renderers won't 
implement functions for things that aren't mapped. The OSM way is that 
mappers should take the lead and renderers will eventually follow 
(maybe). I think that process works really poorly today (the main reason 
being that OSM is just too large and diverse now for the original 
processes to work, in global scope every feature becomes just a tiny 
special interest not worth considering). That we still lack these 
cartography features 14 years into the project is witness to that. We 
need a render engine to take the lead, and more well-defined standard of 
how to arrange the data. I've got 4 - 5 different suggestions of how to 
put a name on this wetland. Imagine if all those naming schemes gets 
used, what a mess to implement a renderer...


/Anders

On 2020-12-13 00:55, stevea wrote:

I don't approach this as getting solved in one multipolygon.  I might
use two multipolygons, one tagged wetland=bog, another tagged
wetland=marsh, both tagged natural=wetland.  Add name=* as
appropriate.  Closed ways (plus other things, with other tags) do
overlap (these two seem they should not).  Let renderers deal with
such issues.

Different than natural=* tagging, there is also a proposal that
includes an "unadorned" boundary=protected_area tag (on a closed way
or a relation), without a protect_class tag (one is not known or is
"less known").  This might, someday, render as a simple green line.
This conveys what is (an often legal) boundary, so it isn't natural=*.
 See if this proposal
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
your logic (and OSM's syntax, a boundary=protected_area tag, or its
semantics, a perhaps-someday-drawn rendered green line) around this.
Untangling natural, leisure and boundary tagging is ahead in OSM,
things do get better.

How (the Carto, for example) renderers draw natural=* on top of one
another is actually a rich topic:  it can be said these behaviors are
renderer specific.  (Yes, Carto "drawing order" is not necessarily
perfectly defined).  These are complex topics, getting better as
proposals gain approval (a working strategy so far).  The example of
natural=* tagging below is a topic of some confusion among mappers.
For example, I don't believe Carto rendering is perfectly predictable
without first knowing "size of all overlapping polygons."  This can
make "accurate" (or pleasing) natural tagging challenging or
unpredictable in some circumstances.  I believe at least some of what
is rendered has to do with the size (and order entered?) of
overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable
tagging them, as accurately as I know how, using OSM's wiki to
describe tagging.  Multipolygons differ from relations like them which
aren't (like those tagged boundary=*), independently as far as
renderers are concerned.  It is easy to get confused, confusion exists
in the map:  semantics are blurry in some cases.  This gets better
with worldwide consensus, over years.  This (how we learn to best tag
and render) is an ongoing long-term OSM process.  As a mapper, "tag
accurately first," then let renderers interpret.

SteveA


On Dec 11, 2020, at 11:53 AM, Anders Torger  wrote:

Unfortunately I don't think that is possible.

Multipolygons may only contain ways that have either role as inner or 
as outer. It may not contain other relations (still possible to 
upload, but not 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Ture Pålsson via Tagging

> 12 dec. 2020 kl. 16:18 skrev Anders Torger :
> 
> Indeed, place=locality seems to be a dead end, it's been misused quite much 
> and there's talks about removing it from OSM-Carto, and you can't render good 
> maps from it, so it's technically a poor concept as well. 


Around where I live (Stockholm), most place=locality seem to refer to old 
”torp” [1] and other (at least historically) inhabited places. At least the 
classic ”Terrängkartan” (the ”official” paper maps of Sweden, sadly no longer 
in production) rendered those differently from pure terrain names (upright vs. 
italic font).

Here in the lake Mälaren valley almost every square meter has been farmed at 
some point, so most names refer to settled places (or archaeological traces of 
them). Up north where I grew up, and where Anders seems to be mapping, you get 
a lot more names that refer to bogs, slopes, mountains and that sort of thing.

It would be nice to have that distinction in OSM, too.

[1] https://en.wikipedia.org/wiki/Torp_(architecture)


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread stevea
Anders, I didn't see this until after I sent my reply.

I believe this list here is interested in what you call "missing features," as 
a list.  I look at them as challenges of ours or frustrations of yours which 
can either be explained or solved.  You might not like the explanations.

For example, if you were to expound upon differences between "mountain" (as 
Anders, or Sweden understands it) and natural=peak (as OSM understands it), 
we're listening.  You might be prompted to "make a proposal for mountain" or 
"write a wiki for how your first mountain=whatever or whatever=mountain tag you 
recently started to enter (because it is well thought-out, defined, follows 
sensible rules about 'what it is' and 'how it is tagged'...)" is now extant, 
and so on.

To solve such frustrations doesn't necessarily include this or that about 
mountaineering.  This is called reducing the map consumer's perspective, as you 
simply "tag well and accurately using a syntax expressing what you mean."  If 
there is no such tagging, we might support it (as new tagging and/or a new 
proposal) and maybe someday it will be rendered.  This is (partly) how our map 
data have grown, it is how our map data continue to grow.

SteveA

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread stevea
I don't approach this as getting solved in one multipolygon.  I might use two 
multipolygons, one tagged wetland=bog, another tagged wetland=marsh, both 
tagged natural=wetland.  Add name=* as appropriate.  Closed ways (plus other 
things, with other tags) do overlap (these two seem they should not).  Let 
renderers deal with such issues.

Different than natural=* tagging, there is also a proposal that includes an 
"unadorned" boundary=protected_area tag (on a closed way or a relation), 
without a protect_class tag (one is not known or is "less known").  This might, 
someday, render as a simple green line.  This conveys what is (an often legal) 
boundary, so it isn't natural=*.  See if this proposal 
(https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap your 
logic (and OSM's syntax, a boundary=protected_area tag, or its semantics, a 
perhaps-someday-drawn rendered green line) around this.  Untangling natural, 
leisure and boundary tagging is ahead in OSM, things do get better.

How (the Carto, for example) renderers draw natural=* on top of one another is 
actually a rich topic:  it can be said these behaviors are renderer specific.  
(Yes, Carto "drawing order" is not necessarily perfectly defined).  These are 
complex topics, getting better as proposals gain approval (a working strategy 
so far).  The example of natural=* tagging below is a topic of some confusion 
among mappers.  For example, I don't believe Carto rendering is perfectly 
predictable without first knowing "size of all overlapping polygons."  This can 
make "accurate" (or pleasing) natural tagging challenging or unpredictable in 
some circumstances.  I believe at least some of what is rendered has to do with 
the size (and order entered?) of overlapping polygons.

In short, I "tag the data I know" at the complexity I'm comfortable tagging 
them, as accurately as I know how, using OSM's wiki to describe tagging.  
Multipolygons differ from relations like them which aren't (like those tagged 
boundary=*), independently as far as renderers are concerned.  It is easy to 
get confused, confusion exists in the map:  semantics are blurry in some cases. 
 This gets better with worldwide consensus, over years.  This (how we learn to 
best tag and render) is an ongoing long-term OSM process.  As a mapper, "tag 
accurately first," then let renderers interpret.

SteveA

> On Dec 11, 2020, at 11:53 AM, Anders Torger  wrote:
> 
> Unfortunately I don't think that is possible.
> 
> Multipolygons may only contain ways that have either role as inner or as 
> outer. It may not contain other relations (still possible to upload, but not 
> considered right according to the wiki). What should the ways be?
> 
> We can't make the separate wetland parts as inner ways, (as areas formed by 
> the inner ways are subtracted from the multipolygon), and even if we try it 
> becomes illegal as inner ways cannot share segments with the outer way. We 
> can't make the parts as outers either as they share segments. The outer must 
> be the surrounding outline without the shared segments splitting the wetland 
> in parts, and there are no inners (unless the parts themselves has inners).
> 
> So then we have a multipolygon with just an outer. I could just as well be a 
> plain polygon made from a single closed way. This would work if drawing order 
> was defined, and that was the method I tried first. The container polygon 
> must have a natural tag as well (the logical would be wetland here without 
> further sub-classification). 
> 
> However the drawing order is not defined (I think, not 100% sure), so this is 
> by the renderer interpreted as a wetland lying on top of the other wetlands. 
> OSM-Carto will still render the insides, but the fill pattern of the outer 
> polygon is drawn on top.
> 
> On 2020-12-11 18:09, Brian M. Sperlongano wrote:
> 
>> Hello Anders,
>>  
>> I would recommend creating a multipolygon relation (type=multipolygon) with 
>> each of the wetland pieces, and set the name= and appropriate natural= and 
>> wetland= tags on the relation.
>> 
>> On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:
>> Hello,
>> 
>> I was on this list a while back expressing some frustration over 
>> limitations when tagging nature and thought about getting involved in a 
>> process for change, but I came to realize that it's not feasible for me 
>> in my current life situation, so I've decided to continue be a normal 
>> mapper as before, doing what I can do with features that exist today.
>> 
>> Anyway, if to be a mapper at all, I still like to solve some of my 
>> naming issues in the best/least bad ways possible today. I'm currently 
>> mapping a national park in Sweden, Muddus. It's in Laponia and consists 
>> of mighty wetlands and old forest. These wetlands are named, like is 
>> common in Sweden and Sami lands. For us navigating in wildlife, names in 
>> nature are important.
>> 
>> A wetland polygon can be named in OSM, so the situation is 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger

Thanks.

I appriciate that you say that features are actually missing in this 
context. The usual way things go when I've tried to discuss these issues 
in various OSM forums is that it's incredibly hard to get to a consensus 
that there actually even is a problem at all. I get suggestions to map 
it in some way that either not work at all or has no renderer support by 
any data user out there, and when I point out that the discussion just 
goes silent, and I'm probably just considered annoying.


If one gets past the first hurdle and actually gets to a consensus that 
these things cannot be done today, the next hurdle is "do we want to 
support this?". Also here I tend to get stuck in meta-discussions about 
how hard these features are to render quickly on a map or difficult it 
is to store in the database or show it in the tools, without anyone 
voicing any opinion for or against the desire to actually have this 
feature, just seemingly trying to kill it with arguments that it's just 
too hard to implement. OSM-folks often say that OSM should support not 
only mapping of streets as the name implies, but also nature. But when I 
point at specifics required to actually do this in a good way, I find 
myself stuck.


This wetland question was sort of put to an end with a reply "just name 
all parts the same". It does work for my particular use case, but as you 
point out it's far from a generic concept, and unlikely that it will be 
taken up by renderers as relation is missing. Wetlands do generally have 
sharp borders (although in the national park I'm mapping some of the 
wetlands are so large that they have different names in different 
places). When it comes to peninsulas, valleys, mountains, broad ridges, 
hills, slopes and more natural features we have names for, not so much. 
Personally I'm okay with just drawing an area on top, everyone 
understands that it's fuzzy. Just like we can do today with bays and 
straits. But as discussed in another post, there's overwhelming 
criticism from leading OSM profiles against having fuzzy areas in the 
main database so it's unlikely to happen. And as long as no widespread 
renderer actually uses the data and there's no wiki info on how to name 
these things there's no chance for this to catch on by regular mappers 
actually taking their time to put in the names.


Mountains are in OSM usually mapped as a point, a peak. However, 
mountaineering was not an interest among those that actually named the 
mouintains, so often what has a name is the mountain, not the peak 
itself. But as OSM doesn't support naming mountains, there's lot of 
misleading naming out there. Today I had a mountain to name, it has 
three peaks, but only one name, and the name is on the mountain not the 
peak. The list goes on. For anyone knowledgeable in cartography missing 
features like this are easily identified.


Sure we can choose to have a map that doesn't support them (and say that 
we only intend to support zoomed in urban contexts, I guess that's where 
the money is anyway), but it's not odd features in any way, any 
institutionally made map have them.


/Anders

On 2020-12-12 13:55, Martin Koppenhoefer wrote:

sent from a phone


On 12. Dec 2020, at 12:26, Anders Torger  wrote:

In the wetland case as described, there is no parent relation at all. 
The only thing that ties them together is implicitly by sharing 
borders and having the same name tag. It seems to me that an 
"official" way to edit should tie them together with a parent 
relation.



Yes, we do not have a way to map toponyms for larger areas when we
also want to map detailed landcover within. Christoph’s idea of using
the same names on the parts fails when the individual parts have
different names. We can’t map bigger geographic entities like deserts,
swamplands, forests, highlands (besides the names for the smallest
parts, or if they correspond to other entities with clear boundaries
like nature reserves, or maybe by overlapping the same kind of
objects, what is generally frowned upon)




The logical way would be a parent relation with type=wetland (and 
actually have the name only there, but no renderer today understands 
that, it needs to be on the separate parts as well). What should the 
roles be? The most logical way would be to leave role field empty.




Maybe a similar approach as the one for relations of type=group (i.e.
a relation type which explicitly “inherits” its meaning from the
members without the requirement but with the possibility for
additional tags, a place to put a name for the ensemble) could be
taken for area relations as well, e.g. the site relation could include
the different wetlands, and a name (and e.g. wikipedia/wikidata
reference, etc.) might be sufficient to map the “collective” of
things? The nature would be implied by its members.

The bigger such geographic entities become, the less you will
typically be able to draw a hard line (fuzzyness of many natural
borders, rather smooth 

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
Indeed, place=locality seems to be a dead end, it's been misused quite 
much and there's talks about removing it from OSM-Carto, and you can't 
render good maps from it, so it's technically a poor concept as well. To 
render names properly for natural features the renderer needs to know 
the extent of the area, so when you zoom out it can sort and show labels 
at appropriate size (and advanced renderers can even bend and shape the 
names according to the containing area), just like it has always worked 
with lakes.


Another way would be to make tags like we have for populated places, 
hamlet, villages, etc where the name tag type decides its prominence. 
This makes sense for populated areas as the area size is not what 
decides its prominence but rather the population size. However for 
natural features I think the area concept is elegant, and also gives 
much more information than just having a tag, as for natural features 
it's not always obvious (like a city) where the feature roughly starts 
and ends, or even what it is. For natural features it's also common in 
cartography to shape the text according to the shape of the feature 
(there are a few examples of renderers doing this already with OSM 
lakes, like opentopomap.org), and having an area gives the renderer 
great information to work with. So I think named areas is the way to go 
for natural features.


Named areas on land, like the peninsula tag that exists today, makes the 
map data a bit crowded in the editor when you show all elements at once. 
I think it would work well enough as you just can filter them out in 
JOSM when editing other stuff, but the concept of named areas has got 
heavy criticism from leading OSM people so it seems to be impossible to 
get consensus for this in the main database. Peninsula and also the 
valley tags are ineffective due to this. Refusal to support/promote the 
feature in OSM hasn't meant that the names have disappeared from the 
real world though, so the need is still very much there. There just 
seems to be no way forward with the main database.


So the only viable option indeed seems to put these things in a separate 
database. Although I think it would be preferable to have this type of 
basic feature represented in the main database, I'm for anything that 
works.


However, how many mappers is willing to contribute to an extra database 
if there's no showcase of it actually being used in a map as accessible 
as osm.org? Wouldn't this database just fade away, just like so many 
OSM-related projects before it? I think that today map renderers has to 
lead the way showcasing great cartography, then mappers will follow. The 
other way around no longer works, the scope is just too big. As a 
mapper, I don't want to invent methods for basic mapping, I just want to 
go to a website and read how it should be done, do my mapping, and then 
see the result on a map freely accessible to anyone all over the world. 
To me that's the attraction of OSM and being a contributor. With a 
global scope of the map it's incredibly hard as in an individual mapper 
to start a geodata trend that grows and gets so big that some relevant 
render implementor actually starts using the data and show it on their 
maps.


Would it be possible to get a global map renderer tied to the project so 
the database is actually used? I think it will be next to impossible to 
grow the database with voluntary contributions if there is no map 
showing it in active use.


/Anders

On 2020-12-12 14:03, Martin Koppenhoefer wrote:

of course all of these could be tagged as place=locality nodes, but 
this is a compromise to drop a name, which does not allow to even guess 
about the extent,  shape or orientation.


My idea is to collectively curate a parallel dataset which can be used 
in addition. Just draw the thing roughly (thinking mainly about 
regional size features, not the very detailed OpenStreetMap editing map 
scale), e.g. here

geojson.io
and send it to me for inclusion ;-)

https://github.com/dieterdreist/OpenGeographyRegions

ideally you would also search the fitting wikidata object (the hope is 
to internationalize names through wikidata items).


Cheers Martin

___
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] How to put a name tag on an area with more than one type?

2020-12-12 Thread Casper van Battum
Does the actual wetland have a name, or does the area which the wetland 
is part of have a name? If the latter is the case, I might just consider 
using a node with place=locality+name=(name) to tag it. It's typically 
used to tag "an unpopulated location for which there is no extant 
feature to which the tag could be associated" (source: wiki) but the 
danger is that you might start tagging for the renderer. I wouldn't use 
it if the /actual/ wetland is named, so if that's the case just ignore this.


Best, Casper

https://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality 



On 2020-12-11 17:07, Anders Torger wrote:

Hello,

I was on this list a while back expressing some frustration over 
limitations when tagging nature and thought about getting involved in 
a process for change, but I came to realize that it's not feasible for 
me in my current life situation, so I've decided to continue be a 
normal mapper as before, doing what I can do with features that exist 
today.


Anyway, if to be a mapper at all, I still like to solve some of my 
naming issues in the best/least bad ways possible today. I'm currently 
mapping a national park in Sweden, Muddus. It's in Laponia and 
consists of mighty wetlands and old forest. These wetlands are named, 
like is common in Sweden and Sami lands. For us navigating in 
wildlife, names in nature are important.


A wetland polygon can be named in OSM, so the situation is better than 
for example for named slopes (also common). However, a wetland here 
can consist of both bog and marsh (and it's important to make the 
difference, since one is easy to walk on, the other not so much). 
That's two different natural types and thus can't be in the same 
multipolygon (as outers).


Asking on OSM Help website for a solution I got the answer to make a 
new containing multipolygon and set the name on that. That would be 
quite elegant for sure, but JOSM warns about that, can't have a name 
without a type, and if I set the type, say natural=wetland without any 
subtype, I get a JOSM warning that I have natural features on top of 
eachother. If I still upload it OSM-Carto does render out the name but 
you can see that the wetland pattern of the outer polygon is drawn on 
top of the contained polygons, so it does not seem to be the way to do 
it.


The least bad way I've come up with is to just name all polygons 
belonging to the same wetlands the same, and hope for that in the 
future smart renderers will understand that polygons with shared 
borders and shared name is the same named entity.


Any ideas or suggestions?

/Anders

___
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] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
To make it clearer, here's a screenshot of the result of a test using 
this method:


https://www.torger.se/anders/downloads/Screenshot_2020-12-12.png

OSM-Carto makes one name tag per sub-part instead of just one for the 
whole which is both undesired and ugly, but I've come to understand that 
OSM-Carto is not really for making good cartography but for a debugging 
view where low computational overhead is prioritized over good 
cartography. I think that design choice is unfortunate, but not 
something I can do anything about, it is what it is. We hope that 
"someone else" does the cartography bit. It does become a bit confusing 
though when the naming method looks incorrect on the de-facto reference 
map that OSM-Carto has become, especially when this naming method is not 
documented anywhere. So it seems unlikely that "someone else" will 
actually make the rendering correct if there is no documented way of how 
the data is organized in these naming situations.


The OSM way seems to be to let individual mappers make their own tagging 
to solve the problems they have. This ends up with a fragmented 
situation of diverse methods where none is big enough to catch on, and 
most mappers just choose the easy way out and just simplify the map so 
the simplest already established methods can be used. The easy way out 
for me here would be just to ignore that the wetlands are both bog and 
marsh and just make everything bog: problem solved by lowering geodata 
quality. And I think this is what many mappers do, it's very 
unsatisfying to map things that doesn't show up properly on any renderer 
one can find in use.


But this time I'll try to be a good OSM citizen and take the lead in 
tagging if necessary. I just need to know that the method I choose is 
the best so it at least have some chance of survival so that my work 
doesn't go to waste. There are more challenges coming up so more 
questions will probably land on this list.


/Anders

On 2020-12-12 12:23, Anders Torger wrote:
Sorry, I realize I have a followup question. Is this really the right 
way?


There's a difference from the Rhine example. With rivers all the
separate parts are tied together with a parent relation of the type
waterway, and the parts have roles like "main_stream".

In the wetland case as described, there is no parent relation at all.
The only thing that ties them together is implicitly by sharing
borders and having the same name tag. It seems to me that an
"official" way to edit should tie them together with a parent
relation.

The logical way would be a parent relation with type=wetland (and
actually have the name only there, but no renderer today understands
that, it needs to be on the separate parts as well). What should the
roles be? The most logical way would be to leave role field empty. To
summarize:

Suggested method of how to name a wetland that has more than one 
sub-type:


* Prerequisite: each sub-type (marsh, bog etc) is a polygon (or
multipolygon if required,
  for example if there's an inner water or forest) which shares
segments with the
  neighboring sub-type, ie the wetland is a single entity.
* Put the name on each part, same for all
* Create a relation with type=wetland (no sub-type) and include all
parts with role
  field empty, also name this relation with the same name (although no 
current

  renderer will care)

What do you think about this way? JOSM thinks it's fine at least, I
get no warnings :-).

(Note that there's another case that can be solved with just a single
multipolygon, when there's a single sub-type but the parts are
separated, so each part can be an outer, this is also (quite) common,
although more common for waters and islands than wetlands. The special
thing with the discussed case is that it's a single entity all parts
bordering to the next)

On 2020-12-11 20:55, Anders Torger wrote:

Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each
separate part so not exactly beautiful, but the data is there.

/Anders

On 2020-12-11 18:07, Christoph Hormann wrote:
Anders Torger  hat am 11.12.2020 17:07 
geschrieben:


The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same,


That is widely considered to be the correct way.  It is established
practice that mapping things like forest, wetland, farmland etc. can
be split to differentiate tagging (like leaf_type, wetland type, crop
etc.).  The name tag is then applied to all components.  Same as for
waterways or roads where you can also split and apply the name to the
components.

This also matches the general concept in OSM that names are typically
local properties and only locally verifiable.  The Rhine river is
called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.


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



Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Martin Koppenhoefer
of course all of these could be tagged as place=locality nodes, but this is a 
compromise to drop a name, which does not allow to even guess about the extent, 
 shape or orientation.

My idea is to collectively curate a parallel dataset which can be used in 
addition. Just draw the thing roughly (thinking mainly about regional size 
features, not the very detailed OpenStreetMap editing map scale), e.g. here 
geojson.io
and send it to me for inclusion ;-)

https://github.com/dieterdreist/OpenGeographyRegions

ideally you would also search the fitting wikidata object (the hope is to 
internationalize names through wikidata items).

Cheers Martin 


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Martin Koppenhoefer


sent from a phone

> On 12. Dec 2020, at 12:26, Anders Torger  wrote:
> 
> In the wetland case as described, there is no parent relation at all. The 
> only thing that ties them together is implicitly by sharing borders and 
> having the same name tag. It seems to me that an "official" way to edit 
> should tie them together with a parent relation.


Yes, we do not have a way to map toponyms for larger areas when we also want to 
map detailed landcover within. Christoph’s idea of using the same names on the 
parts fails when the individual parts have different names. We can’t map bigger 
geographic entities like deserts, swamplands, forests, highlands (besides the 
names for the smallest parts, or if they correspond to other entities with 
clear boundaries like nature reserves, or maybe by overlapping the same kind of 
objects, what is generally frowned upon)


> 
> The logical way would be a parent relation with type=wetland (and actually 
> have the name only there, but no renderer today understands that, it needs to 
> be on the separate parts as well). What should the roles be? The most logical 
> way would be to leave role field empty.



Maybe a similar approach as the one for relations of type=group (i.e. a 
relation type which explicitly “inherits” its meaning from the members without 
the requirement but with the possibility for additional tags, a place to put a 
name for the ensemble) could be taken for area relations as well, e.g. the site 
relation could include the different wetlands, and a name (and e.g. 
wikipedia/wikidata reference, etc.) might be sufficient to map the “collective” 
of things? The nature would be implied by its members.

The bigger such geographic entities become, the less you will typically be able 
to draw a hard line (fuzzyness of many natural borders, rather smooth 
transitions). If we want to map all those “meta areas” with names we would do 
well to think about additional ways of delimiting space (i.e. different kind of 
geometry objects), e.g. a fuzzy border could be represented by providing 
different points for which it seems undisputed that they are in or out of the 
area in question. This would be very lightweight for all mappers, because it 
avoids clear lines which are confusing when they do not correspond with 
something observable. It may be difficult to find these things though 
(obviously would require editor/tool support).


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
So your advice is to actually skip the parent relation object, and thus 
leave the parts separate and related implicitly just by shared borders 
and having the same name? Ok, fine by me.


I certainly agree with you that data users probably won't turn complex 
patterns into something meaningful, as there is no real standard 
documentation of how to map things, just a wiki of soft and incomplete 
"advice", and lots of dead-end methods that never catched on. I rather 
avoid wasting time on using/inventing yet another of those dead-end 
methods. I think a better way would be a well-documented OSM-standard 
where the standards organization on itself figure out needs and take the 
lead rather than anonymous individual mappers like myself must invent 
own methods for needs that are really quite basic. But that just won't 
happen, so I know that I'm probably just wasting my time mapping at this 
detail level. But the OSM way is to let mappers take the lead and 
renderers (maybe) come after, I think it's a very BAD way now when OSM 
is as large as it is, but it's the way it is, so I'm in a take it or 
leave it situation. I enjoy mapping and OSM is the only free alternative 
there is.


On 2020-12-12 12:43, Christoph Hormann wrote:

My strong advise is not to make this more complicated than it is and
especially not cargo cult some complex data model in the hope that
data users will turn this into something meaningful - they won't.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Christoph Hormann


> Anders Torger  hat am 12.12.2020 12:23 geschrieben:
> 
> Sorry, I realize I have a followup question. Is this really the right 
> way?
> 
> There's a difference from the Rhine example. With rivers all the 
> separate parts are tied together with a parent relation of the type 
> waterway, and the parts have roles like "main_stream".

No, waterway relations are like route relations for roads, they are purely 
optional and have nothing to do with the local naming of physical features.

My strong advise is not to make this more complicated than it is and especially 
not cargo cult some complex data model in the hope that data users will turn 
this into something meaningful - they won't.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Anders Torger
Sorry, I realize I have a followup question. Is this really the right 
way?


There's a difference from the Rhine example. With rivers all the 
separate parts are tied together with a parent relation of the type 
waterway, and the parts have roles like "main_stream".


In the wetland case as described, there is no parent relation at all. 
The only thing that ties them together is implicitly by sharing borders 
and having the same name tag. It seems to me that an "official" way to 
edit should tie them together with a parent relation.


The logical way would be a parent relation with type=wetland (and 
actually have the name only there, but no renderer today understands 
that, it needs to be on the separate parts as well). What should the 
roles be? The most logical way would be to leave role field empty. To 
summarize:


Suggested method of how to name a wetland that has more than one 
sub-type:


* Prerequisite: each sub-type (marsh, bog etc) is a polygon (or 
multipolygon if required,
  for example if there's an inner water or forest) which shares segments 
with the

  neighboring sub-type, ie the wetland is a single entity.
* Put the name on each part, same for all
* Create a relation with type=wetland (no sub-type) and include all 
parts with role
  field empty, also name this relation with the same name (although no 
current

  renderer will care)

What do you think about this way? JOSM thinks it's fine at least, I get 
no warnings :-).


(Note that there's another case that can be solved with just a single 
multipolygon, when there's a single sub-type but the parts are 
separated, so each part can be an outer, this is also (quite) common, 
although more common for waters and islands than wetlands. The special 
thing with the discussed case is that it's a single entity all parts 
bordering to the next)


On 2020-12-11 20:55, Anders Torger wrote:

Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each
separate part so not exactly beautiful, but the data is there.

/Anders

On 2020-12-11 18:07, Christoph Hormann wrote:

Anders Torger  hat am 11.12.2020 17:07 geschrieben:

The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same,


That is widely considered to be the correct way.  It is established
practice that mapping things like forest, wetland, farmland etc. can
be split to differentiate tagging (like leaf_type, wetland type, crop
etc.).  The name tag is then applied to all components.  Same as for
waterways or roads where you can also split and apply the name to the
components.

This also matches the general concept in OSM that names are typically
local properties and only locally verifiable.  The Rhine river is
called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.


___
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] How to put a name tag on an area with more than one type?

2020-12-11 Thread Graeme Fitzpatrick
Sorry, ignore me as it looks like the question had already been answered.

When I opened the message, your original question was the only thing there,
but when I answered, all the other earlier replies appeared?

No idea what's going on there? Guess gmail must be having a bad morning!

Thanks

Graeme


On Sat, 12 Dec 2020 at 08:44, Graeme Fitzpatrick 
wrote:

> Does each bog & marsh have it's own name, or are just different surfaces
> inside one big named wetland?
>
> Thanks
>
> Graeme
>
> PS & please don't get frustrated & give up on trying to make progress!
>
>
> On Sat, 12 Dec 2020 at 02:11, Anders Torger  wrote:
>
>> Hello,
>>
>> I was on this list a while back expressing some frustration over
>> limitations when tagging nature and thought about getting involved in a
>> process for change, but I came to realize that it's not feasible for me
>> in my current life situation, so I've decided to continue be a normal
>> mapper as before, doing what I can do with features that exist today.
>>
>> Anyway, if to be a mapper at all, I still like to solve some of my
>> naming issues in the best/least bad ways possible today. I'm currently
>> mapping a national park in Sweden, Muddus. It's in Laponia and consists
>> of mighty wetlands and old forest. These wetlands are named, like is
>> common in Sweden and Sami lands. For us navigating in wildlife, names in
>> nature are important.
>>
>> A wetland polygon can be named in OSM, so the situation is better than
>> for example for named slopes (also common). However, a wetland here can
>> consist of both bog and marsh (and it's important to make the
>> difference, since one is easy to walk on, the other not so much). That's
>> two different natural types and thus can't be in the same multipolygon
>> (as outers).
>>
>>
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Graeme Fitzpatrick
Does each bog & marsh have it's own name, or are just different surfaces
inside one big named wetland?

Thanks

Graeme

PS & please don't get frustrated & give up on trying to make progress!


On Sat, 12 Dec 2020 at 02:11, Anders Torger  wrote:

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Anders Torger
Thanks I'll do it this way then, this actually works and even gets 
rendered, although with OSM-Carto it becomes a name tag in each separate 
part so not exactly beautiful, but the data is there.


/Anders

On 2020-12-11 18:07, Christoph Hormann wrote:

Anders Torger  hat am 11.12.2020 17:07 geschrieben:

The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same,


That is widely considered to be the correct way.  It is established
practice that mapping things like forest, wetland, farmland etc. can
be split to differentiate tagging (like leaf_type, wetland type, crop
etc.).  The name tag is then applied to all components.  Same as for
waterways or roads where you can also split and apply the name to the
components.

This also matches the general concept in OSM that names are typically
local properties and only locally verifiable.  The Rhine river is
called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.


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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Anders Torger

Unfortunately I don't think that is possible.

Multipolygons may only contain ways that have either role as inner or as 
outer. It may not contain other relations (still possible to upload, but 
not considered right according to the wiki). What should the ways be?


We can't make the separate wetland parts as inner ways, (as areas formed 
by the inner ways are subtracted from the multipolygon), and even if we 
try it becomes illegal as inner ways cannot share segments with the 
outer way. We can't make the parts as outers either as they share 
segments. The outer must be the surrounding outline without the shared 
segments splitting the wetland in parts, and there are no inners (unless 
the parts themselves has inners).


So then we have a multipolygon with just an outer. I could just as well 
be a plain polygon made from a single closed way. This would work if 
drawing order was defined, and that was the method I tried first. The 
container polygon must have a natural tag as well (the logical would be 
wetland here without further sub-classification).


However the drawing order is not defined (I think, not 100% sure), so 
this is by the renderer interpreted as a wetland lying on top of the 
other wetlands. OSM-Carto will still render the insides, but the fill 
pattern of the outer polygon is drawn on top.


On 2020-12-11 18:09, Brian M. Sperlongano wrote:


Hello Anders,

I would recommend creating a multipolygon relation (type=multipolygon) 
with each of the wetland pieces, and set the name= and appropriate 
natural= and wetland= tags on the relation.


On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:


Hello,

I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about getting involved in 
a
process for change, but I came to realize that it's not feasible for 
me

in my current life situation, so I've decided to continue be a normal
mapper as before, doing what I can do with features that exist today.

Anyway, if to be a mapper at all, I still like to solve some of my
naming issues in the best/least bad ways possible today. I'm currently
mapping a national park in Sweden, Muddus. It's in Laponia and 
consists

of mighty wetlands and old forest. These wetlands are named, like is
common in Sweden and Sami lands. For us navigating in wildlife, names 
in

nature are important.

A wetland polygon can be named in OSM, so the situation is better than
for example for named slopes (also common). However, a wetland here 
can

consist of both bog and marsh (and it's important to make the
difference, since one is easy to walk on, the other not so much). 
That's

two different natural types and thus can't be in the same multipolygon
(as outers).

Asking on OSM Help website for a solution I got the answer to make a 
new

containing multipolygon and set the name on that. That would be quite
elegant for sure, but JOSM warns about that, can't have a name without 
a
type, and if I set the type, say natural=wetland without any subtype, 
I
get a JOSM warning that I have natural features on top of eachother. 
If

I still upload it OSM-Carto does render out the name but you can see
that the wetland pattern of the outer polygon is drawn on top of the
contained polygons, so it does not seem to be the way to do it.

The least bad way I've come up with is to just name all polygons
belonging to the same wetlands the same, and hope for that in the 
future

smart renderers will understand that polygons with shared borders and
shared name is the same named entity.

Any ideas or suggestions?

/Anders

___
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] How to put a name tag on an area with more than one type?

2020-12-11 Thread Peter Elderson
Actually, there is no Rijn in Rotterdam. But that does not change the argument.

Mvg Peter Elderson

> Op 11 dec. 2020 om 18:11 heeft Christoph Hormann  het 
> volgende geschreven:
> 
> 
> 
>> Anders Torger  hat am 11.12.2020 17:07 geschrieben:
>> 
>> The least bad way I've come up with is to just name all polygons 
>> belonging to the same wetlands the same,
> 
> That is widely considered to be the correct way.  It is established practice 
> that mapping things like forest, wetland, farmland etc. can be split to 
> differentiate tagging (like leaf_type, wetland type, crop etc.).  The name 
> tag is then applied to all components.  Same as for waterways or roads where 
> you can also split and apply the name to the components.
> 
> This also matches the general concept in OSM that names are typically local 
> properties and only locally verifiable.  The Rhine river is called Rhein in 
> Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.
> 
> -- 
> Christoph Hormann 
> http://www.imagico.de/
> 
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-11 Thread Brian M. Sperlongano
Hello Anders,

I would recommend creating a multipolygon relation (type=multipolygon) with
each of the wetland pieces, and set the name= and appropriate natural= and
wetland= tags on the relation.

On Fri, Dec 11, 2020, 11:11 AM Anders Torger  wrote:

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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] How to put a name tag on an area with more than one type?

2020-12-11 Thread Christoph Hormann


> Anders Torger  hat am 11.12.2020 17:07 geschrieben:
> 
> The least bad way I've come up with is to just name all polygons 
> belonging to the same wetlands the same,

That is widely considered to be the correct way.  It is established practice 
that mapping things like forest, wetland, farmland etc. can be split to 
differentiate tagging (like leaf_type, wetland type, crop etc.).  The name tag 
is then applied to all components.  Same as for waterways or roads where you 
can also split and apply the name to the components.

This also matches the general concept in OSM that names are typically local 
properties and only locally verifiable.  The Rhine river is called Rhein in 
Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.

-- 
Christoph Hormann 
http://www.imagico.de/

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


[Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Anders Torger

Hello,

I was on this list a while back expressing some frustration over 
limitations when tagging nature and thought about getting involved in a 
process for change, but I came to realize that it's not feasible for me 
in my current life situation, so I've decided to continue be a normal 
mapper as before, doing what I can do with features that exist today.


Anyway, if to be a mapper at all, I still like to solve some of my 
naming issues in the best/least bad ways possible today. I'm currently 
mapping a national park in Sweden, Muddus. It's in Laponia and consists 
of mighty wetlands and old forest. These wetlands are named, like is 
common in Sweden and Sami lands. For us navigating in wildlife, names in 
nature are important.


A wetland polygon can be named in OSM, so the situation is better than 
for example for named slopes (also common). However, a wetland here can 
consist of both bog and marsh (and it's important to make the 
difference, since one is easy to walk on, the other not so much). That's 
two different natural types and thus can't be in the same multipolygon 
(as outers).


Asking on OSM Help website for a solution I got the answer to make a new 
containing multipolygon and set the name on that. That would be quite 
elegant for sure, but JOSM warns about that, can't have a name without a 
type, and if I set the type, say natural=wetland without any subtype, I 
get a JOSM warning that I have natural features on top of eachother. If 
I still upload it OSM-Carto does render out the name but you can see 
that the wetland pattern of the outer polygon is drawn on top of the 
contained polygons, so it does not seem to be the way to do it.


The least bad way I've come up with is to just name all polygons 
belonging to the same wetlands the same, and hope for that in the future 
smart renderers will understand that polygons with shared borders and 
shared name is the same named entity.


Any ideas or suggestions?

/Anders

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