Ну, сейчас я это не буду делать. Я пока ещё дороги не сконвертил…
Zkir, если кто-нить сделает cmap-файл (или нужный набор параметров для вызова osm2mp) для русского - я соберу карту.
Про слияние .osm файлов.
Слитый append-ом .osm успешно обрабатывается скриптом osmsort.pl, однако скрипт выкидывает дубликаты объектов с одинаковым id.
Это нормально, если файлы выкачаны напрямую (скажем из XAPI), но вот, например, сливать так страны скачанные с geofabrik я не рекомендую - от дорог, разрубленных на страны, остаётся только 1 объект.
В общем, пока сконвертить вместе с дорогами не удаётся - дороги сами по себе в 16МБ не влезают.
Попробую написать оптимизацию Дугласа-Пекера для .mp-файла.
Для .mp проще - можно сделать 1-проходной алгоритм без накопления данных, а для .osm - нет, т.к. координаты в одном месте, а их порядок внутри линии - в другом.
А вроде бы в мапедите была генерализация.
Плюс стоило бы детализацию нижнего уровня сделать поменьше, бит эдак 20
Насколько я вижу, она не настраивается нифига. Я хочу задавать степень оптимизации.
И потом, эта генерализация выполняется после открытия карты, т.е. после округления мапэдитом координат точек.
У меня сейчас 18. Вот так:
Levels=6
Level0=18
Level1=16
Level2=14
Level3=12
Level4=10
Level5=8
Zoom0=0
Zoom1=1
Zoom2=2
Zoom3=3
Zoom4=4
Zoom5=5
Увы, вынужден констатировать, затея с дорогами провалилась.
Несмотря на оптимизацию Дугласа-Пекера, минимальный объём .rus файла с дорогами trunk и motorway при сохранении роутинга - 15 МБ. Без сохранения роутинга делать дороги, имхо, бесполезно.
Выкладываю test6, он же Release Candidat #1.
.rus: http://www.datafilehost.com/download-8d688f71.html
.mp: http://www.datafilehost.com/download-09324602.html
Список объектов тут:
https://spreadsheets.google.com/ccc?key=0Ao3SN5YMf0PmdEJrZTl6M09LSzkxUXdFU1VsTzFLUEE&hl=en (колонка test6)
Вкратце:
Вместо дорог добавлены деревни, а все линии оптимизированы.
Вопросы:
-
Есть пожелания/предложения/замечания по test6?
-
Оптимизатор нужен кому-нить? Собран под Windows, написан на VB6.0 :), исходники могу открыть.
-
Сейчас расстояние при оптимизации считается по пифагору - как будто все объекты на плоскости. Есть идея считать расстояние по поверхности сферы, в этом случае оптимизация около полюсов будет корректнее, чем сейчас.
Есть ли смысл делать такую оптимизацию, как думаете?
Для Русы, возможно, и нет, а для Навитела очень даже нужна обзорка (подложка) именно без роутинга, видимая на масштабах от 120 до 800 км (сейчас карты видны до масштаба 80 км включительно, а увеличивать число слоев в детальной карте, имхо, уже плохо).
OverQuantum: Для готового кода расстояния по сфере см. Distance: http://maps-by.googlecode.com/hg/statistic/komzpa/calchome_xyn.py
Кроме того, перед оптимизацией веи собираются в кучи? т.е. если у меня есть 500 сегментов hw=mw по две точки, будут ли они оптимизированы?
OverQuantum, смотря на сколько врать будет плоский расчет. К примеру в Сыктывкаре на сколько брать будет?
Ладно, буду думать, как бы оптимизировать дороги сильнее.
Нет, останутся 500 сегментов по 2 точки. Боюсь, дороги собирать в кучи почти бесполезно, ибо пересечений и разветвлений очень много.
Примерно в 2 раза.
По направлению запад-восток расстояние “по градусам” вдвое больше, чем “по сфере”, по сравнению с расстоянием по направлению “север-юг”.
Т.е. при текущей оптимизации ломанная линия идущая с запада на восток сплющится вдоль длины и станет изломаней. А линия, идущая с севера на юг - сплющится поперёк и станет более гладкой.
Найти способ убить полосы моторвеев - из двух полос сделать одну дорогу. 
ОверКвантум, да, похоже при таких искажениях нужна сфера при симплификации. (Подумал: на пальцах проще всего представить механизм и степень искажения - представляя плоскость и ‘целующуюся’ с ней в одной точке сферу. Прямая проекция с плоскости на сферу и даст на глаз степень искажения).
Zkir, заманчиво, но в общем случае похоже это всё ручная работа. Так вообще все двойные дороги можно было бы того… Да только никакая программа не соединит все ответвления от этих дорог правильно для маршрутизации.
ОверКвантум, а может сделать двумя частями и не мучаться так? не ужиматься?
Лан, попробую.
А роутинг при двух частях работает в Руссе? У меня что-то ни разу не работало, если атлас загружать, а не 1 карту.
Не знаю 
я теоретик секса.
В руссе маршрутизация в атласах не работает в принципе, только в отдельных картах. 
заманчиво, но в общем случае похоже это всё ручная работа.
Согласен, немножко искусственного интеллекта для этой задачи необходимо. Но для формирования правильной обзорной карты это необходимо. В крайнем случае можно пройти в ОСМе по дорогам и проверить что части двойных имеют одинаковые теги name/ref
…
Т.е. делать атлас для Гисруссы где вся РФ смысла нет?
Меня в соседней теме попросили конвертнуть всю РФ в .rus - всё срослось, вся РФ в атласе видна, только маршрутизации действительно нет - только если выбирать отдельные карты из этого набора.
Ну это смотря какой смысл вкладывать в атлас. 
Начет упрощения моторвеев - можно попробовать округлять координаты узлов в исходном файле до точности координат обзорки.
Затем оставлять из всех веев, соединяющих два узла с совпадающими округленными координатами, один.
Кстати, при округлении метров до двухсот должны убраться и развязки.
Более интеллектуальный метод - собирать группы близкорасположенных узлов в кластеры и ставить один узел в центре тяжести. Но с кластерами я тоже только теоретик 
А вообще методы генерализации параллельных линий, наверное, уже давно придуманы?
Я бы попробовал построить алгоритм следующим образом:
- искать и объединять близко расположенные параллельные (и направленные противоположно) отрезки веев, имеющих одинаковое значение тегов name (либо ref). Проблема же очевидно в том что узлы на противоположных полосах могут быть не парные. Например в одну сторону 1 сегмент, а в обратную - 2.