Proposal talk:Grave

Remove "grave:" prefixes other tags

The grave:*=* prefixes on the other tags seem unnecessary in most cases. In particular, name=*, ref=*, memorial=* and inscription=* are used already elsewhere. The name of the cemetery could probably usually be derived from a cemetery area it is enclosed in, or maybe using the is_in=* tag? Not sure about how to handle the photo, species, and birth/death tags. Neuhausr (talk)

grave:*=* prefix is used deliberately to avoid mixing additional meaning into existing tags. For example name=* has meaning of how this place called by people, while grave:name=* is intended for storing name of a buried one. Also some renders shows name value regardless of other tags so if we'll use name=* tag instead of grave:name=* it can lead into undesirable effect. The same goes for memorial=* which is connected to a historic=memorial and bears different meaning to one proposed for grave:memorial=* tag. But in cases of ref=* and inscription=* grave:*=* prefix is probably indeed unnecessary.

About name of the cemetery. This tag is optional and clearly redundant, but in some cases such redundancy could radically ease programming (for example you can easily create grave card without geospatial requests to DB or build list of graves of chosen cemetery by key-value request), so I thought this tag could be useful in some cases. As for a reason why is_in=* is not used: in my opinion this tag is severely overloaded, so I usually avoid its use.

Thanks for the reply!

• Regarding memorial=*, it seems to me like the values for memorial are very close to the sort of values proposed here. You propose values like headstone and sculpture, and memorial has values like stone, plaque, bust, and statue, which are nearly identical. In addition, I see from taginfo that some people have also used memorial=cross and other values.

As description of memorial=* states this tag is used in conjunction with historic=memorial, so I don't like mixing this scheme with already existing ones as this could make data usage more difficult. Altough I recognize that values are pretty similar, so I guess it up to feedback from other users. But for now I would like to leave it in this way. (but I will add notion about your proposition)

• Regarding name=*, I'm not sure what other name could be used on a grave feature? That is, what is the situation where name != grave:name? In other contexts, this is clear: if the name of a river is XYZ, you tag it name=XYZ, you don't tag waterway:name=XYZ.

http://en.wikipedia.org/wiki/Bronze_Horseman name=Bronze Horseman, grave:name=Peter the Great (I realize that my example is about a monument, not about a grave, but consider a similar case). --Surly (talk) 05:28, 29 October 2014 (UTC)

Example of Surly is a good one, as I stated before in my opinion "the common default name" and the name of a buried one is pretty different concepts and should not be mixed. So I guess this is too up to additional feedback.

• Type doesn't really seem to capture what you're trying to get at with that tag. Grave:type as proposed is not describing the type of grave, but the type of creature buried there. Maybe genus=* would work, with the assumption that the default (no tag) is human.

I totally agree with this one, but I couldn't think of good name for this tag. genus=* is somewhat scientific term and implies usage of latin names (for example homo sapiens instead of human). Probably grave:species=* could be an appropriate replacement.

• For the dates, you might consider the tags person:date_of_birth=* (taginfo) and person:date_of_death=* (taginfo) which are more widely used. Neuhausr (talk) 15:21, 17 October 2014 (UTC)

I agree, because we rejected the person relation. Sometimes dates on a memorial are incorrect (or absent), so grave:birth=* and grave:death=* will represent the dates on the memorial; person:date_of_birth=* and person:date_of_death=* will represent info about the buried person. --Surly (talk) 05:21, 29 October 2014 (UTC)

As Surly stated community rejected person relation, so I don't think it's appropriate to follow tags which was defined in that scheme. Also I don't think that a real date of death or birth should be tagged on the grave object, because it'll state fact about a person, not a grave.

Tag statuses

