Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks Steve, good to know about the wiki, I had a hunch that was how 
it's meant but wasn't really sure. Certainly descriptive for this tag. I 
guess I could "take over" the fell tag but starting massively use it for 
bare mountain landcover, but I shall look more closely into 
alternatives.


Just starting using Overpass Turbo, seems like a really cool and useful 
tool, and impressively fast for the amount of data there is. With a bit 
of learning curve as you say though :-D.


I think I've read about heath+alpine=yes somewhere, I'll see if I can 
make an OT search for it :-).


/Anders

On 2020-12-21 19:11, stevea wrote:

Nice, Anders.  You can use taginfo to get "the raw numbers" (quantity)
of a particular kind of tagging.  What might work specifically for you
in this case is to use some well-crafted Overpass Turbo queries (over
a specific area at first, you can use the "bbox" method of "what you
see on-screen" or you can use the "geocodeArea" directive to restrict
the query to a named place).  OT querying takes some practice to
become skilled in its vast power to query OSM data, but it is worth
investing in the learning curve to do this, as it is likely (imo) the
most powerful tool we have to ask our data "what about this, like
this?"

Usually, our wiki describe "tagging as is," what is known as
"descriptive."  On occasion, some wiki will be "prescriptive," meaning
"here is how one SHOULD tag, though I make a point to say that any
wiki which does that should say so explicitly.

Good luck in your endeavors!

SteveA


On Dec 21, 2020, at 9:56 AM, Anders Torger  wrote:
I just discovered a strange(?) thing with the "natural=fell" tag which 
I missed at first: on the wiki page there's two purposes defined of 
this single tag, the first is landcover of bare mountain as discussed, 
and the other purpose is, quote from the wiki:


"In the north of England, and probably in other areas of Norse 
influence such as Iceland, Norway and Sweden, there is a practice of 
naming the sides of hills, fells, rather than peaks. A single hill can 
have different names on different sides. This tag can be used to 
record such names."


It's true that we do have such a practice although more so at lower 
altitudes. I recently added such a name on an alpine mountain as a 
fell cutout with a fixme tag (there is no other tag for slopes I 
think, didn't realize that "fell" is it). However as said we have 
"fell" in that sense in forested areas as well, even more common 
there.


I guess if "fell without name tag" is defined as landcover, and "fell 
with name tag" is defined as fuzzy area naming a side of a hill it 
could work, but it's the first time I see this type of dual 
definition. Is it normal, or is the wiki page just documenting how 
this tag have ended up being used?


/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] natural=fell not rendered, alternatives?

[stevea]

Nice, Anders.  You can use taginfo to get "the raw numbers" (quantity) of a 
particular kind of tagging.  What might work specifically for you in this case 
is to use some well-crafted Overpass Turbo queries (over a specific area at 
first, you can use the "bbox" method of "what you see on-screen" or you can use 
the "geocodeArea" directive to restrict the query to a named place).  OT 
querying takes some practice to become skilled in its vast power to query OSM 
data, but it is worth investing in the learning curve to do this, as it is 
likely (imo) the most powerful tool we have to ask our data "what about this, 
like this?"

Usually, our wiki describe "tagging as is," what is known as "descriptive."  On 
occasion, some wiki will be "prescriptive," meaning "here is how one SHOULD 
tag, though I make a point to say that any wiki which does that should say so 
explicitly.

Good luck in your endeavors!

SteveA


On Dec 21, 2020, at 9:56 AM, Anders Torger  wrote:
> I just discovered a strange(?) thing with the "natural=fell" tag which I 
> missed at first: on the wiki page there's two purposes defined of this single 
> tag, the first is landcover of bare mountain as discussed, and the other 
> purpose is, quote from the wiki:
> 
> "In the north of England, and probably in other areas of Norse influence such 
> as Iceland, Norway and Sweden, there is a practice of naming the sides of 
> hills, fells, rather than peaks. A single hill can have different names on 
> different sides. This tag can be used to record such names."
> 
> It's true that we do have such a practice although more so at lower 
> altitudes. I recently added such a name on an alpine mountain as a fell 
> cutout with a fixme tag (there is no other tag for slopes I think, didn't 
> realize that "fell" is it). However as said we have "fell" in that sense in 
> forested areas as well, even more common there.
> 
> I guess if "fell without name tag" is defined as landcover, and "fell with 
> name tag" is defined as fuzzy area naming a side of a hill it could work, but 
> it's the first time I see this type of dual definition. Is it normal, or is 
> the wiki page just documenting how this tag have ended up being used?
> 
> /Anders


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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

I just discovered a strange(?) thing with the "natural=fell" tag which I 
missed at first: on the wiki page there's two purposes defined of this 
single tag, the first is landcover of bare mountain as discussed, and 
the other purpose is, quote from the wiki:


"In the north of England, and probably in other areas of Norse influence 
such as Iceland, Norway and Sweden, there is a practice of naming the 
sides of hills, fells, rather than peaks. A single hill can have 
different names on different sides. This tag can be used to record such 
names."


It's true that we do have such a practice although more so at lower 
altitudes. I recently added such a name on an alpine mountain as a fell 
cutout with a fixme tag (there is no other tag for slopes I think, 
didn't realize that "fell" is it). However as said we have "fell" in 
that sense in forested areas as well, even more common there.


I guess if "fell without name tag" is defined as landcover, and "fell 
with name tag" is defined as fuzzy area naming a side of a hill it could 
work, but it's the first time I see this type of dual definition. Is it 
normal, or is the wiki page just documenting how this tag have ended up 
being used?


/Anders

On 2020-12-21 18:27, stevea wrote:
On Dec 21, 2020, at 7:10 AM, Tomas Straupis  
wrote:

2020-12-21, pr, 16:52 Anders Torger rašė:

But what to do if the things you want doesn't
really fit into what OSM currently is and strives to be...


 We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
 YOU define what OSM is and where it is going to by DOING.
 The more I look at it, the more it seems that fragmentation is
inevitable. Question is how much will remain "common".


Thank you for saying it like this, Tomas.  Fragmentation happens,
though it is not the end of OSM when it does.  Private projects, when
they happen, don't necessarily harm OSM, they prove its strength as a
solid foundation of data upon which are built bespoke / custom
solutions.  These even can (and do?) "link up" to form a stronger
fabric which "rides along with" the solid foundation.  There are
examples of this in OSM right now.  Truly, a lot of what was said in
the last few posts are bullseyes on a target:

• YOU define what OSM is by DOING (a crucially important truth!)

• While "local renderers" are by definition limited in their scope,
they need not be limited in their use:  they can be practical/visual
proofs of "better ways" (to do things), testing grounds for finding
solutions to more international problems

• There are already local communities creating local cartographic data
schemas, this is already being talked about as becoming more-widely
and better integrated among data consumers (like yourself, Anders —
that's how this works)

• Making OSM into what we might use in the future as a "baseline" map
for a drop-in replacement for government maps (in Sweden, for example)
will doubtless earn us growing contributions that surpass the
government maps.  Yes, that's a fair bit of sweat, work and time, but
it is worth it!  (That's a fantastic dream, well-stated and shared by
many, Anders!)

• Agreeing on the goals FIRST (among peers who can, do and will work
towards them) takes energy, but it is worth it!

• It is easy to get hooked on this kind of mapping / data /
collaboration!  It works, it is a lot of fun.  Repeat ad infinitum.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 21, 2020, at 7:10 AM, Tomas Straupis  wrote:
> 2020-12-21, pr, 16:52 Anders Torger rašė:
>> But what to do if the things you want doesn't
>> really fit into what OSM currently is and strives to be...
> 
>  We are ALL OSM community. If somebody tells you that "I am OSM and
> only A is right" - do not believe them.
>  YOU define what OSM is and where it is going to by DOING.
>  The more I look at it, the more it seems that fragmentation is
> inevitable. Question is how much will remain "common".

Thank you for saying it like this, Tomas.  Fragmentation happens, though it is 
not the end of OSM when it does.  Private projects, when they happen, don't 
necessarily harm OSM, they prove its strength as a solid foundation of data 
upon which are built bespoke / custom solutions.  These even can (and do?) 
"link up" to form a stronger fabric which "rides along with" the solid 
foundation.  There are examples of this in OSM right now.  Truly, a lot of what 
was said in the last few posts are bullseyes on a target:

• YOU define what OSM is by DOING (a crucially important truth!)

• While "local renderers" are by definition limited in their scope, they need 
not be limited in their use:  they can be practical/visual proofs of "better 
ways" (to do things), testing grounds for finding solutions to more 
international problems

• There are already local communities creating local cartographic data schemas, 
this is already being talked about as becoming more-widely and better 
integrated among data consumers (like yourself, Anders — that's how this works)

• Making OSM into what we might use in the future as a "baseline" map for a 
drop-in replacement for government maps (in Sweden, for example) will doubtless 
earn us growing contributions that surpass the government maps.  Yes, that's a 
fair bit of sweat, work and time, but it is worth it!  (That's a fantastic 
dream, well-stated and shared by many, Anders!)

• Agreeing on the goals FIRST (among peers who can, do and will work towards 
them) takes energy, but it is worth it!

• It is easy to get hooked on this kind of mapping / data / collaboration!  It 
works, it is a lot of fun.  Repeat ad infinitum.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 16:52 Anders Torger rašė:
> But what to do if the things you want doesn't
> really fit into what OSM currently is and strives to be...

  We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
  YOU define what OSM is and where it is going to by DOING.
  The more I look at it, the more it seems that fragmentation is
inevitable. Question is how much will remain "common".

"Don't let the bastards grind you down" - U2 :-)

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Good points.

I think Norway and Sweden is quite well-known for good maps for hikers 
in the mountains (at least we think so ourselves :-) ), but indeed those 
do not require as quick updates as there's not much changing out there 
and so far no craftbeer on the top of Kebnekaise mountain. But maybe its 
coming... :-). I have no doubt though that if we could make a good 
baseline outdoor map which works as a drop-in replacement for the 
government maps, we could get more contributions that surpass what 
official sources can provide, such as various climbing routes. That's my 
dream, and one reason I started to map national parks. However if the 
base map lacks important base features, eg names in the nature or proper 
generalization, the map is considered less relevant for these areas and 
people won't contribute in the same way.


I also agree with your other points, but it does boil down to that I 
need to do a lot of work :-O. On the other hand it's much easier to get 
things done when you have a small community that can agree on the goals, 
than most energy being spent on trying to convince each-other if a goal 
is even worthwhile to pursue or not, and making people upset in the 
process, which I myself have been guilty of. It's energy-draining for 
all of us.


I've seen the large fragmentation in OSM, all those small private 
projects here and there, as a problem. Not the projects as such, those 
are great, many great and interesting ideas, but most seem disconnected 
from the main community and as such few make it back into mainline, but 
instead goes unmaintained and eventually peters out when the authors 
move on to other projects. But what to do if the things you want doesn't 
really fit into what OSM currently is and strives to be... I'll think 
about it over Christmas. I've invested way more time in OSM during the 
fall than I initially planned to. Mapping is dangerous, it's easy to get 
hooked ;-).


/Anders

On 2020-12-21 15:09, Tomas Straupis wrote:

2020-12-21, pr, 15:54 Anders Torger rašė:

A local renderer would be limited in use <...>


  Not necessarily ;-)
  1. It could be a practical/visual proof of a "better way".
  2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problems.
  3. If enough local communities create cartographic data schemas,
they could technically align them (tagging-cartographic maillist?) and
then data consumers would have to adopt to that as well.
  4. I'm not aware of the outdoors map specifics in Sweden, but at
least here OSM maps update much faster and also include
specific/thematic information for tourism, cayaking, craftbeer,
history and all other good things which official sources do not have.
And having all of that in one database (rather than an overlay) has
some important benefits.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 15:54 Anders Torger rašė:
> A local renderer would be limited in use <...>

  Not necessarily ;-)
  1. It could be a practical/visual proof of a "better way".
  2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problems.
  3. If enough local communities create cartographic data schemas,
they could technically align them (tagging-cartographic maillist?) and
then data consumers would have to adopt to that as well.
  4. I'm not aware of the outdoors map specifics in Sweden, but at
least here OSM maps update much faster and also include
specific/thematic information for tourism, cayaking, craftbeer,
history and all other good things which official sources do not have.
And having all of that in one database (rather than an overlay) has
some important benefits.

-- 
Tomas

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks Tomas, much appreciated.

I guess you are right, but if local country cartography is the only way, 
that lowers motivation to contribute a lot here locally. We have great 
local maps already. To me the attraction of providing to OSM is that the 
data gets broadly available in any end product that uses OSM data. So 
any mobile app using OSM maps suddenly gets much better maps here 
locally, even if the app was made for the US market in the first place.


A local renderer would be limited in use, and then I could use just our 
local government maps directly. Which I indeed have done for some 
projects local to Swedish users.


(Thanks for the fuzzy area PS too. Maybe external database is the way to 
go, I see many say that. But that is of little use if it's not getting 
used by standard renderers, and it seems like we maybe aren't into 
making rural/outdoor maps at all)


/Anders

On 2020-12-21 14:38, Tomas Straupis wrote:

2020-12-21, pr, 14:42 Anders Torger rašė:

I personally want to see that the community work for a more defined
mapping baseline with OSM-Carto as a strong reference, used as a
motivational tool for crowd-sourcing, and as it is with the current
provider landscape -- also work as an end product. It does in parts
already, and I want to see more of that. I also got a sense of 
urgency,

map density in OSM has improved a lot, data sources that a mapper has
access too has also improved a lot since OSM started, so mappers can
today map much more than they could before and are more motivated to 
do

so, at least in some places in the world. I want the OSM technical
platform to be ready for that.


  In OSM for natural reasons cartographers are a small minority
comparing to majority of coders. Therefore cartographic goals do not
get through a "coder filter" (it is more important for majority to
have clean code than to have clean map).
  You might try, but in my experience the only way is to:
  * have a more cartographic agreement with local community (it is
easier in small scale, as you can meet in person, show good examples
and thus prove the value of cartography)
  * have your own country renderer (you can start with VPS for ~100EUR
a year and go up as your usage grows).
  * have your own country editor with your regional tagging schema (I
will publish instructions on how to do that in a month or two)
  * do most of the work yourself (or with a small group of cartography
oriented people) at least initially as resistance will be there anyway
until you prove/show results
  You will have cartographic maps and will not have to waste time
agreeing on cartographic nuances with people who do not understand
cartography. You will simply agree about them LOCALLY and use them
(OSM has a rule of "free tagging").

P.S. Frederik is right about fuzzy features, even in cartographic
perspective they do not belong in the same bucket as current OSM
features. I think you should have a separate database for those. It is
not hard to implement that as amount of data/changes is much lower.
They later end up in the same database in similar GIS tables as main
OSM data therefore are seamless to use in final products.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[Tomas Straupis]

2020-12-21, pr, 14:42 Anders Torger rašė:
> I personally want to see that the community work for a more defined
> mapping baseline with OSM-Carto as a strong reference, used as a
> motivational tool for crowd-sourcing, and as it is with the current
> provider landscape -- also work as an end product. It does in parts
> already, and I want to see more of that. I also got a sense of urgency,
> map density in OSM has improved a lot, data sources that a mapper has
> access too has also improved a lot since OSM started, so mappers can
> today map much more than they could before and are more motivated to do
> so, at least in some places in the world. I want the OSM technical
> platform to be ready for that.

  In OSM for natural reasons cartographers are a small minority
comparing to majority of coders. Therefore cartographic goals do not
get through a "coder filter" (it is more important for majority to
have clean code than to have clean map).
  You might try, but in my experience the only way is to:
  * have a more cartographic agreement with local community (it is
easier in small scale, as you can meet in person, show good examples
and thus prove the value of cartography)
  * have your own country renderer (you can start with VPS for ~100EUR
a year and go up as your usage grows).
  * have your own country editor with your regional tagging schema (I
will publish instructions on how to do that in a month or two)
  * do most of the work yourself (or with a small group of cartography
oriented people) at least initially as resistance will be there anyway
until you prove/show results
  You will have cartographic maps and will not have to waste time
