Re: [Tagging] Relations of type=site + tourism=camp_site

[Jake Low]

Like Adam, my experience is with backcountry camping sites located within 
wilderness areas. These sites usually consist of a cluster of camp pitches and 
related facilities like fire rings, pit toilets, etc. They do not generally 
have well-defined geographic boundaries, so it would be inappropriate to map 
them as polygons. However, they often have a name, access restrictions, an 
operator, a webpage, or other information that should be tagged somehow.

In these cases I map the campsite as a site relation with tourism=camp_site, 
and I place all of the other relevant tags (name, access, operator, website, 
etc) on the relation. I then add the various individual features belonging to 
the campsite (tourism=camp_pitch, amenity=toilets, etc), which are usually 
mapped as nodes or ways, as members of the relation.

I would not recommend adding a node tagged tourism=camp_site into this picture, 
as in my opinion it would be redundant with the site relation and a violation 
of the "one feature, one OSM element" guideline. I think that a camp site with 
an indeterminate boundary should either be represented in OSM by a site 
relation tagged tourism=camp_site, or a node with that tag, but not by both. 
And when the individual features of the camp site are also mapped, I prefer the 
relation because it groups the associated features together, and does not 
require inventing an approximate centroid of the camping area at which to 
locate the camp site node.

To add to Adam's examples, consider North Cascades National Park in Washington. 
Nearly all of the camping areas listed on this webpage 
 are deep 
in the backcountry, but each has a name, number of individual pitches, varying 
permit requirements and fire restrictions, and other information that is useful 
to tag in OSM. Currently most are mapped as nodes, but I think if one was 
micromapping the individual features at a given campsite it would be reasonable 
to then group them together in a site relation which described the camping area 
as a whole.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re-opening of historic=* key vote without community notification

[Marc_marc]

Le 15.11.22 à 14:36, Brian M. Sperlongano a écrit :
Sarah Hoffman has previously pointed out some structural issues with the 
use of historic as a top-level key sometimes and an ancillary key other 
times:
https://lists.openstreetmap.org/pipermail/tagging/2022-November/066294.html 




Random example: historic=manor. About 77% of objects tagged with
historic=manor have a building=* tag, which makes perfect sense. A manor
is a building after all. So it looks like historic=manor is more of a
property tag to a building. But what about the 23% other manors that are
not tagged as building? Is a historic=manor without a builing=* tag
meant to be used as a primary key?


random exemple from this exemple :)

1) https://www.openstreetmap.org/node/32944014
no manor at the location of the node but there are buildings around
the node
I imagine that the manor is made up of several buildings, according to 
WP, it's maybe https://www.openstreetmap.org/edit?node=32944014 and that 
there is therefore a sort of duplicate between the node and the building(s)


2) https://www.openstreetmap.org/node/84763173
also a duplicate

3) https://www.openstreetmap.org/node/270920014
no idea, poor aerial imagery

4) https://www.openstreetmap.org/node/269504477 nothing there
maybe a duplicate of https://www.openstreetmap.org/way/751350328

pickup you own https://overpass-turbo.eu/s/1nMy

I have the impression that the absence of a main tag for historic=manor 
is an error and not a manifestation that historic is itself a main tag


for other values however, I don't see what the main tag could be
if not historic=* :
ex historic= archaeological_site: if the site is buried like the one I 
know, it's easy to add a tag to describe that it's a grassy area for 
example, but if the place is now as a visible area of archaeological 
remains, apart from tourism=attractionn, I don't see what other main tag 
would be suitable

other ex historic=monument



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

Re: [Tagging] Re-opening of historic=* key vote without community notification

[Brian M. Sperlongano]

On Tue, Nov 15, 2022 at 6:22 AM Włodzimierz Bartczak <
wlodzimierz.bartc...@openstreetmap.pl> wrote:

> That's right it's an oversight. I was a bit hasty. First of all, I wanted
> to start a discussion. It would be worthwhile to sort out the use of this
> key. Everyone is complaining about this proposal no one wants to put it in
> order. Maybe we should do it together as a community.
>

I'm happy to help start that discussion.

First, it needs to be clarified what problem the authors are trying to
solve with this proposal.  The proposal needs a clear, plainly-stated
purpose and rationale to understand what is being voted on and why the
status quo isn't good enough.

Beyond that, there are several long-standing issues with the historic=*
key.  Over the years, there has been a debate over what counts as
"historic".  Some community members have suggested that features which are
"merely old" are not necessarily historic and that perhaps a heritage
organization or government's recognition is required to meet that threshold.

Additionally, Sarah Hoffman has previously pointed out some structural
issues with the use of historic as a top-level key sometimes and an
ancillary key other times:
https://lists.openstreetmap.org/pipermail/tagging/2022-November/066294.html

I think, at a minimum, these three points should be addressed by the
proposal authors before moving forward.  They are certainly blockers for my
support.  Consider this an opportunity to dig into the issues with this key
and work with the community to find where the consensus may lie.  Do not
rush to declare a vote until the issues raised by the community have been
adequately addressed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging