http://peirce.gis-lab.ru/qa/RU-YAR#citiessummary
Очень хорошо заметно, что на полигоне Гаврилов-Яма отсутствуют addr:region и addr:district
http://www.openstreetmap.org/browse/way/56254026/history
Что-то мне не нравится это пересохранение. Так при сбое можно текущий список потерять. Не хочешь отделить список карт на конвертацию от файла с результатами?
Раньше был костылём.Сейчас в нём смысл пропал. Т.к. названия деревень не дублируются.
В ЯО очень много Бинга высокого разрешения. К сожалению не вся область. Я как-то специально обрисовывал эти полигоны, так что на очень большом кол-ве из этих 5к деревень всё же полигоны есть. Поэтому я бы перефразировал так: В этих деревнях никогда не появится (если кто-то спец. не заедет или ПКК не будет, или планов) адрески, но всё будет прорисовано вплоть до дома. Например: http://openmapsurfer.uni-hd.de/?zoom=13&lat=58.28065&lon=37.81931&layers=B000000FTFF или http://openmapsurfer.uni-hd.de/?zoom=15&lat=58.03847&lon=40.65785&layers=B000000FTFF .
Как-то было дело в ЯО появился новичок из НЯКа и начал сносить точки, а полигоны оставлять. И как иначе подобное можно отслеживать и исправлять на 6к объектов (а т.к. точка и полигон то 12к) ? Поэтому не надо боятся в цифры в 5,7к нас пунктов, потому что если я правильно помню их должно быть около 6к. Те населённые пункты по бингу от которых вообще ничего не осталось удаляем полигон и переносим в place=locality (видимо оставшиеся 300 это локалити которых нет в этих 5.7к).
Так что в данном контексте я бы рассматривал точку не как “ошибку”, а как не домапленное. Потому что даже когда мапишь не всегда на все районы обращаешь внимание, а тут такой инструмент, который не даст возможности просмотреть какой-нибудь район. Правда половина областей сразу в непригодность покачеству придёт и думаю это правда:rolleyes:
Думал привести пример про большое кол-во нас пунктов, так в Костромской области их всего 3,5к -_-’ .
А по улицам там собрались ошибки, которые фиг знает как на самом деле то и исправлять . (к примеру лесотарная улица и Красная пл или наб. реки Черемхи )
К сожалению я не имею чёткого представления как можно было бы охватить все случаи. Иногда встречал две рядом деревни так что точки поменяты местами. А такой случай это учитывает? Что его точечный центр в км? Так же может имеет смысл сделать дополнительную табличку удалённые нп за прошедший месяц.
Если совсем честно, то нет. Потерять там ничего нельзя, потому что при каждом сохранении он бэкапируется.
SaveMapCreationHistory rsMapCreationHistory, OSM_FILES_DIR & "history.txt"
SaveMapCreationHistory rsMapCreationHistory, OSM_FILES_DIR & "history-log\history.txt-"&Year(dtMapDate)&Month(dtMapDate)&Day(dtMapDate)&Hour(dtMapDate)&Minute(dtMapDate)
При этом результаты таке же часть списка карт. Например нужно каждый раз увеличить номер версии на единицу.
Для защиты же от сбоев есть UPS.
Это я видел. Ну ок, пусть будет так.
Как лучше - сделать постоянно работающее приложение, которое в цикле крутит список или как в нынешнем скрипте - завершается после последней конвертации? Просто во втором случае при конвертации последних карт процессор уже будет простаивать, т.к. нечего будет запускать в параллель.
Нынешний скрипт тоже закольцован, просто он считает что russia.pbf и local-1.pbf достаточно обновлять раз в шесть часов. 
Как мне представляется, там надо как-то развести (скоординировать) обновление сорсов (*.pbf) и конвертации. Например, не надо обновлять russia.pbf, если в этот момент идет конвертация RU-XX, и наоборот, если в данный момент идет обновление russia.pbf, это значит что не надо запускать RU-YY. Иначе выдет конфуз.
Поэтому мне кажется, такая ситуация, что такая ситуация, что нечего запустить, потому что не обновлены сорцы (*.pbf) может возникнуть, и она нормальная. Надо просто их обновить, и только после этого запускать дальше.
Может быть, вообще, планировщик должен поддерживать “сродство” между картами и процессорами.
Например, если есть четыре логических процессора, то Россия запускается на первом, Европа на втором и третьем, весь остальной мир на четвертом.
lenux
Вопреки своему названию, валидатор не ставит своей целью отслеживать все что можно отслеживать. Ставится цель отслеживать те параметры, которые влияют на пользовательские качества карты (роутинг, адресный поиск, целое море), и нарушение которых требует немедленных действий (кто-то разломал границы НП и их нужно починить).
По поводу place_name. По-моему, это вполне нормальный тег) Если ты считаешь, что его нужно везде заменить на name, то что мешает так и сделать?
Если кто-то вандально удалит точку, а полигон оставит, то этот НП тут же появится в тесте “города без точечного центра”. Даже если это hamlet. Я подумаю, как его сделать более наглядным и доступным.
Я понимаю о чем ты говоришь. Это называется “отчет по детализации населенных пунктов”. В нем для каждого НП, пусть их даже 6000 должно показываться население и что нарисовано. Есть ли точка, полигон границы, сколько улиц, домов, адресов, пои.
Надеюсь мы проживем достаточно долго чтобы такое увидеть 
Пока этот отчет в зачаточном состоянии.
Zkir, отчего-то в отдельных случаях адресный валидатор считает ошибкой III типа вот такое:
addr:city=Киров
addr:housenumber=12
addr:place=слобода Лянгасы
building=house
В других же случаях addr:place успешно проходит валидацию.
Подавляющее большинство ошибок адресации в Кирове имеют именно такой характер:
http://peirce.zkir.ru/qa/RU-KIR/addr-map
Потому что он эти place все равно ищет, среди других объектов osm. Если находит, значит все ОК, если нет, то ругается
слобода Лянгасы сейчас представлена ввиде аж двух объектов, точки и полигона:
http://www.openstreetmap.org/browse/node/2045391745
http://www.openstreetmap.org/browse/relation/2706985
Но на обоих почему-то
name=Лянгасы
Предлагаю исправить на name=слобода Лянгасы
Первый набросок - https://github.com/sergeyastakhov/OSM/tree/master/osm2dcm
В скомпилированном виде - http://files.mail.ru/87FB1F33A6E540479EDB214C43E25E7A
Параметры настраиваются в config/config.properties, запускается через osm2dcm.bat
Проход по списку пока однократный (как в текущем скрипте), перенаправление вывода батников сделал индивидуально для каждой карты (создаются в каталоге, задаваемым processing.logDir), если сделать в один - там будет каша при параллельном запуске.
Пересохранение history происходит после каждого завершения конвертации, обновление maplist.xml - после каждого успешного завершения конвертации.
Форматирование history не делал, если нужно - можно добавить.
Посмотри, то ли это что нужно. Вполне может быть что я не совсем верно понял некоторые условия в коде скрипта.
Ух, спасибо.
Вопрос, правильно ли я понимаю, что runConversion() и runUpdate() запускаются без всяких взаимных ограничений, а то что я писал чуть выше, пока не учитывается?
update.bat - это же osmupdate, который скачивает дифы с осм и сохраняет их в папке-кэше.
- Если запустить одновременно update одного и того же файла, ничего хорошего точно не получится, если даже двух разных, то может испортиться кэш.
- Если запустить update russia.pbf пока в другом потоке из него osmconvert вырезает RU-SPO.osm, думаю тоже будет плохо.
Пока нет.
Ok, будем пилить дальше.
Надо посмотреть как там кэш организован, возможно всё не так страшно. Но если он не параллелится - организуем отдельную очередь.
Можешь словами расписать условия запуска update, а то в коде скрипта мне как-то не всё очевидно?
Там и вне кода не очень очевидно Идея, во всяком случае, была такая:
Есть некий цикл обновлений, например 30 дней. Если с момента последней попытки обновления данной карты прошло больше чем 30 дней, исходный файл (например greece.pbf) обновляется. При этом есть период (7 дней), в течение которого этот файл считается “новым” и обновлять его не надо (чтобы карты, только что пересчитанные, которые от него зависят (GR-1, GR-2, GR-3), не обновлялись снова и снова).
Просто папка с файлами, типа такой:
Выделил запуск обновлений в отдельный поток. Вроде конфликтов между update и make быть не должно (если какая-нибудь конвертация не затянется на 7 дней), для гарантии можно потом сделать полноценные блокировки запуска конвертации обновляемых файлов.
Новая версия - http://files.mail.ru/54F67210B304462B8AFC5FA24F739698
Вот интересно как это тестировать? поставить просто в процесс… или сделать сперва make.bat из одной команды pause…
Можно попробовать на укороченном списке из маленьких карт. Если всё будет нормально - можно будет уже попробовать полный список.
Скажи пожалуйста, а куда подевалось условие обновления? Что прошло больше 300 дней. Что-то я его не вижу…
Этот параметр - 300 дней хорошо бы вынести в конфиг.
И где он ищет pbf файлы, чтобы сравнить дату?
Зачем он пытается обновить france-H.pbf ?
Почему обновления расцениваются как неуспешные, если батник возвращает код ошибки 0?