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

[Anders Torger]

Impressive work!

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


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


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


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


/Anders

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


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

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


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


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

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

[Anders Torger]

Some more points after a night's sleep:

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


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


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


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


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


/Anders

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

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


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

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

[stevea]

Fascinating thread, fascinating activities it seems to have given rise to!  I 
applaud this dialog as I enjoy it.

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


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

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

[Ture Pålsson via Tagging]

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

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

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

Re: [Tagging] Changes to clarify the Hazards proposal during the vote

[Graeme Fitzpatrick]

Thanks Brian.

As far as I am concerned, those changes are fine.

Graeme


On Tue, 15 Dec 2020 at 10:53, Brian M. Sperlongano 
wrote:

> Hello,
>
> I recently received late feedback on the hazards proposal.  Based on the
> feedback, I felt it was necessary to make small changes to this proposal.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ture Pålsson via Tagging]

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

After having slept on it, make that

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

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

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

[Graeme Fitzpatrick]

On Mon, 14 Dec 2020 at 21:41, Frederik Ramm  wrote:

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


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

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


Why is that a problem?

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

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

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


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

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

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


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

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

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


Does it have to be outside?

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


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

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

Thanks

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Graeme Fitzpatrick]

On Mon, 14 Dec 2020 at 21:28, Paul Allen  wrote:

> I can't think of an English term, other than "holiday cottages."  These
> places
> generally call themselves "Foo Holiday Cottages" or "Foo Holidays" or
> "Foo Farm Cottages" or things like that.
>

I'm with Paul for Holiday Cottages.

How about tagging the whole area as tourism=chalet + name=Foo Cottages +
capacity=25
then tagging each individual cottage / cabin as either
building=cabin / bungalow + name=xxx?

https://wiki.openstreetmap.org/wiki/Tag:building%3Dcabin

https://wiki.openstreetmap.org/wiki/Tag:building%3Dbungalow

Thanks

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

[Tagging] Changes to clarify the Hazards proposal during the vote

[Brian M. Sperlongano]

Hello,

I recently received late feedback on the hazards proposal.  Based on the
feedback, I felt it was necessary to make small changes to this proposal.
I believe these changes are sufficiently minor that they do not invalidate
the voting which has occurred so far.  Since this proposal has begun voting
as of two days ago, I want to ensure that this change is made with full
transparency.  If anyone feels that these changes require a reset of
voting, or an extension of the voting period, I will do so upon request.

The changes are as follows:

1. Clarify that "bump" and "dip" hazards may apply to both artificial and
naturally-occuring dips.  This ensures that the definition of these two
tags are consistent with how those signs are actually used in the real
world, and also ensures that the definitions are consistent with the signs
shown in the sample images.  In addition, a sentence was added to
specifically clarify that this tag should not be applied to traffic control
devices, which have their own tagging.

2. Clarify that it is acceptable to tag both a hazard sign as well as a
hazard itself.  While both of these usages were listed as individually
acceptable, the proposal was silent on whether both approaches might be
used in tandem.

The exact changes to the proposal can be found here:

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2Fhazard=revision=2072737=2072735
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[Brian M. Sperlongano]

On Mon, Dec 14, 2020 at 5:11 PM François Lacombe 
wrote:

> Hi Brian,
>
> Thank you for your comments
>
> Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano 
> a écrit :
>
>> 1. The proposal states "It is proposed to discourage the use of
>> undocumented pump:type=* to state pump mechanisms in favour of new
>> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
>> context.  Given the other threads today regarding reservoirs, it is
>> important to communicate clearly what we mean when we propose to stop using
>> a tag.  I would ask that instead of "discourage", that the proposal should
>> explicitly say "deprecate" so that there is no confusion that you intend
>> for us to stop using pump:type and document it as deprecated in the
>> deprecated features list.  Otherwise, I would ask that you clearly and
>> explicitly state what you mean by "discourage" and where those words of
>> discouragement would go.
>>
>
> To me, discourage means provide a better way to describe features and
> encourage people to do so. Reviewing a proposal and vote approval is a step
> and additional work has to be done in that way.
> I remember a discussion in my early OSM years about sense of "deprecated",
> "discouraged", "approved", "reviewed"... and I'm now merely in favour of
> encouraging and discouraging than enforcing or forbidding
> pump:type isn't documented currently, then how could it be added to any
> deprecated features list?
> The proposal aims to make pump_mechanism approved and then pump:type could
> be added to its wiki page as a possible duplicate.
>

Thanks for the clarification, however it does not quite resolve the
question.  That there is no such status "discouraged".  There is a page
that documents the possible status values[2] used by wiki templates.  To
directly answer your question, since there is no wiki page for the tag (as
in this case), it would be deprecated simply by adding it to the deprecated
features table with no additional action needed.

The wiki[1] says: "OpenStreetMap does not have 'banned features', as
anybody is allowed and encouraged to use any tag they think is useful."
Therefore, deprecating a feature does not "enforce or forbid" the use of a
tag - all it does is set the tag's status to deprecated on the tag's wiki
page, and adds an entry to the deprecated features[1] page.

If you are not proposing to deprecate the pump:type tag, then I think you
need to explain what you mean by "discourage".  Does that mean you will add
a disclaimer to some other wiki page, with a link to the proposal?  I'm not
sure what benefit that brings over simply deprecating the tag.

[1] https://wiki.openstreetmap.org/wiki/Deprecated_features
[2]
https://wiki.openstreetmap.org/wiki/Template:Description/doc#Additional_information
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Brian M. Sperlongano]

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

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

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

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

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

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

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

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[François Lacombe]

Hi Volker

Le lun. 14 déc. 2020 à 06:58, Volker Schmidt  a écrit :

> My main point got lost: the proposal should explain how the mapping of
> pumps in pumping stations should be handled, short of using indoor mapping,
> especially as your cover photo shows an indoors pump in an industrial
> building.
>

Sorry I didn't got your point

I've added a section about pumping stations here
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Pumping_stations

Best regards

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

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

[François Lacombe]

Hi Brian,

Thank you for your comments

Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano  a
écrit :

> 1. The proposal states "It is proposed to discourage the use of
> undocumented pump:type=* to state pump mechanisms in favour of new
> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
> context.  Given the other threads today regarding reservoirs, it is
> important to communicate clearly what we mean when we propose to stop using
> a tag.  I would ask that instead of "discourage", that the proposal should
> explicitly say "deprecate" so that there is no confusion that you intend
> for us to stop using pump:type and document it as deprecated in the
> deprecated features list.  Otherwise, I would ask that you clearly and
> explicitly state what you mean by "discourage" and where those words of
> discouragement would go.
>

To me, discourage means provide a better way to describe features and
encourage people to do so. Reviewing a proposal and vote approval is a step
and additional work has to be done in that way.
I remember a discussion in my early OSM years about sense of "deprecated",
"discouraged", "approved", "reviewed"... and I'm now merely in favour of
encouraging and discouraging than enforcing or forbidding
pump:type isn't documented currently, then how could it be added to any
deprecated features list?
The proposal aims to make pump_mechanism approved and then pump:type could
be added to its wiki page as a possible duplicate.

Furthermore, :type suffixes make things complex and don't bring any
additional information as anything is a type or category of something here.
Any opportunity to move them to simpler key should be used.


> 2.  You propose to deprecate man_made=pumping_rig and propose to replace
> it with the (far more popular) man_made=petroleum_well.  Both of these are
> combined with the substance=* key.  I would ask whether there are usages of
> pumping_rig that are being used with substance=* tags for non-petroleum
> products (i.e. not oil/natural gas) which would be lost by abandoning this
> pumping_rig?  If the answer is "yes", then I would support simply changing
> the description of pumping_rig to explicitly exclude petroleum products,
> and if the answer is "no" then I agree with deprecating it.
>

I've updated to proposal to include man_made=water_well if the pumping rig
was intended to get water from ground and i'm not aware of other usage than
petroleum or water currently.
It seems that no information would be lost from such a manual replacement.

By the way, we had a short discussion here about replacing
man_made=petroleum_well and man_made=water_well with a more generic value
for any well to be combined with substance=* to state what the well is
intended for.
As always it's hard to replace widely used tags, but it would improve
semantics and enable to distinguish wells for hot water and geothermal
plants.

All the best

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

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

[Anders Torger]

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

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


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


/Anders

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

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


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


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

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

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


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

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

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


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



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


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

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

[Anders Torger]

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


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


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


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


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


/Anders

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

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


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


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


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


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


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


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


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


-- Joseph Eisenberg

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



Anders Torger  hat am 14.12.2020 15:49 geschrieben:

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

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


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

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

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

[Mateusz Konieczny via Tagging]

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

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

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

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

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Jmapb]

On 12/14/2020 3:11 PM, Paul Allen wrote:


I'd expect a motel to be set up to handle very short duration (one or two
day) at very short notice (turn up and ask for a room) and to offer
meals unless there are diners/restaurants nearby...



Take a look at https://www.canllefaes.com/
 and note the
requirement that occupancy start/end on a Saturday,
that the cottages have kitchens, etc., and tell me if
that fits into your model of a motel with distributed
cabins.


