Пытаюсь разобрать OSM формат для дальнейшего его отображения на своем смартфоне.
Кто подскажет где найти полное описание на русском или пример реализации разбора OSM.
Это безнадежно. Лучше сперва вникнуть в осм, порисовать свой район.
Полного описания “формата осм” в природе не существует. Схема OSM-xml очень проста, но правильный рендеринг требует замысловатых алгоритмов.
На английском - тут:
http://wiki.openstreetmap.org/wiki/OSM_XML
В некотором смысле это “исчерпывающее описание” - как описание игры в шахматы “есть доска 8*8 и 6 типов фигур, которые ходят так-то и так-то”
само собой разумеется придется сделать некий свой формат…
для первого эксперимент заглянул в *.ai c cloudmade.com и достаточно успешно порисовал свой город…
Но там все просто… а тут набор координат которые непонятно “кто и с кем” соединять.
Например как отобразить(выдернуть) только здания…
С английским не совсем дружу а переводчик просто убивает.
Может кто имел опыт парсинга объектов… или что-то типа того.
Буду благодарен за любую помощь.
опен соурс прожекты юзающие на прямую ОСМ с последующим отображением не нашёл
Vespucci – редактор osm для андроида, использует api напрямую.
Большинство программ не используют для хранения данных формат OSM, потому что он неудобен для использования. Загруженные файлы сначала преобразуются на сервере в более удобный формат, а затем уже результат загружается на смартфон. Самый известный пример – OsmAnd (и MapsWithMe для iOS/Android).
Vespucci - open souce но увы я не java кодер для меня исходник андройда темный лес.
MapsWithMe - закрытый исходный код
воспринимаю С#, C++, C++ .NET, VB.NET…
кодю для WP 7 -8
Знание их более чем достаточно. Причиндалы от андрой ни как не завязаны на чтение ОСМ.
ага… я это к тому что Vespucci и вся логика разбора на яве… а так как в исходниках чужого (родного) C++
не всегда легко разобраться… да и там быстрее всего свой некий XML либ парсинга… да не важно
я вроде как потихоньку начал разбираться
Причем здесь XML либ парсинга?)
Парсинг осм-хмл элементарен на любом языке (есть три типа графических примитивов: точка, вей и отношение, которым присваиваются теги, в формате ключ=значение, и ничего больше).
Рендеринг - совсем нет. На тему рендеринга написанны тонны кода и все бестолку
offmonreal, мой вам совет. Если интерес продлится достаточно долго, и будете писать свой движок рендеринга, сперва преобразуйте осм в формат, в котором будут объекты со своей геометрией и их, этих объектов, атрибуты.
Вот чего OSM-у не хватает - так это как раз объектов.
По идее, нужно было бы ввести четвертую сущность, после чего постепенно разгрузить relation от несвойственных им функций, а затем превратить node и way во вспомогательные сущности, лишив их любых тегов.
Но это в принципе.
Пока же лично мне крайне интересны идеи и подходы к разработке как раз такого формата - в котором будут объекты со своей геометрией.
Понимание необходимости такого формата есть, а понимания, как такой формат должен выглядеть, - нет. 
Тогда в осм придётся всё обрабатывать как мультиполигоны, чего местные программисты ненавидят.
Лично я, как программист, ненавижу ситуации, когда одно и то же может быть описано разными способами, и, следовательно, для обработки одного и того же приходится предусматривать несколько разных вариантов.
Думаю, что “местные” программисты ничем в этом отношении от меня не отличаются: им тоже страшно не нравится, когда один и тот же линейный объект может быть представлен как две разных сущности, при этом еще и различного уровня общности.
Если подход к описанию будет только один - эти программисты только вздохнут с облегчением.
Ситуация с мультиполигонами близка к абсурдной: Вы имеете путь и не знаете, как его нужно обрабатывать - как собственно путь или как элемент мультиполигона, Причем, из тегов самого пути это установить никаким образом невозможно.
Именно это и раздражает программистов.
Если путь - всегда только часть мультиполигона, и не может быть самостоятельной сущностью, это существенно упрощает обработку. И программисты это воспримут с энтузиазмом.
Больше того, линии должны быть линиями, а территории — территориями. Даешь API 0.7 и тип объектов area! Нет мультиполигонам! Слава котам!
Как всегда, всё упирается в отсутствие человека, способного протолкнуть area. Спроектировать переход и написать код для rails_port и миграции базы. Ходить по форумам с рассылками и кричать об area, явно, недостаточно.
Это напоминает мне политическую ситуацию в РФ. Большинству всё равно, оппозиционеры много говорят, но ни первые, ни вторые ничего не делают. :3
Чтобы вводить тип объектов, нужно сначала ввести сами объекты.