Чудненько, по итогам вчерашнего обсуждения теперь у нас на одном нп два полигона - Петровское и Петровск 
(я не при делах, если что)
Не плохо бы чтобы и в ошибках эти нп тоже не высвечивались.
Забавно 
Но это не должно быть проблемой. Я как раз сейчас занимаюсь алгоритмом который использует как name так и alt_name. Надеюсь что завтра в выгрузке ему будет всё равно где какое название используется - альтернативное или традиционное.
Трудно сказать как лучше. Нужно будет отдельную проверку делать. Сейчас там стоит заглушка - если имена и типы совпадают то просто игнорировать. Может какой-то новый цвет придумать - неразличимые алгоритмом НП, так как красный и жёлтый имеют другое значение.
С alt_name возник вопрос. В большинстве случаев я там вижу что-то типа такого:
Т.е. в alt_name что-то написано латиницей и через точку с запятой. А не должен ли там тогда быть язык, alt_name:en=***? И насколько вариант с точкой с запятой лучше чем вариант alt_name, alt_name2, alt_name3, … Ну и вообще в alt_name встречается такая каша … Постоянно натыкаешься на что-то типа такого:
Я наверное специально такие названия выведу отдельным столбцом чтобы глаза мозолило бы
Для себя я беру просто alt_name до первого “;”
Ну такое или в official_name или в full_name
ага, город-герой-курорт Воронцовка - official_name
Я не планировал делать так поскольку валидатор “любит красоту”: есть сельские/городские поселения - будут НП, нет поселений - значит рука мапера не дошла до указанного района, валидация всё равно не совсем точна. Грубо говоря так стимулируется ввод поселений. Плюс я максимально придерживаюсь принципа - не мапить под валидатор, т.е. зачем подсказывать чего не хватает, НП должны заноситься исходя из независимых источников. А в целом я вижу что динамика создания сельских/городских поселений очень неплохая.
Это как раз и есть стандарное поведение, т.е. отображаются объекты отсутствующие на данном уровне иерархии, как говорится - наводится лоск.
Ну я не посмотрел, что это село, значит всё нормально пусть будет альт_имя.
Деревня посреди моря вообще не очень хорошо, не только именами…
Может быть. Тут ситуация аналогична обычному name.
Для многих применений лучше. Т.к. списки в модели OSM отсутствуют, эмулировать их можно либо наборами ключей (alt_nameN) либо наборами значений.
Обычно удобнее работать с фиксированным кол-вом ключей.
Лучше брать весь набор. Ну и кроме alt_name стоит рассмотреть использовать другие типы name, например old_name (для случаев когда эталонная база будет отставать в актуальности при всяких переименованиях).
у нас в области нет многих сёл, дорог и рек. это важнее сельских поселений. их ещё рисовать несколько лет, так что до поселений дело дойдёт совсем не скоро. лет через пять, например. я использую карту для туризма, и мне приоритетнее нарисовать реки, леса и грунтовки. т.е. через пять лет нарисуют поселения при условии, что появится кто-то заинтересованный этим. я был бы рад конечно, если бы это случилось раньше.
я уже приводил пример. гораздо легче понять в чём ошибка. т.е. валидатор показывает ошибку на “Костенки” и показывает, что нехватает НП “Костёнки” - понятно, что проблема в неправильной букве.
А может и валидатор не прав и там третий вариант посёлка. А тупо переправив букву это как раз и есть мапить под валидатор. А надо мапить то что есть в действительности.
а для чего нужен валидатор, как если не “править под него” ?
но вообще мысль понятна. предлагается скрывать некоторые данные, (отсутствующие НП) чтобы усложнить их добавление и исключить злоупотребления.
Валидатор обновлён. Столбец alt_name добавил, но оказалось что этот тег стоит в общем-то на точках, тогда как у меня информация пока берётся с контура. Вообще, ситуация когда - независимые точка и линия НП где информация может быть и там и там - анархична. Ну да ладно. Буду добавлять обработку информации с точек при наличии и точки НП и контура.
На заглавной странице по-прежнему висят suburb Рыбинска, но я так понимаю что это из-за того, что дамп был снят немного раньше чем правки. admin_level>9 у меня не рассматривается, поэтому данные suburb по идее не должны даже проимпортироваться.
Завтра валидатор обновлять не планирую - день будет очень суетный, не до компьютера. Но если вечером время образуется, то я бы предпочёл заняться улучшением обработки нежели прогоном валидатора.
Тут ситуация несколько сложнее, но в грубом варианте описано правильно. Дело в том что раньше информация по сельским поселениям была минимальной в ОСМ. Прежний валидатор более ориентировался на НП которых в большом количестве не хватало. На текущий момент видим следущее, в ОСМ есть 5548 сельских поселений из 18721. Это уже значительное число и можно валидатор делать более требовательным к наличию сельских поселений.
Валидатор нужен для того чтобы можно было бы понятие положение дел в любой точке страны. Например, у нас всё очень неплохо во Владимирской области тогда как в Липецкой - вообще всё плохо (одно сельское поселение из 289). Просто удобство поиска ошибок в отсутствии поселений не очень удобное.
Здесь другая проблема. Валидатор требует наличия сельских поселений и это разумно. Список поселений выводится на странице Хохольского района. Куда выводить несоответствия в населённых пунктах? Разумным кажется вывести населённые пункты из поселений, т.е. Костёнское поселение и внутри него все населённые пункты. Но сильно ли это поможет если поселение не создано в ОСМ? Ведь придётся лазить туда-сюда и сравнивать.
Если пойти другим путём (чтобы упростить нахождение ошибок на уровне района, т.е. сельские поселения вводиться не будут), как Вы предлагаете, то получится ещё большая каша на странице района и будет отутствовать стимул рисования поселений.
Можно пойти третим путём - воткнуть НП и на уровень района и на уровень поселения (если его ещё нет), но это ещё сильнее запутает так как населённые пункты раздвоятся.
Поэтому и принято текущее решение как наиболее нейтральное. Да, валидатор помогает, но если отсутствуют поселения то помощь не идеальна. Но это всё равно лучше чем ничего.
Что-то в таком духе планирую сделать, но это будет влезание в рабочий алгоритм и это нужно только если не введена большая часть поселений. Поэтому задача идёт вторым приоритетом и исправлю как разберусь с более срочными задачами.
Я тоже так думаю, но проблема в том что иногда данные бывают кривыми. На тот случай если сломаны границы/попали ошибочные объекты столбец “центр” и выводится. Его можно будет убрать когда ситуация с АТД более-менее стабилизируется, но пока я готов к любым ошибкам и держу этот столбец на всех уровнях.
В общем случае да, лучше брать весь набор. Но я посмотрел всё что введено по факту в РФ и могу сказать что поле alt_name по факту хранит что угодно, чаще всего аналог int_name в разных вариантах написания. После “;” я не нашёл ни одного осмысленного значения. Поэтому лишний раз делать проверку не хочется.
Ну а old_name это наверное слишком общий случай Мне в общем-то не сложно поменять и справочник, главное чтобы синхорнизация потом бы не затёрла изменения. Думаю что изменения административных границ будет более серьёзной проблемой нежели переименования
А почему не обрабатываются place=locality как заброшенные НП ?
fserges К вопросу о locality присоединяюсь, т.к. очень часто деревни делаю locality. Самый яркий пример такого locality, деревня Берёзовки, которая на всех картах помечается как полноценная деревня http://binged.it/1c4nTPg
Так же, что бы сэкономить время мапперов на поиск схем территориального планирования областей (с границами сельских поселений), их генеральных планов и т.д. Думаю в первом посте можно дать ссылку на http://fgis.minregion.ru/fgis/ где слева от карты нужно выбрать АТД (а не слои или кд).
Я уже отвечал как-то в этой теме - locality не является однозначнло населённым пунктом и по факту там много чего что не интересно валидатору. Т.е. если я подключу их то в отчётах повылазит куча мусора (с точки зрения населённых пунктов). Забавная статистика по миру (taginfo), locality используется 884 598 раз а village - всего 842 520, hamlet - 727 326. locailty - самый распространённый в мире вариант использования тега place.
Чтобы подключать locality в валидатор должен быть критерий который отделяет именованное урочище от формально населённого пункта, входящего в состав некоторого сельского поселения. Заметьте, это две формально большие разницы. Т.е. нужен какой-то специальный тег.
Хоть и костыль, но population=0 логически подходит.
Или наличие на place=locality ещё и адресной информации: addr:region, addr:district, addr:subdistrict
Именованное урочище, по идее, не должно иметь ни того, ни другого.