А если исходник принудительно сортировать перед скармливанием, то можно тормозить чтение исходника по окончании блока соответствующих объектов… Ну как опция, для тех кто свой исходник скармливает. Вряд ли гислаб станет сортировать свои сборки - оно время жрет прилично.
у меня athlon 4000 т.е. честный двухядерный проц. И тоже непонятно почему код читает 3 раза? А с морями вообще в тупик ставит, раз море чем то отличается от земли? и может море внести в кэш и иногда только обновлять?
Тоже верно, почему нельзя прежде чем выкладывать на гис в формате осм, подготовить с сразу mp файлы?Ведь из mp делается гармин и из mp делается навител. Получается что мы все 2 раза проходит этап конвертации в mp
Три раза читает, чтобы не жрать в три раза больше памяти.
Моря отличаются очень сильно. И да, их вполне логично было бы кешировать - это на здоровье 
mp для гармина и навитела достаточно сильно отличаются, поэтому нет смысла делать их универсальными.
liosha хорошо а ты подумаешь как бы делать кеширование тех областей или полей которые не изменились… например сравнивать два осм по дате и содержанию и вносить изменение только по изменным
Леш, а подумай про использование сортировки, плиз… А то при исходнике в 3 гига это очень существенная разница получается
Ezhick, не совсем понятно, что именно в исходнике надо сортировать.
Epolyanichev, можно сделать моря в отдельном mp и обновлять их только раз в месяц, как мапник. А ежедневные mp делать без морей, и добавлять моря уже при конечном конвертировании в навител.
Над этим не мне надо думать, а автору сборочного скрипта.
Леш, можект я неверно понял, но три раза исходник читается для вытаскивания всех нодов, веев и релейшенов последовательно, нет? Если да. то при отсортированном исходнике как только кончились ноды можно прекращать читать исходник - в нем больше нодов нет, для веев его можно начинать читать ровно с этого места и до релейшенов… И так далее.
Нет, не поэтому.
Упс… Сорри тогда
Завтра собираюсь выложить релиз 0.90, поэтому если есть срочные баги - говорите сейчас
liosha а что в нем вкусного ожидается?
Epolyanichev, в 0.9 уже ничего, просто текущая бета из svn станет релизом, в котором будут только исправляться баги. А всё новое будет добавляться уже в следующую версию.
liosha но переход на новую ветвь, нам что то новое из фиц принесет?
Можно как-то поддержать “Пражскую” систему адресации?
http://www.openstreetmap.org/browse/node/296563542
Адреса на точках внутри полигонов зданий? Причем на точках только теги addr:*
Не бага, но пожелание - чтобы обрабатывались границы типа “сыр”. Т.е. в osm2mp пользовать то, что сделано в Math-Polygon-Tree для парсинга poly-файла. Это может быть решением проблемы конвертинга больших карт путём вырезания тяжелых областей (районов, городов, и т.п.) в отдельную карту.
AlRight, это всё уже в следующей версии.
Zkir, а просто сконвертить их в точки домов не поможет?
Может и помогло бы, только по какому условию конвертить?
точки с addr:* в addr:* + building=yes?
Например, по такому:
only_node
addr:housenumber = *
addr:street = *
amenity != *
Угу,
amenity != *
man_maid != *
healthcare!= *
education!= *
!=
