Вопросы по новому валидатору данных OSM

[fserges]

Как тогда выглядит код который позволит действовать в Lua? Я так понимаю что 1-1 не сделать, так как сначала обрабатываются узлы а лишь потом релейшены. Но во втором прогоне можно сделать больше работы чем в первом.

В первом я могу лишь отбросить данные точек и линий. Если это не place=city, village и т.п. - отбрасываем теги, нас дороги и здания не интересуют. Но данные могут быть нужны например, границам. А вот релейшены можно полностью обработать и оставить только те данные которые нужны.

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

Далее хорошо бы пробежать по линиям. Если это place=city, village и т.п. - заполнить таблицу places иначе - ничего не делать.

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

В итоге за 2 прохода мы имеем отдельную таблицу из релейшенов содержащих районы и округа, и 1-2 таблицы с НП (либо все в одной таблице, либо таблица для площадных объектов + таблица про точки).

А вот эти данные нужно проверять или строить под PostGIS.

[fserges]

У кого-нибудь есть код который действует примерно таким образом? Или кто-то может сказать - стоит так делать или нет?

В любом случае через неделю буду пробовать

[Zkir (Urban Eye)]

@fserges

У кого-нибудь есть код который действует примерно таким образом? Или кто-то может сказать - стоит так делать или нет?

Смотря в каком смысле “примерно”.
Я всегда именно так и делал. На первом этапе – выборка объектов, которые в дальнейшем планируется обрабатывать. Вопрос, как эту выборку делать.
Я обычно делал это через. osmfilter

Например, если планируется валидировать здания, то из russia.osm.o5m выбираются здания и записываются buildings.osm.

osmfilter russia-latest.o5m --keep="building=* >buildings.osm

И дальше с buildings.osm уже можно что-то делать. Чем-то его анализировать, куда-то его загружать, и.т.д.

При этом osmfilter умеет фильтровать типы примитивов отдельно.

--keep-nodes
--keep-ways
--keep-relations
--drop-nodes
--drop-ways
--drop-relations

Примечание: russia-latest.o5m используется потому, что osmfilter хорошо работает именно с форматом o5m, c osm.pbf кажется не работает вовсе.

Реальный пример см. тут: VFR_LANDMARKS_3D_RU/scripts/buildings_extract.bat at master · Zkir/VFR_LANDMARKS_3D_RU · GitHub

Можно, вероятно, то же самое на Lua. Я правда никогда так не делал))

[mini-me]

А точно нужно предварительно отфильтровывать данные для программы, задача которой находить в них ошибки? russia-latest весит каких-то 4Gb. Прямо скажем, не big data.
Тем более, кто-то вроде планировал валидатор вплоть до дома

[fserges]

Звучит смешно, но лет 10 назад я подумал, а не переписать ли мой валидатор на чистую Java?

Вот вкратце напишу алгоритм на чистой Java, никакого SQL или PostGIS! Поэтому я и не тратил никаrое время на PostgreSQL. Но мне было просто лень переписывать одну работающую систему на другую работающую.

Но если нужны разные валидаторы то лучше всё-таки делать в PostGIS. Решение нужно более универсальное.

Поэтому я хочу новую версию делать на PostGIS.

А сейчас - описание на чистой Java (если что, можно написать и на Python )

[fserges]

Я беру osm.pbf файл который не понимает чистая Java. Поэтому я использую osmconvert сначала. Я использую ключи –drop-nodes –drop-ways и другие чтобы получить только релейшены. Аналогично создаётся файл с линиями и точками. В формате osm который для Java - xml.

osmconvert --drop-nodes --drop-ways --drop-author --drop-version RU-20%curr_date%.osm.pbf >RU-20%curr_date%R.tmp

Стартует программа на Java. Сначала читает xml файл с релейшенами. Если релейшен - АТД, включаем в Map atd, если НП - np. Создаём отдельную Map-ы в которой идут точки и линии которые использует релейшен.

Потом проходим по второму xml файлу, перетаскиваем НП, заполняем мыпы линий с точками.

Потом тащим ноды. Заполняем Map np и вставляем координаты в Map-ы точки и линии.

Завершаем работу пересчётом BBOX на релейшены и линии.

Далее идет проверка пересечений АТД и НП.

[fserges]

Проверка пересечений на Java делается легко. Есть нюансы, но они не существенные. Большой плюс работы в ОСМ - все объекты состоят из линии. А их гораздо проще проверять чем круги и эллипсы.

Сначала мы проверяем bbox объектов. Если bbox не пресекаются, объекты не пересекаются. Если всё-таки пересекаются - надо проверять более тщательно.

Проверяем все отрезки с одного объекта по другому объекту. Проверка пересечения отрезков простая. Если bbox отрезков не пересекаются, то и сами отрезки не пересекаются. То есть проверить надо всего несколько отрезков. А разве это сложно?

ax + by + c = dx + ey + f

Проверка пересечения двух отрезков - элементарна!

Потом просто проверяем тексты в ОКТМО и в OSM.

Естественно что это не полное описание. Если релейшен “разломан”, то алгоритм выдаст странное значение, поэтому перед запуском нужно проверить валидность объектов.

[fserges]

То есть именно как задача АТД PostGIS не нужен. Очень простой Java код позволяет добиться результатов в нормальное время.

Но всё же вариант с PostGIS более универсальное значение. И более быстр если информации нужно обработать очень большое количество.

[freeExec]

Читаю я этот живой журнал и у меня есть что сказать.

1. План читать сначала релейшены, потом линии тут не нужен. Если ты решил что тебе этот релейшин (линия, точка) нужен, то система сама соберёт его части слепит объект и запишет в базу.
2. Отсюда лезет другой минус (ну для валидатора), битый объект просто не будет добавлен.
3. Хотя я там видел, что собираешься импортировать в режиме --slim. Хотя он не нужен, если собираешься обновлять базу не апдейтами, а нарезками дампов. Но возможно тебе захочется вот так изобрести велосипед и читать сырые данные ОСМ из той части. Тогда можно будет видеть все битые отношения и собирать его по кускам. Но это я считаю оверкил. Есть куда более простые тулзы по загону osm.xml в sqlite
4. ИМХО я бы оставался чисто в Java, если говоришь, что каких-то проблем с геометрическими операциями не испытываешь. А так же перешёл бы на чтение pbf, а не голого XML, который, можно сказать из коробки подталкивает к многопоточному чтению, ибо состоит из чанков.

П.С. Слишком глубоко копаешь. Вместо того чтобы сколотить скворечник, ты начинаешь изучать ботанику и как правильно выращивать деревья; железно-углеродную диаграмму стали, чтобы подобрать качественный гвоздь; и нанимаешься подмастерьем, чтобы учится у профессионала как правильно стучать молотком. А всего лишь надо было забить гвоздь в деревяшку.

Залевай в базу дефолт что предлагается. Пробуй запросы которые тебе дадут правильные ответы на твои вопросы. Потом уже будешь заниматься оптимизацией. Нужно уже пройти полный цикл и понять почему не подошло.

[alexey_zakharenkov]

@freeExec

2. битый объект просто не будет добавлен.

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

[fserges]

@alexey_zakharenkov

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

В этом то и вся соль! Результат работы валидатора - поиск ошибок разного типа, от геометрических до логических.

А создание “зелёных” страниц - как результат прогона тестов. Да, этот тест прошёл, классно!

Прогон валидатора это запуск тестов. Упало - 300 тестов, успешно прошло - 180 000 тестов. А не отчёт по сёлам и деревням.

[fserges]

Я уже не помню как это сейчас, но своё время можно было использовать линии в релейшенах как попало. Но я это считал ошибкой и выдавал “красный” цвет по таким записям. С одной стороны это не нарушало законы в ОСМ - “Ввожу данные как попало”. А я считал что данные нужно делать так чтобы их было проще автоматизировать. И потом руками правил огромную кучу релейшенов.

[fserges]

@freeExec

4. ИМХО я бы оставался чисто в Java, если говоришь, что каких-то проблем с геометрическими операциями не испытываешь. А так же перешёл бы на чтение pbf, а не голого XML, который, можно сказать из коробки подталкивает к многопоточному чтению, ибо состоит из чанков.

Кстати да, с Protobuf можно работать с непосредственно с Java. Если бы принял решение на Java то было бы проще самому прочесть а не использовать внешние тулы.

[Zkir (Urban Eye)]

@mini-me

А точно нужно предварительно отфильтровывать данные для программы, задача которой находить в них ошибки?

Ни один валидатор не может проверять всего, а создание геометрии в постгис посредством Osm2pgsql – долгая и тяжелая операция. Если Osm2pgsql молотит какие нибудь леса и озера, а их проверять никто не собирается, значит время расходуется в пустую.

[fserges]

Потихоньку иду с работой над новой версией валидатора. Хорошо что есть рабочая версия, которая рассматривает массу случаев …

Вопрос такой. Какие данные принадлежности Украине следует убрать из валидатора? Какие требования официальны в ОСМ?

Вот простой пример, но нужно и для районов и городов. У меня в текущем валидаторе стоит масса вариантов, но сейчас я бы хотел привести в порядок. Убирать только если поле X равно Y - так сказано в ОСМ.

[Zkir (Urban Eye)]

По моему, ничего “официального” в осм нет и никогда не было.
Отмеченные теги из валидатора можно просто исключить (никаких проверок для них не делать).

[fserges]

@fserges

Я никогда ранее не работал с PostgreSQL, поэтому имею много простых вопросов. Я буду задавать вопросы в этой теме. Буду мониторить ответы и пробовать сам. Вполне возможно что я найду ответ в доках раньше чем в теме. Если разберусь раньше - напишу об этом. Но если я отвечу не правильно - поправьте меня!

Звучит странно, но кажется я могу закрывать эту тему Черновик нового валидатора сегодня закончен. Остаётся ещё много чего допиливать, черновик далёк от финальной версии. Но сопоставление данных ОКТМО и ОСМ в программе на Java или создание html страниц - рутина. Мне помощь от OSM сообщества не нужна

Я как появлюсь дома - опубликую черновик. Вдруг эта информация покажется полезной.

Но вот где проблема есть, так это в бардаке ОСМ. Я хочу написать официальный валидатор, который может скачать и использовать любой человек из любой страны, хоть из России, хоть из Германии. Главное чтобы люди минимально настроили себе PostGIS и Java (нужен для запуска JOSM!)

Ссылку на валидатор нужно будет вставить в официальную страницу, например RU:Tag:boundary=administrative - OpenStreetMap Wiki или такую - RU:Key:admin_level - OpenStreetMap Wiki

Но валидатор будет работать только так как будет написано на ОСМ вики, никаких секретных данных! Но на мой взгляд у нас на вики бардак. Это было нормально 15 лет назад, но не сейчас.

Поэтому я создам отдельную тему в которой придётся прийти к каким-нибудь решениям. Чтобы валидатор проверял как в ОСМ выполняется описание, приведённое на Вики.

А если не будет никакого решения в Вики, значит валидатор и не нужен! Если валидатор не нужен сообществу, зачем тогда его делать? Тогда валидатор так и останется - в виде черновика.

Ну что, попробуем создать реально удобный продукт для любых пользователей в ОСМ?