agreeing on cartographic nuances with people who do not understand
cartography. You will simply agree about them LOCALLY and use them
(OSM has a rule of "free tagging").

P.S. Frederik is right about fuzzy features, even in cartographic
perspective they do not belong in the same bucket as current OSM
features. I think you should have a separate database for those. It is
not hard to implement that as amount of data/changes is much lower.
They later end up in the same database in similar GIS tables as main
OSM data therefore are seamless to use in final products.

-- 
Tomas

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

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

(Sorry if I missed a private message. I have a generic filter that 
throws all emails that match tagging in some way to one mailbox and 
sometimes I miss things.)


Anyway, I'm talking about globally distributed open source projects, 
where you communicate in text over email and forums. Not a workplace. 
It's very different ways of communicating, and it always looks harsher 
than it is. You probably have a whole different view of me than you 
would have if we met in person. But point is taken, and I have noted 
that discussions go south here a lot quicker than I'm used to, and 
indeed that's ineffective. I'll try to provide a softer tone, because 
what I want really want is solutions to the issues.


I guess one issue with my appearances here is that in my humble opinion 
many things in OSM are problematic, mostly a result of that it has 
piecewise evolved rather than it has had a solid design leadership, and 
it's got some growing pains. I've hidden that view poorly mainly because 
many issues I run into I think would have been non-issues if it has been 
more of a top-down design for a baseline feature set focusing on actual 
end uses. I now understand that this view is very provocative though, so 
I'll try to tone it down.


I personally want to see that the community work for a more defined 
mapping baseline with OSM-Carto as a strong reference, used as a 
motivational tool for crowd-sourcing, and as it is with the current 
provider landscape -- also work as an end product. It does in parts 
already, and I want to see more of that. I also got a sense of urgency, 
map density in OSM has improved a lot, data sources that a mapper has 
access too has also improved a lot since OSM started, so mappers can 
today map much more than they could before and are more motivated to do 
so, at least in some places in the world. I want the OSM technical 
platform to be ready for that.


/Anders

On 2020-12-21 11:55, stevea wrote:

On Dec 21, 2020, at 2:10 AM, Anders Torger  wrote:
I'm sorry if you experience it as that. Maybe I'm a bit too 
confrontational, and maybe I should express myself with a softer tone, 
I guess my style has become a bit shaped by to how we communicate 
engineer to engineer in programming projects.


Anders, I’ve been an employee at Apple, Adobe and many startups (in
Silicon Valley and my university city nearby on the coast), as an
engineer, to other engineers.  I have been a team leader, a manager
and a director — on dozens of programming projects.  I DON’T “guess”
at your style and if you worked with me I’d give you as stern a
talking to behind a closed door, just the two of us.  That’s not as I
do here on-list, precisely because YOU chose the more public venue,
but also because you don’t answer my polite, private email.


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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 21, 2020, at 2:10 AM, Anders Torger  wrote:
> I'm sorry if you experience it as that. Maybe I'm a bit too confrontational, 
> and maybe I should express myself with a softer tone, I guess my style has 
> become a bit shaped by to how we communicate engineer to engineer in 
> programming projects.

Anders, I’ve been an employee at Apple, Adobe and many startups (in Silicon 
Valley and my university city nearby on the coast), as an engineer, to other 
engineers.  I have been a team leader, a manager and a director — on dozens of 
programming projects.  I DON’T “guess” at your style and if you worked with me 
I’d give you as stern a talking to behind a closed door, just the two of us.  
That’s not as I do here on-list, precisely because YOU chose the more public 
venue, but also because you don’t answer my polite, private email.

> That is the jargon can be quite "hard" with many strong opinions clashing, 
> but it's nothing personal.

Your jargon isn’t what I experience in professional software engineering 
settings, it is what I hear from smart-aleck, spoiled children or teenagers.  I 
don’t take it personally, that’s a mistake on your part.  I find it wholly 
ineffective.  Because it is.

> I've seen others in this list use the same "tough" way to voice their 
> opinions so I thought it was okay. As long as one focus on the merits of the 
> arguments, have an open mind to change opinion, is open to solutions one 
> didn't think about, and don't go personal it usually works well.

While on occasion here, I have seen a certain swagger and displays of, let’s 
say, “attitude,” I haven’t seen the constant, aggressive, highly negative 
“toughness” that you bring.  It is relentless.  What others do is ask 
questions.  By contrast, what you do is complain and say what is wrong with how 
we already do things.  We’ve gotten a lot done and have much to do yet, but we 
partly do that with dialog, not by giving cookies to children.

> I can try go softer in jargon, but it won't change the fact that the reason I 
> get on this list is when things either don't work or I don't find an answer 
> to some question. So it will be "complaints" in some way or another. I think 
> I do provide some solutions too though, although some may not be easy to 
> realize or is not likable by everyone.

The problem isn’t jargon.  I understand jargon, the list understands jargon.  
(And if or when we don’t we ask for clarification, usually getting it.  That’s 
part of how good dialog works).  The problem is that your complaints to this 
list are nearly completely lacking in “good questions” that any of us can field 
(or, given your poor attitude, really want to).  They are as I have described 
them.  Only very rarely are they well-posed questions.  Please endeavor to 
remedy that and I virtually guarantee that you will find people who reply with 
thoughtful answers, or at the very least helpful direction.  But plain and 
simple, nobody likes a complainer.

> That there are many "complaints" coming from me now is because I currently 
> map *a lot* and mainly nature (which wasn't an original goal for OSM but 
> something that has come later, so it's understandable that there are issues)

Please be careful about assumptions that you make and how they affect you:  
this is part of what is ineffective with your interactions with this list.  OSM 
doesn’t need you to make excuses (like that you or anybody “understands that 
“there are issues”).

> and therefore come across many issues which have no clear answers.

To you, now, when you haven’t clearly and politely asked your question.  Try 
this:  before posting your “issues,” distill them down to one or two 
well-crafted questions that someone on this list MIGHT be able to answer 
succinctly.  Before you actually write it, consider some possible answers.  
Ask:  might it be X, is Y even possible, does Z seem like a feasible direction 
to explore if this has never been done in OSM before?  Like that.  It works!

> This is a list for tag discussion, strategy and related tools. Issues bubble 
> up to here. If I had a clear answer I wouldn't even need to post, and there 
> are many of those too (ie where I've found working solutions on the wiki or 
> through OSM help).

I understand how that works, you are correct.  This IS a (good) place to turn 
when the wiki or other sources do not satisfy your craving to know how to do 
something in OSM.  It is HOW one does that questioning here that (partly) 
determines how likely you are to get an answer.  Well-crafted, judgement-free, 
lacking-in-assumptions questions do well.  Non-questions that are judgmental 
and assume (a little, a lot) do poorly, as you have discovered.

> The reason I don't have a clear answer is that there is several issues with 
> the current approaches, which I described in my post.

You can describe these “issues” in the course of the dialog with someone who 
engages you here if and as they actually provide a blockade to 

Re: [Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Thanks, good points and information.

Indeed, the fell tag seems to be a bit misused. I would guess it could 
be because there are things actually named "Fell" there, and then 
inexperienced mappers may use the Fell tag as that seems appropriate. 
Incorrect use can be cleaned up in time though (fell is not used *a lot* 
so it's not like fixing place=locality uses...), and I think it 
shouldn't stop a useful tag. But sure we could perhaps make a new one, 
or a new tag combination if that is better.


I have myself looked at the fell definition here:

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell

And interestingly enough the "examples" photographs are from areas I'm 
actually currently mapping(!) so I thought if it was meant to be used at 
all, this is the place :-). It also matches up how maps are 
traditionally made here, so very good for the local community. We don't 
call these areas "fell" in our local language, but rather what would be 
translated to "bare mountain" (ie mountain above tree line), but the 
actual name of the tag isn't what matters, it's the definition. And the 
current wiki page clearly points at the use I'm looking for.


Although the bare rock/scree altitude is quite clear and I'll probably 
map it as that in time, I'm afraid that if I map the mid altitude bare 
mountain with "heath" instead of fell, the heath definition will be a 
bit watered out due to the speckled and diffuse character of this 
nature. So I think it would be better with a specific tag that embraces 
this property of the land.


/Anders

On 2020-12-21 10:34, Andy Townsend wrote:

On 21/12/2020 07:39, Anders Torger wrote:

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. ...


This isn't really anything to do with tagging, but I can understand
why some renderers decide not to render it.

Usage, at least where am I, is hugely problematic:
http://overpass-turbo.eu/s/11nH .

Usage in the Pennines northwest of Leeds is almost exclusively just a
bunch of names that have been copied from old out-of-copyright NPE
maps.  The features may be peaks, or patches of moorland, or something
else again.  If a renderer was to do something with them, it'd
probably be as "place=locality".

Further west examples like https://www.openstreetmap.org/way/412325588
correspond better to the wiki definition.  In that example other
landuse (woodland, heath) is also mapped.

There are also some surprising uses in place of other tags - on
https://www.openstreetmap.org/way/368051383 it surely means
"trail_visibility"!

Best Regards,

Andy



___
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] natural=fell not rendered, alternatives?

[Anders Torger]

Steve,

I'm sorry if you experience it as that. Maybe I'm a bit too 
confrontational, and maybe I should express myself with a softer tone, I 
guess my style has become a bit shaped by to how we communicate engineer 
to engineer in programming projects. That is the jargon can be quite 
"hard" with many strong opinions clashing, but it's nothing personal. 
I've seen others in this list use the same "tough" way to voice their 
opinions so I thought it was okay. As long as one focus on the merits of 
the arguments, have an open mind to change opinion, is open to solutions 
one didn't think about, and don't go personal it usually works well.


I can try go softer in jargon, but it won't change the fact that the 
reason I get on this list is when things either don't work or I don't 
find an answer to some question. So it will be "complaints" in some way 
or another. I think I do provide some solutions too though, although 
some may not be easy to realize or is not likable by everyone.


That there are many "complaints" coming from me now is because I 
currently map *a lot* and mainly nature (which wasn't an original goal 
for OSM but something that has come later, so it's understandable that 
there are issues) and therefore come across many issues which have no 
clear answers. This is a list for tag discussion, strategy and related 
tools. Issues bubble up to here. If I had a clear answer I wouldn't even 
need to post, and there are many of those too (ie where I've found 
working solutions on the wiki or through OSM help). The reason I don't 
have a clear answer is that there is several issues with the current 
approaches, which I described in my post.


If OSM intends to be for all globally, there is a need to consider local 
needs and respect local knowledge, not only consider a feature relevant 
if it is has global spread. Maybe these natural=fell issues are specific 
to Scandinavia (although I think Great Britian has similar), but they 
are real here.


I try to make a case that it would be wise to render natural=fell, and 
describe why. There's a closed issue report on OSM-Carto github about 
this (yes I actually do some research before I post), and my arguments 
were shaped by that thread, to proactively meet what came up there so we 
don't need to have exactly the same discussion all over again.


However, that I have a suggested solution doesn't mean that I'm open to 
other suggestions, maybe an alpine tag for indicating nature above tree 
line for example. I think it's however very difficult and not worthwhile 
to go very specific for our fell habitat, which I also described in the 
original post.


Heath below the tree line is quite easy to identify, as it's surrounded 
by forest. Heath above the tree line is pretty chaotic, speckled with 
bare rock and scree. Hence a generic tag "fell" would suit perfectly 
well, and is already in existence, but it needs rendering in OSM-Carto 
to show mappers that there is backing for this tag.


/Anders

On 2020-12-21 10:12, stevea wrote:

On Dec 20, 2020, at 11:39 PM, Anders Torger  wrote:
I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. I don't think that (somewhat 
randomly) requiring detailed landcover is a good design choice.


Can Anders write anything here without telling OSM that it is broken
and we don't know what we are doing?

Anders, where did you study cartography or get an advanced degree in
design?  Ignoring the question speaks volumes.

I think it would be better to have a defined hierarchy from more 
generic to more specific tags so the map can evolve.


Thank you for your opinion.

Taking the leap to high detail mapping directly makes covering the map 
very slow and sometimes inaccurate.


Maybe.  Again, only maybe.  If you don't like OSM, you are welcome to
not use it.

Fell in particular is in parts so heavily speckled with slightly 
different covers it's hard to even see on the satellite photo what it 
is.


Complain, complain, complain.

You can have say 30% bare rock, 20% scree and 40% heath and 10% 
wetland in an area. So I guess I make that heath then as it's 
dominant? That would however be more misleading than actually setting 
a more generic tag like natural=fell. Forcing detailed mapping where 
this is very difficult to do is not a good idea.


Bleating, bleeeating to this list with little to no
constructive bent to your complaints is not a good idea.

When we get to even higher altitude the growth disappear and we have 
just bare rock and scree so it becomes easier. It can at times be 
quite hard to differ between bare rock or scree though (the resolution 
of the satellite photos in the mountains is often not that great).


I'm beyond thinking that this barrage of "my preferences are the best"
is not that great:  I'm 

Re: [Tagging] natural=fell not rendered, alternatives?

[Andy Townsend]

On 21/12/2020 07:39, Anders Torger wrote:

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more 
specific landcover tags to be used. ...


This isn't really anything to do with tagging, but I can understand why 
some renderers decide not to render it.


Usage, at least where am I, is hugely problematic: 
http://overpass-turbo.eu/s/11nH .


Usage in the Pennines northwest of Leeds is almost exclusively just a 
bunch of names that have been copied from old out-of-copyright NPE 
maps.  The features may be peaks, or patches of moorland, or something 
else again.  If a renderer was to do something with them, it'd probably 
be as "place=locality".


Further west examples like https://www.openstreetmap.org/way/412325588 
correspond better to the wiki definition.  In that example other landuse 
(woodland, heath) is also mapped.


There are also some surprising uses in place of other tags - on 
https://www.openstreetmap.org/way/368051383 it surely means 
"trail_visibility"!


Best Regards,

Andy



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

Re: [Tagging] natural=fell not rendered, alternatives?

[stevea]

On Dec 20, 2020, at 11:39 PM, Anders Torger  wrote:
> I'm doing further mapping of Swedish national parks, now in the mountains, 
> and I have noted that natural=fell (habitat over tree line) is not rendered.
> 
> Looking into why it seems that OSM-Carto implementors want more specific 
> landcover tags to be used. I don't think that (somewhat randomly) requiring 
> detailed landcover is a good design choice.

Can Anders write anything here without telling OSM that it is broken and we 
don't know what we are doing?

Anders, where did you study cartography or get an advanced degree in design?  
Ignoring the question speaks volumes.

> I think it would be better to have a defined hierarchy from more generic to 
> more specific tags so the map can evolve.

Thank you for your opinion.

> Taking the leap to high detail mapping directly makes covering the map very 
> slow and sometimes inaccurate.

Maybe.  Again, only maybe.  If you don't like OSM, you are welcome to not use 
it.

> Fell in particular is in parts so heavily speckled with slightly different 
> covers it's hard to even see on the satellite photo what it is.

Complain, complain, complain.

> You can have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an 
> area. So I guess I make that heath then as it's dominant? That would however 
> be more misleading than actually setting a more generic tag like 
> natural=fell. Forcing detailed mapping where this is very difficult to do is 
> not a good idea.

Bleating, bleeeating to this list with little to no constructive 
bent to your complaints is not a good idea.

> When we get to even higher altitude the growth disappear and we have just 
> bare rock and scree so it becomes easier. It can at times be quite hard to 
> differ between bare rock or scree though (the resolution of the satellite 
> photos in the mountains is often not that great).

I'm beyond thinking that this barrage of "my preferences are the best" is not 
that great:  I'm already there!

