Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

freeExec · 2013-10-27 07:30:59

Я остановился на уровне Сельских поселений, описательных границ деревень нет наверное в принципе.

lenux · 2013-10-27 07:48:26

Для меня иногда было загадкой как работал тот валидатор и какие проверки он выполнял, что для него было первичнее addr:* или отношение того района? Потому что сейчас понимаю, то что может это даже к лучшему, что его уже нет.
И надо не забывать одну простую истину в том, что хорошо отмаппить можно знакомые места, отмапить не тщательно, а обще можно только область. Поэтому области типа ЯНАО, Чукотки и т.п. остаются как бы не тронутными особо, т.к. нет активных мапперов живущих в них. Всё равно как то получается, что "эффективный " маппинг остаётся на уровне области (даже не в целом, а скорее даже до некоторых районов). Т.к. в ином случае не получить качественную и подробную карту. Слишком много для одного человека.

fserges Я может забегу вперёд, но хочу поинтересоваться: Тот валидатор что пишешь сейчас будет с открытым исходным кодом, что можно будет присылать патчи : ) ? И на какой основе он будет обновляться?

fserges · 2013-10-27 11:14:51

Хм, а как вот такое создать можно? Объект украинский, но в обрезку России попадает:

name = Ромашкове
place = village
Точки:
768487124
768487126
768487128
768487132
768487134
768487136
2484178767 (содержится в линии Знобовка (240707932))
2484178767 (содержится в линии Знобовка (240707932))
768487142
768487144
768487145
768487147
768487149
768487124
http://www.openstreetmap.org/browse/way/61639105

Это "created_by = iD 1.2.1". На контуре вея одна точка задублировалсь! Алгоритм проверки замкнутости вея бежит по контуру и один из сегментов нулевой длины! Это бага iD или такое и в JOSM создать можно? Данный набор правок довольно свежий, от 5 октября 2013 года.

akks · 2013-10-27 13:30:16

fserges wrote:

Хм, а как вот такое создать можно? Объект украинский, но в обрезку России попадает:
...
Это "created_by = iD 1.2.1". На контуре вея одна точка задублировалсь! Алгоритм проверки замкнутости вея бежит по контуру и один из сегментов нулевой длины! Это бага iD или такое и в JOSM создать можно? Данный набор правок довольно свежий, от 5 октября 2013 года.

Есть (или были) такие баги у ID. В JOSM-е с такое сделать сложнее, но если игнорировать предупреждения при выгрузке или импортировать откуда попало - тоже можно (пару багов таких исправили в последний год, в т.ч. в FastDraw и угловой привязке).

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

Last edited by akks (2013-10-27 13:33:03)

lenux · 2013-10-27 14:40:12

fserges wrote:

Хм, а как вот такое создать можно? Объект украинский, но в обрезку России попадает:

Контур обрезки всегда можно изменить;)

StreloG · 2013-10-27 16:59:30

freeExec wrote:

Я остановился на уровне Сельских поселений, описательных границ деревень нет наверное в принципе.

в старом еще сравнивало
http://www.openstreetmap.org/browse/way/31001870
http://www.openstreetmap.org/browse/node/438264676
place_name = Дегтярск name:de = Degtjarsk
в 7дорог выводится Degtjarsk не в поиск, на карту

и такое, ну это к amdmi3
(с Пт, 28 окт. 2011) http://www.openstreetmap.org/browse/way/81809576
(сама ул. Вт, 15 нояб. 2011) http://www.openstreetmap.org/browse/way/51981482
да давно не заглядывали http://addresses.amdmi3.ru/?zoom=14&lat … layers=B0T
неужто нельзя автоматом исправить?

fserges · 2013-10-27 17:02:33

wowik wrote:

fserges wrote:
wowik wrote:
дефолтная роль outer
Дефолтный когда?.
Outer для линии применим, про них и речь

Ну тут мне вообще шикарный объект попался, специально для wowik

admin_level = 8
boundary = administrative
name = Сорожское сельское поселение
Линия 115837530 в роли outer
Линия 115837524 в роли outer
Линия 116744458 в роли outer
Линия 115837525 в роли outer
Линия 115837538 в роли outer
Линия 115837528 в роли outer
Точка Сорога (611557514) в роли admin_centre
Линия Залучье (217276754)
Линия Сорога (88270448)
Линия Покровское (88270450)
Линия Кравотынь (176085316)
Линия Дубок (112629650)
Точка Пески (639116898)
Линия Пачково (217721228)
http://www.openstreetmap.org/browse/relation/1608427

Что имеем:

1) 6 линий порождающих outer
2) точка admin_centre
3) 6 линий без роли которые находятся внутри outer, т.е. или фигня или inner
4) точка без роли
5) 3 контура имеют пересечения ...

Объект пришёл в такой вид 13 апреля, т.е. пол-года назад ... Линии и точки без роли - зло, их нужно лечить ...

fserges · 2013-10-27 17:18:58

lenux wrote:

fserges Я может забегу вперёд, но хочу поинтересоваться: Тот валидатор что пишешь сейчас будет с открытым исходным кодом, что можно будет присылать патчи : ) ? И на какой основе он будет обновляться?

Отвечаю негативно, но про это я писал ещё в самом первом посте. Валидатор поставляет данные для некоторого стороннего решения. Поэтому интегрируемость валидатора в это решение является ключевым требованием в ТЗ. Из кода я не делают секрета, но он пишется на языке для одной из экзотических корпоратиных баз данных поэтому маловероятно что кто-то сможет его использовать, но теоретически решение можно сделать доступным, так как есть бесплатная однопользовательская версия. Но вряд ли кому-то будут интересны танцы с бубнами вокруг ещё одного софта. Сделано это намеренно поскольку миграция всей системы в Postgres гораздо более тяжёлая операция чем добавление ещё одного модуля в работающий комплекс. Ну не знаком я с Postgres или SQL ... Вот буду переводить весь комплекс на Postrgres тогда и смогу заняться обратным портированием, но не раньше. Time.

Теперь позитивно. Данные работы алгоритма вполне себе общедоступны, я их могу регулярно выкладывать в требуемом виде. Качество данных АТД не просто некая идея-фикс для меня а требование продукта над которым я работаю (уже не один год к слову). Поэтому поблажек не будет

lenux · 2013-10-27 18:53:16

fserges правильно ли я понял, что в текущем в виде для этого проекта поддержка всего АТД России будет выполнятся одним человеком, который будет запускать алгоритм(или количество ошибок вполне по силу исправить одному)? Можешь описать как это всё видишь?

Конечно с экзотическими вещами я не думаю. что будет кто-то разбираться

Paspartu · 2013-10-28 01:47:47

Что то я не понял. Валидатор будет как был? т.е. зашёл на некую веб-страницу, увидел что хотел, воспользовался/исправил.
Или это возня mr. fserges для некого коммерческого проекта, от которой простым пользователям прока не будет?

fserges · 2013-10-28 08:30:51

lenux wrote:

fserges правильно ли я понял, что в текущем в виде для этого проекта поддержка всего АТД России будет выполнятся одним человеком, который будет запускать алгоритм(или количество ошибок вполне по силу исправить одному)? Можешь описать как это всё видишь?

Ну вы тут нафантазировали Короче я понял, сначала нужно выложить прототип а потом его обсуждать. Просто проблема в том что я пока даже не знаю сколько времени этот самый валидатор работать будет чтобы рассказывать о процедуре. Если (я утрирую) валидатор будет отрабатывать 27 часов то что-либо говорить о ежедневном валидаторе глупо.

Кстати, я достиг пре-альфы То есть формируется список административной вложенности всех элементов до сельских и городских поселений включительно на основе данных ОСМ. Теперь нужно доделать некоторые мелочи что я оставил на сладкое и скрестить ОСМо-данные с эталонным справочником. Вот тогда будет альфа.

Раз уж альфа близка, может кто-нибудь поможет с макетом веб-страниц? В идеале - пара страниц с Дежинского валидатора (html/css/js) и тогда я сделаю визуальную часть максимально близкой к прежнему валидатору (я делаю всё кроме улиц!!!). Альтерантива - пара крупных скриншотов с прежнего валидатора. Иначе я всё сделаю в минималистическом академическом стиле

И да, начиная с альфы я создам отдельную ветку.

akks · 2013-10-29 09:03:30

Время до 27 часов - это с самописными алгоритмами или что-то стандартное для затратных операций всё же используется? Если не PostGis, то, может, Oracle Spatial или С++/Java либы типа GEOS или JTS topology suite?

Last edited by akks (2013-10-29 09:04:21)

lenux · 2013-10-29 16:58:24

fserges например получение для Москвы: Город, улица, номер дома.

(SELECT sp.name, bpp.a_strt, bpp.a_hsnmbr FROM "settlement-polygon" as sp
INNER JOIN "building-polygon" as bpp ON (bpp.a_hsnmbr <> '' and bpp.a_strt <> '' and ST_Within(bpp.geom, sp.geom))
WHERE sp.name='Москва' )
UNION ALL
(SELECT sp.name, bpl.a_strt, bpl.a_hsnmbr FROM "settlement-polygon" as sp
INNER JOIN "building-point" as bpl ON (bpl.a_hsnmbr <> '' and bpl.a_strt <> '' and ST_Within(bpl.geom, sp.geom))
WHERE sp.name='Москва' )

БД взята после shp2pg (выгрузка RU для России) без всяких оптимизаций типа индексов. Выполнилось за 5 секунд для 63802 значений в результате.

Last edited by lenux (2013-10-29 16:58:51)

fserges · 2013-10-29 17:29:24

Я 27 часов написав добавив (утрирую), т.е. сначала получаем время работы а потом придумываем схему выгрузки результатов. Я ещё не готов сказать сколько всё это чудо будет работать, так как не уверен что все ветки отработали. Но на данный момент задача по загрузке файла bz2, распаковки, загрузки в БД занимает больше времени чем вся работа валидатора.

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

Sergey Astakhov · 2013-10-29 17:52:32

fserges wrote:

на данный момент задача по загрузке файла bz2, распаковки, загрузки в БД занимает больше времени чем вся работа валидатора.

Переходите на pbf, минимум в 2 раза быстрее чтение будет.

fserges · 2013-10-29 17:53:31

Sergey Astakhov wrote:

fserges wrote:
на данный момент задача по загрузке файла bz2, распаковки, загрузки в БД занимает больше времени чем вся работа валидатора.
Переходите на pbf, минимум в 2 раза быстрее чтение будет.

А чем этот pbf читать? Быстрый пробег по Гуглу мало чего дал ...

Sergey Astakhov · 2013-10-29 18:05:30

fserges wrote:

А чем этот pbf читать? Быстрый пробег по Гуглу мало чего дал ...

Формат основан на библиотеке protobuf
Общий принцип у protobuf такой - берётся описание формата в виде файла .proto (файл для pbf) и при помощи компилятора protoc генерится код парсера на необходимом языке. Искаропки поддерживаются C++, Java, и Python, но можно прикрутить и другие языки.
Тут есть готовый набор Makefile/build.xml/pom.xml для C++ и Java - https://github.com/scrosby/OSM-binary
Тебе для какого языка?

Last edited by Sergey Astakhov (2013-10-29 18:08:44)

wowik · 2013-10-29 18:46:11

fserges wrote:

А чем этот pbf читать? Быстрый пробег по Гуглу мало чего дал ...

Тут на мой вкус заморочек меньше: https://code.google.com/p/osmpbf2sqlite … e%2FOSMPBF

Last edited by wowik (2013-10-29 18:47:30)

lenux · 2013-10-29 19:25:13

Гораздо более простой алгоритм это сделать выгрузку в postgresql затем с помощью ежеминутных дампов обновляешь БД. в файле стиля пишешь необходимые тэги : ) а с bbox обрезаешь
Я сделаю маленькое предположение то что если разделить файл bz2 или распакованный но поместить его на другой hdd не с бд, то это даст прирост , т.к. всё (?) упирается в io
fserges Какую кафедру закончил?))) Думаю связанную с алгоритмами

fserges · 2013-10-29 19:53:47

У меня вопрос концептуальный ... после того как я обнаружил что куча объектов не попадает в БД стал разбираться ... При написании фильтра я отталкивался от такой информации:

Отношение boundary=* может использоваться для группировки границ, обозначения анклавов и эксклавов.
<relation id="1">
<tag k="type" v="boundary" />
<tag k="boundary" v="administrative" />
<tag k="land_area" v="administrative" />
<tag k="admin_level" v="2" />
<tag k="name" v="light green country" />
<member type="way" id="AB" role="outer" />
<member type="way" id="AC" role="inner" />
</relation>
http://wiki.openstreetmap.org/wiki/RU:Relation:boundary

В общем у нас в основном используется type=boundary что логично - это специфическое отношение. Тем не менее type=multipolygon тоже относительно распространён. Нет, я понимаю что софт должен понимать что хотел сделать пользователь который не знает чего хочет. Насколько правильно ставить на отношения границ type=boundary или type=multipolygon? Или вообще type=* в ОСМ не имеет особого значения, софт всё сам должен распознать?

Zkir · 2013-10-29 20:00:36

fserges, тут не как в кадастре, тут как в естественном языке. Железных правил нет. type=boundary - правильнее, но type=multipolygon тоже встречается, особенно если на нем же place=*. В данном случае type=multipolygon лучше обрабатывать.

fserges · 2013-10-29 20:02:12

Zkir wrote:

fserges, тут не как в кадастре, тут как в естественном языке. Железных правил нет. type=boundary - правильнее, но type=multipolygon тоже встречается, особенно если на нем же place=*. В данном случае type=multipolygon лучше обрабатывать.

То есть первое правило валидатора - нет никаких правил?

fserges · 2013-10-29 20:06:07

Zkir wrote:

fserges, тут не как в кадастре, тут как в естественном языке. Железных правил нет. type=boundary - правильнее, но type=multipolygon тоже встречается, особенно если на нем же place=*. В данном случае type=multipolygon лучше обрабатывать.

Раз уж так пошло ... А есть ли у нас правила относительно использования буквы "Ё"? Я стараюсь держать БД с "Ё" но в ОСМ это далеко не всегда так ... вот типичный пример:

admin_level = 6
boundary = administrative
name = Пономаревский район
type = boundary
http://www.openstreetmap.org/browse/relation/1396085

Но

Пономарёвский район — муниципальный район Оренбургской области Российской Федерации.
Административный центр — село Пономарёвка.
http://ru.wikipedia.org/wiki/%D0%9F%D0% … 0%BE%D0%BD

Я отбраковываю такие записи, но каково мнение сообщества относительно Ё? Валидтор должен делать вид что такой буквы нет в русском языке?

Sergey Astakhov · 2013-10-29 20:09:08

Zkir wrote:

type=boundary - правильнее, но type=multipolygon тоже встречается, особенно если на нем же place=*

Автор JOSM-а пошёл дальше, и сделал автозамену type=multipolygon на type=boundary если стоит тег boundary=administrative. Замечание про то что в паре с place=* это неправильно было проигнорировано.

Sergey Astakhov · 2013-10-29 20:12:12

fserges wrote:

То есть первое правило валидатора - нет никаких правил?

Разумеется. Валидатор не говорит что правильно или неправильно. Он говорит в чём отличие текущего состояния данных от желаемой картины.

Announcement

#1551 2013-10-27 07:30:59

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1552 2013-10-27 07:48:26

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1553 2013-10-27 11:14:51

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1554 2013-10-27 13:30:16

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1555 2013-10-27 14:40:12

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1556 2013-10-27 16:59:30

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1557 2013-10-27 17:02:33

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1558 2013-10-27 17:18:58

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1559 2013-10-27 18:53:16

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1560 2013-10-28 01:47:47

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1561 2013-10-28 08:30:51

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1562 2013-10-29 09:03:30

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1563 2013-10-29 16:58:24

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1564 2013-10-29 17:29:24

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1565 2013-10-29 17:52:32

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1566 2013-10-29 17:53:31

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1567 2013-10-29 18:05:30

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1568 2013-10-29 18:46:11

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1569 2013-10-29 19:25:13

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1570 2013-10-29 19:53:47

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1571 2013-10-29 20:00:36

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1572 2013-10-29 20:02:12

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1573 2013-10-29 20:06:07

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1574 2013-10-29 20:09:08

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

#1575 2013-10-29 20:12:12

Re: Проверялка границ по ОКТМО, НП по ОКАТО и улиц по КЛАДР

Board footer