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

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

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


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


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


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


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


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


Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

2020-12-15 Thread Graeme Fitzpatrick
On Wed, 16 Dec 2020 at 14:51, Andrew Harvey 
wrote:

>
> Personally I'd usually try to add the operator and operator:wikidata tags
> in combination to give more context.
>

Thanks - I never think of wikidata tags as I don't usually use them.

Added

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


Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

2020-12-15 Thread Andrew Harvey
Looks good to me.

Personally I'd usually try to add the operator and operator:wikidata tags
in combination to give more context.

On Wed, 16 Dec 2020 at 13:47, Graeme Fitzpatrick 
wrote:

>
> On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
> wrote:
>
>> Please visit https://wiki.openstreetmap.org/wiki/Rescue_Stations & have
>> a look.
>>
>
> Reminder that voting is close to opening on this proposal.
>
> *Precis:*
>
> Amend the heading emergency=other_stations to emergency=rescue_stations /
> rescue_services (still in two minds about this one?)
>
> Under that heading, introduce new, or define existing, tags for various
> rescue services:
>
> emergency =
> disaster_response
> 
>
> emergency =
> marine_rescue
> 
>
> emergency =mine_rescue
> 
>
> emergency =
> mountain_rescue
> 
>
> Deprecate:
>
>- emergency =
>ses_station
>
>- emergency_service
>
> 
>=technical
>
>- amenity =
>rescue_station
>
>
>
> So far, there have been very few comments, so if there is anything you'd
> like to bring up about the idea, please do so, either here or on the talk
> page.
>
> Thanks
>
> Graeme
>
> ___
> 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] destination:ref with direction?

2020-12-15 Thread Skyler Hawthorne
I've seen a few examples in both New York and California put in the tags of 
on-ramps the destination:ref that has the direction in it, e.g.: 
https://www.openstreetmap.org/way/5566969

However, after looking through the wiki, to my surprise, I cannot find this 
practice mentioned anywhere. It made sense to me when I saw it because how else 
is GPS navigation supposed to tell you which highway to get onto? But I don't 
see it mentioned anywhere, and in fact, the only thing the wiki page on Highway 
Directions in the United States mentions is putting the direction on the ways 
of the actual freeway.

Is this practice incorrect?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Graeme Fitzpatrick
On Wed, 16 Dec 2020 at 09:32, Brian M. Sperlongano 
wrote:

>
> Would this be satisfactory to the group in resolving the question of
> reservoir tagging?
>

Good idea to bring it up, but not sure it will resolve anything once & for
all?

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?

2020-12-15 Thread Graeme Fitzpatrick
On Tue, 15 Dec 2020 at 23:55, Paul Allen  wrote:

>
> 1) Holiday cottages are rarely building=cabin, they are mostly
> building=house.
>

May depend on where you are? I know of a number of places that advertise
cottages / cabins eg http://lyrebirdspringbrook.com/index.html

One around the corner from me is a former house
> that has been converted to a holiday let.  Even the ones on farms
> are converted stone barns, converted stone stables, etc.
>

Shouldn't they then stay as their original type of building? From the
buildings page:  the value may be used to classify the type of building.
Note that it may be not the same as the building's current use (tagged
using building:use =*).
For example, a hospital building that is abandoned or repurposed to be a
marketplace is still a building=hospital



> 2) A farm which has converted some of its buildings to
> holiday cottages will have a mix of building types.  Mappers
> who wish to go into details would prefer to see the
> individual holiday cottages rendered distinctly (as
> they currently are).
>

But building=yes + name=xxx will still render sufficiently, won't it?

3) This scheme has problems with individual holiiday
> cottages, such as the one around the corner from me,
> unless you retain tourism=chalet for such cases.
>

Individual as 1 cabin per site, or, as Mateusz raised, multiple cabins on
one site?

 4) There are a lot of tourism=chalet.  Are you proposing we bulk edit them?
>

Nope!

Thanks

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


Re: [Tagging] Feature Proposal - RFC - Military=Coast-Guard & Rescue=Marine_Rescue

2020-12-15 Thread Graeme Fitzpatrick
Thanks

Graeme


On Sun, 6 Dec 2020 at 12:21, Graeme Fitzpatrick 
wrote:

>
> Please visit https://wiki.openstreetmap.org/wiki/Marine_rescue & have a
> look.
>

This proposal (which is partly linked to both the Rescue Services &
Military Bases proposals) is also close to moving to voting.

Precis:

*Deprecated*:

   - emergency =
   coast_guard
   
   - amenity =coast_guard
   

*Add*:

   - military =coast_guard
   

   - emergency =
   marine_rescue
   


 So far, comments appear positive, but if there is anything you would like
to add, please mention it either here or on the Talk page.

Thanks

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


Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