> We already have more-generic-to-more-specific landcovers in other areas, you 
> can provide wood without specifying tree type for example, or wetland without 
> specifying type of wetland. (Parenthesis: going from more generic to more 
> specific by adding additional specifying tags is an elegant design, I think 
> it's a bit unfortunate that that design is mixed with a flat tag structure as 
> well, but that's the way it is...).

More than a bit unfortunate are posts by constant complainers.

> It seems like a very odd design choice to require more detailed mapping in 
> alpine areas where this is rather difficult. If we look into how official 
> maps do it in Sweden and Norway they don't have specific landcovers above the 
> tree line, they have just "fell", and in addition significant wetlands, plus 
> waters and streams of course.

It seems like a very odd choice to write to a list with little more than "you 
folks are wrong, why don't you simply do things the way that _I_ want them 
done?"  Even after we (I, others...) politely and patiently engage you, do you 
expect us to keep doing so when it appears you cannot write to this list with 
little more than a litany of complaints?

> Fell indicates where we have bare mountain (above treeline), which is the key 
> information outdoor goers need

Says you.  Others might agree, others disagree, not everybody thinks like you.  
OSM aims to be for all, not just you.

> plus waters and significant wetlands. Anyone that has been to these mountains 
> know that once above the tree line the land cover is quite predictable, it's 
> decided by altitude and steepness.

The reason humans make maps is because nature, the world around us, is always 
changing in some way and is absolutely NOT predictable.  Maps are an 
approximation of reality, not reality.  There is no such thing of value as 
"quite predictable."  The first time something happens that wasn't predicted, 
you'll learn the value of that.

> At the fell altitude contour lines is key information, not if it's a patch of 
> heath or bare rock, which rather just makes a map harder to read without 
> providing valuable information.

I'm pretty sure of one thing:  you are not hard to read.  I see your name in 
the From header and know that I'm about to read someone hostile to OSM who 
can't seem to make even constructive criticism.  It's all rock-throwing, here's 
what's wrong with you and why don't you do things my way?  (Without so much as 
a "please").

> So far I have tagged these areas with natural=fell. I'm thinking about adding 
> bare_rock at high altitude (and scree only when clear and significant), but 
> in the medium altitude where there is growth more detailed mapping becomes 
> very difficult. Heath would be the most natural generic tag for that area, 
> but then we loose the distinction that it's above the tree line, as there 
> already is some heath areas below the tree line. Maybe adding an extra tag 
> like 

[Tagging] natural=fell not rendered, alternatives?

[Anders Torger]

Hello,

I'm doing further mapping of Swedish national parks, now in the 
mountains, and I have noted that natural=fell (habitat over tree line) 
is not rendered.


Looking into why it seems that OSM-Carto implementors want more specific 
landcover tags to be used. I don't think that (somewhat randomly) 
requiring detailed landcover is a good design choice. I think it would 
be better to have a defined hierarchy from more generic to more specific 
tags so the map can evolve. Taking the leap to high detail mapping 
directly makes covering the map very slow and sometimes inaccurate. Fell 
in particular is in parts so heavily speckled with slightly different 
covers it's hard to even see on the satellite photo what it is. You can 
have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an 
area. So I guess I make that heath then as it's dominant? That would 
however be more misleading than actually setting a more generic tag like 
natural=fell. Forcing detailed mapping where this is very difficult to 
do is not a good idea.


When we get to even higher altitude the growth disappear and we have 
just bare rock and scree so it becomes easier. It can at times be quite 
hard to differ between bare rock or scree though (the resolution of the 
satellite photos in the mountains is often not that great).


We already have more-generic-to-more-specific landcovers in other areas, 
you can provide wood without specifying tree type for example, or 
wetland without specifying type of wetland. (Parenthesis: going from 
more generic to more specific by adding additional specifying tags is an 
elegant design, I think it's a bit unfortunate that that design is mixed 
with a flat tag structure as well, but that's the way it is...).


It seems like a very odd design choice to require more detailed mapping 
in alpine areas where this is rather difficult. If we look into how 
official maps do it in Sweden and Norway they don't have specific 
landcovers above the tree line, they have just "fell", and in addition 
significant wetlands, plus waters and streams of course.


Fell indicates where we have bare mountain (above treeline), which is 
the key information outdoor goers need, plus waters and significant 
wetlands. Anyone that has been to these mountains know that once above 
the tree line the land cover is quite predictable, it's decided by 
altitude and steepness. At the fell altitude contour lines is key 
information, not if it's a patch of heath or bare rock, which rather 
just makes a map harder to read without providing valuable information.


So far I have tagged these areas with natural=fell. I'm thinking about 
adding bare_rock at high altitude (and scree only when clear and 
significant), but in the medium altitude where there is growth more 
detailed mapping becomes very difficult. Heath would be the most natural 
generic tag for that area, but then we loose the distinction that it's 
above the tree line, as there already is some heath areas below the tree 
line. Maybe adding an extra tag like "alpine=yes"? I suppose it won't 
render differently from normal heath on any renderer though so we still 
lose the rather significant tree line information in actual maps.


Suggestions are welcome.

/Anders

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

Re: [Tagging] natural=water inside natural=wetland

[Jean-Marc Liotier]

On 5/1/20 12:12 PM, John Willis via Tagging wrote:
There is often overlap where I am where a wetland lives permanently in 
the bottom of a basin, and the surrounding area is a park or sports 
field. When there is a storm the basin fills up and wetland, pitch, 
and parking lot end up under 3m of water for a day or so.


The wetland is not exclusively part of that structure. The basin or 
intermittent reservoir consumes everything inside of it.


[..]

In a lake, some corner of the lake is often a wetland - yet that 
wetland is 100% the part of the lake. It should be layered IMO. That 
could happen for a wetland too, right?


I always thought of the lake as part of the wetland - but now you open 
my mind to the reverse...


What I'm attempting to tag is seasonal Sahelian lakes, the core of which 
is often permanent, surrounded by a humidity gradient of swamp and 
mudflats - often surrounded by vegetable gardens. Indeed, the whole area 
is what is often designated as "lake something"... Would that be the 
correct way or is the lake the water body stricto sensu ?


Then comes the question of of to tag - but that part of the answer I 
guess is multipolygon too.



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

Re: [Tagging] natural=water inside natural=wetland

[John Willis via Tagging]

If you are talking about a simple wetland you may find in a small pond or lake, 
It’s easy, but natural formations are often very messy and complicated - 
especially when a wetland covers an area larger than most villages. 

There is often overlap where I am where a wetland lives permanently in the 
bottom of a basin, and the surrounding area is a park or sports field. When 
there is a storm the basin fills up and wetland, pitch, and parking lot end up 
under 3m of water for a day or so. 

The wetland is not exclusively part of that structure. The basin or 
intermittent reservoir consumes everything inside of it. 

I have 3 basins In my area that are 5KM wide that 363 days a year are wetland, 
sports complexes, airstrips, parks, etc. then a typhoon hits and fills it with 
3m of water for a day or so. 

The structure of the surrounding area still influences the smaller area, like a 
river way going through a giant wetland. 

In a lake, some corner of the lake is often a wetland - yet that wetland is 
100% the part of the lake. It should be layered IMO. That could happen for a 
wetland too, right? 

Maybe I am looking at it in a wrong way. 

A multipolygon might be a good solution for some of these pond in wetland 
situations (like an island in a lake), but won’t there also be some cases with 
water features where the they truly are 2 things in the same space? 

Can it always be validated as “wrong?”  

Javbw

> On May 1, 2020, at 3:36 AM, Andy Townsend  wrote:
> 
> 
>> On 30/04/2020 19:09, Paul Allen wrote:
>> On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging 
>>  wrote:
>> 
>>> There are always going to be edge cases that aren't easy to categorise.  
>>> There's an area just up the road from where I am currently that started out 
>>> as https://www.openstreetmap.org/way/13866095
>> 
>> That's coming up as deleted 6 years ago by Yorvik Prestigitator.  Typo?
>> 
> No - follow the history forward and you'll get to 
> https://www.openstreetmap.org/way/796675406 .  I was doing some tidying up of 
> the fence, woodland and ditches at 
> https://www.openstreetmap.org/changeset/84161134#map=19/54.02644/-0.99852 a 
> few days ago and the object "moved" to a new ID.  For convenience it would 
> have made sense to link to that as well, obviously :)
> 
> Best Regards,
> 
> Andy
> 
> 
> 
> ___
> 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] natural=water inside natural=wetland

[Joseph Eisenberg]

> Vast areas of Australia are used to raise cattle, no tillage yet they are
'used' for farm land. And they are natural scrub...

These areas are considered "rangeland" in North American English. I would
not tag them as landuse=farmland, because they are only lightly touched by
human intervention, in most cases they are natural vegetations which has
always been grazed by various animals (in the past, by American Bison or
Elk, now by sheep or cattle).

I agree that landuse=farmland is mostly limited to cropland: we have other
tags for meadows, pastures, farmyards, orchards, vineyards, etc. - though
certainly there are some meadows or orchards or farmyards that are
currently tagged as landuse=farmland for various reasons. I have not seen
any scrub or semi-desert rangeland tagged as landuse=farmland.

-- Joseph Eisenberg

On Thu, Apr 30, 2020 at 6:58 PM Warin <61sundow...@gmail.com> wrote:

