Tag:cemetery=grave

General talk
21

I also find this relation weird, IMHO this is a kind of category and not compatible with our rules. No need for a relation. The tagging with “wikidata” of objects is fine to convey identity, what I was writing against is leaving the “authority” of names and other properties that we are interested in, to third parties by not adding them to OSM.

22

I edited claim that historic=tomb is mandatory as it is an obvious nonsense.

See Pl:Tag:cemetery=grave: Difference between revisions - OpenStreetMap Wiki

2 Likes
23

Just doing some mapping & spotted a cemetery nearby.

After checking, it turns out that it’s now closed for further burials, but all of the previous graves are still inplace.

Should it be retagged as disused:landuse=cemetery?

Something historic perhaps?

24

The dead still exist underground. At least start with landuse=cemetery + disused=yes , but that’s confusing on whether it only doesn’t accept more (continues to be active), or truly became unmanaged.
I don’t like overusing historic= too much. Almost all of these won’t have historical significance, whatever it means.
For something usable and extendable in general, I can only think of the controversial operational_status=

To expand on this topic further, while there’s capacity= , there’s nothing for the number of utilization, owing to how unique deathcare becomes static, compared to other features used in real-time. As a complication, it may be possible to stop burials when there is still space physically, for some special reasons. On the other hand, a currently full one could still be open to more, when allowed to expand.

Interestingly, there is something for the form =mound in =archaeological_site burial | Keys | OpenStreetMap Taginfo

The limitation is they are unsuitable for =columbarium (storing urns for cremated ashes above-floor, not burying coffins in soil)
For the exact number of use in general, I can think of “occupancy”. However, this is mostly being used similar to the poorly named aerialway:occupancy= for the capacities of vehicles now, eg on railway= where aerialway:*= won’t be used. occupancy | Keys | OpenStreetMap Taginfo

25

Should it be retagged as disused:landuse=cemetery?

Something historic perhaps?

as long as the grounds are still used as cemetery I would not think so. IMHO it is not required that new burials are accepted.

6 Likes
26

do you think we should have wiki specified burried tag?
are semicolons really a good idea to separate names?
what do you think about born and died tags for the dates?

I started this topic o figure out stuff, but so far it appears like grave are not that popular to map i gues? xD

  • Also, i would like to ask about displaying grave nodes on the name.
    Right now cemetery=grave is not enough to render. adding name doesn’t make it to appear eighter.
  • You can’t use the search box to find graves by its name eighter

Who is there to talk about this?

There are maps, which make renderable nodes to display details (like the name) display uppon clicking it, but right now not even graves qualify i gues.

But if you use historic=tomb then it displays alright. This might be reason why polish wiki contributor decided it to be mandatory (he wanted to improperly walkaround that not rendering issue)

I also wonder if maybe a better way would be to make grouping relation, so uppon selecting the whole cemetery area tag, it could list all graves on it. but that’s likely too far out idea.

27

I don’t think there’d be any way of individual graves ever rendering on OSM as it would be just too crowded (unless they didn’t appear any earlier than zoom ~22!)

Here’s the old General Cemetery in our city: OpenStreetMap (which isn’t all that big as cemeteries go). You “could” tag every one of those graves but how would they display?

28

map cemetery as area, that is sufficient

I think this is out of scope for OSM (and similarly all this type=person relations are out of scope and should be removed)

2 Likes
29

but don’t you want to navigate your way to a certain grave? If a name is really popular, but you know the birth/death year, that can allow to narrow the search and point you in the right direction withough leaving home
Those graves of the dead are just landmarks IMO.

This is about finding a certain spot on a cemetery and navigating to it as precisely as possible.

As for the relations:

This is just an opportunity to search for a landmark.
We group up stream|river sections into a relation to find em easly i gues, even tho every segment of the river has a name tag on the geometry already. In case of this dead famous person, all of its memorials are grouped, so they’re easy to find.
I think that’s very much in the scope, but not insisting.

