Работает! (WinXP, GF 8600GT)
Сразу зачесались руки правильно проставить этажность домов. 
Виндовская версия заработала, в отличие от Убунты, под которой что-то не собралось 
Красота. Скорость потрясает! Шикарная штука!!! Вот бы с гдеэтотдом договориться и взять у них этажность…
ubuntu 10.04 все норм. собралось - еще раньше писал об этом
Хотелось бы поддержку отношений. А то здания нарисованные мультиполигонами не отображаются. И было бы шикарно иметь поддержку mapCSS, хотя бы частичную.
AMDmi3, немного оффтоп: как вы умудрились на домене заработать такую репутацию: скриншот большой, поэтому только ссылкой ? Спам надо же рассылать с чужого домена, а не со своего.
А я правильно понимаю, что сначала работает PreloadedXmlDatasource, затем он выдается GeometryGenerator и дальше все работает только с геометрией, а данные из PreloadedXmlDatasource удаляются и память не занимают?
Может тогда не стоит экономить на тегах у точек? По ним потом можно будет объекты рисовать.
Для статистики - WinXpSp3 ATi5770 - полет нормальный. Домики красивые, все остальное серенькое 
И еще один вопрос. Геометрия хранится в классе Geometry в собственном формате. Это дает большой бонус в скорости т.к. этот формат не содержит ничего лишнего. Пока не содержит. Но уже хочется хранить там цвета vertex’ов, захочется текстуры. И каждый раз его надо будет расширять. И в результате он получится таким же большим и сложным, как существующие решения. А потом захочется вставлять 3D модельки для точечных объектов. Если в 2D ставят иконку, то тут логично поставить 3D модель. И надо будет конвертировать что-то типа collada или obj в этот внутренний формат. И будут трудности с тем, что ради скорости и простоты он не поддерживает “прикольные фишки”.
Может быть стоит сейчас, на ранней стадии, перейти на что-то готовое и более продвинутое?
libglosm-server/include/glosm/NonCopyable.hh - это чтобы от boost не зависеть?
Насколько я знаю, никто и не собирается городить костыли по ходу усложнения движка. Сначала форматы, потом код. То, что есть сейчас, всего лишь технодемо. Пусть AMDmi13 меня поправит, если я не прав.
Ну я просто исходники посмотрел немного. Там местами записаны идеи, что автор хочет сделать в том или ином месте. Кстати, код красивый.
Возможно вот эта библиотека была бы полезна:
http://assimp.sourceforge.net/
1
Планируется, только не мапник а нормальные материалы.
Планируется в ближайшем будущем.
А это вряд-ли в ближайшем, но когда-нибудь вполне вероятно.
Кому интересно, на https://github.com/amdmi3/glosm/wiki есть TODO и Roadmap.
Понятия не имею, я не рассылал спам. Пусть это беспокоит пользователей wot’а и подобной ерунды.
Готовый формат почти наверняка нет, потому что во-первых, он был бы нужен для обмена моделями с внешними приложениями, а это к назначению фреймворка относится весьма и весьма косвенно, во-вторых, в нём будет куча ненужного, сложно будет запихнуть нужное (например, данных о том, где рисовать название улицы) и всё это наверняка будет недостаточно эффективно храниться (а планируется раздавать геометрию в т.ч. мобильным устройствам). Расширяемость и обратная совместимость - это да, но для этого я скорее всего возьму protocol buffers, и то, наверное, не сразу.
Да.
В master-ветке это уже не так - геометрия генерится кусочками налету, поэтому выкидывать данные не получится. Но на самом деле вариантов работы масса - можно сгенерить геометрию для всего дампа одним куском и выкинуть дамп, можно нагенерить тайлы и выкинуть дамп, можно вообще не использовать OsmDatasource и грузить нужные куски геометрии из сети (вероятно, основной режим для user-oriented решения). А вообще PreloadedXmlDatasource не планировался как основной источник OSM данных - данные в идеале нужно брать из базы (основной вариант для серверного решения, т.е. генерилки тайлов). Данные можно брать и другими способами - например, через API, TRAPI.
Я на них не экономлю, я просто ещё не написал их поддержку 
AMDmi3, а как ты относишься к mapCSS? Если я правильно понимаю спецификацию, он применяется только за O(n*m) где n - количество объектов, а m - количество правил. И ускорить это дело за счет каких-нибудь индексов, позволяющих быстро находить нужные правила, проблематично. Но в вики пишут, что работает все равно достаточно быстро. Тебя такая сложность алгоритма устраивает?
Пока никак. Из того что я белго прочитал в wiki, это нечто с перенавороченным синтаксисом селекторов со свойствами только для плоских рендеров.
Да нет, на первый взгляд поиск правил для объекта можно сделать за что-то между O(1) и O(log m).
Это если жёстко задать, что один объект = одно правило.
Нет, конечно.
На отдельной странице описана следующая версия, 0.2. Там уже есть extrude.
Проблема в том, что правила надо выполнять в том порядке, в котором они указаны. Причем могут быть правила, которые устанавливают объектам css класс, а ниже правила, описывающие как этот класс рисовать.
Не важно, выбрать относящиеся к конкретному объекту можно быстрее чем за O(m)
А что происходит с объектами, попадающими в тайл частично?
Обрезаются по границе.