> On 1/5/20 9:14 am, Graeme Fitzpatrick wrote:
>
>
>
>
> On Fri, 1 May 2020 at 01:25, Florian Lohoff  wrote:
>
> I also do consider overlapping natural and landuses to be a bug,
>> either its a natural=scrub or a landuse=farmland. It cant be both.
>>
>
> Sorry, Florian, but why do you say that?
>
> I've seen a lot of farms with scrub on them!
>
>
> And trees used as wind breaks and to provide shelter for animals (both
> 'farm' and 'natural').
>
>
> A problem is the OSM definition may suggest only those areas used for
> tillage are 'farmland'.
>
> Vast areas of Australia are used to raise cattle, no tillage yet they are
> 'used' for farm land. And they are natural scrub...
>
> Some areas are used for both military (a rocket range) and for farming
> (they get bunkers for use when firing takes place!). They are
> natural=scrub/sand/lake (dry salt)/*.
> ___
> 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] natural=water inside natural=wetland

[Warin]

On 1/5/20 9:14 am, Graeme Fitzpatrick wrote:




On Fri, 1 May 2020 at 01:25, Florian Lohoff mailto:f...@zz.de>> 
wrote:


I also do consider overlapping natural and landuses to be a bug,
either its a natural=scrub or a landuse=farmland. It cant be both.


Sorry, Florian, but why do you say that?

I've seen a lot of farms with scrub on them!



And trees used as wind breaks and to provide shelter for animals (both 
'farm' and 'natural').



A problem is the OSM definition may suggest only those areas used for 
tillage are 'farmland'.


Vast areas of Australia are used to raise cattle, no tillage yet they 
are 'used' for farm land. And they are natural scrub...


Some areas are used for both military (a rocket range) and for farming 
(they get bunkers for use when firing takes place!). They are 
natural=scrub/sand/lake (dry salt)/*.


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

Re: [Tagging] natural=water inside natural=wetland

[Graeme Fitzpatrick]

On Fri, 1 May 2020 at 01:25, Florian Lohoff  wrote:

I also do consider overlapping natural and landuses to be a bug,
> either its a natural=scrub or a landuse=farmland. It cant be both.
>

Sorry, Florian, but why do you say that?

I've seen a lot of farms with scrub on them!

Thanks

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

Re: [Tagging] natural=water inside natural=wetland

[Andy Townsend]

On 30/04/2020 19:09, Paul Allen wrote:
On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging 
mailto:tagging@openstreetmap.org>> wrote:


There are always going to be edge cases that aren't easy to
categorise.  There's an area just up the road from where I am
currently that started out as
https://www.openstreetmap.org/way/13866095


That's coming up as deleted 6 years ago by Yorvik Prestigitator.  Typo?

No - follow the history forward and you'll get to 
https://www.openstreetmap.org/way/796675406 .  I was doing some tidying 
up of the fence, woodland and ditches at 
https://www.openstreetmap.org/changeset/84161134#map=19/54.02644/-0.99852 
a few days ago and the object "moved" to a new ID.  For convenience it 
would have made sense to link to that as well, obviously :)


Best Regards,

Andy


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

Re: [Tagging] natural=water inside natural=wetland

[Paul Allen]

On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging <
tagging@openstreetmap.org> wrote:

There are always going to be edge cases that aren't easy to categorise.
> There's an area just up the road from where I am currently that started out
> as https://www.openstreetmap.org/way/13866095
>

That's coming up as deleted 6 years ago by Yorvik Prestigitator.  Typo?

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

Re: [Tagging] natural=water inside natural=wetland

[Andy Townsend via Tagging]

On 30/04/2020 16:29, Joseph Eisenberg wrote:

> wetland area within a forest where trees are growing also within the wetland 
area

That’s a “swamp”: natural=wetland + wetland=swamp

https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dswamp


... or it might be seasonal or intermittent, depending on the weather.

There are always going to be edge cases that aren't easy to categorise.  
There's an area just up the road from where I am currently that started 
out as https://www.openstreetmap.org/way/13866095 in 2007 and has been 
continuously refined ever since.  The main area's mapped as 
natural=heath now (and that's probably as good a bet as any for what 
"most of it" is), but there are areas that are wetter than others and 
areas that are drier; and areas with more trees and areas with fewer 
trees.  There are some permanent ponds but many more "it'll only be wet 
here N months of the year", where N might be anything between 2 and 11.


Any attempt to draw lines between "wood", "wetland" and "water" is a 
compromise, and to me it's perfectly understandably to sometimes have 
those overlapping (though in the example above it is something I've 
tried to avoid).


Best Regards,

Andy


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

Re: [Tagging] natural=water inside natural=wetland

[Joseph Eisenberg]

> wetland area within a forest where trees are growing also within the
wetland area

That’s a “swamp”: natural=wetland + wetland=swamp

https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dswamp

https://en.m.wikipedia.org/wiki/Swamp#Differences_between_marshes_and_swamps
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=water inside natural=wetland

[Florian Lohoff]

On Thu, Apr 30, 2020 at 04:36:31PM +0200, Jean-Marc Liotier wrote:
> Consider a wetland that contains a water body. I'm used to map that as
> natural=water inside natural=wetland - no multipolygon fanciness, just one
> on top of the other. JOSM validator complains about it, which irks me, so I
> opened a ticket at https://josm.openstreetmap.de/ticket/19171 - where mdk
> suggests that I may be doing it wrong...
> 
> Is my simple way incorrect ? It feels correct to me because wetlands are
> complex objects - water bodies are part of them, cross them or partially
> overlap them. From a tagging point of view, it implies that some area is
> both natural=water and natural=wetland - I see no problem with that... But
> others might consider that a logical impossibility.
> 
> So, which is the correct way: plain natural=water inside natural=wetland, or
> a natural=water multipolygon with natural=wetland on its inner ?

I have myself some QA stuff running and i also do consider this a bug.
A squaremeter can either be wetland or open water e.g a pond. So
cant simply layer them.

I also do consider overlapping natural and landuses to be a bug,
either its a natural=scrub or a landuse=farmland. It cant be both.

I agree that there are corner cases where this fails. E.g a pond
in a landuse=residential or landuse=forest. Its still the forest.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=water inside natural=wetland

[Hauke Stieler]

Hi,

I would create a multipolygon for that. Wetland is something different
than a lake/pond.

For wetland the wiki says, that wetland areas contain "characteristic
vegetation that is adapted to its unique soil conditions" [0]. A lake
obviously doesn't (at least no land-vegetation like grass and bushes)
and this is why an area cannot be wetland *and* lake at the same time.
And this is why I consider a multipolygon to be correct.

There might be situations, where two different areas have to be on top
of each other (e.g. a wetland area within a forest where trees are
growing also within the wetland area?), but I thing most of the time
there's only one landuse that fits.

Of course there might be some discussion but I would consider a
multipolygon to be correct in your specific example.

Hauke

[0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland

On 30.04.20 16:36, Jean-Marc Liotier wrote:
> Consider a wetland that contains a water body. I'm used to map that as
> natural=water inside natural=wetland - no multipolygon fanciness, just
> one on top of the other. JOSM validator complains about it, which irks
> me, so I opened a ticket at https://josm.openstreetmap.de/ticket/19171 -
> where mdk suggests that I may be doing it wrong...
> 
> Is my simple way incorrect ? It feels correct to me because wetlands are
> complex objects - water bodies are part of them, cross them or partially
> overlap them. From a tagging point of view, it implies that some area is
> both natural=water and natural=wetland - I see no problem with that...
> But others might consider that a logical impossibility.
> 
> So, which is the correct way: plain natural=water inside
> natural=wetland, or a natural=water multipolygon with natural=wetland on
> its inner ?
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] natural=water inside natural=wetland

[Jean-Marc Liotier]

Consider a wetland that contains a water body. I'm used to map that as 
natural=water inside natural=wetland - no multipolygon fanciness, just 
one on top of the other. JOSM validator complains about it, which irks 
me, so I opened a ticket at https://josm.openstreetmap.de/ticket/19171 - 
where mdk suggests that I may be doing it wrong...


Is my simple way incorrect ? It feels correct to me because wetlands are 
complex objects - water bodies are part of them, cross them or partially 
overlap them. From a tagging point of view, it implies that some area is 
both natural=water and natural=wetland - I see no problem with that... 
But others might consider that a logical impossibility.


So, which is the correct way: plain natural=water inside 
natural=wetland, or a natural=water multipolygon with natural=wetland on 
its inner ?



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

Re: [Tagging] natural=bay on areas

[Martin Koppenhoefer]

sent from a phone

> On 30 Mar 2017, at 22:22, Juan Pablo Tolosa Sanzana  
> wrote:
> 
> Vice versa, the practice is mapping the baseline along the coastline.

in Italy there's a law with actual coordinates for the baseline, but AFAIK we 
are generally using EU data in Europe for the maritime borders (without caring 
about the baseline, there's no tag for it)

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

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

I didn't know about the practice of mapping the coastline along the baseline, 
AFAIK we don't map the baseline, only their 12nm offset (maritime borders)



Vice versa, the practice is mapping the baseline along the coastline. 
But I think this is no a good idea, because baseline extend up a bit 
outside of the coastline, if the baseline runs along the low tide. In 
some places the tidal range is huge.


The example of  Rio de la Plata exposed previously is clearly poorly 
mapped according the definition of natural=coastline. Note that 
according IHO Rio de la Plata is a sea.


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

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

On 30 March 2017 at 07:41, Juan Pablo Tolosa Sanzana
 wrote:
> An exact limit between the open ocean and a sheltered coast is too arbitrary
> as natural feature. It seems a political issue. You can use
> boundary=maritime + border_type=baseline for excluding internal waters from
> the open ocean, according of laws of the country. Check the article
> https://en.wikipedia.org/wiki/Internal_waters

I'm looking to tag natural features as surveyed on the ground, not
political or administrative boundaries. Sure the boundary is fuzzy but
we can still get it close.

On 30 March 2017 at 08:00, Christoph Hormann  wrote:
> No, it is not a political issue, the position of the baseline is not in
> doubt here.  If Andrew wants to indicate the sheltered nature of the
> coast in some way via supplemental tags that seems perfectly fine - as
> long as these tags are documented and verifiable of course.
>
> In any case tagging the bay as natural=bay will already indicate this
> part of the coastline to be of special nature.

Agreed. coastline=pelagic, natural=ria all are potential ways to help here.

For me Botany Bay (http://www.openstreetmap.org/relation/1214649)
isn't part of the open ocean but Bondi Bay
(http://www.openstreetmap.org/node/926183187) is, even though both
offer shelter.

On 30 March 2017 at 18:25, Martin Koppenhoefer  wrote:
>> On 30 Mar 2017, at 01:06, Eugene Alvin Villar  wrote:
>> because UNCLOS allows countries to specify a baseline separate from the 
>> coastline that encloses parts of the sea/ocean (thereby making those parts 
>> internal waters of the country) .
> I thought the baseline was generally separate from the actual coastline. It 
> is an administrative construct, while this thread is about natural features. 
> Internal waters, territorial waters , exclusive sea zones, they're all about 
> political and economical power and benefit, not about natural 
> geologic/geographical configurations.

Exactly. According to https://en.wikipedia.org/wiki/Baseline_(sea),
the baseline political, they are like an administrative boundary.
That's a separate discussion, I'm only talking about natural features
here.

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

Re: [Tagging] natural=bay on areas

[Martin Koppenhoefer]

sent from a phone

> On 30 Mar 2017, at 01:06, Eugene Alvin Villar  wrote:
> 
> because UNCLOS allows countries to specify a baseline separate from the 
> coastline that encloses parts of the sea/ocean (thereby making those parts 
> internal waters of the country) .


I thought the baseline was generally separate from the actual coastline. It is 
an administrative construct, while this thread is about natural features. 
Internal waters, territorial waters , exclusive sea zones, they're all about 
political and economical power and benefit, not about natural 
geologic/geographical configurations.



> 
> If we follow the practice of mapping the coastline along the claimed baseline 
> like in the Rio de la Plata elsewhere in the world, then the Gulf of Sidra in 
> Libya[1] would be considered as an inland waterbody


I didn't know about the practice of mapping the coastline along the baseline, 
AFAIK we don't map the baseline, only their 12nm offset (maritime borders)

cheers,
Martin 



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

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

By default baselines match with mean low water spring, meanwhile 
natural=coastline is tagged at mean high water spring.


It would be good define some rules related to maritime boundaries don't 
agree with UNCLOS, .e.g. peruvian boundary extends up 200 miles away the 
coastline.


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

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

I don't know the Australian baseline, this is only an example. Sometimes 
the countries define a straight baseline that close a bay. Of course, 
Andrew have the freedoom to use, e.g. the tag description=* to do the 
mentioned difference.


> No, it is not a political issue, the position of the baseline is not 
in doubt here. If Andrew wants to indicate the sheltered nature of the 
coast in some way via supplemental tags that seems perfectly fine - as 
long as these tags are documented and verifiable of course.
> In any case tagging the bay as natural=bay will already indicate this 
part of the coastline to be of special nature.



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

Re: [Tagging] natural=bay on areas

[Eugene Alvin Villar]

On Thu, Mar 30, 2017 at 4:41 AM, Juan Pablo Tolosa Sanzana <
jptolosanz...@gmail.com> wrote:

> An exact limit between the open ocean and a sheltered coast is too
> arbitrary as natural feature. It seems a political issue. You can use
> boundary=maritime + border_type=baseline for excluding internal waters from
> the open ocean, according of laws of the country. Check the article
> https://en.wikipedia.org/wiki/Internal_waters
>

Speaking of maritime boundaries and bays and estuaries, the Rio de la Plata
estuary between Argentina and Uruguay is currently modeled in OSM as
*inside* the coastline. If you look at the OSM default carto layer at zoom
5 and lower, where inland waterbodies are not rendered, Montevideo and
Buenos Aires appear to be landlocked inland cities, which doesn't look
right.[1] (See the attached image.) The coastline there follows the UNCLOS
claimed baseline which isn't right because UNCLOS allows countries to
specify a baseline separate from the coastline that encloses parts of the
sea/ocean (thereby making those parts internal waters of the country) when
it meets certain geometric conditions. I think the coastline between
Argentina and Uruguay should include most of the Rio.

If we follow the practice of mapping the coastline along the claimed
baseline like in the Rio de la Plata elsewhere in the world, then the Gulf
of Sidra in Libya[1] would be considered as an inland waterbody, which does
not make sense. Note that the United States have protested as excessive
both the claimed baseline of Libya in the Gulf of Sidra (this resulted in
the Gulf of Sidra incident in 1981) and the joint claimed baseline of
Argentina and Uruguay in the Rio de la Plata.

[1] http://www.openstreetmap.org/#map=5/-35.335/-56.382
[2] http://www.openstreetmap.org/#map=5/31.961/17.249
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Wednesday 29 March 2017, Juan Pablo Tolosa Sanzana wrote:
> An exact limit between the open ocean and a sheltered coast is too
> arbitrary as natural feature. It seems a political issue. [...]

No, it is not a political issue, the position of the baseline is not in 
doubt here.  If Andrew wants to indicate the sheltered nature of the 
coast in some way via supplemental tags that seems perfectly fine - as 
long as these tags are documented and verifiable of course.

In any case tagging the bay as natural=bay will already indicate this 
part of the coastline to be of special nature.

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

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

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

An exact limit between the open ocean and a sheltered coast is too 
arbitrary as natural feature. It seems a political issue. You can use 
boundary=maritime + border_type=baseline for excluding internal waters 
from the open ocean, according of laws of the country. Check the article 
https://en.wikipedia.org/wiki/Internal_waters


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

Re: [Tagging] natural=bay on areas

[Martin Koppenhoefer]

sent from a phone

> On 29 Mar 2017, at 14:00, Andrew Harvey  wrote:
> 
> I'd also like to consider how to tag rias, so we can differentiate
> between a ria and the open ocean.


the tag is natural=ria


cheers,
Martin 




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

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

I've learned a lot from the comments here, based on others comments I
think the solution to my issue is to use a tag like like
coastline=pelagic (from wikipedia "A pelagic coast refers to a coast
which fronts the open ocean, as opposed to a more sheltered coast in a
gulf or bay.") on the oceanic coastline because I'd like separation of
these shorelines within these bays and the coastline facing the open
ocean.

I'd also like to consider how to tag rias, so we can differentiate
between a ria and the open ocean.

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

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

No, I just tagged the edge of the bay as natural=coastline because this 
is the top of the tidal range. Even being more rigorous the 
natural=coastline must be shifted far away towards west of current 
position. The lower part of Georges River is a typical ria: an 
unglaciated valley submerged into the seawater.



El 28/03/17 a las 09:47, Andrew Harvey escribió:

Initially I was concerned that by changing the tagging from
natural=water, water=bay to natural=bay that the whole bay would be
rendered as land since that's what the wiki suggests. I now see that
the same user changed the edges of the bay to be natural=coastline to
prevent this.

I'm agree now that it makes sense for the wiki to not recommend
filling bays as water since a bays is either part of the ocean or part
of some other waterbody like a river, lake, reservoir   etc.). A
natural=bay as an area can share a common boundary with the riverbank
like http://www.openstreetmap.org/way/483211748.

I'm not convinced that the inside here should be tagged as
natural=coastline, as it simply doesn't match the description of what
a coastline is. I think the solution here is to include botany bay and
other bays here as part of a waterbody.

On 28 March 2017 at 00:28, Christoph Hormann  wrote:

On Monday 27 March 2017, Andrew Harvey wrote:

It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
fully

maritime waterbody.

What do you mean by "maritime waterbody"?

A waterbody where plant and animal life matches or is close to that of
the sea rather to that of a river or lake.

I think it's a grey area, it's not completely like a river, nor that
of the sea. But in this case, I'm not sure, what information do you
have that confirms this?


Botany Bay is unlike many conventional bays which are on the
coastline and part of the sea. You're right that these types of bays
are part of the sea and ocean, and other times they are part of a
river, but botany bay is really a river nor sea, if anything Botany
Bay sounds much more like an Esturary.
https://en.wikipedia.org/wiki/Estuary

In OSM we have no separate tagging for estuaries, this would not make
sense because it would just introduce yet another boundary problem
(where the river turns into the esturary and where the esturary turns
into the ocean).  An esturary is the transit of a river into the ocean.

That's exactly what botany bay is, a transit of a river into the ocean.


If you consider the Botany Bay to be part of the esturary of Georges
River you still have to decide where you place the coastline and if you
place it below the bay you have to tag the bay waterway=riverbank or
natural=water + water=river.  Creating a separate waterbody that is not
part of the river but within the coastline is wrong in our current
tagging scheme.

I don't have a problem with waterway=riverbank, as many parts of the
shoreline here are closer to a riverbank than a coastline. That's
probably the best solution here.


Note in general the esturary of Georges River would be considered to
start much further upstream, likely somewhere around here:

https://www.openstreetmap.org/#map=15/-33.9765/151.0237

at the transit from a meandering river to a ria
(https://en.wikipedia.org/wiki/Ria).

Thanks for that link!

On 28 March 2017 at 06:48, Juan Pablo Tolosa Sanzana
 wrote:

A maritime waterbody are all those waters under the influence of the tides.
You can review article for natural=coastline. The coastline should be placed
in the "high water mean spring":
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline

The wiki says "The natural=coastline tag is used to mark the mean high
water spring line along the coastline at the edge of the sea." The
last part is key. The tidal limit is way upstream at
http://www.openstreetmap.org/search?query=-33.9252261917%2C%20150.9283593270#map=15/-33.9252/150.9284
but since the coastline tag is only marking high water mark on the
coast (the boundary between sea and land), it shouldn't be used there.


Botany Bay is part of the ocean, not a separate inland waterbody. You can
see in the terrain the mark of the tides.

So you're saying that anything below the tidal limit is the ocean?


If you swim at a coastal beach you're swimming in the sea and the
ocean. At the beaches of Botany Bay, no one would say you're in the
sea or ocean. Nor would they say you're on the coast of Australia.

This is only a colloquial thing. That lacks of verifiability. For example,
Dead Sea is not a sea, really is a lake.

What's the verifiable thing on the ground which backs up
natural=coastline on the inside of the bay(s)?


Botany Bay is unlike many conventional bays which are on the coastline
and part of the sea. You're right that these types of bays are part of
the sea and ocean, and other times they are part of a river, but
botany bay is really a river nor sea, if anything Botany Bay sounds
much more like an Esturary. https://en.wikipedia.org/wiki/Estuary

The 

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Tuesday 28 March 2017, Andrew Harvey wrote:
> >
> > A waterbody where plant and animal life matches or is close to that
> > of the sea rather to that of a river or lake.
>
> I think it's a grey area, it's not completely like a river, nor that
> of the sea. But in this case, I'm not sure, what information do you
> have that confirms this?

My initial assessment was based on an intuitive look on the water 
balance of the bay - which can be backed up with numbers from here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.575.3453=rep1=pdf

If you do the math you see that the freshwater inflow is insignificant 
compared to the tidal water exchange.

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

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

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

Initially I was concerned that by changing the tagging from
natural=water, water=bay to natural=bay that the whole bay would be
rendered as land since that's what the wiki suggests. I now see that
the same user changed the edges of the bay to be natural=coastline to
prevent this.

I'm agree now that it makes sense for the wiki to not recommend
filling bays as water since a bays is either part of the ocean or part
of some other waterbody like a river, lake, reservoir   etc.). A
natural=bay as an area can share a common boundary with the riverbank
like http://www.openstreetmap.org/way/483211748.

I'm not convinced that the inside here should be tagged as
natural=coastline, as it simply doesn't match the description of what
a coastline is. I think the solution here is to include botany bay and
other bays here as part of a waterbody.

On 28 March 2017 at 00:28, Christoph Hormann  wrote:
> On Monday 27 March 2017, Andrew Harvey wrote:
>> > It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
>> > fully
>>
>> maritime waterbody.
>>
>> What do you mean by "maritime waterbody"?
>
> A waterbody where plant and animal life matches or is close to that of
> the sea rather to that of a river or lake.

I think it's a grey area, it's not completely like a river, nor that
of the sea. But in this case, I'm not sure, what information do you
have that confirms this?

>> Botany Bay is unlike many conventional bays which are on the
>> coastline and part of the sea. You're right that these types of bays
>> are part of the sea and ocean, and other times they are part of a
>> river, but botany bay is really a river nor sea, if anything Botany
>> Bay sounds much more like an Esturary.
>> https://en.wikipedia.org/wiki/Estuary
>
> In OSM we have no separate tagging for estuaries, this would not make
> sense because it would just introduce yet another boundary problem
> (where the river turns into the esturary and where the esturary turns
> into the ocean).  An esturary is the transit of a river into the ocean.

That's exactly what botany bay is, a transit of a river into the ocean.

> If you consider the Botany Bay to be part of the esturary of Georges
> River you still have to decide where you place the coastline and if you
> place it below the bay you have to tag the bay waterway=riverbank or
> natural=water + water=river.  Creating a separate waterbody that is not
> part of the river but within the coastline is wrong in our current
> tagging scheme.

I don't have a problem with waterway=riverbank, as many parts of the
shoreline here are closer to a riverbank than a coastline. That's
probably the best solution here.

> Note in general the esturary of Georges River would be considered to
> start much further upstream, likely somewhere around here:
>
> https://www.openstreetmap.org/#map=15/-33.9765/151.0237
>
> at the transit from a meandering river to a ria
> (https://en.wikipedia.org/wiki/Ria).

Thanks for that link!

On 28 March 2017 at 06:48, Juan Pablo Tolosa Sanzana
 wrote:
> A maritime waterbody are all those waters under the influence of the tides.
> You can review article for natural=coastline. The coastline should be placed
> in the "high water mean spring":
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline

The wiki says "The natural=coastline tag is used to mark the mean high
water spring line along the coastline at the edge of the sea." The
last part is key. The tidal limit is way upstream at
http://www.openstreetmap.org/search?query=-33.9252261917%2C%20150.9283593270#map=15/-33.9252/150.9284
but since the coastline tag is only marking high water mark on the
coast (the boundary between sea and land), it shouldn't be used there.

> Botany Bay is part of the ocean, not a separate inland waterbody. You can
> see in the terrain the mark of the tides.

So you're saying that anything below the tidal limit is the ocean?

>> If you swim at a coastal beach you're swimming in the sea and the
>> ocean. At the beaches of Botany Bay, no one would say you're in the
>> sea or ocean. Nor would they say you're on the coast of Australia.
>
> This is only a colloquial thing. That lacks of verifiability. For example,
> Dead Sea is not a sea, really is a lake.

What's the verifiable thing on the ground which backs up
natural=coastline on the inside of the bay(s)?

>> Botany Bay is unlike many conventional bays which are on the coastline
>> and part of the sea. You're right that these types of bays are part of
>> the sea and ocean, and other times they are part of a river, but
>> botany bay is really a river nor sea, if anything Botany Bay sounds
>> much more like an Esturary. https://en.wikipedia.org/wiki/Estuary
>
> The rules for tagging are in the OSM wiki. Even in Wikipedia says Botany Bay
> is an oceanic bay: https://en.wikipedia.org/wiki/Botany_Bay
> The coastline is a natural feature. You don't mix it with political things.
> You can use the tag boundary=maritime + 

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

El 27/03/17 a las 16:48, Juan Pablo Tolosa Sanzana escribió:

>>/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully /> 
maritime waterbody.
>
> What do you mean by "maritime waterbody"?

A maritime waterbody are all those waters under the influence of the tides. You can 
review article for natural=coastline. The coastline should be placed in the "high 
water mean spring":https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline


> If you're in Botany Bay or the other bays there such as
> https://www.openstreetmap.org/relation/1333569, 
  you're not at sea or

> in the sea, or in the ocean.

Botany Bay is part of the ocean, not a separate inland waterbody. You can see 
in the terrain the mark of the tides.
  
> If you swim at a coastal beach you're swimming in the sea and the

> ocean. At the beaches of Botany Bay, no one would say you're in the
> sea or ocean. Nor would they say you're on the coast of Australia.

This is only a colloquial thing. That lacks of verifiability. For example, Dead 
Sea is not a sea, really is a lake.

> Botany Bay is unlike many conventional bays which are on the coastline
> and part of the sea. You're right that these types of bays are part of
> the sea and ocean, and other times they are part of a river, but
> botany bay is really a river nor sea, if anything Botany Bay sounds
> much more like an Esturary.https://en.wikipedia.org/wiki/Estuary

The rules for tagging are in the OSM wiki. Even in Wikipedia says Botany Bay is 
an oceanic bay:https://en.wikipedia.org/wiki/Botany_Bay
The coastline is a natural feature. You don't mix it with political things. You 
can use the tag boundary=maritime + maritime=base_line to delineate political 
inner waters. Even the boundary runs in the mouth of Botany Bay, therefore is 
respected local things that you mean.
Here there are instructions to tag an 
estuary:https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement


Sorry, in the last paragraph is boundary=maritime + border_type=baseline 
for outer edge of internal waters.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully /> 
maritime waterbody.


What do you mean by "maritime waterbody"?


A maritime waterbody are all those waters under the influence of the tides. You can 
review article for natural=coastline. The coastline should be placed in the "high 
water mean spring": https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline



If you're in Botany Bay or the other bays there such as
> https://www.openstreetmap.org/relation/1333569, 
  you're not at sea or

in the sea, or in the ocean.


Botany Bay is part of the ocean, not a separate inland waterbody. You can see 
in the terrain the mark of the tides.
 

If you swim at a coastal beach you're swimming in the sea and the
ocean. At the beaches of Botany Bay, no one would say you're in the
sea or ocean. Nor would they say you're on the coast of Australia.


This is only a colloquial thing. That lacks of verifiability. For example, Dead 
Sea is not a sea, really is a lake.


Botany Bay is unlike many conventional bays which are on the coastline
and part of the sea. You're right that these types of bays are part of
the sea and ocean, and other times they are part of a river, but
botany bay is really a river nor sea, if anything Botany Bay sounds
much more like an Esturary.https://en.wikipedia.org/wiki/Estuary


The rules for tagging are in the OSM wiki. Even in Wikipedia says Botany Bay is 
an oceanic bay: https://en.wikipedia.org/wiki/Botany_Bay
The coastline is a natural feature. You don't mix it with political things. You 
can use the tag boundary=maritime + maritime=base_line to delineate political 
inner waters. Even the boundary runs in the mouth of Botany Bay, therefore is 
respected local things that you mean.
Here there are instructions to tag an estuary: 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

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

Re: [Tagging] natural=bay on areas

[Kevin Kenny]

I don't think it does to be too fussy about what is 'river' and what is
'sea' and what is 'estuary'.

Near where I live, a hydrologist would classify the Hudson River as
'estuary' as far as http://www.openstreetmap.org/way/90929525 because it
has a measurable tide right up to that point. Nevertheless, it's fresh
water (the salt front is at least 100 km downstream even in a dry summer),
The actual meeting of river (which, by then, is indeed salt) and ocean is
another 100 km downstream from there.

The locals would be astonished if you were to claim that the bank of the
Hudson River is 'seacoast', even if it has a tide and ships of considerable
size can navigate the river as far as the Port of Albany. A hydrologist
would say, "well, technically, that's correct" and the locals would roll
their eyes.

On Mon, Mar 27, 2017 at 10:05 AM, Kevin Kenny 
wrote:

> I don't think it does to be too fussy about what is 'river' and what is
> 'sea' and what is 'estuary'.
>
> Near where I live, a hydrologist would classify the Hudson River as
> 'estuary' as far as http://www.openstreetmap.org/way/90929525 because it
> has a measurable tide right up to that point. Nevertheless, it's fresh
> water (the salt front is at least 100 km downstream even in a dry summer),
> The actual meeting of river (which, by then, is indeed salt) and ocean is
> another 100 km downstream from there.
>
> The locals would be astonished if you were to claim that the bank of the
> Hudson River is 'seacoast', even if it has a tide and ships of considerable
> size can navigate the river as far as the Port of Albany. A hydrologist
> would say, "well, technically, that's correct" and the locals would roll
> their eyes.
>
>
>
> On Mon, Mar 27, 2017 at 9:28 AM, Christoph Hormann  wrote:
>
>> On Monday 27 March 2017, Andrew Harvey wrote:
>> > > It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
>> > > fully
>> >
>> > maritime waterbody.
>> >
>> > What do you mean by "maritime waterbody"?
>>
>> A waterbody where plant and animal life matches or is close to that of
>> the sea rather to that of a river or lake.
>>
>> > Botany Bay is unlike many conventional bays which are on the
>> > coastline and part of the sea. You're right that these types of bays
>> > are part of the sea and ocean, and other times they are part of a
>> > river, but botany bay is really a river nor sea, if anything Botany
>> > Bay sounds much more like an Esturary.
>> > https://en.wikipedia.org/wiki/Estuary
>>
>> In OSM we have no separate tagging for estuaries, this would not make
>> sense because it would just introduce yet another boundary problem
>> (where the river turns into the esturary and where the esturary turns
>> into the ocean).  An esturary is the transit of a river into the ocean.
>> If you consider the Botany Bay to be part of the esturary of Georges
>> River you still have to decide where you place the coastline and if you
>> place it below the bay you have to tag the bay waterway=riverbank or
>> natural=water + water=river.  Creating a separate waterbody that is not
>> part of the river but within the coastline is wrong in our current
>> tagging scheme.
>>
>> Note in general the esturary of Georges River would be considered to
>> start much further upstream, likely somewhere around here:
>>
>> https://www.openstreetmap.org/#map=15/-33.9765/151.0237
>>
>> at the transit from a meandering river to a ria
>> (https://en.wikipedia.org/wiki/Ria).
>>
>> --
>> 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] natural=bay on areas

[Christoph Hormann]

On Monday 27 March 2017, Andrew Harvey wrote:
> > It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
> > fully
>
> maritime waterbody.
>
> What do you mean by "maritime waterbody"?

A waterbody where plant and animal life matches or is close to that of 
the sea rather to that of a river or lake.

> Botany Bay is unlike many conventional bays which are on the
> coastline and part of the sea. You're right that these types of bays
> are part of the sea and ocean, and other times they are part of a
> river, but botany bay is really a river nor sea, if anything Botany
> Bay sounds much more like an Esturary.
> https://en.wikipedia.org/wiki/Estuary

In OSM we have no separate tagging for estuaries, this would not make 
sense because it would just introduce yet another boundary problem 
(where the river turns into the esturary and where the esturary turns 
into the ocean).  An esturary is the transit of a river into the ocean.  
If you consider the Botany Bay to be part of the esturary of Georges 
River you still have to decide where you place the coastline and if you 
place it below the bay you have to tag the bay waterway=riverbank or 
natural=water + water=river.  Creating a separate waterbody that is not 
part of the river but within the coastline is wrong in our current 
tagging scheme.

Note in general the esturary of Georges River would be considered to 
start much further upstream, likely somewhere around here:

https://www.openstreetmap.org/#map=15/-33.9765/151.0237

at the transit from a meandering river to a ria 
(https://en.wikipedia.org/wiki/Ria).

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

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

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

> It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a fully
maritime waterbody.

What do you mean by "maritime waterbody"?

If you're in Botany Bay or the other bays there such as
https://www.openstreetmap.org/relation/1333569, you're not at sea or
in the sea, or in the ocean.

If you swim at a coastal beach you're swimming in the sea and the
ocean. At the beaches of Botany Bay, no one would say you're in the
sea or ocean. Nor would they say you're on the coast of Australia.

Botany Bay is unlike many conventional bays which are on the coastline
and part of the sea. You're right that these types of bays are part of
the sea and ocean, and other times they are part of a river, but
botany bay is really a river nor sea, if anything Botany Bay sounds
much more like an Esturary. https://en.wikipedia.org/wiki/Estuary

On 27 March 2017 at 22:46, Christoph Hormann <o...@imagico.de> wrote:
> On Monday 27 March 2017, Andrew Harvey wrote:
>>
>> What water body is Botany Bay
>> https://en.wikipedia.org/wiki/Botany_Bay part of?
>>
>> I don't think it's right too tag the inside of the bay as coastline.
>> "A coastline or a seashore is the area where land meets the sea or
>> ocean" the inside of the bay isn't the sea, hence the water/land
>> boundary isn't the coastline.
>
> I have had this discussion countless times in other cases and Botany Bay
> is not even a borderline case.
>
> It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a fully
> maritime waterbody.
>
> The only alternative would be to consider it the lowest part of the
> Georges River which would be an extreme stretch considering the size of
> the bay and its connection to the sea compared to the discharge of the
> river.
>
> More elaborate discussion of the matter can be found on the wiki:
>
> http://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
>
> As said a bay is not a separate waterbody in OSM so if you consider
> something a bay you need to decide what it is a bay of.  Tagging
> natural=water + water=bay is always factually wrong (and is also only
> used about 80 times globally).
>
> --
> 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] natural=bay on areas

[Andrew Harvey]

On 27 March 2017 at 21:35, Martin Koppenhoefer  wrote:
> as there's the coastline as well, it shouldn't produce any problem to remove
> natural=water from the bay. We generally don't add natural=water to the sea:
> https://www.openstreetmap.org/way/148455492#map=13/-33.9809/151.2086
> because they're dealt with by the coastline rendering.

The problem is this bay, is not part of the sea or the ocean.

See https://snag.gy/h51wM0.jpg. The blue area is Botany Bay, the red
is the coastline, and the yellow is the sea and ocean.

The coastline shouldn't go on the inside of the bay, as it's not the
coast. Shoreline yes, but the coastline is only on the coast in red.

Outside Botany Bay you have the Tasman Sea.

On 27 March 2017 at 21:51, Christoph Hormann  wrote:
> Bays are by definition parts of waterbodies and not independent
> waterbodies so they should not be tagged natural=water.  The waterbody
> they are part of should of course be tagged either natural=water or be
> outside the coastline if it is a maritime bay (as in this case as
> tagged by https://www.openstreetmap.org/changeset/46829336).

What water body is Botany Bay https://en.wikipedia.org/wiki/Botany_Bay part of?

I don't think it's right too tag the inside of the bay as coastline.
"A coastline or a seashore is the area where land meets the sea or
ocean" the inside of the bay isn't the sea, hence the water/land
boundary isn't the coastline.

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

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Monday 27 March 2017, Andrew Harvey wrote:
> The wiki for natural=bay says "Since bays are generally part of a
> larger waterbody, either a lake or the ocean, they should not be
> rendered in solid color indicating water themselves."
>
> This creates a conflict with a recent change to Botany Bay
> https://www.openstreetmap.org/relation/1214649 in
> https://www.openstreetmap.org/changeset/47138016.
>
> It was changed from natural=water, water=bay to natural=bay. However
> it most definitely should be rendered as water, contrary to the
> advice on the wiki.

Bays are by definition parts of waterbodies and not independent 
waterbodies so they should not be tagged natural=water.  The waterbody 
they are part of should of course be tagged either natural=water or be 
outside the coastline if it is a maritime bay (as in this case as 
tagged by https://www.openstreetmap.org/changeset/46829336).

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

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

Re: [Tagging] natural=bay on areas

[Martin Koppenhoefer]

2017-03-27 12:29 GMT+02:00 Andrew Harvey :

>
> What should we do to fix this? Change the wiki to note that it should
> be rendered as water and fix renders?




as there's the coastline as well, it shouldn't produce any problem to
remove natural=water from the bay. We generally don't add natural=water to
the sea:
https://www.openstreetmap.org/way/148455492#map=13/-33.9809/151.2086
because they're dealt with by the coastline rendering.

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

[Tagging] natural=bay on areas

[Andrew Harvey]

The wiki for natural=bay says "Since bays are generally part of a
larger waterbody, either a lake or the ocean, they should not be
rendered in solid color indicating water themselves."

This creates a conflict with a recent change to Botany Bay
https://www.openstreetmap.org/relation/1214649 in
https://www.openstreetmap.org/changeset/47138016.

It was changed from natural=water, water=bay to natural=bay. However
it most definitely should be rendered as water, contrary to the advice
on the wiki.

What should we do to fix this? Change the wiki to note that it should
be rendered as water and fix renders?

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

[Tagging] natural=river_terrace : open or closed way ? JOSM Validator and OSM wiki disagree

[Jean-Marc Liotier]

I have been tagging a big bunch of natural=river_terrace in eastern
Senegal. The features that I have been tagging are ridges that follow
the course of a river in rocky terrain - not quite a canyon, but more
abrupt than a valley... I could have tagged them as natural=ridge but I
stumbled upon natural=river_terrace and since they are dependent
features of the river I thought it would be more appropriate and
http://wiki.openstreetmap.org/wiki/Tag:natural%3Driver_terrace seems to
agree.
Anyway, I tagged natural=river_terrace on open ways - the same way it is
normally done for natural=ridge. The JOSM Validator doesn't like that:
"natural type river_terrace - Unclosed way". But then, the
http://wiki.openstreetmap.org/wiki/Tag:natural%3Driver_terrace proposal
mentions that natural=river_terrace should not be used on areas - only
on ways.So, which is right ? Open way, closed way or both ?And should
natural=river_terrace even exist or should it be natural=ridge +
ridge=river_terrace ?

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

Re: [Tagging] Tagging natural or historic regions

[Georg Feddern]

Am 28.03.2016 um 08:28 schrieb Martin Koppenhoefer:

Am 27.03.2016 um 21:59 schrieb Colin Smale :

If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons

well, as was proposed above, we could introduce a way to store fuzzy areas 
without using polygons, or by using more than one polygon as one object


May be: Using a minimum (core area) and maximum (extension area) 
estimation as one relation.



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

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 21:59 schrieb Colin Smale :
> 
> If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons


well, as was proposed above, we could introduce a way to store fuzzy areas 
without using polygons, or by using more than one polygon as one object 

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

Re: [Tagging] Tagging natural or historic regions

[Warin]

The precision/accuracy is not only limited by the instruments used but 
also the knowledge used.


For some things OSM has access to very precise data. In other instances 
it is fuzzy. For some things .. the past entries has been much improved 
by new data from other sources  (sometimes opening of government sources)


No mater the precision/accuracy .. is the information 
usefull/informative? That should be the criteria for data entry, not 
its' accuracy/precision. Signifying the accuracy/precision has no formal 
tag .. I usually enter a note if I am concerned, or if I am really 
uncertain and want to wave a flag that it should be fixed .. then a 
fixme tag suits. But I have no objection to 'fuzzy' data ... provided it 
is usefull/informative.


On 28/03/2016 9:59 AM, Dave Swarthout wrote:
This sort of object is common in Thailand. We have many gated 
communities here whose boundaries are not exactly known although they 
are sometimes fairly obvious in aerial imagery because of being 
surrounded by a wall or fence of some sort. I create a polygon using 
Bing imagery, tag it as place=neighbourhood, name=* and add a fixme or 
note tag indicating that the boundary is inexact. Later, if a mapper 
has better data available they can update that boundary.


Most polygons in OSM are simply not precise enough to define the 
property boundaries or even the object's position exactly. Such 
measurements are, practically speaking, beyond the capability of our 
instruments, and we must accept that in our tagging philosophy. 
Obviously, forests and woods, wetlands, and the scrub bordering them 
are not clearly defined. Yet we usually tag them as areas rather than 
nodes so they will show up in a more useful manner on a map.


I see no problem with this whatsoever.

Cheers,
Dave

On Mon, Mar 28, 2016 at 3:40 AM, Clifford Snow 
> wrote:


Fuzzy boundaries do have their place. Currently we use sharp
boundaries for landuse, but often the boundary is really fuzzy. A
wooded area would be a good example of a where a fuzzy boundary
might be employed. But the fuzziness of a wooded area may only be
a few meters. The fuzziness of "Shakespeare Country" is completely
different.

I agree that there are advantages to including fuzzy boundaries,
but we should first document how to tag these features.

On Sun, Mar 27, 2016 at 12:59 PM, Colin Smale
> wrote:

If we can't mark polygons as fuzzy, then we can only allow
'accurate' polygons. Then we are back to square one, with no
way of accommodating these regions except for a simple node.

I think the problem is clear (how do we represent regions
whose boundaries are not precisely defined). Time to talk
about solutions.

The status quo is without any guidelines, possibly leading to
random creativity according to the whim of the mapper concerned.

Another option is to not do it, to say such things have no
place in OSM, and actively reject any attempt to do so (i.e.
if anyone dares to put "Pays de Bray" or "Shakespeare Country"
into OSM, the objects will be deleted and the mapper admonished).

Or we go for the single-node approach, and lose out on any
clues about the extent of the area concerned.

Or we accept "best-guess" polygons with "incremental refinement."

Any offers?

//colin

On 2016-03-27 21:36, Martin Koppenhoefer wrote:




sent from a phone


Am 27.03.2016 um 21:16 schrieb Anders Fougner
>:

Did you already consider a fuzzy tag (such as fuzzy=yes or
boundary_fuzzy=yes)?



that's a makeshift which isn't quite elegant and still has
similar problems (things that seem to be in might be out and
vice versa).


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





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

Re: [Tagging] Tagging natural or historic regions

[Dave Swarthout]

This sort of object is common in Thailand. We have many gated communities
here whose boundaries are not exactly known although they are sometimes
fairly obvious in aerial imagery because of being surrounded by a wall or
fence of some sort. I create a polygon using Bing imagery, tag it as
place=neighbourhood, name=* and add a fixme or note tag indicating that the
boundary is inexact. Later, if a mapper has better data available they can
update that boundary.

Most polygons in OSM are simply not precise enough to define the property
boundaries or even the object's position exactly. Such measurements are,
practically speaking, beyond the capability of our instruments, and we must
accept that in our tagging philosophy. Obviously, forests and woods,
wetlands, and the scrub bordering them are not clearly defined. Yet we
usually tag them as areas rather than nodes so they will show up in a more
useful manner on a map.

I see no problem with this whatsoever.

Cheers,
Dave

On Mon, Mar 28, 2016 at 3:40 AM, Clifford Snow 
wrote:

> Fuzzy boundaries do have their place. Currently we use sharp boundaries
> for landuse, but often the boundary is really fuzzy. A wooded area would be
> a good example of a where a fuzzy boundary might be employed. But the
> fuzziness of a wooded area may only be a few meters. The fuzziness
> of "Shakespeare Country" is completely different.
>
> I agree that there are advantages to including fuzzy boundaries, but we
> should first document how to tag these features.
>
> On Sun, Mar 27, 2016 at 12:59 PM, Colin Smale 
> wrote:
>
>> If we can't mark polygons as fuzzy, then we can only allow 'accurate'
>> polygons. Then we are back to square one, with no way of accommodating
>> these regions except for a simple node.
>>
>> I think the problem is clear (how do we represent regions whose
>> boundaries are not precisely defined). Time to talk about solutions.
>>
>> The status quo is without any guidelines, possibly leading to random
>> creativity according to the whim of the mapper concerned.
>>
>> Another option is to not do it, to say such things have no place in OSM,
>> and actively reject any attempt to do so (i.e. if anyone dares to put "Pays
>> de Bray" or "Shakespeare Country" into OSM, the objects will be deleted and
>> the mapper admonished).
>>
>>
>> Or we go for the single-node approach, and lose out on any clues about
>> the extent of the area concerned.
>>
>> Or we accept "best-guess" polygons with "incremental refinement."
>>
>> Any offers?
>>
>> //colin
>>
>> On 2016-03-27 21:36, Martin Koppenhoefer wrote:
>>
>>
>>
>> sent from a phone
>>
>> Am 27.03.2016 um 21:16 schrieb Anders Fougner :
>>
>> Did you already consider a fuzzy tag (such as fuzzy=yes or
>> boundary_fuzzy=yes)?
>>
>>
>>
>> that's a makeshift which isn't quite elegant and still has similar
>> problems (things that seem to be in might be out and vice versa).
>>
>>
>> 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
>>
>>
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging natural or historic regions

[Clifford Snow]

Fuzzy boundaries do have their place. Currently we use sharp boundaries for
landuse, but often the boundary is really fuzzy. A wooded area would be a
good example of a where a fuzzy boundary might be employed. But the
fuzziness of a wooded area may only be a few meters. The fuzziness
of "Shakespeare Country" is completely different.

I agree that there are advantages to including fuzzy boundaries, but we
should first document how to tag these features.

On Sun, Mar 27, 2016 at 12:59 PM, Colin Smale  wrote:

> If we can't mark polygons as fuzzy, then we can only allow 'accurate'
> polygons. Then we are back to square one, with no way of accommodating
> these regions except for a simple node.
>
> I think the problem is clear (how do we represent regions whose boundaries
> are not precisely defined). Time to talk about solutions.
>
> The status quo is without any guidelines, possibly leading to random
> creativity according to the whim of the mapper concerned.
>
> Another option is to not do it, to say such things have no place in OSM,
> and actively reject any attempt to do so (i.e. if anyone dares to put "Pays
> de Bray" or "Shakespeare Country" into OSM, the objects will be deleted and
> the mapper admonished).
>
>
> Or we go for the single-node approach, and lose out on any clues about the
> extent of the area concerned.
>
> Or we accept "best-guess" polygons with "incremental refinement."
>
> Any offers?
>
> //colin
>
> On 2016-03-27 21:36, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> Am 27.03.2016 um 21:16 schrieb Anders Fougner :
>
> Did you already consider a fuzzy tag (such as fuzzy=yes or
> boundary_fuzzy=yes)?
>
>
>
> that's a makeshift which isn't quite elegant and still has similar
> problems (things that seem to be in might be out and vice versa).
>
>
> 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
>
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging natural or historic regions

[Colin Smale]

If we can't mark polygons as fuzzy, then we can only allow 'accurate'
polygons. Then we are back to square one, with no way of accommodating
these regions except for a simple node. 

I think the problem is clear (how do we represent regions whose
boundaries are not precisely defined). Time to talk about solutions. 

The status quo is without any guidelines, possibly leading to random
creativity according to the whim of the mapper concerned. 

Another option is to not do it, to say such things have no place in OSM,
and actively reject any attempt to do so (i.e. if anyone dares to put
"Pays de Bray" or "Shakespeare Country" into OSM, the objects will be
deleted and the mapper admonished).

Or we go for the single-node approach, and lose out on any clues about
the extent of the area concerned. 

Or we accept "best-guess" polygons with "incremental refinement." 

Any offers? 

//colin 

On 2016-03-27 21:36, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> Am 27.03.2016 um 21:16 schrieb Anders Fougner :
>> 
>> Did you already consider a fuzzy tag (such as fuzzy=yes or 
>> boundary_fuzzy=yes)?
> 
> that's a makeshift which isn't quite elegant and still has similar problems 
> (things that seem to be in might be out and vice versa).
> 
> 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] Tagging natural or historic regions

[Anders Fougner]

Den 27. mars 2016 21.36.01 CEST, skrev Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> Am 27.03.2016 um 21:16 schrieb Anders Fougner
>:
>> 
>> Did you already consider a fuzzy tag (such as fuzzy=yes or
>boundary_fuzzy=yes)?
>
>
>that's a makeshift which isn't quite elegant and still has similar
>problems (things that seem to be in might be out and vice versa).
>
>
>cheers,
>Martin 

It's completely possible to render a name without drawing a border if the 
border is indicated as fuzzy, but still use the approximate size to determine 
which zoom level it should be rendered at. 

You might also render the border in a "fuzzy manner", whatever that means (e.g. 
using a gradient for the transition between areas of different colors). 

Anders 


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

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 21:16 schrieb Anders Fougner :
> 
> Did you already consider a fuzzy tag (such as fuzzy=yes or 
> boundary_fuzzy=yes)?


that's a makeshift which isn't quite elegant and still has similar problems 
(things that seem to be in might be out and vice versa).


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

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 20:50 schrieb Clifford Snow :
> 
> I agree using polygons is far superior to nodes. The question I'm raising is 
> do these fuzzy areas belong in OSM.


agreed, adding fuzzy areas in a way that suggests they are well delimited areas 
(polygons) is questionable, while doing it in a way that preserves/conveyes the 
fuzziness might be easier acceptable.

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

Re: [Tagging] Tagging natural or historic regions

[Anders Fougner]

>I agree using polygons is far superior to nodes. The question I'm
>raising
>is do these fuzzy areas belong in OSM. Using my example for the
>Cascadia
>(Independence Area) a polygon with the boundary could be used to search
>for
>features in the OSM database.
>
>Clifford

Did you already consider a fuzzy tag (such as fuzzy=yes or boundary_fuzzy=yes)? 

Anders 

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

Re: [Tagging] Tagging natural or historic regions

[Clifford Snow]

On Sun, Mar 27, 2016 at 11:20 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

> well, this didn't prevent 12% of mappers to add neighborhoods as areas
> anyway: http://taginfo.osm.org/tags/place=neighbourhood
>

The discussion was around neighborhoods that did not have a clear boundary,
not the majority that have clearly defined boundaries. I believe we should
add neighborhood boundaries that are clearly defined.

>
>
> Tagging large things as nodes clearly lacks important information
> (extent), and it makes nested stuff impossible (or requires relations
> rather than getting it for "free" with implicit spatial hierarchies)
>

I agree using polygons is far superior to nodes. The question I'm raising
is do these fuzzy areas belong in OSM. Using my example for the Cascadia
(Independence Area) a polygon with the boundary could be used to search for
features in the OSM database.

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 19:00 schrieb Mateusz Konieczny :
> 
> Areas with completely undefined borders should not be stored in OSM.


who if not the crowd would be able to iteratively come to approximations of 
these borders. As long as the existence of the area is not disputed all 
together, there will be an approximation for its border.

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

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 18:50 schrieb Clifford Snow :
> 
> A while back one of the conversations on the mailing list was about adding 
> neighborhood boundaries. There was a lot of concern that many neighborhood 
> boundaries are not clearly define which would result in boundary disputes. 
> How is adding a rough boundary for an informal area any different? 


well, this didn't prevent 12% of mappers to add neighborhoods as areas anyway: 
http://taginfo.osm.org/tags/place=neighbourhood

Tagging large things as nodes clearly lacks important information (extent), and 
it makes nested stuff impossible (or requires relations rather than getting it 
for "free" with implicit spatial hierarchies)

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

Re: [Tagging] Tagging natural or historic regions

[Mateusz Konieczny]

On Sun, 27 Mar 2016 19:16:42 +0200
Anders Fougner <anders.foug...@gmail.com> wrote:

> 
> 
> Den 27. mars 2016 19.00.18 CEST, skrev Mateusz Konieczny
> <matkoni...@gmail.com>:
> >On Sun, 27 Mar 2016 09:50:21 -0700
> >Clifford Snow <cliff...@snowandsnow.us> wrote:
> >
> >> On Sun, Mar 27, 2016 at 9:18 AM, Martin Koppenhoefer
> >> <dieterdre...@gmail.com
> >> > wrote:
> >> 
> >> > I agree that a rough polygon seems better than a node because it
> >> > allows to estimate the size (a new relation datatype would even
> >> > be better, like a collection of (existing/already mapped) things
> >> > inside (role) and outside (role) that would serve the same
> >> > purpose but make it clear that it is only an estimate / that
> >> > there aren't clear borders anyway).
> >> >
> >> > I don't like boundary=informal though. It should be something
> >> > more verbose regarding what kind of region this is
> >> > (natural/geographic, (low) mountain range, area of lakes,
> >> > forest, desert, plains, cultural, ethnographic, wine, etc.)
> >> >
> >> 
> >> A while back one of the conversations on the mailing list was about
> >> adding neighborhood boundaries. There was a lot of concern that
> >> many neighborhood boundaries are not clearly define which would
> >> result in boundary disputes. How is adding a rough boundary for an
> >> informal area any different?
> >> 
> >> Worse, if we start adding informal boundaries I can see someone
> >> wanting to add the Cascadia [1] (Independance Movement) boundary.
> >> 
> >> 
> >> 
> >> [1]
> >https://en.wikipedia.org/wiki/Cascadia_%28independence_movement%29
> >> 
> >> Clifford
> >> 
> >
> >Given that idea of tagging natural=bay as polygons is controversial I
> >am not expecting this to be a good idea.
> >
> >Areas with completely undefined borders should not be stored in OSM.
> 
> If I understand correctly what you mean (?), I completely disagree. 
> Maps are really useless if they cannot contain names of such features
> that are hard to define the borders of (bays, cliffs, seas,
> neighborhoods, etc.). Where's the border of e.g. the North Sea, the
> Bay/Gulf of Bothnia, and Skagerrak, and why should they not be on the
> map? (they are probably indicated on every useful map of northern
> Europe or Scandinavia) 

I never said that these should not appear on maps. It is about
unfortunate fact such objects have no clear definitions - I had recent
unfortunate case of somebody expecting clear definition of borders of
Carpathians.

In that case answer strongly depends on who and how defines Carpathians.

For examples see https://en.wikipedia.org/wiki/Carpathian_Mountains
with articles in other languages. Even basic facts like length and list 
of countries where this mountain range is located are different.

OSM is not a proper place to store all possible definitions of "border
of Carpathians" or pretend to have the perfect one.

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

Re: [Tagging] Tagging natural or historic regions

[Anders Fougner]

Den 27. mars 2016 19.00.18 CEST, skrev Mateusz Konieczny <matkoni...@gmail.com>:
>On Sun, 27 Mar 2016 09:50:21 -0700
>Clifford Snow <cliff...@snowandsnow.us> wrote:
>
>> On Sun, Mar 27, 2016 at 9:18 AM, Martin Koppenhoefer
>> <dieterdre...@gmail.com
>> > wrote:
>> 
>> > I agree that a rough polygon seems better than a node because it
>> > allows to estimate the size (a new relation datatype would even be
>> > better, like a collection of (existing/already mapped) things
>> > inside (role) and outside (role) that would serve the same purpose
>> > but make it clear that it is only an estimate / that there aren't
>> > clear borders anyway).
>> >
>> > I don't like boundary=informal though. It should be something more
>> > verbose regarding what kind of region this is (natural/geographic,
>> > (low) mountain range, area of lakes, forest, desert, plains,
>> > cultural, ethnographic, wine, etc.)
>> >
>> 
>> A while back one of the conversations on the mailing list was about
>> adding neighborhood boundaries. There was a lot of concern that many
>> neighborhood boundaries are not clearly define which would result in
>> boundary disputes. How is adding a rough boundary for an informal
>> area any different?
>> 
>> Worse, if we start adding informal boundaries I can see someone
>> wanting to add the Cascadia [1] (Independance Movement) boundary.
>> 
>> 
>> 
>> [1]
>https://en.wikipedia.org/wiki/Cascadia_%28independence_movement%29
>> 
>> Clifford
>> 
>
>Given that idea of tagging natural=bay as polygons is controversial I
>am not expecting this to be a good idea.
>
>Areas with completely undefined borders should not be stored in OSM.

If I understand correctly what you mean (?), I completely disagree. 
Maps are really useless if they cannot contain names of such features that are 
hard to define the borders of (bays, cliffs, seas, neighborhoods, etc.).
Where's the border of e.g. the North Sea, the Bay/Gulf of Bothnia, and 
Skagerrak, and why should they not be on the map? (they are probably indicated 
on every useful map of northern Europe or Scandinavia) 

Anders 

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

Re: [Tagging] Tagging natural or historic regions

[Mateusz Konieczny]

On Sun, 27 Mar 2016 09:50:21 -0700
Clifford Snow <cliff...@snowandsnow.us> wrote:

> On Sun, Mar 27, 2016 at 9:18 AM, Martin Koppenhoefer
> <dieterdre...@gmail.com
> > wrote:
> 
> > I agree that a rough polygon seems better than a node because it
> > allows to estimate the size (a new relation datatype would even be
> > better, like a collection of (existing/already mapped) things
> > inside (role) and outside (role) that would serve the same purpose
> > but make it clear that it is only an estimate / that there aren't
> > clear borders anyway).
> >
> > I don't like boundary=informal though. It should be something more
> > verbose regarding what kind of region this is (natural/geographic,
> > (low) mountain range, area of lakes, forest, desert, plains,
> > cultural, ethnographic, wine, etc.)
> >
> 
> A while back one of the conversations on the mailing list was about
> adding neighborhood boundaries. There was a lot of concern that many
> neighborhood boundaries are not clearly define which would result in
> boundary disputes. How is adding a rough boundary for an informal
> area any different?
> 
> Worse, if we start adding informal boundaries I can see someone
> wanting to add the Cascadia [1] (Independance Movement) boundary.
> 
> 
> 
> [1] https://en.wikipedia.org/wiki/Cascadia_%28independence_movement%29
> 
> Clifford
> 

Given that idea of tagging natural=bay as polygons is controversial I
am not expecting this to be a good idea.

Areas with completely undefined borders should not be stored in OSM.

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

Re: [Tagging] Tagging natural or historic regions

[Clifford Snow]

On Sun, Mar 27, 2016 at 9:18 AM, Martin Koppenhoefer  wrote:

> I agree that a rough polygon seems better than a node because it allows to
> estimate the size (a new relation datatype would even be better, like a
> collection of (existing/already mapped) things inside (role) and outside
> (role) that would serve the same purpose but make it clear that it is only
> an estimate / that there aren't clear borders anyway).
>
> I don't like boundary=informal though. It should be something more verbose
> regarding what kind of region this is (natural/geographic, (low) mountain
> range, area of lakes, forest, desert, plains, cultural, ethnographic, wine,
> etc.)
>

A while back one of the conversations on the mailing list was about adding
neighborhood boundaries. There was a lot of concern that many neighborhood
boundaries are not clearly define which would result in boundary disputes.
How is adding a rough boundary for an informal area any different?

Worse, if we start adding informal boundaries I can see someone wanting to
add the Cascadia [1] (Independance Movement) boundary.



[1] https://en.wikipedia.org/wiki/Cascadia_%28independence_movement%29

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging natural or historic regions

[Martin Koppenhoefer]

sent from a phone

> Am 27.03.2016 um 11:47 schrieb Colin Smale :
> 
> In the UK the word "country" is also used in that context, for example 
> "Shakespeare Country", "White Cliffs Country", "Black Country".
> 
> I would suggest a relation with type=boundary and boundary=informal, plus an 
> indication of the accuracy/authority of the border like source=guesswork, or 
> signs, or local authority brochures, ..
> 


I agree that a rough polygon seems better than a node because it allows to 
estimate the size (a new relation datatype would even be better, like a 
collection of (existing/already mapped) things inside (role) and outside (role) 
that would serve the same purpose but make it clear that it is only an estimate 
/ that there aren't clear borders anyway).

I don't like boundary=informal though. It should be something more verbose 
regarding what kind of region this is (natural/geographic, (low) mountain 
range, area of lakes, forest, desert, plains, cultural, ethnographic, wine, 
etc.)

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

Re: [Tagging] Tagging natural or historic regions

[Christoph Hormann]

On Sunday 27 March 2016, David Marchal wrote:
> Hello, there.
> At least here, in France, there are numerous regions, whose unity is
> based either on a common historical background, for example as a
> medieval county or duchy like the Barrois, or on a uniform natural
> landscape, as the Bauges mountains or the Mont Blanc massif.

For mountain areas there has been some use of

place=region + region:type=mountain_area

Much of this data is however somewhat questionable due to lack of 
verifiability (exception being the Alps where there are fairly well 
established conventions of the boundaries of the subdivisions).

In principle infering approximate extents from mountain areas mapped as 
nodes based on relief data is often possible.

An alternative and possibly more specific and intuitive way of defining 
mountain areas could be mapping them as relations containing all peaks 
of these areas.

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

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

Re: [Tagging] Tagging natural or historic regions

[Colin Smale]

Good question. 

In the UK the word "country" is also used in that context, for example
"Shakespeare Country", "White Cliffs Country", "Black Country". 

As to whether a node or a polygon should be used... Personally I would
prefer an approximate polygon to a node. A node may indicate location,
but it conveys no sense of the size and shape of the area. In many cases
the local government is proud enough of these areas to put up signs on
the roads saying "You are now entering ..." or "Welcome to ..." and
these could be used as points in a first-order approximation of the
extent. 

I would suggest a relation with type=boundary and boundary=informal,
plus an indication of the accuracy/authority of the border like
source=guesswork, or signs, or local authority brochures, .. 

//colin 

On 2016-03-27 11:08, David Marchal wrote:

> Hello, there. 
> 
> At least here, in France, there are numerous regions, whose unity is based 
> either on a common historical background, for example as a medieval county or 
> duchy like the Barrois, or on a uniform natural landscape, as the Bauges 
> mountains or the Mont Blanc massif. These regions are often called "pays" in 
> French, but it should not be understood as a nation, and the regions I'm 
> talking about do not always have an administrative representations, being 
> often known only as a traditionally-named area. 
> 
> Whatever, how to map such regions? I asked on a French forum, but it seems 
> that the issue has not really been addressed, at least not from our point of 
> view, but there may be an existing tagging scheme for that, as I see no 
> reason for this issue being culturally restricted to our country. I assume 
> that, as there areas do not always have clearly defined borders, they should 
> be tagged as a single node, but, still, how to map them? 
> 
> Awaiting your answers, 
> 
> Regards. 
> ___
> 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] Tagging natural or historic regions

[David Marchal]

Hello, there.
At least here, in France, there are numerous regions, whose unity is based 
either on a common historical background, for example as a medieval county or 
duchy like the Barrois, or on a uniform natural landscape, as the Bauges 
mountains or the Mont Blanc massif. These regions are often called "pays" in 
French, but it should not be understood as a nation, and the regions I'm 
talking about do not always have an administrative representations, being often 
known only as a traditionally-named area.
Whatever, how to map such regions? I asked on a French forum, but it seems that 
the issue has not really been addressed, at least not from our point of view, 
but there may be an existing tagging scheme for that, as I see no reason for 
this issue being culturally restricted to our country. I assume that, as there 
areas do not always have clearly defined borders, they should be tagged as a 
single node, but, still, how to map them?
Awaiting your answers,
Regards.  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=wood status=approved?

[Tobias Knerr]

Am 07.02.2016 19:03, schrieb Martin Koppenhoefer:
> I'm not very familiar with how the proposed templates work (which ones are 
> actually in use) but it doesn't seem as if defacto was a valid status now: 
> http://wiki.openstreetmap.org/w/index.php?title=Template:Proposal_Status

The status "defacto" does not exist for proposals (as it implies the
absence of a proposal). It does, however, exist for keys and tags:
http://wiki.openstreetmap.org/wiki/Template:ValueDescription

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

Re: [Tagging] natural=wood status=approved?

[Martin Koppenhoefer]

sent from a phone

> Am 06.02.2016 um 22:43 schrieb Warin <61sundow...@gmail.com>:
> 
> The key 'natural' was marked status approved in 2014 ... nothing on the tag 
> list


I'm participating in OSM since early 2008 and can assure you that natural=wood 
already was an established tag by that time, but also that wiki documentation 
was very scarce back then.


> 
> So ... what is the point of having an approval process if it is circumvented 
> by simple wiki edits?


+1, generally yes, in this particular case I'd say that setting the wiki docu 
to approved seems consistent with the actual usage reality.

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

Re: [Tagging] natural=wood status=approved?

[Martin Koppenhoefer]

sent from a phone

> Am 07.02.2016 um 17:51 schrieb Tobias Knerr :
> 
> The "approved" setting isn't about usage reality, though, but about the
> proposal process. As this tag has, as far as I know, never been formally
> approved (not that it needs to), "defacto" would be preferable.


yes, you're right of course, but in 2014 there wasn't any "defacto" status yet 
AFAIK

I'm not very familiar with how the proposed templates work (which ones are 
actually in use) but it doesn't seem as if defacto was a valid status now: 
http://wiki.openstreetmap.org/w/index.php?title=Template:Proposal_Status


cheers 
Martin 



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

Re: [Tagging] natural=wood status=approved?

[Tobias Knerr]

Am 07.02.2016 09:20, schrieb Martin Koppenhoefer:
> in this particular case I'd say that setting the wiki docu to approved seems 
> consistent with the atual usage reality.

The "approved" setting isn't about usage reality, though, but about the
proposal process. As this tag has, as far as I know, never been formally
approved (not that it needs to), "defacto" would be preferable.

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

Re: [Tagging] natural=wood status=approved?

[Warin]

On 7/02/2016 3:22 AM, Lauri Kytömaa wrote:

On Thu, Feb 4, 2016 Warin wrote:

  The wiki page for natural=wood has the status shown as 'approved'.
This was set to 'approved' on 20th May 2010.

Many major basic tags were included in a list written in I-believe-it-was
2006, i.e. on the original Map Features page. The tag status templates,
tagging list, and even the idea of proposed features was conceived
later than many basic tags that just about everybody uses. FWIW,
before the tagging list existed, the discussion on new tags took place
on the "talk" list.


I did 'look' on the talk list archive too ... for some 4 months previous to the 
change... two authors with 'wood' .. but no subjects with 'wood'.

The key 'natural' was marked status approved in 2014 ... nothing on the tag 
list ...
and that is after the tagging list and approval process were established by 
some years...

It does appear that the status being set to 'approved' does not necessarily 
mean that it ;

a) pre-dates the approval process

or

b) has been approved by the tagging list

So ... what is the point of having an approval process if it is circumvented by 
simple wiki edits?


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

Re: [Tagging] natural=wood status=approved?

[Lauri Kytömaa]

On Thu, Feb 4, 2016 Warin wrote:
>  The wiki page for natural=wood has the status shown as 'approved'.
> This was set to 'approved' on 20th May 2010.

Many major basic tags were included in a list written in I-believe-it-was
2006, i.e. on the original Map Features page. The tag status templates,
tagging list, and even the idea of proposed features was conceived
later than many basic tags that just about everybody uses. FWIW,
before the tagging list existed, the discussion on new tags took place
on the "talk" list.

-- 
alv

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

Re: [Tagging] natural=ridge vs natural=arete

[Martin Koppenhoefer]

2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at:

 This discussion comes late. Both natural=ridge and natural=arete have been
 approved by voting just 2 years ago.



arguably it is not too late, there are only 450 uses of arete by now (and
17K+ ridges). Please also note that the tag natural=arete was formally
rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete
)

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

Re: [Tagging] natural=ridge vs natural=arete

[Richard Z.]

On Wed, Nov 05, 2014 at 10:01:47AM +0100, Martin Koppenhoefer wrote:
 2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at:
 
  This discussion comes late. Both natural=ridge and natural=arete have been
  approved by voting just 2 years ago.
 
 
 
 arguably it is not too late, there are only 450 uses of arete by now (and
 17K+ ridges). Please also note that the tag natural=arete was formally
 rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete
 )

after two years in the wiki where it was marked as approved and active it 
would not appear as a great idea to declare the vote for invalid based on
nitpicking formalities, how many votes were missing for approval?

Would be better to make a new proposal including details of a transition path.

Another reason I don't like current arete/ridge state is that some ridges are
very long - and they may be partially arete and ridge in different segments.
Having a way that is tagged partially as natural=ridge and partially as 
natural=arete seems like a bad idea.

Richard




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

Re: [Tagging] natural=ridge vs natural=arete

[Martin Koppenhoefer]

2014-11-05 12:23 GMT+01:00 Richard Z. ricoz@gmail.com:

 after two years in the wiki where it was marked as approved and active it
 would not appear as a great idea to declare the vote for invalid based on
 nitpicking formalities, how many votes were missing for approval?



it was 50% missing (5 people)



Another reason I don't like current arete/ridge state is that some ridges
 are
 very long - and they may be partially arete and ridge in different
 segments.



you can split them ;-)


Having a way that is tagged partially as natural=ridge and partially as
 natural=arete seems like a bad idea.




it won't be a way, it will be several ways.

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

Re: [Tagging] natural=ridge vs natural=arete

[Friedrich Volkmann]

On 05.11.2014 10:01, Martin Koppenhoefer wrote:

 arguably it is not too late, there are only 450 uses of arete by now (and
 17K+ ridges).

450 uses are quite a lot for a feature that is constantly ignored by renderers.

For the same reason, I suppose that some of the 17K+ ridges were created by
imports.

 Please also note that the tag natural=arete was formally
 rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete )

http://wiki.openstreetmap.org/wiki/Proposal_process#Voting:
A rule of thumb for enough support is 8 unanimous approval votes or 15
total votes with a majority approval

It got 10 unanimous approval votes, which is obviously even better than 8.
Therefore, it clearly was approved. And, by the way, there was more than
enough time for critics to object.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] natural=ridge vs natural=arete

[Friedrich Volkmann]

On 05.11.2014 12:23, Richard Z. wrote:
 Another reason I don't like current arete/ridge state is that some ridges are
 very long - and they may be partially arete and ridge in different segments.
 Having a way that is tagged partially as natural=ridge and partially as 
 natural=arete seems like a bad idea.

Subtags make it even worse, because they require to split the way a couple
of times. Most renderers label every part separately; and whenever someone
searches for the ridge name, Nominatim will deliver multiple parts instead
of the whole ridge.

Therefore, it's better to tag the name on one long way, and you may make it
natural=ridge and add some additional and nameless natural=arete where you
want renderers to display arete signatures (i.e. double sided cliffs).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] natural=ridge vs natural=arete

[Mateusz Konieczny]

This doesn't matter in this particular case, because natural=ridge and
natural=arete were approved at the same time.


It is about futureproof solution - new values may appear and break existing
data consumers. Adding subtags would not cause problems like this.

That's why we have a wiki with descriptions.

Is is better to have general tags that are usable without checking wikis.
Also, definition of arete is fuzzy by itself (see post by Alan Trick Most
of the things that the Wikipedia refers to as aretes are coloquially
called ridges here)

Your argumentation is based on practical issues, but essentially your
considerations are merely theoretical.

No, I am using OSM data in two projects
- map of cycleway-related data, currently in planning stages
( https://github.com/mkoniecz/bicycle_map_of_Krakow )
- contributing to Default style
( https://github.com/gravitystorm/openstreetmap-carto/ )

I can assure you that cascading tag scheme is way easier to support,
at least in my opinion.


2014-11-06 6:38 GMT+01:00 Friedrich Volkmann b...@volki.at:

 On 05.11.2014 07:19, Mateusz Konieczny wrote:
  And it is not just because with the second solution new values
  for main tag will quickly appear (see building=*).

 This doesn't matter in this particular case, because natural=ridge and
 natural=arete were approved at the same time.

  With second
  scheme there is much smaller pool of people that really understand how
  main_tag should be processed and tagged.
 
  For example I have enough general knowledge to implement support for
  natural=ridge (everybody knows what it means), but with natural=arete it
  would require at least some learning about specialist terms. Currently I
  have no idea is this tag is even correctly spelled - Wikipedia defines
 arete
  as term meaning virtue or excellence. - and ridge related article
 is
  titled arête. I also have not enough knowledge to decide whatever
  something is ridge or arête, is it clear term or something fuzzy.

 That's why we have a wiki with descriptions. When you find a description
 fuzzy or misleading, please improve it.

  Yes, I can learn about it - but I worry about the same happening for more
  things. I am NOT interested in learning about how to recognize different
  different power tower types, I want to tag just power=tower and leave
  further classification to power enthusiast that will use subkeys so
  rendering power towers on my map will be easy to implement.

 Your argumentation is based on practical issues, but essentially your
 considerations are merely theoretical.

 As a data consumer, e.g. when you want to render power towers in a 1:25000
 map, you are well advised to have a look at the subtags. Maybe there are
 power tower types which represent power towers so small and unimportant
 that
 you find it better to omit those on your 1:25000 map.

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

 ___
 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] natural=ridge vs natural=arete

[Richard Z.]

Hi,

following some discussions on github (1) and talk-at (2) I have tried
to clarify the definition of natural=ridge in the wiki
  
http://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dridgediff=1104725oldid=998905

Not sure if this is good enough, personaly I would prefer a single ridge 
key with additional subkeys denoting properties such as gentle,sharp, cliff
ridges.

1. https://github.com/gravitystorm/openstreetmap-carto/issues/1097
2. https://lists.openstreetmap.org/pipermail/talk-at/2014-November/007058.html

Richard

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

Re: [Tagging] natural=ridge vs natural=arete

[Mateusz Konieczny]

I think that natural=arete should be rather subtag of natural=ridge
(natural=ridge; ridge=arete).
It is opening way for next specialized tags - what will make using data
significantly harder.

2014-11-04 13:58 GMT+01:00 Richard Z. ricoz@gmail.com:

 Hi,

 following some discussions on github (1) and talk-at (2) I have tried
 to clarify the definition of natural=ridge in the wiki

 http://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dridgediff=1104725oldid=998905

 Not sure if this is good enough, personaly I would prefer a single ridge
 key with additional subkeys denoting properties such as gentle,sharp, cliff
 ridges.

 1. https://github.com/gravitystorm/openstreetmap-carto/issues/1097
 2.
 https://lists.openstreetmap.org/pipermail/talk-at/2014-November/007058.html

 Richard

 ___
 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] natural=ridge vs natural=arete

[Martin Koppenhoefer]

2014-11-04 13:58 GMT+01:00 Richard Z. ricoz@gmail.com:

 personaly I would prefer a single ridge
 key with additional subkeys denoting properties such as gentle,sharp, cliff
 ridges.



+1
or the subkey variant Mateusz has offered.

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

Re: [Tagging] natural=ridge vs natural=arete

[Friedrich Volkmann]

On 04.11.2014 14:04, Mateusz Konieczny wrote:
 I think that natural=arete should be rather subtag of natural=ridge
 (natural=ridge; ridge=arete).

This discussion comes late. Both natural=ridge and natural=arete have been
approved by voting just 2 years ago. And I think that there's nothing wrong
with them. Whether to use subtags is mainly a matter of taste.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] natural=ridge vs natural=arete

[Mateusz Konieczny]

Whether to use subtags is mainly a matter of taste.

No. Lets say that there is something with four main values that are
noticeable for general public and several subtypes, important for
specialists.

For data consumers interested in just four values version with subtags
is vastly easier to use cascading tagging scheme.

main_tag=first_value
main_tag=second_value
main_tag=third_value
main_tag=fourth_value

with subkeys, ignored by this general purpose renderer
first_value=a
first_value=b
(...)
fourth_value=z

Scheme with placing everything into main tag is much harder to support:

main_tag=a
main_tag=b
main_tag=c
(...)
main_tag=z

And it is not just because with the second solution new values
for main tag will quickly appear (see building=*). With second
scheme there is much smaller pool of people that really understand how
main_tag should be processed and tagged.

For example I have enough general knowledge to implement support for
natural=ridge (everybody knows what it means), but with natural=arete it
would require at least some learning about specialist terms. Currently I
have no idea is this tag is even correctly spelled - Wikipedia defines
arete
as term meaning virtue or excellence. - and ridge related article is
titled arête. I also have not enough knowledge to decide whatever
something is ridge or arête, is it clear term or something fuzzy.

Yes, I can learn about it - but I worry about the same happening for more
things. I am NOT interested in learning about how to recognize different
different power tower types, I want to tag just power=tower and leave
further classification to power enthusiast that will use subkeys so
rendering power towers on my map will be easy to implement.

On the other hand I am interested in cycling infrastructure and tag it to
absurd detail. But I am using

[amenity=bicycle_parking; bicycle_parking=stands]
[amenity=bicycle_parking; bicycle_parking=wall_loops]
not
[amenity=bicycle_stands]
[amenity=wall_loops]

-

[oneway=yes; oneway:bicycle=no]
not
[oneway=yes;bicycle:no]

And yes, I am considering usability of oneway=yes;bicycle:no
and natural=arete as similar. natural=arete in fact is even worse
as in the first case everything starting from ; sign may be
safely dropped what allows adding new details without breaking
more general rendering, and once somebody changed natural=ridge
to natural=overly_specific_value it is impossible to recover
information that it is ridge, without manually adding support to new tags.

So I will tag ridges as natural=ridge (also arêtes and other subtypes),
I will not use natural=arete as user of OSM data and I consider existence
of this tag as a really poor idea.

Maybe it is matter of taste but I have yet to see arguments why flat
tagging
is superior.

2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at:

 On 04.11.2014 14:04, Mateusz Konieczny wrote:
  I think that natural=arete should be rather subtag of natural=ridge
  (natural=ridge; ridge=arete).

 This discussion comes late. Both natural=ridge and natural=arete have been
 approved by voting just 2 years ago. And I think that there's nothing wrong
 with them. Whether to use subtags is mainly a matter of taste.

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

 ___
 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] natural=bay as nodes are evil

[Marc Gemis]

Could we try an example to see whether mappers agree on bay areas ? could
you draw the Gulf of Biscay on a map ?

This guy did it :
http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.jpg

I might have extended it a bit further to the west on the Spanish coast...

regards

m

On Wed, Oct 29, 2014 at 6:12 PM, moltonel 3x Combo molto...@gmail.com
wrote:

 On 29/10/2014, Richard Z. ricoz@gmail.com wrote:
  On Tue, Oct 28, 2014 at 05:21:06PM +0100, moltonel 3x Combo wrote:
  On 28/10/2014, Richard Z. ricoz@gmail.com wrote:
  well even if the issues were nonexistent, mapping the area of a bay seems
  to me like mapping an artificially introduced concept for which there is
  very little real world use or recognition otherwise.

 Huh ? Forget about maps and osm for a moment. A bay is a body of
 water mostly surrounded by land. You're in a bay, not at a bay.
 It has a size, it's not a point in space with a buoy marking the spot.
 It's an area.

 The fact that a lot of sources have simplified it down to a point is
 an entirely different issue. But there's no reason that, with modern
 tools and manpower, we can't make a better job than those historical
 sources. And remember that when you see a rendered bay label, you
 don't actually know wether the source (wether it's some vector data or
 an idea in the sailor's brain) was an area or a point to begin with.

  Also bays with very
  flat or deep geometry will result in disproportionately small areas so
  mappers may feel compelled to do some ugly workarounds if the name of the
  bay isn't shown as expected.

 Disproportionate compared to what ? And fairly flat coastlines are a
 good example of cases that are tricky for algorythms, where the human
 mapper can probably make a better decision.

  So I would say
  * if there is some other reason valid to map the bay as area, do it

 pros:
  - bays are areas in real life
  - it makes geocoding trivial
  - it makes knowing which bays to render preferably easy (bigger bays
 first)
  - it enables representing nested bays
  - it is deterministic, as opposed to relying on a heuristic algorythm
 cons:
  - relations are harder to work with than nodes
  - the extent of bays is usually fuzzy; nodes make that fuzzyness obvious
  - most of the existing data (osm and potential imports) are nodes

 YMMV, those are reasons enough for me.

  * something better needs to be invented for hinting the renderer.

 It's not just the renderer, I actually think that the geocoding
 usacase is more important. And geocoding requires an area, wether it
 is provided in readily-usable form as osm data, or by a
 heuristics-based algorythm that infers it from a node.

 ___
 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] natural=bay as nodes are evil

[Bryce Nesbitt]

A lot of the bay points were imported.
Many bays do not have firm boundaries.

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

Re: [Tagging] natural=bay as nodes are evil

[Richard Z.]

On Thu, Oct 30, 2014 at 08:41:18AM +0100, Marc Gemis wrote:
 Could we try an example to see whether mappers agree on bay areas ? could
 you draw the Gulf of Biscay on a map ?
 
 This guy did it :
 http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.jpg
 
 I might have extended it a bit further to the west on the Spanish coast...

note that the big bodies of water such as the bay of biscay have been defined
by the international hydropgraphic organization, wikipedia provides the link.

Those definitions should be probably mapped, but most likely with a special tag 
rather than our natural=bay because their definition of gulf of mexico is 
obviously 
not compatible with our definition of bay (refering to the sentence fragment 
in Cuba, 
through this island to the meridian of 83°W which includes a landmas to the
definition)

Richard

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

Re: [Tagging] natural=bay as nodes are evil

[Michael Kugelmann]

On 30.10.2014 12:51, Richard Z. wrote:

their definition of gulf of mexico is obviously
not compatible with our definition of bay
IMHO: this has some similarities to definition of regions like the 
Alps or the Rocky Mountains...



Cheers,
Michael.


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

Re: [Tagging] natural=bay as nodes are evil

[Ilpo Järvinen]

On Thu, 30 Oct 2014, Marc Gemis wrote:

 Could we try an example to see whether mappers agree on bay areas ? could
 you draw the Gulf of Biscay on a map ?
 This guy did it: 
 http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4
 /s1600/Golf+van+Biskaje.jpg 
 I might have extended it a bit further to the west on the Spanish coast...

Would it be possible that locals around that region of the coastline would 
know it better than tagging@ ? ...If so, then the usual argument for OSM 
taking advantage of mappers' local knowledge applies also here and we 
should defer determining that boundary point more accurately to a local 
mapper.


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

Re: [Tagging] natural=bay as nodes are evil

[Brad Neuhauser]

I think this appears to be the reference Richard mentioned:
http://www.iho-ohi.net/iho_pubs/standard/S-23/S23_1953.pdf

On Thu, Oct 30, 2014 at 6:51 AM, Richard Z. ricoz@gmail.com wrote:

 On Thu, Oct 30, 2014 at 08:41:18AM +0100, Marc Gemis wrote:
  Could we try an example to see whether mappers agree on bay areas ? could
  you draw the Gulf of Biscay on a map ?
 
  This guy did it :
 
 http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.jpg
 
  I might have extended it a bit further to the west on the Spanish
 coast...

 note that the big bodies of water such as the bay of biscay have been
 defined
 by the international hydropgraphic organization, wikipedia provides the
 link.

 Those definitions should be probably mapped, but most likely with a
 special tag
 rather than our natural=bay because their definition of gulf of mexico is
 obviously
 not compatible with our definition of bay (refering to the sentence
 fragment in Cuba,
 through this island to the meridian of 83°W which includes a landmas to
 the
 definition)

 Richard

 ___
 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] natural=bay as nodes are evil

[Richard Z.]

On Tue, Oct 28, 2014 at 05:21:06PM +0100, moltonel 3x Combo wrote:
 On 28/10/2014, Richard Z. ricoz@gmail.com wrote:
  On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote:
  2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com:
 
  The assumption is that a large bay will typically be more important than a
  smaller bay. For a good rendering you'd show only the more important bay
  names in medium zoom level and show the less important ones in higher zoom
  levels. You would use the size to decide which name to omit in case you'd
  not have space to render all of them.
 
  so to decide which label should be bigger or rendered at lower zoom level
  you would suggest to:
  * map bays as areas, with all previously mentioned issues
 
 The issues are real, but we disagree on how big they are. I'm of the
 opinion that they aren't worth fussing over, but YMMV.
 

well even if the issues were nonexistent, mapping the area of a bay seems 
to me like mapping an artificially introduced concept for which there is 
very little real world use or recognition otherwise. Also bays with very 
flat or deep geometry will result in disproportionately small areas so
mappers may feel compelled to do some ugly workarounds if the name of the
bay isn't shown as expected.

So I would say
* if there is some other reason valid to map the bay as area, do it
* something better needs to be invented for hinting the renderer.

Richard




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

Re: [Tagging] natural=bay as nodes are evil

[Martin Koppenhoefer]

2014-10-29 14:40 GMT+01:00 Richard Z. ricoz@gmail.com:

 Also bays with very
 flat or deep geometry will result in disproportionately small areas so
 mappers may feel compelled to do some ugly workarounds if the name of the
 bay isn't shown as expected.




disproportionate to what? water depth really doesn't matter at all in this
context (IMHO)

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

Re: [Tagging] natural=bay as nodes are evil

[Janko Mihelić]

2014-10-29 14:46 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:


 2014-10-29 14:40 GMT+01:00 Richard Z. ricoz@gmail.com:

 Also bays with very
 flat or deep geometry will result in disproportionately small areas so
 mappers may feel compelled to do some ugly workarounds if the name of the
 bay isn't shown as expected.


 disproportionate to what? water depth really doesn't matter at all in this
 context (IMHO)


I think he was talking about bay shapes:

http://i.imgur.com/AMigrSf.png


What if we mapped bays on coastlines, and then the renderer can connect the
ending points with a straight line or a curve. And we can combine that with
a node which can be something like place=country (a rendering hint).

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

Re: [Tagging] natural=bay as nodes are evil

[moltonel 3x Combo]

On 28/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
 On Tuesday 28 October 2014, moltonel 3x Combo wrote:
 I admit I don't fully understand how your algorythm works. I can't
 imagine how you reduce everything to nodes and still retain
 information about orientation and curves. Can you change your
 rendering to display the infered polygons instead of the name ?

 I do not infer any areas, i just generate curves (splines) based on the
 nodes and the surrounding coastlines and place the text along them.

Hum, so that's only usable for label rendering, not geocoding :/

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