Ну вы тут нафантазировали Короче я понял, сначала нужно выложить прототип а потом его обсуждать. Просто проблема в том что я пока даже не знаю сколько времени этот самый валидатор работать будет чтобы рассказывать о процедуре. Если (я утрирую) валидатор будет отрабатывать 27 часов то что-либо говорить о ежедневном валидаторе глупо.
Кстати, я достиг пре-альфы То есть формируется список административной вложенности всех элементов до сельских и городских поселений включительно на основе данных ОСМ. Теперь нужно доделать некоторые мелочи что я оставил на сладкое и скрестить ОСМо-данные с эталонным справочником. Вот тогда будет альфа.
Раз уж альфа близка, может кто-нибудь поможет с макетом веб-страниц? В идеале - пара страниц с Дежинского валидатора (html/css/js) и тогда я сделаю визуальную часть максимально близкой к прежнему валидатору (я делаю всё кроме улиц!!!). Альтерантива - пара крупных скриншотов с прежнего валидатора. Иначе я всё сделаю в минималистическом академическом стиле
Время до 27 часов - это с самописными алгоритмами или что-то стандартное для затратных операций всё же используется? Если не PostGis, то, может, Oracle Spatial или С++/Java либы типа GEOS или JTS topology suite?
Я 27 часов написав добавив (утрирую), т.е. сначала получаем время работы а потом придумываем схему выгрузки результатов. Я ещё не готов сказать сколько всё это чудо будет работать, так как не уверен что все ветки отработали. Но на данный момент задача по загрузке файла bz2, распаковки, загрузки в БД занимает больше времени чем вся работа валидатора.
А алгоритмы все самописные. Полный хардкор, так сказать Но у каждого свои слабости, Вы же не знаете, какую кафедру я закончил
Формат основан на библиотеке protobuf
Общий принцип у protobuf такой - берётся описание формата в виде файла .proto (файл для pbf) и при помощи компилятора protoc генерится код парсера на необходимом языке. Искаропки поддерживаются C++, Java, и Python, но можно прикрутить и другие языки.
Тут есть готовый набор Makefile/build.xml/pom.xml для C++ и Java - https://github.com/scrosby/OSM-binary
Тебе для какого языка?
Гораздо более простой алгоритм это сделать выгрузку в postgresql затем с помощью ежеминутных дампов обновляешь БД. в файле стиля пишешь необходимые тэги : ) а с bbox обрезаешь
Я сделаю маленькое предположение то что если разделить файл bz2 или распакованный но поместить его на другой hdd не с бд, то это даст прирост , т.к. всё (?) упирается в io fserges Какую кафедру закончил?))) Думаю связанную с алгоритмами
У меня вопрос концептуальный … после того как я обнаружил что куча объектов не попадает в БД стал разбираться … При написании фильтра я отталкивался от такой информации:
В общем у нас в основном используется type=boundary что логично - это специфическое отношение. Тем не менее type=multipolygon тоже относительно распространён. Нет, я понимаю что софт должен понимать что хотел сделать пользователь который не знает чего хочет. Насколько правильно ставить на отношения границ type=boundary или type=multipolygon? Или вообще type=* в ОСМ не имеет особого значения, софт всё сам должен распознать?
fserges, тут не как в кадастре, тут как в естественном языке. Железных правил нет. type=boundary - правильнее, но type=multipolygon тоже встречается, особенно если на нем же place=*. В данном случае type=multipolygon лучше обрабатывать.
Раз уж так пошло … А есть ли у нас правила относительно использования буквы “Ё”? Я стараюсь держать БД с “Ё” но в ОСМ это далеко не всегда так … вот типичный пример:
Но
Я отбраковываю такие записи, но каково мнение сообщества относительно Ё? Валидтор должен делать вид что такой буквы нет в русском языке?
Автор JOSM-а пошёл дальше, и сделал автозамену type=multipolygon на type=boundary если стоит тег boundary=administrative. Замечание про то что в паре с place=* это неправильно было проигнорировано.
Я бы не много поспорил с данным утверждением. ОСМ является БД, БД должна заполняться по некоторым правилам. Есть схема тэггирования атд, и она должна быть едина на всей территории РФ. Поэтому я думаю, что их не стоит обрабывать. Или можно выделять как отдельный вид ошибок типа неправильного обозначения.
Любое действие должно иметь цель. Если есть два популярных варианта обозначения одного и того же, а я один из них отбрасываю, объявляя “неправильным”, то хуже я сделаю прежде всего себе - я просто останусь без части нужных мне данных.
Короче я понял, сначала нужно выложить прототип а потом его обсуждать. Просто проблема в том что я пока даже не знаю сколько времени этот самый валидатор работать будет чтобы рассказывать о процедуре. Если (я утрирую) валидатор будет отрабатывать 27 часов то что-либо говорить о ежедневном валидаторе глупо.
Но у каждого свои слабости, Вы же не знаете, какую кафедру я закончил 