Да, определенная проблема в этом есть. Тем не менее по пунктам:
Я не пользуюсь интерпретируемыми ЯП т.к. считаю, что программы написанные на них работают неприемлемо медленно. Ну уж не для обработки гигабайтных файлов точно.
Исходники достаточно объемные, т.к. по сути я использовал для написания данной программы наработки из других проектов, ничего из них не удаляя. Так что для “посмотреть” они не очень пригодны. А для “откомпилировать” - тем более, т.к. я пользуюсь очень редким компилятором с не слишком характерного для подобных задач ЯП.
Программа консольная и использует минимум средств WinAPI без привлечения специфических библиотек. Так что с запуском, думаю, могут быть проблемы только из-под “голого” ДОС. Но под “голым” ДОС это принципиально работать не может, т.к. ДОС не поддерживает длину файла более 2 Гб, а для программы подобного назначения это ОБЯЗАТЕЛЬНОЕ условие.
Выложил следующую версию (и опять альфа - вот незадача!) http://slil.ru/29211415
Теперь сделана обработка строк и управление листингом.
Программа может, например, выполнить следующую задачу:
Если у объекта присутствуют теги cladr и cladr:code, причем их значения (val) совпадают, то тег code удаляется (приведен пример).
В принципе, можно сразу было добавить и cladr:note, но решил не усложнять программу.
Из идей - совместить этот инструмент с задачей получения простенькой статистики.
Простенькая статистика, это здорово. Например, хочу запросы: кто рисовал за последнюю неделю? Кто рисовал за период с - по? какие теги рисовали/изменяли за нужный период? Рисовали ли тег (к примеру) highway за запрашиваемый период? Рисовал ли пользователь pupkin тег water за запрашиваемый период?
Да уж. Под статистикой каждый подразумевает нечто свое.
Я, например, когда по совету lesha решил перейти с MP на OSM d качестве источника данных, первым делом попытался “очистить” OSM от той информации, которую я никогда не буду использовать. И “под сокращение” как раз попала та часть, в которой указывается, когда и кем данная точка последний раз была отредактирована. Кстати, объем после этого сразу уменьшился более чем вдвое.
Есть и еще одно препятствие.
В посте №18 вкратце сформулировано, что нужно сделать. И там явно указано, что работать нужно с файлом, а не БД или API. А это значит, что:
Во входной информации ОТСУТСТВУЕТ информация по истории изменений.
Сам файл может быть сколь угодно древний.
В этом же случае для сбора статистики подобного рода целесообразно уже пользоваться в качестве источника данных не файлом, а чем-то онлайновым.
А под статистикой я подразумевал анализ состояния информации, имеющейся в ТЕКУЩЕМ файле, т.е. на один момент времени, а не динамика ее изменения со временем.
Тут в ветке “Стандартизация…” я уже выкладывал кое-какую статистику. Просто хотелось бы иметь инструмент, который мог бы восполнить отсутствующую там информацию по каким-нибудь конкретным тегам. И чтобы это можно было сделать просто и быстро.
сделал на пробу пару конфигов для предпроцессора (osmosis+tag_transform), для гармина рестораны раскидываются по типам кухни, для навитела еще места поклонения (церкви, мечети).
если кому интересно http://code.google.com/p/osm2mp-preprocess/
