Так это если обрезать по общим нодам, а до совмещения регионов мы пока не доросли. Как я понял, комрад вёл речь о конвертации не изменённых областей.
А в чём проблема с обрезкой? .poly-файлы можно с того же гис-лаба взять
Надо попробовать. Я так понимаю для этой цели подходит вариант 1 и 3 отсюда? А внешние ноды состыкуются?
Нет, только 1.
В гармине всё стыкуется, хотя я .poly непосредственно из OSM тяну.
Кстати, пара вопросов по полигонам обрезки из OSM
- при использовании ключа --bploy=… вместо --osmbbox в mp не увидел полигона “Область покрытия карты”. Так и должно быть?
- liosha, нельзя ли выкладывать полигоны обрезки из OSM, чтобы все использовали одинаковые полигоны для сквозного роутинга?
ключ --bpoly 
Выкладывать отдельно полигоны не вижу смысла, в svn есть скрипт getbound.pl для их получения.
bpoly, конечно 
Но полигона границы таки нет. Или смотрел плохо?
Должен быть
Спасибо!
слепил новый вариант странички. Комментируйте
Ох, ресурсы жрет новый скриптик… Как бы меня хостер не “погладил” по голове за такое.
Мне нравится Только со столбиком дата что-то не все ровно и сортировать наверно имеет смысл не по столбику “файл” а по столбику “область”
А ты кэшируй страничку…
Кешировать наверно не саму страничку надо, а данные, вытаскиваемые из файла.
Согласен, будет.
БД поднимать влом, но видимо стОит.
А зачем базу? Может просто текстовый файл с табулированными полями?
Терзают подозрения, что может начать клинить при одновременном доступе.
Почему бы и нет. Правда, узковаты столбцы получатся, но оно того стоит, наверное. Только файл этот явно нужно упихвать в архив с картой - буду вытаскивать скриптом.
Если нужно обязательно в архиве, давайте лучше не в архив с картой, а в отдельный файл: <название области>-osm-err.7z а внутри аналогичный info.txt Пример
У меня была мысль что если все запихать в один архив, то так или иначе информация, хранящаяся в нем, будет связанная. А если держать отдельно - как бы расползаться оно все не стало потихоньку. Чем плохо в один архив все запихать?