Во время первого валидатора был сторонником проставить тэги на все деревни досконально. Повозившись с базой, да и в целом уже имея большой опыт участника в проекте, пришло осмысление некоторых моментов, пересмотрел некоторые стороны маппинга и т.п.
Так вот последние мои изыскания в том, что в нашей БД бардак! : D (Попытка пошутить)
А если серьёзно, то у нас нет концепций. Просто пример стоит или нет прописывать addr: ? Считать ли такое прописывание ошибкой?
Например во времена Дежиновского валидатора, что бы разобраться во всем это хитросплетении из отношений и т.п. прописывал в addr: , но даже сейчас иногда находятся оплошности вида точка с одним районом, а район совершенно другой чуть ли не в соседней области. Отсюда идёт целая вереница вопросов: Валидатор плох? Маппер плох? Концепция плоха? А что тогда правильнее?
Что бы понять суть в кратце предлагаю:
Принцип геометрической наследственности.
Считать ошибочным заполнением тэги входящие в противоречие с п.1.
Информация о каком-то объекте, может находится только в одном месте(!), например информация об области берётся только из полигона области, а адрес с домом ПОИ берётся из полигона дома, а информация о городе и области из соответствующих отношений.
Пояснения: Точка или полигон может содержать адресную информацию, которая в силу ряда причин не может быть извлечена из вышестоящих.
Пример: Россия, Ярославская область, Ярославль, дом 56, кафе ННН.
Отсюда следует, что бы замапить кофе, необходимо на нём иметь два тэга: amenity=cafe + name= “ННН” . Информация о городе из полигона города, об области из отношения области, а страна и так понятна :З
Так же я понимаю, что не всегда возможно к примеру провести границы МР, и я думаю в таких случаях является уместным прописывание . Ровно до тех пор пока не нарисована граница МР. Как только она будет нарисована этот тэг будет ошибкой.
Большое кол-во ошибок которые я сразу думаю обнаружатся дублирование на линии тэгов мультиполигона.
Что вы думаете об очистике базы от множества дублирующих тэгов?
Моя позиция:
Если addr:city addr:region addr:street и прочее на объекте соответствует действительности - не удалять ни в коем случае - не все программы/конверторы могут работать с полигонами region/city/dictrict и не всегда такие полигоны имеют место быть.
Вообще всю информацию соответствующую действительности добавленную другими пользователями удалять ни в коем случае нельзя
Добавлять или нет такие тэги на Вами создаваемые объекты - это Ваше право
dudka а смысл в их хранении? Если вдруг изменится название, которое прописано в 100500 местах, то если оно изменится, то и менять его надо будет в 100500 местах, а если оно в одном будет, то и менять его в одном. Paravoz а Вам не кажется, что это рисование в прихоть разработчикам ПО? Если есть принятое рисование (к примеру такая концепция), то это проблема валидатора, конвертора и т.п., а не проблема ОСМ? + изменение 100500 объектов если вдруг завтра Ваш любимый валидатор выпустит версию 2.0? Не думаю, что изменение такого большого кол-ва объектов произведётся в одно мгновение.
Фактически да, вложенность НП должна определяться либо по геометрии, либо по is_in, либо по отношениям.
Схема addr:* не предназначена для этого. http://wiki.osm.org/wiki/Key:addr
Поселок адреса не имеет (за отдельными исключениями, которые как раз лучше описывать addr:full).
Есть is_in:* - замена той самой вложенности полигонов для случая когда полигонов нет. Может использоваться для дублирования вложенности полигонов при желании.
Scondo насколько я помню из рассуждений о is_in это ещё до отношенновский период. Основная мысль которая у меня в первом посте пробегает это уход от ручной излишней дублёшки, к автоматически генерируемому контенту, по сути некий шаг к упрощеннию создателям валидаторов, рендеров и т.д. про который говорит Paravoz
lenux - это борьба с ветряными мельницами… В Беларуси благополучно пройден этап с так называемой “белорусской” адресацией основанной на релейшенах. Все было хорошо, круто, избыточной информации хранилось минимум - прямо как в Ваших пожеланиях - но в результате напрямую работать с данными было очень затратно, и в конце концов все было похерено Людей которые разбирались в этой адресации досконально было совсем мало, еще меньше было тех, кто с этим всем мог работать. После того как разработчики этой схемы самоустранились от ее поддержки - она практически сразу и померла - хотя ее рудименты в Минске так и остались - вот только кто это напрямую использует? Гораздо более правильно направить свою энергию не на удаление чужих якобы неверных с Вашей точки зрения данных а на добавление своих правильных И вообще - ведь проблем то нет глобально обрабатывать данные - в конце концов будет наверняка реализован валидатор, который еще будет и исправлять ошибки самостоятельно - уж лучше тогда в этом направлении работать. А на счет избыточности данных - все относительно - это все меньше и меньше волнует - это примерно то же самое что на java сейчас раздувая щеки ругаться с лозунгами что компилируемые языки быстрее работают. Ну быстрее… Ну и что дальше?..
Чего-то я вообще не понял - то есть рассматривается предложение вычистить из базы add… ??? Или как?
Сразу скажу от себя - я принципиально на все здания и схожие объекты добавляю add… - тк это нужно в дальнейшей работе с материалом. Нужно иногда очень оперативно вывести постройки определенного типа и определённого региона для поисково-спасательных нужд. Писать конверторы у нас просто некому)))
И никогда не помышляю над удалением чужих тэгов - хотя очень раздражает ferry на местных рейсовых трамвайчиках “Москва” ))))
Возьмем для примера простенький addr:country.
Теперь, внимание, вопрос. А есть ли в выгрузках по областям целиком границы государств, к тому же не битые, чтобы мне это 100% заменить геометрией?
Paravoz пока никто ничего не предлагает вычищать. Это просто пока что мысли с которыми я делюсь с сообществом))))…
Так это просто сделать! Ставишь Postgresql +postgis . Качаешь shp2pg (это колосально быстрее чем osm2pgsql ), потом составляешь банальный запрос SELECT’ом по тому полигону в котором это нужно. Будет табличка с нужной инфой : )
Они не настолько часто меняются, можно как с coastline - хранить их отдельно и периодически обновлять, предварительно проверяя на битость. А иначе вам придётся каждой точке проставлять addr:country.
Представил так на минутку: Поисковая операция: Ночь. Лес. Холод. Проливной дождь. Интернет через КВ-транссивер. Ноут на издыхающей батарее ))))))
А если серьезно я так и не понял какие реальные плюсы даёт удаление addr, ради чего все это затевается ??? Какая-то мифическая “очистка базы” - возникили какие-то ограничения ресурсов - дак сейчас с приходом F4 и этажи и крыши и цвета домов, а также их фрагментов заливается, колонны-надстройки всякие.
lenux, вы пробовали посчитать вот ту самую табличку, кто в кого вложен, только не для Москвы, а к примеру для РФ. После того как попробуете, запилите весь мир.
А когда надо-е-е-е-е-ест возвращайся назад,
гулять по воде, гулять по воде, гулять по воде со мно-о-о-о-о-й.
Поменять теги на 100500 объектах - не сложнее чем посчитать для них геометрическую вложенность.
Сильно плюсую Смотрю обрезку России (russia.osm) и болтается куча нп за пределами России. Если это НП в Беларуси то это легко видно - http://www.openstreetmap.org/browse/node/243047370 Нет, понятно, что я могу скачать planet.osm, построить все границы и убедиться что Засожье это населённый пункт в Мстиславском районе Могилёвской области. Это же несложно - простой SELECT. Но зачем, ведь:
Я работаю с обрезкой и мне не нужен planet.osm, я не хочу строить дерево АТД Беларуси
Привязка НП к районам вещь очень стабильная! Внесённая информация не устаревает годами
И таки легко валидируется - простой SELECT и список ошибок готов
fserges, mixdm я не борюсь, я знаю что это бесполезно). Тема скорее пофлудить, да и возможно более продвинутся в понимании ОСМа. Чем не вариант поправить poly файл? В СГ поправил теперь не одной ошибки по обрезке.
Людей которые разбирались в этой адресации досконально было совсем мало, еще меньше было тех, кто с этим всем мог работать. После того как разработчики этой схемы самоустранились от ее поддержки - она практически сразу и померла 