В России нет формальных границ нп. Есть лишь границы поселений, в которых границы отдельных нп не определены или не всегда определены.
Например, у меня на даче нет границы деревни. Всё, что можно нарыть, это то, что есть два кадастровых квартала с довольно странными границами. Но кадастровое деление не является административным.
… и мы придём к тому, что у нас будет 100500 разных адресов у одних и тех же объектов: по навигатору, по валидатору, по ФИАС и тд. Зачем нам это нужно?
Иногда мне кажется что мы говорим на разных языках, поэтому приведу свой опыт. Я здесь ничего не предлагаю, только описываю свой опыт.
Я веду БД с “поселениями” около 10 лет и со всеми НП около 5 лет. Сколько и в каких регионах населённых пунктов можно подсмотреть здесь (данные немного устарели но порядок тот же) - http://www.gks.ru/free_doc/new_site/perepis2010/croc/Documents/Vol1/pub-01-03.pdf Раз в год (иногда чаще, спасибо “Большой Москве”) я эти данные актуализирую и ничего. Я не анализирую никакие геометрии. Я знаю что есть деревня Петрово Судогодского района Владимирской области и есть деревня Петрово Бабаевского района Вологодской области. Я это вбил один раз а могу извлекать сколькоо хочу. Зачем мне перечитывать иерархии или геометрии каждый раз когда мне нужна информация по какому-то району или по объектам относящимся к деревне Петрово? Даже если это относительно несложгная процедура - зачем? Количество НП не такое уж и большое и вполне валидируемое. Я читаю какие-то страшилки что “всё пропало”, деревень в России миллионы и новые деревни появляются сотнями если кто-то запортит одну-другую деревню то всё. Но ошибку найти легко и исправить.
Но итогом дискуссий я наверное считаю что лучше иметь валидный классификатор АТД/населённых пунктов у себя в личной БД, что либо улучшать в ОСМ бессмысленно ибо ничем кроме пустых споров не заканчивается. Просто наставлю костылей в программе импорта в мою БД и этого достаточно. А критические ошибки (сломанные границы, ошибки в названиях, вандализм) стоит предлагать как результат работы валидатора.
Повторюсь - это просто наблюдение, ничего менять в ОСМ я не собирался а теперь и подавно не собираюсь.
Это гараздо лучше чем пытаться эти костыли запихнуть в сам OSM. В процессе конвертации и так обычно много чего делается для адаптации исходных данных в формат, удобный для конкретной программы, причём у разных конвертеров разные вещи и требования к ним. Если каждый конвертер будет это тащить свои фишки в общую базу - ей станет невозможно пользоваться. Мне вот в своей программе нужен дорожный граф в направленном виде (по линии на каждое направление) с разбивкой по всем перекрёсткам. Если же подобное внести в исходную базу - это будет форменная катастрофа. Поэтому я сделал свой плугин к osmosis-у и спокойно пользуюсь им, никому не мешая.
Я боялся, что их миллионы. Если меня хватило (и ещё несколько активных мапперов до меня), то следовательно для 200к нас пунктов нужно порядка 33 (дада 33 богатыря:D и дядька Черномор) Даже если по 4-ре человека на область и у которых цель обмапить нас пункты, то всего 120-200 человек хватит, правда очень активных, а не делающих правки раз в день по 3-4 объекта(30 точек и 10 линий).
Так мы формально считаем границ нп -границу участков. Я так маплю деревни вообще от дома несколько метров, не обводя частные случаи у кого больше земли за домом у кого меньше. И все довольны. Главное в границы внести жилые дома.
Пока что у нас нет классификации для нас пунктов(чёткой до какого уровня указывать). Поэтому я не вижу ничего где было 100500 разных адресов . Хотя если с другой стороны посмотреть, всё кажется лаконичным. Например разработчики osm.org.ru вполне учли, что деревни надо искать и показывать по точкам, а на главном osm.org всё дублируется.
И как следствие главный вывод в том, что нам нужно наполнять базу. И если на текущем этапе программисты не знают как поддерживать 100500 копий, то завтра вполне и техника сможет, и программисты научаться.
Хотя я думаю мы говорим о разных вещах.
Пока из рассуждения я вообще честно говоря не понял что ты хочешь сделать (извини). Но если это был бы валидатор по твоим базам, то я наверное скажу, что не нужен.
В принципе задача довольна проста. Просто тебе тут её чрезмерно очень усложняют))))). Как сделать быстрый, простой и удобный валидатор НП:
Принять “стандарт”(я не говорю, что его должны “одобрить” я имею ввиду для себя для валидатора), что деревни например описываться должны так: Страна,область,район,название и не обязательные: тип,окато, октмо
По такому “стандарту” распарить ФИАС. Исходный файл я полагаю будет до 1 Гигабайта (т.к. фиас 1,5гбайт но там с улицами почт индексами и т.д.). Предположим, что 200к нас пунктов. Если очень грубо посчитать, что на каждую ячейку по 40 символов, юникод 8байт, значит для 200к деревень: 200000408*7/1024/1024=427мбайт. (Если с юникодом, а без него 53 мбайта)
3.1. С помощью osmfilter из local.osm или из planet.osm (по тех возможности) выбрать точки деревень (place=town|village|hamlet) с addr:country=RU, что из себя образует osm файл размером с несколькими может сотнями мегабайт (максимум). (на local.osm у меня вроде заняло минут 15-ть, или 10-ть и то всё упёрлось в hdd)
3.2. С помощью osmconvert из полученного ОСМ файла преоборазовать в csv где будет id, и 7-мь столбцов по “стандарту” (тут даже из файла п.3.1 всё делается молниеносно)
Мини итог: п.1-2 я не знаю сколько времени займут. 3-ий занял у меня час на чтение мануалов : )
Таким образом в идеале получится одна табличка с ФИАСом 100-500 мбайт, а другая с деревнями из ОСМ такая же. Т.е. в оперативку они войдут полностью. И задача будет сведена к сопоставлению двух массивов. Впринципе по желанию можно их будет загнать в любой инструмент который тебе будет удобен например SQLite , MySQL
Анализ этих двух табличек должен выдать результат в виде ещё нескольких табличек: 1. Деревни, которые есть в ФИАС, но нет в ОСМ 2. Деревни, которые есть в ОСМ, но нет в ФИАС 3. Деревни, которые есть в ОСМ, но нельзя сопоставить в ФИАС (например в ФИАСе 2 деревни с таким названием, а в ОСМ получилось 1 или 3 деревни)
И мои поздравления! Валидатор готов.
Мы же будет загружать и в том же Excel е смотреть результаты работы скрипта. Я думаю, что возможно в будущем можно на минутных диффах сделать такие обновления ;).
На самом деле - это обоюдное желание, программисты хотят изменений в осм, пользователи хотят новых сервисов от программистов. Положа руку на сердце, есть в осм вещи которые у большинства программистов вызывают дикую попаболь.
В рамках моих колупаний с ФИАС и ОСМ могу сказать: ФИАС по этой схеме вытащить можно. ОСМ сложнее.
Это связано с тем, что у ФИАС для каждого объекта прописан уровень, а у ОСМ не для всех (admin_level на тех же деревнях скорее исключение чем правило)
Ну если спросить лично меня, то я бы сказал так: есть база ФИАС. Поскольку она описыват существующее деление, то эти объекты должны быть в ОСМ. А еще в ОСМ должно быть много чего.
Так что главная задача - найти такое наибольшее множество данных, которое бы описывало бы и административные (ФИАС) и бытовые реалии, дополнив потом с обоих сторон. Тогда ОСМ сможет осуществлять привязку административной теории “к земле” (создав “заглушки” для чисто административных сущностей мы все равно дадим им больше реального воплощения чем строчка в документе, как сейчас).
Scondo вытащить из ОСМ можно и так (полагаю, что текстовый файл разделенный запятыми парсить легче чем xml или его потом зафигачить в удобную бд):
Для НП:
bzip2 -d RU-YAR.osm.bz2
./osmfilter RU-YAR.osm --keep=“addr:country=RU AND addr:region= AND addr:district= AND (place=town OR place=village OR place=hamlet OR place=city)” --drop-ways --drop-relations --ignore-dependencies > res.osm //Магия
./osmconvert res.osm --drop-ways --drop-relations --out-csv --csv-headline --csv-separator=“,” --csv=“@id addr:country addr:region addr:district place name” > out.csv //То же магия
После очистки от других областей в Calc (аналог Екселя в libreoffice) 5067 точно относится к области и ещё 1234 нп имеющих только названия и place . И одна просто точка деревни без названия.
Думаю эти 1к нас пунктов можно исправить за 3-4часа.
Теперь для улиц, к сожалению, я думаю подойдёт проверка только по cladr:code поскольку тэги вроде addr: не проставляются массово.
./osmfilter RU-YAR.osm --keep=“highway= AND name= AND cladr:code= AND cladr:suffix= AND cladr:name=” --ignore-dependencies > res.osm
./osmconvert res.osm --out-csv --csv-headline --csv-separator=“,” --csv=“@id@oname highway addr:city cladr:code cladr:suffix cladr:name name” > out.csv
Для Ярославской области(ЯО) всего 2632. По СГ 2445 улиц.
Теперь для домов. Я думаю, что минимум из тэгов на домах может висеть addr:city (проставляется быстро для всего города) , addr:housenumber - номер, addr:street- улица.
При желании получить кладр улиц, то см предудыщий пункт по улицам. Полагаю что названия города + улицы будет уникальным.
./osmfilter RU-YAR.osm --keep=“addr:city= AND addr:street= AND addr:housenumber= AND building=” --ignore-dependencies > res.osm
./osmconvert res.osm --out-csv --csv-headline --csv-separator=“,” --csv=“@id@oname addr:city addr:street addr:housenumber building name” > out.csv
Для ЯО получилось 17760 домов. Учитывая, что по СитиГиду 23886 адресов. А без addr:city (только улицы, дома и номера) получилось 25303 пункта, то можно тогда предположить, что просто это решается навешиванием addr:city
В заключение хочу сказать, что данные операции выполнялись быстро, на local.osm и тем более на planet.osm не получилось проверить. Т.к. это будет в моём случае не тест производительности этих приложений и способа, а тест моего жёсткого диска.
Так же что касается проблемы разрыва полигональных границ , то считаю что её следует вынести вне рамок данного валидатора. (и точно на первых этапах) поскольку её вполне можно заменить валидатором отношений , который бы на основе тэгов и проверял к примеру разрывы.
Есть ряд тэгов addr:country addr:region addr:district addr:city , который при правильном и аккуратном использовании поиска в JOSM проставляются массово и быстро. И я не думаю, что этого стоит боятся.
lenux, если вы не можете запрограммировать нам валидатор, то теги addr:city на всех объектах вам не помогут. Проверять геометрическую вложенность не сложнее, чем проверять тег.
Целостность данных для проверки геометрической вложенности поддерживать гораздо труднее. Отношения все время разламываются, а потом годами, как у Москвы, не чинятся.
Вот не надо пессимиз нагонять. Мультиполигоны place поддерживаются в очень приличном состоянии и довольно быстро чинятся. см. тут
А вот поддерживать тег addr:city на двухстах тысячах (!) объектах в МО человеческими силами невозможно. Это может только робот. Такой робот и был, кладр-бот, он проверял геометрическю вложенность и расставлял повсюду cladr:code (addr:* в одном флаконе). Потом протух.
Про Москву и область мы все помним сколько стоял битый полигон.
Всё верно, если отношение не поломано, то валидатор должен отслеживать непротиворечивость данных. Зато, если отношение вдруг отвалилось, то адреска при конвертации не рассыпется в одночасье.
. Хотя если с другой стороны посмотреть, всё кажется лаконичным. Например разработчики