To summarise, the main goal is to pick one tag to represent cemeteries instead of the current two and to define a subtag to define cemetery types (among them is cemetery=graveyard).
This however causes the need to change the tagging of existing features using cemetery=* as its physical tag such as cemetery=grave and cemetery=sector. I promise we’ll deal with the former at a later date as I know it’s rather controversial but for now let’s focus on the second one.
In the proposal I suggested we use amenity=cemetery_sector which is inspired by the usage of amenity=parking_space inside of parkings. I hope that you can accept that concept.
Now, my main question is: should we stick to using landuse=cemetery or should we actually switch to amenity=cemetery?
The argument for using the latter is because then we’ll have amenity=cemetery_sector inside amenity=cemetery just like we have amenity=parking_space inside amenity=parking and because in my mind an amenity=* seems more fitting to use as a node compared to landuse=*. The rendering will then also have an icon which is often used on paper maps so I think that fits a lot better.
I know this may seem unnecessary to invent an entirely new tag and be forced to have a mass edit changing all the cemeteries in the world, so I simply want to ask for your thoughts and opinions about which tag should be used.
I’d also like to hear if you have anything to say about the cemetery=* key’s values or the proposal in general.
Best regards
Yes, it’s supposed to stay as it is in terms of defining the type of cemetery. The goal is to approve such usage, add cemetery=graveyard to the list of approved values and to deprecate (to some degree) the usage of the tags without landuse=cemetery.
It’s both. Why would it introduce confusion? amenity=grave_yard while possibly deprecated it won’t be banned from using, just landuse=cemetery + cemetery=graveyard will be preferred.
I would prefere amenity=cemetery but since all mainstream maps don’t recognize this tag, it’s likely impossible to change and we are stuck with landuse=cemetery
By same logic i would keep using cemetery=sector but since it might not be recognized by mainstream maps yet, amenity=cemetery_sector works just fine for me as well.
Each sector should have an option to set religion=* for it if the whole cemetery sectors use divission like this and it begs a question if we can set the tag to the whole cemetery and if specified to individual sector, will it render properly? I would very much like to avoid relations with inner/outer roles…
If it is cemetery=sector, then cemetery=greveyard|forest|military|mass_grave|gravefield might be an issue when you’d like the sector have type of cemetery tagged
Also, it may be interesting to find that some GB speakers may refuse to call graveyard a cemetery, but i hope not ;D
As for individual graves, we gonna see about this tagging later i gues, but i very much like how iD solves not very logical tagging, especially when translated to other langues to use:
It just doesn’t use attribute=value logic, but just say what it is and so many new iD editors don’t even know tags and whatever is the naming of tags, mapping for them goes undisturbed and completely alright with data input without errors, because they don’t type in tags by hand.
iD solves many many problems with this.
There’s no problem to create a =cemetery feature on top of landuse=cemetery here. Similar happened with military=base for landuse=military before. amenity=grave_yard can be kept as a special case. cemetery=graveyard isn’t intuitive either.
However, I don’t like =*_sector , as creating many different =*_part for subdivisions of each feature in amenity= isn’t scalable and sustainable. Again, =*_parking is a special case, and =parking_space was created before alternatives eg area:highway= . I prefer to have a better solution for it first, before migrating cemetery= as a whole.
Another possible solution is to move cemetery= to eg cemetery:part= / cemetery:sector= , although the syntax is different from building:part= when building= is a feature. This would allow the type to be included directly ie cemetery:part=war_cemetery etc. (though cemetery=war_cemetery is verbose that could be shortened to =war , or clarified further)
As a new cemetery:*= has been considered, a more radical idea instead of this, or amenity= and man_made= , is to start eg deathcare= similar to healthcare= . This would allow adding deathcare=grave_yard / =cemetery while keeping amenity=grave_yard , not having a conflict from amenity=cemetery during transitioning. But =crematorium was voted as well. Talk:Tag:amenity=crematorium - OpenStreetMap Wiki
Another issue is the definition of =cemetery . For cremated ashes, there are “cemetery” that are only columbariums including some grounds, while man_made=tomb + tomb=columbarium is better to use for the physical structure ie building= . There are also “memorial gardens” , which aren’t exactly the same as =mass_grave . It could further be argued dedicated cemetery=pet is not the same as human cemeteries. These could be worth considering for deathcare= , for whether it’s a large enough category to start anew.
Now, my main question is: should we stick to using landuse=cemetery or should we actually switch to amenity=cemetery?
IMHO it would make sense to tag cemeteries as features, i.e. with amenity rather than landuse, although I am not sure there would be sufficient support to make such a breaking move just for the sake of logical consistency.
It would also fit better with the similar amenity=graveyard tag
because even if it would pass proposal process it would not deprecate amenity=grave_yard
they’re different features, amenity=grave_yard is for the (in christianity) mostly older burial places that are part of a church area, while the cemeteries are more modern burial places (in christianity). I do not know how burial places in other religions are tagged.
In Greece, we typically call them cemeteries, but almost all of them have a church within, so I tag them as amenity=grave_yard, because as the wiki describes it this tag is the one with commonly church within, while the landuse=cemetery doesn’t necessarily have a church.
I heavily disagree. Cemeteries are their own thing that should most commonly be used without any tag accommodating it or together with cemetery=graveyard . The other option is to use cemetery=yes as a physical tag which in my opinion is really stupid.
One of the main points of the proposal is to stop having this weird language-based divide, when in reality these objects are the same.
While I know it may be hard for English speakers to call a graveyard a cemetery, it’s not really a stretch tag-wise as we already use such creations like leisure=pitch + sport=chess for mapping chess tables.
Also in most European languages the word for cemetery or graveyard is a derivative of ‘cemetery’ and that word is used for both “objects”.
I understand your opinion but the physical tag for cemeteries should stay as *=cemetery and not cemetery=* like with buildings (building=*) so I don’t think using cemetery:*=* as a physical tag is a good idea either.
By the way, cemetery sectors should most commonly be used just for enumerating sectors of cemetery, so something like cemetery_sector=war would very rarely be used.
I do realize, that the values for cemetery=* should actually be well thought out and consistent among each other, so I’d also like to hear more suggestions about cemetery=* values for the proposal.
I very much oppose such an idea. I think the creation of these new healthcare or education keys to be used alongside amenity is really stupid and unnecessarily complicating. I wonder where all the hate amenities came from.
That’s alright. It could either be deprecated in this proposal or not, but the usage of cemetery=graveyard will be strongly preferred.
It’s similar in Poland though there are quite a few cemeteries not beside churches. Either way you can see that it makes more sense for you linguistically and the fact it’s beside a church will have a tag for it still.
I don’t understand what’s exactly behind your opposition to amenity=cemetery now. You only explained for the reason of using amenity=cemetery_sector , not why amenity=cemetery shouldn’t be used.
The argument for education= is that you can easily recognize new features related to education, and handle them generically. Applications would have no idea what a new unsupported amenity= is about.
That’s a really interesting idea but it brings up the same issue being should we use a brand new tag vs an already existing one.
You misunderstood me. I am fully for using amenity=cemetery if we don’t persist on using landuse=cemetery. I’m just against inventing stuff like deathcare=cemetery or some sort of new key instead of using the already well-established ones which work very well in this scenario.
I think this is answered, because amenity=burial_ground would be a brand new tag, would be suitable to deprecate amenity=grave_yard (if deemed desirable), would be suitable to deprecate landuse=cemetery (as a “feature” tag), would be more religion agnostic, as long as deads are buried in the ground.
How would you recommend adding amenity=cemetery + cemetery=graveyard to amenity=grave_yard though? There’s a conflict. It doesn’t work out in this case. That’s one reason I suggest exploring deathcare= , to avoid affecting existing uses and applications.
I wrote about amenity=burial_ground which could be amended by burial_ground=cemetery and burial_ground=grave_yard and burial_ground=grave_field, and burial_ground=necropolis etc.
We might also want to distinguish public cemeteries and private family cemeteries. Maybe “catacombs” are a kind of “burial ground” as well?
OSM tags are just that - tags. There’s no inherent meaning in the fact that one concept is amenity=grave_yard and a similar but different concept is landuse=cemetery. In OSM, as in real life, there is overlap.
Apart from riverbank**, I can’t think of a single successful example of “renaming tags for the hell of it”. Where there have been successful tag moves it has been with things like highway=ford, where the previous scheme prevented us from tagging what sort of highway it was. That does not appear to be the case here.
While it’s fun to think about how we might rename OSM tags in a “fantasy football” sort of way, it would be a mistake to think that it was ever going to happen.
Instead, it’d make sense to concentrate on what we can’t or don’t tag in cemeteries and graveyards today, and explore why.
** somewhat arguably. I view that as mostly a complete waste of time.
Apart from riverbank**, I can’t think of a single successful example of “renaming tags for the hell of it”.
landuse=farm
site_type to archaeological_site=* and likely some more, arguably very few, there are probably more failed attempts like contact:phone than there are successful ones
