Использовать новые фичи

AMDmi3 commented 11 years ago

Как напоминалка:

добавляем поддержку любых значений тэгов через "tags": [ "key": "*" ] (можно добавить электростанция: power=generator + generator:output:electricity=*)
добавляем поддержку синонимов через словарь. Ключ replace_with: "другой объект" в словаре обрабатывается следующим образом:
- объект обрабатывается как другой объект
- категория с replace_with не показывается в дереве POI
- опционально также добавляется ключ replace_reason="deprecated|similar|..." для указания причины замены

Таким образом:

все тэги остаются в каталоге как отдельные объекты, что полезно для справки
поведение синонимов можно настраивать в зависимости от страны (скажем, в другй стране tailor и dressmaker - не синонимы)
есть информация характере замены, ибо устаревание (highway=ford -> ford=*), одинаковость значения (craft=tailor/dressmaker) и просто ненужность отдельной сущности для определённых объектов в дереве POI (island/islet) - разные вещи.

Для =* нужна отмашка @ErshKUS , второе обратно совместимо и его можно постепенно внедрять. Алсо, нужно не забыть обновить описание схемы в wiki.

ErshKUS commented 11 years ago

добавляем поддержку любых значений тэгов

сделано, в вики добавил

kiselev-dv commented 11 years ago

добавляем поддержку синонимов через словарь. Ключ replace_with: "другой объект" в словаре обрабатывается следующим образом

Что делать если replace_with и заменяемый имеют разные доп. теги или разных родителей в каталоге? Ну и может так и обзавем synonims:["synonim1", "synonim2"]

synonims:["synonim1", "synonim2"] при этом инвертирует смысл по отношению к replace_with но при этом гораздо нагляднее кто основной а кто вспомогательный (удобно для пресетов) и не нагенеришь циклов.

ErshKUS commented 11 years ago

Я категорически против синонимов, когда сказано что магазин спорттоваров это key1=val1 или key2=val2, без указания какой первичнее, какой устаревший и пр.

kiselev-dv commented 11 years ago

Давайте ка я по подробнее объясню. По большому счету это лишь вопрос записи.

Допустим есть 3 категории

A     B     C

C заменена B, B в свою очередь заменена на A

С точки зрения машинной обработки нет разницы, как это указанно, через ссылки у B и С или через список у A. Это влияет на удобство заполнения человеком. Тоесть я нахожу в словаре поиском "Букмекерскую контору" которая задана как перевод для shop_bookmaker и вижу в синонимах что так же для нее допустимо office_bookmaker

"shop_bookmaker": {"name": "Букмекерская контора",
     synonyms: [office_bookmaker]
}

И если знаю ещзе синонимы то просто добавляю их. Имя основного объекта каталога "shop_bookmaker" записано вместе с его возможными заменами. Основной набор тегов - тот что на shop_bookmaker, его пищем в базу. Те теги что на office_bookmaker используем по желанию. Переводы синонимов при этом опциональны, достаточно чтобы они были описаны в каталоге, плодить для них совпадающие переводы не обязательно, но если хочется то можно (например чтобы вики указать).

Если хочется указывать причину, хотя все будут лениться и указывать всегда "deprecated", можно вместо массива использовать хэш:

"shop_bookmaker": {"name": "Букмекерская контора",
     synonyms: {office_bookmaker":"deprecated"}
}

Ключ synonims обсуждаем, если не достаточно понятно какие пары key=value основные, а какие допустимые. Возможно какиенибудь old_values будут понятнее.

Мне просто кажется что проставляя ссылки, проще напортоь и проставить ссылку не на ту запись или еще как ошибиться.

"shop_bookmaker": {"name": "Букмекерская контора"},
//тут еще куча левых записей между ними
//записи сортированы по алфавиту
//так что здесь может быть не один десяток строк
"office_bookmaker":{
    "name": "Букмекерская контора", 
    "replace_with": "shop_bookmaker", 
    "replace_reason": "deprecated" 
 }

Ну и в переводе сразу 1 запись для основного объекта каталога а не 2 десятка со ссылками.

Впрочем такая запись не лишена приемуществ: например тут основная запись получается лаконичнее.

Послесловие:

Еще раз повторюсь, это помоему лишь вопрос записи, программировать примерно одинаково, просто каталог мы покашто заполняем вручную и такой способ записи мне кажется удобнее. Но меня устроит любое решение данного вопроса, лишь бы оно было принято раньше чем я начну писать это :)

ErshKUS commented 11 years ago

что то я не вижу особой разницы между, в плане допустить ошибку

"shop_bookmaker": {"name": "Букмекерская контора"},
//тут еще куча левых записей между ними
//записи сортированы по алфавиту
//так что здесь может быть не один десяток строк
"office_bookmaker":{
    "name": "Букмекерская контора", 
    "replace_with": "shop_bookmaker", 
    "replace_reason": "deprecated" 
 }

и

"shop_bookmaker": {
    "name": "Букмекерская контора"
    "synonyms": {"office_bookmaker":"deprecated"}
},
//тут еще куча левых записей между ними
//записи сортированы по алфавиту
//так что здесь может быть не один десяток строк
"office_bookmaker":{
    "name": "Букмекерская контора"
 }

kiselev-dv commented 11 years ago

~~Скрипач~~ "office_bookmaker" не нужен.

Но в общем то вариант со ссылками меня тоже устроит.

AMDmi3 commented 11 years ago

Мы в своё время в приватной беседе с @ErshKUS решили примерно следующее (сейчас будет то что я примерно помню из беседы, скорее всего оно отличается от того что мы реально решили): в _словаре_ (потому как синонимы могут быть разные для разных стран) нужно добавить ключи "replace_with": другой объект + "replace_reason": причина которые ссылаются на объект/moretag которым должен заменяться текущий объект/moretag с объяснением причины, например:

"replace_reason": "deprecated" = текущий тэг устарел, однозначная замена на указанный - для пресетов JOSM текущий тэг можно игнорировать полностью
"replace_reason": "same_as"/"prefer"/"synonym" (нужно выбрать более подходящее) = значит что среди тэгов определяющих одно и то же следует использовать указанный (например, tailor/dressmaker, watchmaker/clockmaker (см. issues про пробелмы с этими тэгами))
"replace_reason": "generalize" = значит что для каталога POI нужно использовать определение указанного тэга (например, для place=island/islet), для пресетов же нужны оба тэга

написав это, я подумал что правильнее будет для каждого пункта из вышеперечисленных сделать отдельное свойство (по-прежнему, в словаре):

"deprecated": другой объект
"same_as": другой объект
"generalize": другой объект

потому как одни флаги влияют на обработку в дереве POI, другие - на генерацию пресетов.

Примеры использования:

generalize

place=islet (с переводом "островок" либо "маленький остров") помечается как "generalize": "island" (при том что place=island переведён как "остров"). Для дерева POI эти объекты = одно и то же под названием "остров", для пресетов же это разные объекты "остров" и "маленький остров". Возможно, в будущем потребуется ввести генерализирующие объекты без тэгов вообще ("остров" без тэгов, "крупный остров" place=island, generalize=остров, "маленький остров" place=islet, generalize=остров), но давайте пока не забегать.

same_as

Для тэгов, значение которых для нас совпадает (например watchmaker/clockmaker, см. #37). Пусть мы решили что часовую мастерскую мы обозначаем как clockmaker, тогда watchmaker мы помечаем как "same_as": "clockmaker" - тогда osm.ru приравнивает watchmaker к clockmaker и показывает только один тип POI в дереве, пресеты делают аналогично.

deprecated

Скорее всего, на данном этапе обрабатываются в точности как same_as. Но вообще, например, osm.ru может вовсе игнорировать объекты с "deprecated": *, побуждая мапперов обновлять их до новой схемы, а валидаторы могут, наоборот, показывать объекты отмеченные как deprecated с явным указанием заменить их на новый тэг.

Как-то так.

kiselev-dv commented 11 years ago

Ок, принято.

ErshKUS / osmCatalog