Meanwhile please help me out to find out how to deal with our fellow contributors who edit wiki pages without any approval, coz there is this one person who does it and I would love this isse being resolved :wink:

30

That’s why i linked:

osm.org likely won’t work this way, but it could at least render graves like it does parking spots :heart:
It should also be possible finding the nodes with the search box. yeah/nay?
And then those third party maps could know they can program it and have those elements clickable.

I have one historic deserted family graveyard in my neighborhood with just 20 graves total i think and really kind pointless to map em, coz noone would be able to find em with the search box and there is no map that’d render even a dot if i did map em ;]

31

I don’t think we should “just not map small things” or, worse, misuse other tags because the default renderer on osm.org only supports a max zoom level of 19.

Almost no-one uses osm.org as a “general purpose mapping site” as it really isn’t useful for (or designed to be) that.

It’s perfectly reasonable to map things that it only makes sense to display at even zoom 22+, and technically it is possible to create raster and vector maps that support that sort of zoom level easily.

4 Likes
32

I conclude that noone wants to make any development in the official specification of a cemetery=grave.

Fact is that there is no passed proposal for even this tag.
Do people want to pass such a proposal?

Do people want to pass other tags along with it?
Should cemetery=sector be specified and passed as well.

Give reaction feedback

1 Like
33

More correctly, osm.org only deploys the Carto style to Z19. It is defined out to Z20, and it would be great if were deployed to this zoom level; I don’t think the additional storage requirements will be significant as people will only be zooming in on the small fraction of crowded areas.

The open issue on rendering cemetery=sector in OSM Carto is here. A concrete design proposal is needed from anybody who is keen to develop it.

34

That’s certainly my experience of running a public, but not widely publicised, tile server. In terms of disk usage following access requests, raster zoom 16 is 10 times as much as 19 and 20. The maximum zoom supported natively is 24, with 25 as an overzoom.

35

I don’t know if it should. I have used cemetery=sector, but very limited. Tracestrack Topo has some support for cemetery sectors: sectors can have a sector name which is rendered as the sector label.

36

Dear community, please express by emotions this idea:

For tagging graves by i single decissive main tag:

:heart: for tag man_made=grave

:star_struck: for tag historic=grave

man_made=grave has very recently made it unofficially to the wiki

grupy man_made oraz historic są tak opisane:

man_made=* is used to identify man-made (artificial) structures added to the landscape.

The historic=* key is used to tag features that still exist or of which traces are observable, and that are of historic interest

I don’t deny a possibility that in future historic might be additionally tagged also for very old graves from past centuries, but right now it’s necessary to decide something for a start

Why there is no cemetery=grave to vote?
Coz graves are very different and don’t have to be within any cemetery at all. Also this tag is in use but was never approved

Give out your votes by those emotes please
& add any comments with a different opinnion giving a different emote

2 Likes
37

I don’t think I’ll be mapping individual graves in a cemetery, just as I don’t map individual parking spaces in a parking lot, individual solar panels in a solar panel installation, individual trees in a forest, or individual shrubs in a shrubbery.

However, if I encounter a single grave which is not historic but does standout e.g. as a landmark on a hiking trip (there are so many way-side graves, makes my heart bleed) I think man_made=grave would be the best fit. Where it’s also of historic interest adding historic=yes is fine with me.

cemetery=grave for individual graves belonging to a cemetery (cemetery= as a theme key), I have no problem with that either, even though I wil not map them. And I see no problem in using all the variants either, if we can formulate a preference for particular situations.

As long as variants make sense and don’t bite each other, they can happily coexist, and maybe one variant gets traction and another may fade out over time. I worry more about variants that use the same tags to express different things, such as cros/ sorry, let’s not go there.

38

I think it should not be an emotional decision but one based on argument and thought.

IMHO any grave fits under the historic key.
Cemetery as a key should ideally describe a kind of cemetery, although that ship has sailed…

39

I think they meant:
“Please vote for your preference using the emoji reactions” :slight_smile:

40

We have a polling function for these.
If you disagree, please leave a message in the comments :arrow_down:

4 Likes