Учитывая объем данных - тема для отдельного проекта типа OpenGraveMap 
Тэг нужен другой; вместо этого тэга для дословного цитирования надписи, оказывается, есть inscription.
Возражаю. При таком тэгировании мы смешиваем данные о двух разных сущностях: о могиле и о захороненном в нём усопшем.
А то может еще оказаться такой вариант, что даты жизни у человека одни, а на могиле они указаны с ошибкой. Как в таком случае быть?
Предлагаю оставить даты, только если они указаны на самой могиле. Причём формат YYYY-MM-DD есть смысл расширить двумя значениями:
– yes – выяснено, что дата на памятнике присутствует, но не удалось узнать конкретную дату;
– no – выяснено, что даты на памятнике нет.
А для того, чтобы указать данные о самом захороненным, поляки придумали отношение Person.
Зачем, если по вхождению могилы в полигон кладбища можно определить?
Какой тэг в твоей системе предполагается для обозначения внешнего вида памятника?
Тема архиважная!
Пушкин даже не нашелся, что уж говорить про других… Местные наши могильщики использовали этот сайт как рекламную площадку, при этом “Records: 0/0” естественно. А ведь я слышал, что затевается инвентаризация захоронений. Уже и книги поистрепались настолько, что многих не найти по записям. Да и по могилам вряд ли восстановить получится. Прошлым летом регулярно мотались с женой на предмет поиска её прадеда. Так и не нашли, бардак полнейший…
Соглашусь. Правда думаю, что стоит его поместить в пространство имён grave:, т.е. использовать для надписей grave:inscription=, а не просто inscription=*. Хотя тут возникает вопрос, что делать с длинными надписями не помещающихся в лимит длины ОСМа.
Тут тоже соглашусь, т.е. схема дат сведётся к:
grave:birth=YYYY-MM-DD/yes/no (дата рождения указанная на памятнике, вне зависимости от её корректности, no - дата не указана, yes - дата имеется на памятнике, но по каким-то причинам не удалось её указать точно)
grave:death=YYYY-MM-DD/yes/no (дата смерти, аналогично дате рождения)
Хотя к схеме Person, лично я, отношусь достаточно скептически, и думаю что это уже выход за сферу данных которые стоит хранить в ОСМе.
Для облегчения работы софта (аналогично схемам использующимся для адресации). Вообще, я думал, что лучше это делать через отношение и включение могил в отношение кладбища с ролью grave, но вспомнив о кладбищах пятимиллиониках, решил, что такой подход будет не очень оправданным.
User defined, т.е. что пользователи занявшиеся картографированием могил решат обозначать, то и использовать, постепенно внося наиболее используемые в список для поддержания единообразия.
Не только, FamilySearch тоже интегрирован с billiongraves. Для справки, FamilySearch - создатель того самого формата GEDCOM, упоминавшегося тут.
Как и большинство молодых (создан в 2011) сервисов, созданных в США, он пока что популярен преимущественно там. Возможно, и в России альтернатива этому сервису появится (как в своё время Вконтакте - фейсбуку).
Пример маппинга кладбища в Вашингтоне: http://www.openstreetmap.org/#map=16/38.8805/-76.9790
А вот интересный пример маппинга участков кладбища во Львове: http://www.openstreetmap.org/edit#map=17/49.83240/24.05580 На карте мапник такое не отображает: http://www.openstreetmap.org/#map=17/49.83245/24.05581
Больше всего секторов кладбищ замаплено с тэгом cemetery=sector http://taginfo.openstreetmap.org/keys/cemetery#values
в Польше
http://overpass-turbo.eu/?key=cemetery&value=sector&template=key-value
На втором месте - Австрия и Чехия с cemetery=section: http://overpass-turbo.eu/?key=cemetery&value=section&template=key-value
На Find a grave больше записей, но там нет GPS-координат
http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GSln=Pushkin&GSbyrel=all&GSdyrel=all&GSob=n&GRid=1204&df=all&
Предложение для участков кладбищ: https://wiki.openstreetmap.org/wiki/Proposed_features/Cemetery_sector
Голосование не началось, а ты уже проголосовал, как так.
И потом там должно бы быть не name, а ref. Ну и area=yes мне кажется совсем не нужна, т.к. линейный сектор я себе не представляю.
Это важно? Ты переделаешь 1000 объектов, уже использующих тэг name?
Без area=yes - это не полигон. area=yes нужен везде, где определяется полигон, кроме некоторых случаев, где он предполагается по умолчанию (building, landuse).
А линейные границы сектора?
Да, вполне может быть именная могила где похоронены какие нибудь знаменитости, но она так же имеет свой порядковый номер, который всегда заносился в ref. И если 1000 оформлены неправильно, это не повод их поддерживать.
Не, не представляют, они должны быть оформлены в мультиполигон и представлять замкнутый контур. Мы же не рассматриваем стену от дома как полноценный дом.
Речь об участках. На участке обычно несколько сотен могил.
О могилах речи пока нет.
Поразительно, насколько участники ОСМ оторваны от реальности. Вам шашечки или ехать?
То есть вам абсолютно неважно, насколько удобно будет редактировать или использовать карту, главное чтоб теги были по феншую.
Удобство нисколько не страдает, наоборот поддержка однообразия. И да всё должно быть по феншую.
Немного поясню, почему был выбран этот набор тэгов.
cemetery=sector - безусловный лидер по количеству: https://taginfo.openstreetmap.org/keys/cemetery#values
cemetery=grave - обозначает отдельную могилу
cemetery=water - источник воды на кладбище, вероятно, слудует читать как “amenity=drinking_water + drinkable=no”
cemetery=section - то же самое, что и cemetery=sector, используется в Австрии: http://overpass-turbo.eu/?key=cemetery&value=section&template=key-value
cemetery=yes - также используется для участков
Смотрим комбинации:
cemetery=sector использует исключительно name.
cemetery=section использует name=“Участок N” + ref=N
То есть первый критерий - распространенность.
Почему я предпочитаю name и area=yes? Потому что так гораздо легче править в iD-редакторе без его изменения: легко выделить, легко увидеть имя (ref не отображается), легко ввести имя: http://www.openstreetmap.org/edit#map=16/46.3935/30.7044
То есть второй критерий - простота редактирования существующими инструментами.
Так как ни один рендерер не отображает ни ref, ни name, то третий критерий - простота использования - не выявляет каких-либо преимуществ одного тега перед другим.
Мне в принципе без разницы имя того или иного тэга. Главное, чтоб оно было каноническим, было легко редактировать и легко использовать (в идеале - рендерить в стиле мапника).
Я всё больше убеждаюсь, что osm - это не карта для людей, а предмет холиваров на тему именования тегов.
Оффтоп:
О нет. Мой мозг вывихнут. Наверное, лучше использовать man_made=water_well + drinkable=no.
Хотя ключ tomb по-прежнему находится в статусе proposed: http://wiki.openstreetmap.org/wiki/Key:tomb
не вижу причин его не использовать.
Странно, что в Польше и Германии с тэгами уже определились:
http://wiki.openstreetmap.org/wiki/DE:Key:tomb
http://wiki.openstreetmap.org/wiki/Pl:Tag:historic%3Dtomb
http://wiki.openstreetmap.org/wiki/Pl:Key:tomb
ref конечно хорошо (я только за!), но думаю будет недостаточно только номером идентифицировать. Есть пример того, что в разных частях одного кладбища встречается повторяющиеся номера. Подумайте, чтоб у участка еще был диапазон годов захоронения. Или дата первого захоронения.
И всё это не отменяет name. Так что спорить не о чем, надо в пропозал добавлять ref.
Лучше бы с информационными указателями порешали, на предмет их вывода из категории туризм. А то как-то неправославненько 