No indeed it does not. I would be uncomfortable using the tourism=motel
tag on any establishment with a minimum week stay, kitchens or no. Even
a 2-night minimum at a motel would wrinkle my brow.

For Canllefaes, I'd be happy enough with leisure=resort.

(By the way, I would generally *not* expect a motel to offer food beyond
coffee and packaged snacks, though many of them share a parking lot with
a restaurant or fast food.)

J

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

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

[Anders Torger]

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


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


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


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


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


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


/Anders

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

Anders Torger  hat am 14.12.2020 15:49 geschrieben:

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

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


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

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

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

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 20:38, Joseph Eisenberg 
wrote:

> I suppose we also lack a way to distinguish extended-stay hotels which are
> designed for 1 week to multi-month stays;
>
> https://en.wikipedia.org/wiki/Apartment_hotel
>

If it's a single building, maybe it's still a hotel.  Maybe some refining
tags could be added.  Maybe it needs a new value.  Maybe it's not
even tourism.

Things always end up being complicated.  The only way the extended stay
hotel could get more complicated is if it was composed of distributed
cabins.

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

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

[Joseph Eisenberg]

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

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

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

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

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

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

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

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

-- Joseph Eisenberg

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

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Joseph Eisenberg]

I suppose we also lack a way to distinguish extended-stay hotels which are
designed for 1 week to multi-month stays;

https://en.wikipedia.org/wiki/Apartment_hotel

" There are currently 27 extended stay chains in North America with at
least 7 hotels, representing over 2,000 properties.[*citation needed
*] There is
substantial variation among extended stay hotels with respect to quality
and the amenities available. Some of the economy chains attract clientele
who use the hotels as semi-permanent lodging. Extended-stay hotels
typically have self-serve laundry facilities and offer discounts for
extended stays, beginning at 5 or 7 days. They also have guestrooms (or
"suites") with kitchens. The kitchens include at a minimum usually: a sink,
a refrigerator (usually full size), a microwave oven, and a stovetop. Some
kitchens also have dishwashers and conventional ovens. Extended stay hotels
are aimed at business travelers on extended assignments, families in the
midst of a relocation, and others in need of temporary housing."

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 12:14 PM Paul Allen  wrote:

> On Mon, 14 Dec 2020 at 19:41, Jmapb  wrote:
>
>>
>> At least In the rural USA, there's a continuum between motels that have
>> an array of rentable rooms in one or two buildings and those where each
>> room is an individual cabin, or sometimes half of a duplex cabin. It's
>> common to see motels offering both styles of accommodation.
>>
>
> I don't think tourism=chalet fits that distributed motel cabin model.
>
> I'd expect a motel to be set up to handle very short duration (one or two
> day) at very short notice (turn up and ask for a room) and to offer
> meals unless there are diners/restaurants nearby.  Groups of
> holiday cottages are generally longer duration (minimum one week
> except by special arrangement) and generally longer notice
> (usually months, although there may be last-minute deals
> if they have a cancellation).  Holiday cottages are self-catering.
> You can go to a restaurant or diner but you have fairly
> comprehensive cooking facilities (more than just a microwave).
>
> I know that there are blurry edges to everything, but I can't
> fit a group of holiday cottages into my mental model of a hotel.
> Take a look at https://www.canllefaes.com/ and note the
> requirement that occupancy start/end on a Saturday,
> that the cottages have kitchens, etc., and tell me if
> that fits into your model of a motel with distributed
> cabins.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

On Mon, 14 Dec 2020 at 19:41, Jmapb  wrote:

>
> At least In the rural USA, there's a continuum between motels that have
> an array of rentable rooms in one or two buildings and those where each
> room is an individual cabin, or sometimes half of a duplex cabin. It's
> common to see motels offering both styles of accommodation.
>

I don't think tourism=chalet fits that distributed motel cabin model.

I'd expect a motel to be set up to handle very short duration (one or two
day) at very short notice (turn up and ask for a room) and to offer
meals unless there are diners/restaurants nearby.  Groups of
holiday cottages are generally longer duration (minimum one week
except by special arrangement) and generally longer notice
(usually months, although there may be last-minute deals
if they have a cancellation).  Holiday cottages are self-catering.
You can go to a restaurant or diner but you have fairly
comprehensive cooking facilities (more than just a microwave).

I know that there are blurry edges to everything, but I can't
fit a group of holiday cottages into my mental model of a hotel.
Take a look at https://www.canllefaes.com/ and note the
requirement that occupancy start/end on a Saturday,
that the cottages have kitchens, etc., and tell me if
that fits into your model of a motel with distributed
cabins.

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Jmapb]

I've been using tourism=motel for these, if there are no other features
that would tip them into leisure=resort.

At least In the rural USA, there's a continuum between motels that have
an array of rentable rooms in one or two buildings and those where each
room is an individual cabin, or sometimes half of a duplex cabin. It's
common to see motels offering both styles of accommodation.

Jason


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

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

[Christoph Hormann]

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

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

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

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

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

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

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

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

[Ture Pålsson via Tagging]

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

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

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

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

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

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

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

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



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

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

[Anders Torger]

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

Anders Torger  hat am 14.12.2020 14:01 geschrieben:

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


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


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


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

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



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


I think you have a pretty fundamental misunderstanding here.


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


/Anders

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

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

[Anders Torger]

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


About fuzzy areas:

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


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


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


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


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


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


/Anders

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

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


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


Note that this is not "tagging 

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

[Christoph Hormann]

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

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

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

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

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

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

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

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

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

[Anders Torger]

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


/Anders

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

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

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

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

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

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

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

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

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

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

/Anders

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

Anders Torger  hat am 14.12.2020 07:59 geschrieben:


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

the critique instead of wrapping it in a question.


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

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

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

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


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


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

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

[Brian M. Sperlongano]

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

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

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

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

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

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

[Anders Torger]

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


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


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

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


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


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


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


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


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


/Anders

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

Anders Torger  hat am 14.12.2020 07:59 geschrieben:


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


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

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

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

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


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

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

[Christoph Hormann]

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

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

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

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

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

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

[Anders Torger]

Hello Frederik,

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


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


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


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


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


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


/Anders

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

Hi,

On 14.12.20 12:20, Anders Torger wrote:

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


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

peak, this protected tree, this lake.

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

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

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

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

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

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

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

Bye
Frederik


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

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

[Frederik Ramm]

Hi,

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

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

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

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

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

Bye
Frederik

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

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

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

So my questions are: what is the UK (or English in general) word for
> location with group
> of holiday cottages?
>

I can't think of an English term, other than "holiday cottages."  These
places
generally call themselves "Foo Holiday Cottages" or "Foo Holidays" or
"Foo Farm Cottages" or things like that.


> Especially group of them in a fenced area, with shared amenities
>

There isn't anything I can think of, other than holiday cottages (plural).

such as restaurant/cafeteria,
>

Far too grandiose.  For starters, the whole idea of holiday cottages is
that they are self-catering.  A restaurant or cafeteria is something
you'd find at a resort.  Occasionally I've seen a farm conversion
which has a B and a couple of holiday cottages where the
B could provide meals by special arrangement, but that's
rare.


> firepit,
>

Firepit, barbeque, swimming pool, fishing pond are all things I've
seen with a group of holiday cottages.


> maybe sauna or lake access.
>

I've not seen a sauna.  A couple of hot tubs (we don't have a good
official way to tag them as the wiki recommendation of Jacuzzi is
a registered trademark).  I'd say a sauna is highly unusual for
holiday cottages in the UK, but might be common in Nordic
countries.

>
> But without extensive entertainment infrastructure that would qualify for
> leisure=resort.
>

Also without the restaurant/cafe you suggested.

>
> Would it be a good idea to revert this two edits and fully restore
> recommendation
> to use tourism=chalet for group of chalets?
>

I would say it's a bad idea for tourism=chalet to apply to both
individual holiday cottages and to groupings.  It makes it harder
to figure out how many there are.  A building tagged with it might
be an individual holiday cottage but I've seen a long barn converted
to three holiday cottages.  A number of buildings within an outline
might all be holiday cottages or a couple of holiday cottages and a
couple of farm buildings.

Or maybe we need a new tag?
>

I think we need a new tag.  Either a boundary or a relation.

Note also that there may be hybrids.  Just as we've come to the
realization that caravan parks may allow some tents and camping
grounds may allow some caravans, some farms offer holiday cottages
and camping.  It gets messy.

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

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

[Anders Torger]

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


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


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


/Anders

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


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

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

Why is the relation problematic (honest question)?

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


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


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


/Anders

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

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

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


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

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

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


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

verify it by survey.

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

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


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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Mateusz Konieczny via Tagging]

Dec 14, 2020, 10:07 by marius...@gmail.com:

> On 14.12.2020 07:19, Mateusz Konieczny via Tagging wrote:
>
>>
>> There are cases where there is group of multiple holiday cottages,
>>
>> each rentable independently. I know about cases with just 2 and big groups, 
>> 25 in one place.
>>
>> How it should be tagged?
>>
>> I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
>> that is for a single one.
>>
>
> There is an old edit error present on this page. The "This could apply to 
> nodes (single chalet) or areas (a group of chalets)." is incorrectly placed 
> in "Tags used in combination" instead of "How to map" chapter.
>
> See the old version, just before "Tags used in combination"" was added - > 
> https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=1296833
>
I fixed this edit.

