There is an ongoing issue with wiki page describing graves. Polish translation is not actually a translation, but a page of its own. Everyone across the world are mapping by english wiki specifictions, but in Poland, user “Władysław Komorek” refuses to make a translation and instead has made up specifications to his liking.
Please take a look at wiki discussion page at https://wiki.openstreetmap.org/wiki/Talk:Tag:cemetery%3Dgrave to catch a glympse of it.
Please see which of these ideas makes sense to be introduced into the english wiki and which has to be removed.
I would like the polish wiki to start being an actual translation and i also know that “Władysław Komorek” will unfortunately not let it go, so please advice how conflicts like those are supposed to be solved.
I really would like that his work not be wasted, but he is kinda stubborn and refuses to cooperate by the community standards, so it’s a tough one.
Have you discussed in the country? I don’t see a post linking to it. Polska (Poland) - OpenStreetMap Community Forum
It would be quicker and easier if you explain what’s wrong here. As I happened to have commented on a section, I will help you by mentioning the disagreement is about name= on =grave for the buried person.
There is an ongoing issue with wiki page describing graves. Polish translation is not actually a translation, but a page of its own. Everyone across the world are mapping by english wiki specifictions, but in Poland, user “Władysław Komorek” refuses to make a translation and instead has made up specifications to his liking.
Please take a look at wiki discussion page at https://wiki.openstreetmap.org/wiki/Talk:Tag:cemetery%3Dgrave to catch a glympse of it.
as we’re on it, there are some issues with cemetery=grave in general:
it is against the general scheme of tagging, because what would usually be expected for a “cemetery” value is a kind of cemetery, like prevalently described here: https://wiki.openstreetmap.org/wiki/Key:cemetery, e.g. war_cemetery or columbarium. Actually it is a mess beyond the grave tag, a burial forest or ossuary are burial places, but maybe they are alternatives to a cemetery rather than a type of?
The other point is: from my understanding (which as a German, where grave and tomb have the same word, may not be sufficient), while both are burial places, a grave is different from a tomb, it is a hole dug into the earth and then refilled, while a tomb is a structure (typically of stone, either constructed or cut into rock), so combining grave and tomb into the same feature may be strange.
A concurrent scheme of tagging is the theme approach: all things belonging to theme x are tagged as x=thing.
E.g. highway has both schemes abundantly: highway types and highway-related objects such as elevator, bus_stop, crossing, give_way, emergency_access_point, street_lamp, …
This is what’s not being discussed. highway=footway is a feature. footway= should be an attribute for it, not another set of features. =grave and =sector are blocking cemetery= from being an obvious initial solution to describe =cemetery , causing limbo and unneeded fragmentation.
There are many cemetery= , but it could be acceptable to migrate if considered a micro detail with less disruption, and certainly possible to double-tag when transitioning. =sector is mostly steady growth, with a proposal, which didn’t pass voting in 2014. Then @dieterdreist commented on this in 2017, when it’s also only ~5k. Proposal talk:Cemetery sector - OpenStreetMap Wiki =grave was mostly mass added with tripling by thousands in 2017, and ~70k eightfolded in 2021. It can use some scrutiny. section= / =section was proposed in 2009, mentioning this Proposal:Section - OpenStreetMap Wiki
For me, I want to be further away from the topic, in case *:part= is mentioned. For landuse=cemetery as a whole, landuse= is not a unique individually identifiable feature, only a homogeneous dissolvable statistical classification. landuse= + name= is basically used in the absence of a suitable solution. This is unlike =grave_yard using amenity= properly.
So it’s an accepted method, any mapper will encounter it often enough. Which doesný say anything about ideal grave mapping, it’s just not an argument against cemetery=grave. A burial forest may be a separate burial place or a part of a cemetery sporting other facilities as well; so it’s not in itself a type of cemetery.
Also, an ossuary is a regular part of a graveyard. When graves are cleared, the bones go into an ossuary.
beside cemeteries is done with “golf” and very few other specific fields.
So it’s an accepted method, any mapper will encounter it often enough. Which doesný say anything about ideal grave mapping, it’s just not an argument against cemetery=grave.
IMHO these are rather outliers (playground is another one), historical debt from times where we had not so many tags to see what the system will become.
Also, an ossuary is a regular part of a graveyard. When graves are cleared, the bones go into an ossuary.
ok, there may be ossuaries and ossuaries, I have encountered them as a room in churches and as part of a war memorial (I think the former is a crypt, but the latter was likely part of a cemetery).
About, I understand both the NINO side (name is name only) and the NIWOI (name is what’s on it) side. I had the same issue with Stolpersteine. Both preferences have issues when applied very strictly.
Never found it worth an edit war, though. The wiki should describe both practices. I also try to keep in mind that community choices often are made by a small self-selected group (note I did not say elite!) and are seldom valid for eternity, but they do resist change just because it’s a change (“You may be right but I am not going to change the preset!”)
Yeah, i do think there is a general issue with tagging graves, coz tombs seem to be graves of various kind, but completly different tag family ?
And there is also amenity=crypt which kinda describes a tomb but not really?
We should clean this up,
but primarly i’m asking to decide which tagging should we introduce into the cemetery=grave and which is not accepted. Over the long years a lot has happened and lots of cemeteries across Poland are mapped with specifications taken from the polish wiki translation, which is simply officially invalid.
They have even developed a grave search app that works solely because of these tags specified in polish wiki translation but absent in the english official one.
So you guys don’t even know what tags, unless you go to polish wiki and try to understand it from the browser automatic translation.
Finally i would like to know how to deal with wiki editor, who refuses to follow the official guidelines and keeps on editing against the consensus, reverting valid translations.
I saw some type=person relations and I find weird to save names, surnames, birth and death dates, birth and death places and even the religion of a person there when we have tags such as subject:wikidata=*, buried:wikidata=* ecc. where all these informations can be retrieved from.
the app actually read up data from those relations, which IMO are useful for “modern” family graves with multiple ppl burried inside.
Those relations are simple and data fillup is unequivocal while if tags of all burried ppl, their dates and multiple other details, were assigned to the grave itself, it is extremely hard to parse and easy to make an input error on user side.
But i don’t agree those relations use has to be mandatory if grave has only one burried person like it used to be in those old graveyards, not modern cemeteries.
Now, those relations were rejected like over 10 years ago… but those person relations that are used nowadays are somewhat different and tbh as someone standing aside, i think the idea should be reintroduced, but this time with proper explanation.
If multiple people is buried the semicolon separator can be used. Now we have 1 extra relation with 12 tags that could be replaced with 1 tag (buried:wikidata), for two people in the same place it becomes 2 extra relations with 12 tags each instead of 1 tag. If the max length of a OSM value is 255, we can tag at least 25 people with just one tag. For example https://etymology.dsantini.it/ retrieves informations about people from Wikidata (even with the semicolon separator). Personally I find these relations a complication.
yeah, could use semicolons, but that is exactly what i described as easy for user input error and not very unequivocal
say you have a grave with 99 ppl and some names/surnames are missing along with titles, born/died dates
Someone started mapping it with a random order, but didnt finish, so we got tags like:
name=abc lol; bcd; lol ; ; ; ; ; ; ; ;zxy;
born=1812; ; ; ; ; 1801; ; ; ; ; ; ; ;1799
died= 1853; ; ; ; ; ; ; ;1853 ; ; ; 1853; ;1854
then someone tries to map the rest and likely just gives up
and yeah, there is the 255 char limit, and names/surnames can be real long, so you have to come up with tags like name2, name3, name4 …
Now try to programm an app that will parse that data and display it…
Also, those semicolons are not clearly specified eighter and i’m not sure if anyone used it anywhere, while the relation is quite commonly used due to stubborness of a certain individual.
As for my personal opinion… I’m not mapping those graves with that many burried people, i prefere to map only historical graveyards.
But if i was to map that many people for single grave… then i would not use those semicolons for sure, coz it would of no use to anyway and it is a nightmare as well.
Think how other people would do it, not you personally.
and yah, this is just one point of the whole grave matter ;]
I saw some type=person relations and I find weird to save names, surnames, birth and death dates, birth and death places and even the religion of a person there when we have tags such as subject:wikidata=*, buried:wikidata=* ecc. where all these informations can be retrieved from.
connecting to other databases is useful but it doesn’t mean we shouldn’t collect the things that we are interested in ourselves, even if they are also available through these linked sources
Of course, I just find weird we map people in a geographical database.
At the moment type=person is used 94% of times with “tomb” member roles, but I saw there are some “memorial” roles already (see link below) and I guess these relations could also be used instead of name:etymology:wikidata= with a “etymology” role, or instead of artist:wikidata= or architect:wikidata=. If these kind of relations will start growing in other fields than tombs (because why not?) - as the mentioned “memorial” - we could potentially have thousand of extra relations for stolpersteins alone, and relations that span over entire countries (e.g. the Joanne d’Arc equestrian statues in France) or continents (e.g. Relation: Johann Wolfgang von Goethe (3806749) | OpenStreetMap ). But if the consensus is that such relations are ok it’s not a problem for me.
yeah, i have been using buried:wikidata=* but in almost all of the cases, this external info wasn’t there and i had to name the grave somehow, so its name went into name tag coz i dont really map graves with multiple deceased.
@ivanbranco
as for the relations, I don’t treat the dead as person anymore, but more like a landmark to find and that’s why i think it’s very valid to map em,
just like monuments of other memorable people.
Oh and i definetly dont want this person relation to be mandatory and so i want to use normal tags within the grave node to keep it simple and backwards compatiple will all maps that are not coded to retrieve name/details from some unspecified relation.
As to why
type=person is used 94% of times with “tomb”
that’s solely becase of one main individual who decided that historic=tomb tag is necessary to be used with cemetery=grave and i can bet with you that 99% of these cases are in Poland only ;]
He made this requirement on PLwiki all on his own and kept on mapping for th last 10 years ;]
| 
dieterdreist: