Кстати, можно было бы объединить усилия с Gmurik’ом. Раз формат так или иначе планируется полностью описывающий OSM, можно было бы забацать универсальную расширяемую софтину, пригодную на десктопе для редактирования, а на мобилках - для навигации. Ы? Как-нибудь объединить бы мозговые усилия - нас тут уже как минимум трое, считающих что из разработки на Qt может выйти толк.
Если интересно, то вот что получил юзая OpenGL!
По-быстрому замутил на wxWidgets тестовую прогу с окном OpenGL.
рисую вот такие полики:
В них в каждом снизу полигон простой, затем черный контур, обводит полик цветной, а потом четыре зеленых вершины по углам.
Все поле - Земля по горизонтали от -180 до 180 b -90 - 90 по вертикали соответственно.
Замутил 360х180 таких полигонов, т.е. всего 64800 штук.
получилась такая картина… размер сжал:
Координаты и данные цвета лежат в VBO. При перерисовке тормозов нет вообще! Проверял ресайзом окна. Не тормозит вроде, но видюха начинает реветь куллером как боинг на взлете… Хотя она обычно по любой, даже мало значительной, причине реветь начинает т.к. плата однослотовая 8800GT с забитым пылью куллером)
Больше 360х180 поликов не делал т.к. у меня какой-то трабл с выделением памяти под буфер в который генерирую координаты… или еще с чем… лень разбираться.
Думаю даже такого результата может быть достаточно для сравнения скорость рендера.
Хотя на тупых квадратных поликах может оно и не правильно мерять…
ОпенГЛ мощь! Qt даже при 100х100 обычных квадратных контурах конкретно тормозила, хотя вроде OpenGL ускорение включено было в коде.
Можно еще попробовать повесить тесселяцию кривых поликов на видюшку)
респект!
нормуль. Все равно оно все в треугольники переводит.
CUD’у заюзать?
Ivan Komarov я у него в теме отписывался как Chertov Maxim) Конечно и у навигашки и у редактора основа одна. Обоим карту нужно рисовать, работать с базой…
Изначально моя идея происходит от создания навигашки, которой можно было бы рисовать чисто по векторным данным… без хранения растра и связи с сервером.
Мне кажется проблема не нарисовать, а выбрать данные, которые нужно нарисовать… очень быстро и из очень большого объема данных.
К примеру все что не меньше площади в условный “1 пиксель” на дисплее при данном масштабе - рисуем, все что меньше и на цвет пикселя повлиять не сможет идет лесом.
Есть идеи как базу для этого перебрать нужно, по аналогии с уровнями растра, но я так и не могу создать базу для тестов в PostgreeSQL))) Моя тема по этой проблеме заглохла
Да про CUDA и была мысль. Слышал что уже OpenCL вышел от nVidia, но я его не трогал никогда)
С кудой давно игрался, когда первая версия была…
OpenCL ведь не только nVidia собирается поддерживать, с OpenCL и на ATI бы считалось… везде)
2Ezhik: еще раз спасибо!
2x10kHz: думаю, что CUDA и альтернативы тут не особо нужны. Нормально реализованный алгоритм построения триангуляции Делоне имеет сложность O(N logN), думаю, что быстродействие будет вполне достаточное, тем более что это можно делать на стадии загрузки/компиляции карты.
Насчет базы - хорошо бы таки прикрутить ей возможность выбирать содержимое произвольного полигона. Насколько я понимаю, большинство людей предпочло бы выкачивать либо административными областями, либо рисуя произвольный ограничивающий многоугольник.
Как бы консолидироваться, а? Я, возможно, тоже мог бы что-нибудь полезное делать для разработки. Мысли об этом давно бродят в голове, но понимаю, что в одиночку не потяну - не хватит времени и сил.
Насколько я понимаю, постгре+постгис должны дать возможность быстрого выбора произвольного полигона для скачивания.
Да, на стадии загрузки можно обсчитать триангуляцию, в навигашке, думаю, такое прокатит на ура!)
Вот в редакторе это наверное иногда нужно будет пересчитывать быстро, например при редактировании контура москвы (который мне попадается, это лишь контур? или все же полигон, кстате) нужно разбивать весь полигон заного или частично, если точку какую-нибудь изменили, удалили/добавили.
Но думаю Вы правы, тут и без новомодных штук производительности должно быть достаточно.
Одному конечно очень трудно! Можно попробовать завести проект на каком-нибудь Google Code, SourceForge, GitHub… или даже лучше свое что-нибудь запустить с svn’ом и форумом. Есть сервачок, который крутится круглосуточно, из инета доступен практически всегда. Могу попробовать настроить. Для тестовой базы OSM’а хочу выделить отдельный комп, но пока даже “прототип” в WMware не собрал)
Вообще все на уровне экспериментов, сейчас ничего работающего нету… в свободное время вожусь ради интереса) Вероятности того что получится что-то реальное стремится к нулю)))
Для svn-а есть шикарный ресурс XP-dev.com, уже около года пользуюсь. Недавно туда еще ведение проектов прикрутили. (а также - wiki и форум)
Думаю тему создавать новую не стоит, т.к., насколько я понял, кодеров тут можно пересчитать по пальцам одной руки)
Непонятки с протоколом
Пытаюсь разобраться с xml’ьными данными осма.
Из исходников JOSM’а, примеров (сохранял osm файл JOSM’мом) и самой важной странички на вики “API v0.6” нашел довольно разнообразные теги, которые могут встретится.
Вот чтобы понять как это все правильно обработать хотелось бы уточнить несколько моментов.
Не могу определиться с полным списком элементов которые могут встретиться между в xml осмофайле.
Пока бегал по страничкам вики насобирал довольно много тегов:
<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
<bounds />
<user />
<preferences />
<node />
<way />
<nd />
<relation />
<member />
<tag />
<gpx_file />
<changeset />
<api />
</osm>
насколько я понял многие из них в osm файле встречаться не могут, может относятся только к протоколу.
Есть ли спецификация точная для osm’о файла? В которой точно сказано какие элементы может содержать такой-то элемент и какие у этого элемента могут быть параметры и закакие значения могут принимать эти параметры?
Или в одном месте эту инфу еще не собрали, или не нашел… все как-то размазано)
Пытаюсь выяснить какие параметры и дочерние элементы может содержать каждый из них.
Например для node собрал параметры… node[ id, action, timestamp, user, uid, visible, version, lat, lon, changeset ]
Парсер xml собираюсь реализовать на libxml2. Примеры компилятся, работает…
Возможно есть какие-нибудь более подходящие либы?
AkMeR, Спасибо! На эту страничку не попадал)
Ivan Komarov, Спасибо! Посмотрю что за зверь…
Eugene, Спасибо! Посмотрел… не совсем понятно что за штучка еще, основательно не разбирался)
Но идея понравилась. И ничего за собой не тянет, кстати!
Я так понял оно умеет переваривать xml в свой формат что ли, с которым очень быстро работает…
Если кому интересно, то при компиляции исходников (из ximpleware_2.7_c.zip, в ximpleware_2.7_c_light.zip все нормально) вы получите ошибки о том что не найден “xpath1.hpp”
Эти ошибки в файлах с функцией main, какие-то утилиты, тесты, а конкретно в:
benchmark_vtdxml.c
RSSReader.c
soap.c
stats.c
update.c
vtd-xml.c
Я их вообще убрал из проекта (т.к. весь VTD собрал в либу), и все собралось нормально, впрочем можно в них поменять #include “xpath1.h” на #include “xpath.h”, тогда и они компилятся без ошибок.
UPD1: VTD вместе с моими исходниками на cpp работать не хочет, но в отдельном проекте собралось)
UPD2: RapidXML, удобно юзать, без громоздких коллбеков как в libxml2) Почитал что она довольно шустрая + упакована целиком в hpp, буду разбираться
VTD-XML не осилил) он на С… отлично работает, но в С++ проге замучался прикручивать…
UPD3 накатал парсер osm файлов на RapidXML… вроде бы полностью должен обрабатывать node, way, relation… согласно указанному AkMeR’ом API v0.6 DTD
О том что такое DTD кратко написано ТУТ, и ТУТ есть наглядные примеры. Раньше с xml особо не возился(
RapidXML действительно удобная штука, парсить довольно легко, думаю и создавать тоже не трудно)
Потестил пока только обработку node и way… ловит все атрибуты, теги, ссылки! Надеюсь скоро смогу что-нибудь нарисовать из файла, в меркатор уже пересчитывать научился… вроде рисует координаты правильно.
Сравнивал визуально с осмом)))
well, чутье меня не подвело. Грамотно сделанное с использованием лучших практик программирования и должно хорошо работать 
Скоро тоже понадобится XML к проекту прикручивать, воспользуюсь. Спасибо за комментарий!
Заметил такую особенность! В файлах есть элемент bounds, например:
<osm version='0.6' generator='JOSM'>
<bounds minlat='55.7545543020341' minlon='37.5684356689453' maxlat='55.783427185411' maxlon='37.6307487487793' origin='OpenStreetMap server' />
<node id='297532810' timestamp='2009-05-29T20:12:44Z' uid='82861' user='azomazo' visible='true' version='38' lat='55.5810759' lon='37.5962018' />
но в описании API v0.6 DTD его нет…
Как правильно-то? Это его JOSM “неофициально” дописывает?
Да и uid, кстати, тоже нет!
Ivan Komarov, парсер осмофайлов прикручивать будете?
Я, думаю, допишу скоро… пока еще не отлажен толком, все типы храню как QString( но ноды и веи уже собираются правильно!
Сейчас релейшены тестить буду. Да и просто как тутор по работе с либой могу выложить) Из стандартного мануала не все понятно было.
Нет - свое, девичье. Проект еще не завели где-нибудь?
Add: кстати, о птичках: у qt-а же свои есть средства по работе с XML. их не смотрели?
У JOSM`а - немного другой формат файла.
По поводу уид - http://wiki.openstreetmap.org/wiki/API_v0.6#Reliably_identifying_users - взамен user.