Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render historic=tomb #1068

Closed
Grillmannen opened this issue Oct 16, 2014 · 15 comments
Closed

Render historic=tomb #1068

Grillmannen opened this issue Oct 16, 2014 · 15 comments
Labels

Comments

@Grillmannen
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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

@Grillmannen
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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
Copy link

2014-10-16 8:24 GMT+02:00 Mateusz Konieczny notifications@github.com:

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
Copy link

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
Copy link
Contributor

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
Copy link
Collaborator

pnorman commented Oct 16, 2014

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
Copy link
Collaborator

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
Copy link

2014-10-16 15:18 GMT+02:00 mboeringa notifications@github.com:

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
Copy link

2014-10-16 15:48 GMT+02:00 math1985 notifications@github.com:

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
Copy link

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.

@matkoniecz matkoniecz added the wontfix-unfeasible Issues closed because of lack of suitable solution label Oct 16, 2014
@matkoniecz matkoniecz added declined and removed wontfix-unfeasible Issues closed because of lack of suitable solution labels Mar 24, 2016
@BertMule
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants