Render historic=tomb

[Grillmannen]

There are currently a little over 3000 uses of historic=tomb in the database,[1] and the wiki page is well written and has several different tomb tags with image descriptions.[2]

Rendering example would be a small religion neutral tomb stone.

Most historic=archeological_site that I find are actually tombs of some kind, so I think there are actually more tombs in the database but with the wrong tag. If tombs get rendered people will probably start to use the correct tag more frequently.

[1] https://taginfo.openstreetmap.org/tags/historic=tomb
[2] https://wiki.openstreetmap.org/wiki/Tag:historic%3Dtomb

[matkoniecz]

Is there a tag for graves of not notable people (this tag is even now used to tag graves of unknown/ordinary people - see http://overpass-turbo.eu/s/5uq)?

[matkoniecz]

Also, I expect problems in some places with many graves - see http://overpass-turbo.eu/s/5uo

[Grillmannen]

Of course separate graves in grave yards should not be tagged with historic=tomb. This is primarily for historic (as the key suggests) tombs (like tumuli).

As the description on the wiki says: "This tag is for mapping graves of historical interest where are buried important or well-known persons of their era." Probably something denoting that people who got huge tumuli dedicated to them were probably important, but of course today we have no idea of who they were, should be added to the description.

Tombstones of important people located inside of churches should probably be rendered too, but as you say the rendering of those could become a problem... Maybe use another rendering if the tomb is tagged inside of a building?

This is how I have used the tag thus far: http://overpass-turbo.eu/s/5uv Primarily for places like this: https://sv.wikipedia.org/wiki/Bolmers_h%C3%B6gar

[matkoniecz]

Most historic=archeological_site that I find are actually tombs of some kind, so I think there are actually more tombs in the database but with the wrong tag. If tombs get rendered people will probably start to use the correct tag more frequently.

That rather indicates bad tagging scheme - it should be possible to tag something as an archeological site and tomb.

Of course separate graves in grave yards should not be tagged with historic=tomb. This is primarily for historic (as the key suggests) tombs (like tumuli).

Again, bad tagging scheme. It happened already with natural=tree, historic=wayside_shrine etc - and it will certainly happen again. People will expect that only notable will be mapped, maybe document it on wiki - but notability limit gets lower and lower till at certain point nobody even pretends that it exists.

Can you give examples of objects that should be rendered? Maybe there is way to filter out less important one (show only with big way_area?, show only ones with wikipedia or wikidata tag?, show only ones with name tag?).

[matkoniecz]

But conflict with historic=archeological_site is a bigger problem, most likely with such issue this tag should not be used and encouraged.

In addition this tag never went through some discussion/vote/RfC on tagging ml.

I added my comments on wiki and posted on ml.

[mboeringa]

Again, bad tagging scheme. It happened already with natural=tree, historic=wayside_shrine etc - and it will certainly happen again. People will expect that only notable will be mapped, maybe document it on wiki - but notability limit gets lower and lower till at certain point nobody even pretends that it exists.

Agree, this is a real problem for rendering. In the end, people will map everything, down to the last cobble stone if it were...

However, looking at the "tomb=x" tagging scheme, so NOT the historic=tomb tagging, it seems there may be some options for filtering out senseless detail for some scales. This means ignoring any unspecified historic=tomb tags, but render only tomb=x instead (https://wiki.openstreetmap.org/wiki/Tag:historic%3Dtomb)

E.g., you probably don't want to render tomb=wargraves or tomb=tombstone at any zoomlevel but 19, but you could render things like tomb=tumulus or tomb=pyramid at other zoom scales.

[dieterdreist]

2014-10-16 8:24 GMT+02:00 Mateusz Konieczny [email protected]:

But conflict with historic=archeological_site is a bigger problem, most
likely with such issue this tag should not be used and encouraged.

In addition this tag never went through some discussion/vote/RfC on
tagging ml.

particularly the current state of the page never was voted on. There is a
proposal for this tag which uses another definition (and which has been
amended in the meantime with questionable subtags like tomb=tombstone,
which I'd suggest to remove as you can also see on the discussion page.
https://wiki.openstreetmap.org/wiki/Proposed_features/tombs

[mboeringa]

particularly the current state of the page never was voted on. There is a proposal for this tag which uses another definition (and which has been amended in the meantime with questionable subtags like tomb=tombstone, which I'd suggest to remove as you can also see on the discussion page. https://wiki.openstreetmap.org/wiki/Proposed_features/tombs

This proposal page (which I noted was originally started by you), seems identical in its tagging scheme as the historic=tomb page?

I agree tomb=tombstone is questionable, but as to having no closed voting or not: there seem to be many of such de-facto accepted tags, which stay draft for extended periods of time, and never receive voting. I think it wise to "accept" well designed drafts in case they have received strong support in tagging practice, and use them in the style if, and when, appropriate (assuming there are no technical hurdles like the wait for Mapnik 3). It may help solve issues that can otherwise not be solved, e.g. see the discussion about "Stolpersteine", both as issue here on Github and on the forums:

#1066
http://forum.openstreetmap.org/viewtopic.php?id=27315&p=1

[matkoniecz]

I prefer to run vote even for well done and used tags (like man_made=bridge). Also "well designed drafts" is not relevant here.

[pnorman]

We've never needed a tag to be voted on to use it, or rejected tags just because they were not voted on.

Voting is one of multiple indications on the status of a tag.

[matthijsmelissen]

We've never needed a tag to be voted on to use it, or rejected tags just because they were not voted on.

And that's why tagging is now a total mess, such as the plurals in shop=shoes and shop=toys versus shop=bicycle and shop=gift. I agree with @mkoniecz.

[dieterdreist]

2014-10-16 15:18 GMT+02:00 mboeringa [email protected]:

This proposal page (which I noted was originally started by you), seems
identical in its tagging scheme as the historic=tomb page?

Yes, mostly, the questionable part was the definition, which I have now
changed on the tag page today to make it compatible with the proposal
(given that the proposal was the only available definition for more than 3
years I believe this is OK). The tag should be about tombs (which is also
the semantics of historic=tomb), but someone had written on the tag page
that it was about "graves of notable people".

[dieterdreist]

2014-10-16 15:48 GMT+02:00 math1985 [email protected]:

We've never needed a tag to be voted on to use it, or rejected tags just
because they were not voted on.

And that's why tagging is now a total mess,

no. This discussion probably belongs to talk, but just some short thoughts:
usually very few people take part in votings (like 5-20 typically), and few
people read in the wiki (most people use presets (i.e. typically one word
in their language) and do not look up the wiki, or they asume from the
words of the tags what it is about. And the wiki states different things in
different languages. And different (specialized) maps have their own
interpretation of the tags and their display. And ...

[mboeringa]

And that's why tagging is now a total mess, such as the plurals in shop=shoes and shop=toys versus shop=bicycle and shop=gift. I agree with @mkoniecz.

I think we all basically agree that a well defined - and consistent! - tagging scheme, voted on with a good number of people (who hopefully also made useful comments that led to necessary changes to the tagging scheme) is to be preferred over anything else.

That said, OSM not having something like a single "DBA" carefully crafting and managing a rigid database model, this is the situation we have to live with as people trying to render of the database...

Besides "steering" people in a preferred direction (from a style technical and maintenance point of view) by either rejecting, or incorporating render rules based on specific tagging schemes (whether approved or not), I think "go-with-the-flow" is the only option for OSM rendering given its open data model.

[BertMule]

Just give me an icon, as already used while editing.
As frustrating as ever,

Example of a landmark in a park.
https://www.openstreetmap.org/#map=19/51.99853/4.77250

[wlakom]

I think it's time to reopen this topic and add an icon representing a grave, similar to https://umap.openstreetmap.fr/en/map/new/#19/53.83448/18.10317

This icon shows that its dimensions are sufficient so that they don't overlap.

So, please create an icon for the tag "historic=tomb" for the OpenStreetMap.org map.
We already have entire cemeteries mapped, such as in Czarna Woda
​https://www.openstreetmap.org/#map=18/53.834347/18.102832

​https://taginfo.openstreetmap.org/tags/historic%3Dtomb#overview

We also have an updated " Wyszukiwarkę grobów na OSM (OSM Grave Finder)" that allows you to display grave descriptions:

https://dotevo.github.io/gravemap-osm/#16/50.0759/19.9550

[imagico]

Re-opening would require convincing new arguments. The case example pointed to is a graveyard where every single grave is tagged historic=tomb. That speaks against rendering the tag under the premise of this issue (which is rendering historic=tomb as a class of historic sites).

For reference: Current use numbers:

• historic=tomb: 66k uses, 26k with building=*, 25k with tomb=*
• cemetery=grave: 100k uses.

Not really relevant here, but piece of advice: Before you add things like https://www.openstreetmap.org/relation/18092768 it might be a good idea to discuss with your local community first. See also https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

[wlakom]

Every grave is in fact historic.

This is not my opinion.

The current way of tagging graves has been very popular in Poland for a very long time and all graves on OSM are tagged in a similar way. Presumably there will be more and more of them, regardless of whether the community outside Poland likes it or not.

The community in Poland has developed the following procedure a long time ago. https://wiki.openstreetmap.org/wiki/Pl:Tag:landuse%3Dcemetery.

As I wrote before, the "Wyszukiwarka grobów na OSM" will allow increasing the number of graves in a similar way.

[imagico]

The community in Poland has developed the following procedure a long time ago. https://wiki.openstreetmap.org/wiki/Pl:Tag:landuse%3Dcemetery.

That is interesting, thanks for the pointer.

That also explains that of the 5154 features double tagged historic=tomb + cemetery=grave 3504 are in Poland.

Anyway - as already said: This issue is about rendering historic=tomb as a class of historic sites (in the sense of a site that has significance today in a manner that is detached from its original function - see also amenity=place_of_worship vs. building=church/historic=church). Rendering contemporary graves, potentially differentiated by their design, would be a separate matter for a separate issue. And for that the dominant tag is clearly cemetery=grave.

[wlakom]

Personally, I have nothing against it.

But my request and issue concerns the design of an icon representing a grave in a cemetery.
So I don't care whether the icon represents historic=tomb or cemetery=grave.
The important thing is to do it as soon as possible.
In that case, you can change the topic from Render historic=tomb to Render cemetery=grave.

[imagico]

In that case, you can change the topic from Render historic=tomb to Render cemetery=grave.

We don't re-purpose issues like that. If you want to request rendering cemetery=grave as representing an individual grave in a cemetery please open a new issue for that.

[dieterdreist]

sent from a phone

On 31 Oct 2024, at 19:03, Christoph Hormann ***@***.***> wrote: Not really relevant here, but piece of advice: Before you add things like https://www.openstreetmap.org/relation/18092768 it might be a good idea to discuss with your local community first. See also https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

can you explain how the name of a person who died more than 50 years ago could be related to the concept of “private information”?

[dieterdreist]

sent from a phone

On 31 Oct 2024, at 19:23, Władysław Komorek ***@***.***> wrote: Every grave is in fact historic.

agreed, but a grave is not a tomb

[imagico]

can you explain how the name of a person who died more than 50 years ago could be related to the concept of “private information”?

I could, but not here. 😉

[dieterdreist]

sent from a phone

On 1 Nov 2024, at 12:19, Christoph Hormann ***@***.***> wrote: I could, but not here. 😉

As you started the discussion here, and it is somehow relevant to the topic of rendering graves, I will still use the opportunity to tell you that according to the current state of things and my knowledge, birthdates and day of death and names of long dead people and the positions of their graves are not covered by privacy protection in jurisdictions I am aware of. Maybe there could be very rare exceptional cases where privacy interests of living descendants could be touched by publishing such information, but it is not to be generally expected.

[imagico]

I understood you the first time. Yet again: this is not a discussion i am going to have here.