КПК + Osm

Ivan Komarov, проблема видимо не в ортогональности понятий, а в том что само это отображение оказывается довольно нетривиальным. В этом самом бинарном формате может быть нужна в принципе другая структура данных. Например, принадлежность точки городу в OSM задается самими координатами. Для адресного поиска предпочтительнее иметь проставленный адрес для каждой точки. что бы не проверять принадлежность каждой точки полигону on-the-fly.

Даже элементарная задача - выбрать из осм данные для конкретного прямоугольного участка не так проста как кажется.

Делать преобразование налету может оказаться совсем не выгодно. Например преобразование из osm в компактный бинарный формат rus занимает около 30 минут.

Нетривиальность задачи делает ее еще более привлекательной :slight_smile:
Существование навигационного ПО, заточенного именно под OSM позволило бы ему использовать данные, в принципе недоступные остальным. Промежуточная конвертация, либо конвертация, расчитанная на принципиально другой набор входных данных существенно ограничивает их потенциальные возможности. Насколько я могу судить, подобной широтой используемых понятий и сущностей никакой другой исходный формат не может и близко похвастать.

а в такой же компактный бинарный формат navit - в несколько раз быстрее
так что тут дело только в желании разработчиков. ну и в их способностях конечно

WildMan, не буду спорить, скрипты можно было бы написать и получше (хотя это камень скорее в огород Лёши и разработчиков осмозиса, а не в мой :slight_smile: )

Но согласись, что даже 3 минуты - это безумно много, если это время между включением навигатора и появлением на экране карты.

Хм, а я то думал что с точки зрения используемых понятий и сущностей формат osm-xml наоборот крайне простой и круглый, как колобок. Есть только точки(nodes), линии (ways), причем даже нет разделения на линии и полигоны, как в mp, отношения(relations) и теги (tags) - а больше ничего и нету. В mp сущностей намного больше :smiley:

Никакие способности не помогут парсингу xml на дохлой машине. :smiley:

Точно-точно. Для навигаторов Xml это не по зубам (пока процессоры там не многогигагерцовые и память не многогигобайтная). Только бинарник.

Хм, WhereAmI вполне себе скачивает XML и отображает. Тормозит, правда, но работает.

Парсинг XML - далеко не самое ресурсоёмкое занятие.
А вот с обработкой сырых данных в реалтайме даже мощный комп не справится.

UPD
Vovanium, ключевое слово - “скачивает”. :slight_smile:
То есть такая задача как выбор данных для отображения передаётся на сервер.

Ну конечно, скачивается не весь глобус целиком, а какой-то район, только всё это кэшируется и ворочается уже самостоятельно.

Скачивается даже не район, а маленький кусочек, который и требуется отобразить.
Кроме того, никакого понялия о роутинге, адресации, мультиполигонах, морях etc у WhereAmI нет, он только тупо отображает геометрию объектов.

Надо, что бы Osmf выработал свою спецификацию на бинарную версию данных, и своими серверами бы ее и поддерживал :slight_smile: После этого мобильные платформы бы и ‘шагнули’ в деле популяризации Osm. Вот :slight_smile:

http://wiki.openstreetmap.org/wiki/OSM_Mobile_Binary_Protocol

Я имел в виду физические сущности, как то ширина и качество покрытия дорог, время работы заправок и т.п.

liosha, интересная мысль)) надо будет поковырять…

WhereAmI использует OSM Mobile Binary Protocol, упомянутый Лёшей.

WhereAmI на Symbian 9.4 стабильно вылетает

Посмотрел Яндекс.Карты (для Питера нет routing’а).
Очень понравился принцип работы с картами - абсолютно прозрачен для пользователя: всё качается с сервера и кешируется на устройстве, т.е. после можно ездить и без интернета. Трафика не много (правда я не пользовался масштабированием). А при желании весь кеш можно сразу залить.

Эх! Для КПК + OSM тут целое поле непаханных идей. Можно такую шикарную прогу зафигачить! :frowning:
Замутил бы кто проект, я бы им ФС (ТЗ) написал бы. :slight_smile:

Семь бед - один ответ:SASGIS. Он умеет делать кеш для мяк.

Дык пишите :slight_smile: Может, дело как-нибудь и сдвинется