Hi everyone,
I have no knowledge of Polish that’s why I post in English.
In German part of OSM Forum we oppose the relation proposal type=person. Our main arguments against this proposal are:
Relations are no Categories
This type of relation is a collective relation. There is no advantage over tagging the information of people being born or died in a building onto the tomb node or house of birth polygon/address node. We had about 100 so called “Stolperstein-Relationen”. This relations tried to collect all stolperstein nodes in a city or county. This relations have been deleted over the last months because they are unmaintainable and not necessary. They were used to show all stolpersteins in a city via www.openstreetmap.org/relation/ID. They are unmaintainable because if users created new nodes they often did not add them to the collective relation.
Let’s imagine a JOSM user. He splits up a Bing-drawn building into two buildings because the have different house numbers (this edit is common in Germany). If he uses JOSM, JOSM will automatically add both buildings to the relation. If JOSM gets to know type=person, it might ask the user. Now the user has two choices. Either he researches for the house the (famous) person has been born and removes one building from the relation. Or he ignores the warning and thinks “WTF person relation. Relations are not categories. It is the own fault of people creating/using this type of relation if it is broken.”
Now imagine, he uses iD (I still hate iD in some parts). I don’t know what iD will do. Either nothing, something strange or something more strange. But iD will do something – the user won’t be warned.
We do not need collective relations since we have got Overpass API and other simple database query tools. For the stolperstein example: Ask Overpass API for all memorial= inside a boundary relation.
OSM is for Geographic Data
OSM is designed and used to collect, store and provide geographic data. You all know our basic rule “We map what’s on the ground.”, don’t you? Ok, there are a few megabytes of data which are not “on the ground” like boundaries and public transport rules, but they are exceptions you find on much maps and that’s why they are in OSM.
Personal Rights and Right to be Forgotten
You all know the Right to be Forgotten introduced for whole EU this year making Google et. al. to hide entries. How long will it take until a living person asks Data Working Group to delete her place of birth because he/she was born in a town quarter with bad reputation?
Even the descendants of dead persons have personal rights. They could cause deleting requests. (Ok, boundary issues probably are a important part of DWG work … Ukraine vs. Russia, China vs. India, Kosove vs. Serbia, …)
If you still want to store this data in OSM …
… why don’t you tag tombs with multiple persons inside as
cementary = grave
grave:inside = Joe Average (1920-08-04 to 2001-01-15); Maria Average (1919-11-02 to 2009-02-27)
grave:ontop = nice flowers
if the grave is mapped as area or node.
Or instead on the tombstone:
historic=tombstone
inscription:machine-parsable=Joe Average (1920-08-04 to 2001-01-15); Maria Average (1919-11-02 to 2009-02-27)
I think that we should not map place of birth. Grave durate long on graveyards, have tombstones (in Europe) with names on it. Signs with names of people being born in a building usually do not exist (apart from famous persons). If the building is/was a hospital, the list might become very very very long. That’s why birth information should only be tagged on buildings if there is a sign in- or outside the building “Angela Merkel was born here.” or this information is available in public accessible sources.
Why don’t you store genealogic information in an open genealogy database? Let’s call it OpenGenDB? [1] If OpenGenDB has an open license, I would not disagree adding ref:opengendb=person-id to the grave.
To summarize: OSM is not the right place to store informations about relationships between persons. It is for geodata (place of grave and maybe place of birth, if public accessible).
Best regards
Michael
[1] Hereby I abandon all rights of the name OpenGenDB in all types of writings if I have these rights.