2020-12-15 Thread Graeme Fitzpatrick
On Sun, 6 Dec 2020 at 12:18, Graeme Fitzpatrick 
wrote:

> Please visit https://wiki.openstreetmap.org/wiki/Rescue_Stations & have a
> look.
>

Reminder that voting is close to opening on this proposal.

*Precis:*

Amend the heading emergency=other_stations to emergency=rescue_stations /
rescue_services (still in two minds about this one?)

Under that heading, introduce new, or define existing, tags for various
rescue services:

emergency =
disaster_response


emergency =marine_rescue


emergency =mine_rescue


emergency =
mountain_rescue


Deprecate:

   - emergency =
   ses_station
   
   - emergency_service
   

   =technical
   
   - amenity =
   rescue_station
   


So far, there have been very few comments, so if there is anything you'd
like to bring up about the idea, please do so, either here or on the talk
page.

Thanks

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


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

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

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

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

Lather, rinse, repeat.

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

> On Dec 15, 2020, at 2:25 PM, Martin Koppenhoefer  
> wrote:
> 
> Am Di., 15. Dez. 2020 um 08:51 Uhr schrieb Anders Torger :
> The simple answer is that this naming concept is fundamentally broken, and 
> that we need to have some other concept, such as fuzzy areas.
> 
> 
> I agree that there isn't really a concept for naming larger (natural) areas. 
> In OSM you can map areas of the same kind of thing and add the names for the 
> smallest entities (e.g. forest) to it, but you cannot add a name for several 
> parts of a forest together (when the parts themselves have names). Naming 
> works for administrative entities, countries, cities etc, but not for 
> geographic entities. 
> 
> Cheers
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Martin Koppenhoefer


sent from a phone

> On 16. Dec 2020, at 00:32, Brian M. Sperlongano  wrote:
> 
> I want to be clear that in such a proposal, any instances of disrespectful or 
> insulting commentary directed towards any group or individual will not be 
> tolerated and will be immediately brought to the attention of the wiki admins 
> for followup.


the wiki and tagging ml are safe places, no worries, if you are wary of 
insulting commentary stay away from the diversity list and 
OpenStreetMap-Foundation talk in the short period before board elections. ;-)

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-15 Thread Brian M. Sperlongano
Thanks everyone for the discussion.

I believe there are two germane points being raised by Tomas that warrant
our consideration:

1. It is not clear from the original 2011 vote which created
water=reservoir (and other values) as to whether the community intended to
deprecate landuse=reservoir or whether the community intended to create two
parallel tagging schemes for the same object.

2. There is some subset of the user base that uses and/or prefers
landuse=reservoir over, or in addition to, water=reservoir.  The iD editor
preset appears to use water=reservoir while the JOSM preset appears to use
landuse=reservoir.  It is unclear whether there is actually a strong user
base preference for either tag or whether the numbers simply reflect the
presets in the editors that users happen to use.  There is also no way to
determine from these discussions alone the size of community support for
either scheme, particularly if such support is factional within non
English-speaking communities.

Given these issues, I would suggest a narrowly-written proposal that puts
forth the clear and specific question as to whether landuse=reservoir
should be deprecated.  If that proposal demonstrates clear community
consensus for deprecation (per the guidelines in our proposal process), we
can update our wiki documentation to explicitly recommend that
landuse=reservoir be gradually replaced by natural=water+water=reservoir.
If, instead, that proposal demonstrates that there is still a sizable
subset of mappers that prefer the landuse=reservoir tag, we would simply
leave both tags documented without caveats, noting the results of both this
and the 2011 proposals, and allow the community to sort out which tagging
scheme is preferred based on actual usage over time.

As I am the one that raised this issue in the first place, I would be happy
to draft such a proposal for consideration.  I want to be clear that in
such a proposal, any instances of disrespectful or insulting commentary
directed towards any group or individual will not be tolerated and will be
immediately brought to the attention of the wiki admins for followup.

Would this be satisfactory to the group in resolving the question of
reservoir tagging?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

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

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



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

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

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


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

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

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


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

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


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

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

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


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

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


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

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

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

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

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

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

-- Joseph Eisenberg

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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


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


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

2020-12-15 Thread Paul Allen
On Mon, 14 Dec 2020 at 21:07, Jmapb  wrote:

[On distributed motel 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.
>
There might be individual cases where the lines blur, but mostly holiday
cottages operate on a very different basis to motels.  So tourism=motel
doesn't fit, as we both agree.

> For Canllefaes, I'd be happy enough with leisure=resort.
>
I wouldn't.  Maybe there's a difference between UK and US understanding
of the term resort.

In the UK a holiday resort is in many ways similar to a large village.
Many residences.  On-site facilities usually include some or all of
a pub, a fast-food diner, a restaurant, a night club/disco, maybe a
cinema, a convenience store, an amusement arcade, amusement
rides.  You can get everything you need (except experience the
surrounding area) without leaving the grounds.  Usually
the facilities are open to non-guests but guests may get
discounted prices and or priority access (such as free
rides on the big dipper and the privilege of getting on
the ride ahead of non-guests).  Given on-site
fast food and restaurant, catering in the
accommodations may be limited to kettle,
toaster and maybe microwave.  In some ways
there are similarities between a docked cruise ship
and a holiday resort.

A group of five or six holiday cottages that are converted
farm buildings don't justify that sort of investment in
infrastructure.  You might get a playground with a slide
and swings.  Maybe even a swimming pool (those
are rare and Canllefaes is an exception).  Maybe,
if there are a dozen holiday cottages then a small
convenience store (which may also serve a nearby
hamlet).  There's not the room in a farmyard to
put more holiday cottages (and planning permission
would be withheld even if there were room).  So
the facilities I'd expect at a holiday resort won't
be there.

We might find a case or two where the boundary is blurred,
but mostly leisure=resort (as I understand resort) doesn't
fit.

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


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

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

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

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

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

-Joseph Eisenberg

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

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


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

2020-12-15 Thread Paul Allen
On Tue, 15 Dec 2020 at 08:53, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Dec 15, 2020, 03:33 by graemefi...@gmail.com:
>
> 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
>
>
> I am fine with that and I plan to restore this tagging recommendation
> unless someone will proposed a better one.
>

I see four problems with it.

1) Holiday cottages are rarely building=cabin, they are mostly
building=house.  One around the corner from me is a former house
that has been converted to a holiday let.  Even the ones on farms
are converted stone barns, converted stone stables, etc.

2) A farm which has converted some of its buildings to
holiday cottages will have a mix of building types.  Mappers
who wish to go into details would prefer to see the
individual holiday cottages rendered distinctly (as
they currently are).

3) This scheme has problems with individual holiiday
cottages, such as the one around the corner from me,
unless you retain tourism=chalet for such cases.  But
then we end up with two ways of tagging individual
cottages in a group with different renderings.

4) There are a lot of tourism=chalet.  Are you proposing
we bulk edit them?

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


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

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


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


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


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


/Anders

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

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


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


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


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

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


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


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


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

2020-12-15 Thread John Sturdy
How about "holiday park"?  A google search for that brings up some caravan
parks but also some with chalets / "lodges".


On Tue, Dec 15, 2020 at 8:53 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 15, 2020, 03:33 by graemefi...@gmail.com:
>
> 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
>
>
> I am fine with that and I plan to restore this tagging recommendation
> unless someone will proposed a better one.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

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


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


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


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


/Anders

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


stevea :

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


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

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


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

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


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


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


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


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


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


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


/Anders

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


sent from a phone

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


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


have a look at this overview:

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

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


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


Cheers Martin

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


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

2020-12-15 Thread Martin Koppenhoefer


sent from a phone

> On 14. Dec 2020, at 23:11, François Lacombe  wrote:
> Furthermore, :type suffixes make things complex and don't bring any 
> additional information as anything is a type or category of something 


yes, the keys should rather say which kind of type they are referring to. For 
example if there’s a memorial, it could be a plate and at the same time a war 
memorial and at the same time be attached to a building or lie flat on the 
ground. “Type” does not make it clear what the criteria are and we would end up 
with different typologies mixed up in the same key (there are still some real 
instances of this problem waiting in the db to be sorted out).

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


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

2020-12-15 Thread Peter Elderson
stevea :

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

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


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

2020-12-15 Thread Mateusz Konieczny via Tagging
+1, this kind of change is completely fine


Dec 15, 2020, 06:19 by graemefi...@gmail.com:

>
> Thanks Brian.
>
> As far as I am concerned, those changes are fine.
>
> Graeme
>
>
> On Tue, 15 Dec 2020 at 10:53, Brian M. Sperlongano <> zelonew...@gmail.com> > 
> 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?

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


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


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


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


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


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


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


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

2020-12-15 Thread Martin Koppenhoefer


sent from a phone

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


have a look at this overview:

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

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

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

Cheers Martin 


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


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

2020-12-15 Thread Mateusz Konieczny via Tagging



Dec 15, 2020, 03:33 by graemefi...@gmail.com:

> On Mon, 14 Dec 2020 at 21:28, Paul Allen <> pla16...@gmail.com> > 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
>
>

I am fine with that and I plan to restore this tagging recommendation
unless someone will proposed a better one.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

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

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

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

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

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

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

Still, the OP continues:

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

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

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

Whew, I need a shower!

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

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

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


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

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

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

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

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


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

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

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

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


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