I spotted two more:
https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=prev=1448037
https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=prev=1249899

that discouraged using this tag for group of them.

So my questions are: what is the UK (or English in general) word for location 
with group
of holiday cottages? Especially group of them in a fenced area, with shared 
amenities 
such as restaurant/cafeteria, firepit, maybe sauna or lake access.

But without extensive entertainment infrastructure that would qualify for 
leisure=resort.

Would it be a good idea to revert this two edits and fully restore 
recommendation
to use tourism=chalet for group of chalets?

Or maybe we need a new tag?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

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


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

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

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

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

[Anders Torger]

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


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

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


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


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


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


/Anders

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

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


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

It's located in Muddus national park, Sweden.

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


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


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


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


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

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


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


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

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

[Anders Torger]

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


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

It's located in Muddus national park, Sweden.

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


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


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


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


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


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


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


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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Martin Koppenhoefer]

sent from a phone

> On 14. Dec 2020, at 09:46, Paul Allen  wrote:
> 
> Yes, that's for one.  But there is nothing for a group,  Operator on each
> ties them together loosely, but it would be nice to have a relation or
> a boundary for them that could be rendered as a name for the grouping,
> would have a link to the web site for the whole enterprise, etc.  It would
> also make the operator name findable with Nominatim.


type=group?

Cheers Martin 

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Mariusz]

On 14.12.2020 07:19, Mateusz Konieczny via Tagging wrote:


There are cases where there is group of multiple holiday cottages,

each rentable independently. I know about cases with just 2 and big 
groups, 25 in one place.


How it should be tagged?

I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
that is for a single one.


There is an old edit error present on this page. The "This could apply 
to nodes (single chalet) or areas (a group of chalets)." is incorrectly 
placed in "Tags used in combination" instead of "How to map" chapter.


See the old version, just before "Tags used in combination"" was added - 
https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dchalet=1296833


---
Mariusz



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

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

[Ture Pålsson via Tagging]

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

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


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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Paul Allen]

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

> There are cases where there is group of multiple holiday cottages,
> each rentable independently. I know about cases with just 2 and big
> groups, 25 in one place.
>

I know many of those.  It happens around here when a farmer decides it's
more profitable to farm humans than animals so converts outbuildings
to holiday cottages.  Sometimes with names reflecting their former
usage (The Barn, The Dairy, etc).

> How it should be tagged?
> I found https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
> that is for a single one.
>

Yes, that's for one.  But there is nothing for a group,  Operator on each
ties them together loosely, but it would be nice to have a relation or
a boundary for them that could be rendered as a name for the grouping,
would have a link to the web site for the whole enterprise, etc.  It would
also make the operator name findable with Nominatim.

>
> Tagging 25 tourism=chalet independently is sill when they form
> single object, not 25 separate ones.
>

I would still tag them independently, so that people can see which building
is Chestnut Cottage, Oak Cottage, etc.  Also so as to distinguish holiday
cottages from unconverted farm buildings (some of the farms around
here still operate as farms but have converted only two or three of
many farm buildings).  But mappers could leave the buildings untagged
if they were unsure or didn't want to put too much time into it.

If we go for a relation rather than a boundary there would be a need for
other
roles. Some places have a playground, or a games building, or a common
building for laundry, or a soccer pitch, or a barbeque area, or a swimming
pool, or
a miniature railway (yes, I've mapped a miniature railway at a group of
holiday
cottages), etc.

leisure=resort doesn't fit.  At least not as it's described in the wiki.
There may be no other recreational features at all, just accommodation.
If there are recreational features they are (usually) only for those
staying at the accommodation and not available to the general
public.

In some ways the concept resembles a small static caravan park
but with buildings rather than static caravans.

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

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2020, at 21:37, stevea  wrote:
> 
> This is problematic to my thinking.  In California (my state), at an 
> UNCONTROLLED intersection (no traffic_signal, stop sign, other traffic 
> control device...), for example where the sidewalk "would continue to another 
> sidewalk on the other side of the roadway," pedestrians ALWAYS have the 
> right-of-way (over all vehicles) when they indicate it.  How do they indicate 
> it?  By lifting one foot to step towards / into the intersection (from the 
> sidewalk).  Drivers must (by law) stop short of entering the intersection to 
> allow the pedestrian to cross, once a pedestrian has so entered the crossing 
> (even it if is unmarked or "invisible").



the same for Italy and Germany 


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