Talk:Proposed features/Relation:person

From OpenStreetMap Wiki
Jump to: navigation, search

Shouldn't there be some more text in here ?

When a proposal with more than ~40 votes only has one line in talk page, I really feel we miss something. Wiki proposal's first goal aren't voting but discussing, aren't they ?

  • What does this proposal try to achieve ?
  • what are possible alternatives ?
  • should wikidata/wikipedia links better be used ?
  • is is feasible without relation and only a common tag on all memorial/tombs/grave/birthplace ?
  • should this be some third party linked database about genealogy ?

I don't now if my questions are relevant, but I miss some kind of "Request for Comment" before casting a vote sletuffe (talk) 14:16, 14 October 2014 (UTC)

ps: Ho ! and just when I write that I got a "conflict edit" because someone stated to use that page, good thing ;-) sletuffe (talk) 14:17, 14 October 2014 (UTC)

It skipped the RFC phase because it didn't follow the normal procedure of being announced on the tagging mailing list.(talk) 15:44, 14 October 2014 (UTC)
Ok, got it. Here [1] was the edit that changed this page to start a vote but we hadn't the chance to discuss it first. sletuffe (talk) 00:12, 15 October 2014 (UTC)
The alternative is to use a separate database and to link from there or from OSM. Usually Wikidata is used for this, but there are other projects, such as and --Jgpacker (talk) 15:44, 14 October 2014 (UTC)
A related tag is openplaques:id=*. --Jgpacker (talk) 23:52, 14 October 2014 (UTC)


Another kind of member which might be relevant is information-board, isn't it? Ogmios (talk) 19:18, 6 April 2014 (UTC)


Browsing TagInfo I noticed that we have multiple tags incomprehensible to the public but used locally in the country. Most of them have no "proposal". For example, some of them make sense only in the United Kingdom or in a particular country, and no one disputes.

So, indeed it is, how big is the demand for a given tag and its use.

The current voting begins to remind me of discussions on Wikipedia, where a group of a dozen people can dominate the thousands.

OSM has the advantage that we are trying to introduce new tags which are now or in the future allow the creature interesting applications. So removing them now, without making sure about their usefulness is pure vandalism. --Władysław Komorek (talk) 14:15, 14 October 2014 (UTC)

Has anyone mentioned removing them ? if so, I'm against that and will consider it vandalism as well. But I think the question is : How prominent should it be displayed on the wiki ? If my personal taste was to tag this_is_a_motorway=yes then I hope it won't be accepted on the "main feature" page, just like I hope no one will revert me but just add highway=motorway. But we might be drifting apart here, and that probably calls from some deeper thoughts about : what is the wiki for, what should be in (documentation of usage or recommendations or both ?) and is the current process for proposal/rfc/voting good, mandatory or only required to have a line on the Map_Features page. sletuffe (talk) 14:24, 14 October 2014 (UTC)
I also agree that simply removing these relations would be vandalism. However replacing it by another tagging approach would not be vandalism. I believe adding buried:name=* on the tomb instead of using a relation would be enough for most cases (or perhaps using the tag inscription=*) . For more "complete" relations, there could be some discussion on how to re-tag it, but I believe that the part of the data that can only be associated with the person and not with a physical place would be thrown away, understandably. --Jgpacker (talk) 20:57, 14 October 2014 (UTC)
Yes, removing something without ensuring ensuring that relevant data is properly tagged is a bad edit. At the very least data from inscription on tomb must be not deleted. Mateusz Konieczny (talk) 06:08, 15 October 2014 (UTC)


Maybe unambiguous definition of "relation" will solve our doubts. --Władysław Komorek (talk) 12:22, 15 October 2014 (UTC)

Probably one step in the good direction. Renaming the relation, limiting it to graves mapping purpose (and therefore dead people only) and to the minimum of personal data like just the name would increase its chance of acceptance. --Pieren (talk) 16:19, 15 October 2014 (UTC)

The main issue about this proposal

I see that most of the proposal supporters are coming from Poland, the country where this relation has emerged. For those who created and support now this relation, you have to understand that we did not follow the original discussions neither see the motivations to create it.

The main argument is explaining that it was created originaly for graves with several names. Problem : the proposal does mention graves only as examples. Basically, it is open for any use to modelize a person, with or without graves, dead or alive, known or unknown. So the intent of this proposal has moved from an original and valid problem for tagging multiple names on graves to something very generic which can be used to modelize everything about people. Also nothing is mentionned about possible local regulations/legislations restrictions but this is important in many countries (about privacy even in cemeteries). This is opening the Pandora's box and we can see already new extensions/ideas like this one : with new roles like named_in_honor, birthplace, etc. It is not because something can be read in a tombstone or on any element in the public area that it can go into OSM. Imagine that in many countries, we see the private people names on their mailbox. It is allowed to show it on the street, allowed to read it, but forbidden to collect them into a database without permission.

-- Pieren (talk) 14:20, 15 October 2014 (UTC)

That the use of some tags is dependent on the legal regulations in your country, I think it is obvious to all. This applies to the use of all tags. Thus, writing about it, is not substantive.
In Poland, it is not prohibited to publish information taken from the plates on the tombstones. Some cemetery administrators publish detailed maps and information about the deceased in these cemeteries.
Our intention, from the beginning, based on the needs of Polish users, was to describe the location of the grave of their loved ones, as well as detailing the persons buried there by every user and on every cemetery free of charge, not just those published commercially. November 1 is All Saints' Day in Poland, when everyone visiting the graves of their loved ones. Having information on the smartphone about location of each grave, it would be very easy to find the grave of their relatives or friends to honor them. Some already have started to write an application for Android to help reach out to the graves by moving along paths in large cemeteries. Therefore, mapping cemeteries in Poland, I also draw paths between the graves.
The reason for choosing relation named "person" was that it was one of the relation already used and most suited to the subject. Of course, we could call relation, "thumb", "grave" or something similar, but we thought that it will always be possible to change the name in the future if necessary.

--Władysław Komorek (talk) 19:05, 15 October 2014 (UTC)

If you need a smartphone app to find the grave of your loved ones I have bad news for you... --AndiG88 (talk) 22:29, 15 October 2014 (UTC)


I saw some of the instances of this relation contain the role named_in_honor (this isn't a role proposed here though). I just would like to comment that there already is a tag that could be used instead of this role: name:etymology=*. It is often used to reference a wikidata ID, for example name:etymology:wikidata=Q12345. --Jgpacker (talk) 12:04, 16 October 2014 (UTC)


There is a "gravestone project" at (only german, unfortunately) which could be a good partner to implement a "open genealogy GIS dataset". They aim to create a foto database for gravestones, I guess one could also suggest that they store those fotos geotagged. --Gormo (talk) 12:55, 16 October 2014 (UTC)

Simplified version

Please take a look at Proposed features/Relation:person (rewrite). In fact this is how this relation is now mostly used. Yarl 14:25, 16 October 2014 (UTC)