Да, более чем успешно)
А что хм?
peirce.gis-lab.info - сейчас молотит германию и весь мир по кругу.
peirce.zkir.ru - обходит РФ и ближнее зарубежье в двухдневном цикле. Он быстрее, потому что делает только валидацию, без конвертации в СГ.
Все для вашего удобства 
Что-то после этого последняя дата валидации застыла на 2013-09-22
И на старуху бывает проруха. Починил полигон обрезки.
А вот границу воронежа так и не починили.
P.S.
Совсем не обязательно 10 дней ждать, чтобы сообщить о проблеме.
Боюсь сглазить, но вроде итальянцы начали потихоньку сами править свою обзорку. Надо позапуливать ссылочку на валидатор в другие сообщества.
А кто интересно более 2000 дубликатов в Шотландии исправил?
Ты представляешь, один из них писал мне в личку и спрашивал, когда, блин, будут регулярные обновления Италии.
Все упирается в быстродействие. Попросить что-ли кого нибудь переписать osm2mp на java ?))
А распараллелить обработку разных карт получилось?
Я даже близко не представляю, с какой стороны за это взяться.
Оно же должно не только распараллеливаться, но и синхронизироваться.
Сейчас есть это:
https://github.com/Zkir/osm2dcm/blob/master/osm2dcm/main.vbs
Есть текстовый файл (history.txt), в котором хранится история конвертаций. образец.
Скрипт читает файл, организует циклическую очередь, для каждой карты в очереди запускает батник (make.bat), который обновляет данные и собирает карту, если сборка успешна, файл истории (history.txt) пересохраняется, кроме того сохраняется maplist.xml, который закидывается на сервер.
Никакая база данных при этом не используется, как слишком сложная в поддержке.
Если ты сделаешь прототип на java, который в той же архитектуре сможет молотить в четыре потока, буду очень благодарен.
P.S.
Данные обновляются osmupdate. Можно ли запускать два osmupdate одновременно, и не поругаются ли они за кэш - вопрос.
ок, сделаем.
Если кто-то чего-то будет переписывать, то большая просьба
Ты ему пригрози, что если карты Италии для Ситигида не будут скачивать - то и валидации не будет 
А вообще здорово, что этим инструментом не только мы пользуемся!
+100500
А что не так с place_name? почему его надо убирать?
Инструменты для этого есть, даже два:
Если в деревне есть обозначенные дома с номерами или улицы, отсутствие границ тут же вылезет в этих тестах.
Счет деревень и поселков идет на тысячи, например в ЯО 5778. В большей части из них ничего кроме собственно точки place не нарисовано, и в обозримом будущем врядли будет. Ставить цель во чтобы то ни стало нарисовать им все границы, я думаю, было бы неправильно.
Города без точечного центра как раз так и работают. В этот тест включаются все НП, имеющие границы, даже village и hamlet.
Для проверки целостности адм. границ нужен отдельный валидатор, к сожалению. Да и для РФ адм.границы используются только для отрисовки.
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) может возникнуть, и она нормальная. Надо просто их обновить, и только после этого запускать дальше.
Может быть, вообще, планировщик должен поддерживать “сродство” между картами и процессорами.
Например, если есть четыре логических процессора, то Россия запускается на первом, Европа на втором и третьем, весь остальной мир на четвертом.