Tag statuses should be explained in more details - mandatory/recommended/optional for different cases. I propose: grave - mandatory; grave:name - recommended; grave:species - "human" by default, mandatory otherwise; grave:photo - recommended; grave:birth - recommended if specified; grave:death - recommended if specified; grave:cemetery - recommended if grave is not inside cemetery/grave_yard polygon, optional otherwise; inscription - optional; religion - recommended if important; ref - optional. OverQuantum (talk) 19:18, 21 January 2015 (UTC)

I've tried to add status column. Feel free to make edits if you want.

Changed to proposed status?

Noticed this got changed to proposed status, but I didn't see a message sent to the osm-tagging mailing list. This is recommended on Proposal_process#Proposed Neuhausr (talk) 16:39, 27 January 2015 (UTC)

Sorry, missed this. Message has been sent.

Species

Please use the same conventions as for the regular Key:species. That is, if you want to use English values such as "human" or "dog", use grave:species:en. --Tordanik 12:17, 2 February 2015 (UTC)

In my opinion use of scientific names in this case is clearly excessive because number of values for this tag used in practice will be pretty low. This is one of the reasons why I intentionally used grave:* namespace and not existing tag. As you can see by this discussion before that I even though of using grave:type to avoid mixing, but I couldn't come with better tag name than grave:species. So it's better not to mix grave:species and Key:species tags.

I think that all of species=*, species:en=* and grave:species=* are misleading, because "dog" is a subspecies. What about grave:for=*, analogous to social_facility:for=*? --Fkv (talk) 00:30, 14 July 2015 (UTC)

grave:cemetery

I do not believe that tagging the name of the cemetery on every grave is a good idea. It can easily be extracted from the surrounding cemetery area. --Tordanik 12:19, 2 February 2015 (UTC)

This is why this tag is highly optional. I think this tag will not be used very much, but I think it's better to have it described in cases if someone will need it in some special cases.

"Optional" is vague enough that some people will still go ahead and spam that tag. I would prefer if it was only to be used in those special cases, and never in normal cases. --Tordanik 14:08, 3 February 2015 (UTC)

Changed status for this tag to "use only if cemetery can't be extracted by other means (e.g. grave is not inside landuse=cemetery or amenity=grave_yard)".

Thank you! --Tordanik 18:00, 7 February 2015 (UTC)

Wikidata

I've added a line to the table for Wikidata values. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:32, 6 February 2015 (UTC)

wikidata=* tag is appropriate, so no objections here. But I don't think that "internee" is a good word for this situation, in my knowledge it's usually not used in relation to people graves. Please, correct me if I wrong on this. So as temporary solution (until we find appropriate word) I would like to propose to use grave:wikidata=* for wikidata reference to a person, it's slightly confusing, but correlates well with grave:name, grave:birth and grave:death tags and extends with no problem to a graveN:* scheme. But on the other side in this case we will not use wikidata:* namespace which also not so good...

The act of burying a body or putting it in a mausoleum is called "internment". Your alternative would be inappropriate, because the Wikidata item would be about the person, not the grave. Perhaps grave_of:wikidata=*? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:03, 13 February 2015 (UTC)

Slight slip here, you surely mean "interment" not "internment", is which case the key would be interee (which doesn't seem a familiar word. I think the more convential english usage is grave occupant, leading to wikidata:occupantN etc. SK53 (talk) 09:43, 6 August 2015 (UTC)

How about using subject:* namespace? subject:wikidata was even described in wikidata proposal [1].

What if the grave has a statue, and it was subject=angel? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:40, 15 February 2015 (UTC)

I don't see any problems here. As it stated in the proposal, subject:wikidata is used for "The subject of a statue, artwork or memorial (a person, event, geographical feature..)". So subject=angel makes no sense, because subject:* namespace will be used for information about buried person(s), while properties of memorial and burial site will be inside grave:* namespace.

We should use the same terms for Foo= and Foo:wikidata= Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:35, 17 February 2015 (UTC)

Could you be more specific? I can't fully understand your opinion on this problem.

Our terms should match:

• "grave:name="
• "grave:name:wikidata="

or:

• "grave1:name="
• "grave1:name:wikidata="

and:

• "subject="
• "subject:wikidata="

not:

• "grave:name="
• "subject:wikidata="

-- Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:30, 21 February 2015 (UTC)

Sorry, I didn't explain myself clearly enough. I thought about using subject:* namespace for all information related to buried ones. So in such scheme following set of tags will be used: subject:name, subject:species, subject:image, subject:wikidata, subject:birth and subject:death; while in grave:* namespace only grave:memorial and grave:cemetery will be left. And accordingly, instead of graveN:* scheme, subjectN:* will be used. (if may be worth to even simplify it to just memorial and cemetery tags) It's a pretty big change, but it's seems logical.

Then we're back to having a confict with subject=angel, as I outlined above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:07, 21 February 2015 (UTC)

Once more, I don't see conflict here. There is no definition for subject=* tag, nor in wikidata proposal, nor in this proposal. So subject=angel is simply impossible key-value combination for both proposals. Thus I don't understand that you imply by subject=angel case.

Multiple burials

Multiple burials involve a single grave, so "grave1:name=" and "grave2:name=" seems wrong.

I would favour something like "internee1=", "internee2=", etc. For single burials, "internee=" should suffice. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:49, 6 February 2015 (UTC)

As I stated higher in my personal knowledge "internee" in this situation is not appropriate too. While I'm too thinking that separate namespace for data on buried person is a better solution, I couldn't come up with a good word for it. This is why I simply used grave:* namespace for this data and straightforwardly extended it for multiple burials. So if you could find right word for this namespace I would happily update proposal, but I don't think that "internee" is a right one.

"grave" is a word for the hole in the ground, not the (one or several) people put in such a thing. Also, see my comment in the section above this one. 22:06, 13 February 2015 (UTC)Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits

As I proposed above we can use subject:* namespace, so instead of graveN:* scheme which utilizes subjectN:* will be used. What your opinion on this?

Types of simple graves

Currently, all simple graves use the "yes" value. However, there exists quite a variety of graves one would consider simple. So how about creating additional values for those? --Tordanik 00:23, 14 February 2015 (UTC)

Can you make short list of such types? Unfortunately my knowledge in this field is pretty limited.

Personal Information = NOPE

--AndiG88 (talk) 09:50, 7 March 2015 (UTC)

• I highly doubt that we can view information about graves as personal information. Also it's up to mappers communities in different countries to decide should they map graves or not. OSM is international project so it's obvious that there exists different norms in the different countries. Purpose of this scheme is just to define coherent way to tag this objects if such need arise.

• Information that is publicly displayed on a grave is not private. It may be mapped, 'personal' information at appears in public is no longer 'personal'. Warin61 (talk) 23:28, 11 July 2015 (UTC)

Cenotaph

-- Cenotaphs are memorials/monuments. They are not graves as no remains are present, can already be mapped in OSM and so should not be falsely mapped with the tag 'grave'. Warin61 (talk) 23:28, 11 July 2015 (UTC)

-- Agree. Cenotaph is a memorial to person or group of persons who's remains are interred elsewhere and is therefore not a grave. R41phA (talk) 08:02, 12 July 2015 (UTC)

Scatter Site

Definition: A place where cremated remains are scattered. -- There are many places where remains are scattered. I would be in favour of mapping those regularly used for this purpose - usually the grounds around a crematorium. But where the site is only used for one, or used only for a few, I would be against mapping it. Warin61 (talk) 23:49, 11 July 2015 (UTC)

No headstone

What about if there's a grave, but no memorial present? 23:59, 5 August 2015 (UTC)

What's the problem? Tag it with grave=yes + memorial=no. --Surly (talk) 06:01, 6 August 2015 (UTC)

We already have historic=tomb

What's the difference with historic=tomb? --Zverik (talk) 19:53, 22 August 2019 (UTC)