Свой редактор для ОСМ

Нужно взять какой-нибудь опенсорсный проект и переделать под редактор осмокарт) Главное чтобы были всякие залипания, выравнивания и т.д.
JOSM меня добивает тем что написан на яве… даже на довольно мощном компе он умудряется тормозить. Яву не люблю в принципе, но может вопрос и не в тормознутости явы, а в архитектуре самого джосма…
Пару дней ковыряю исходники блендера, JOSM’а, либу CGAL… надеюсь получится собрать примитивную рисовалку осмофайлов для начала…

Щито? o_O
Возьмите тогда уж Inkscape.

Мда. Inkscape или (что, по-моему, ближе) dia, или что-нибудь из cad’ов еще можно было бы понять, но blender… И почему не merkaartor? Хотя если делать, то на OpenGL, да.

Вот тут и собака зарыта) Inkscape заценил… вроде как пишут что ее или собираются или уже перевели на cairo. Исходники не смотрел
Cairo конечно удобная либа в плане отрисовки, но производительность у нее будет ниже реализации на OpenGL.
С cairo раньше имел дело, писал простенькие тулзы, графики рисовал.
На опенгл не удобно рисовать невыпуклые полики, полики с дырками… а в картах осма таких очень много, в cairo с этим проще само обсчитывается.

Накопипастил в Inkscape 40’000 объектов и оно упало)
После 10 - 15 тысяч начинает конкретно тормозить… работать становится не возможно

Можно еще на Qt рисовать…
вобщем надо экспериментировать)

Прототип можно на чем угодно написать, рендер переделать если что)

Вот, кстати, есть тест Qt vs Cairo

Боюсь, что из Сигала “собрать” рисовалку не получится, там же только геометрические примитивы и работа с ними. Также подозреваю что Qt будет хорош (по причинам производительности) только в качестве оболочки для графического ядра на OpenGL или OpenVG. Насчет готовых движков ничего не скажу, не знаком с ними.
Upd: заглянул в подзабытый Сигал, там же есть триангуляция Делоне, что еще надо для разбиения областей под OpenGL? Лучше не придумаешь.
А inkspace - он только для SVG? Удастся ли полноценно свести редактор к работе с ним?

Занятный тест :slight_smile: Уже в 2006 Qt использовал OpenGL! не знал. Интересно, какие там подводные камни и ограничения реализации.

закинул на QGraphicsView 10’000 квадратиков… отрисовка тормозит довольно сильно(
скорее всего я не врубился где что подкрутить и как правильно использовать (скомпилил “влоб”), либо не такое оно уж и шустрое)
Попробую написать демку на OpenGL)

Советую сразу ориентироваться на использование VBO и сопутствующих, так гораздо веселее крутиться будет

Да! VBO само собой, с OpenGL опыт работы кое-какой есть…
Вот триангуляция дырявых и невыпуклых поликов волнует, где-то была у меня демка самопальная.
Юзал теселляцию из либы glu, интересно в OpenGL 3.0 ввели что-нибудь для отрисовки кривых поликов.
Разбивание поликов есть еще в CGAL, скомпиленные демки под винду можно тут скачать
Очень прикольные, интересные! написано, кстати, с использованием Qt… можно свои полики рисовать и издеваться над ними)

Агащаз! :smiley:
Add: они вовсе хотели поубирать все примитивы, кроме треугольников; народ молил, чтоб хотя бы четырехугольники оставили. Для биллбоардов.
Наверное, для стимуляции Qt’а его надо было собирать с опцией, указывающей использовать GL для отрисовки…

Кстати, можно было бы объединить усилия с 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 бы считалось… везде)

Структура базы под Постгре
http://ifolder.ru/14365295

2Ezhik: еще раз спасибо!

2x10kHz: думаю, что CUDA и альтернативы тут не особо нужны. Нормально реализованный алгоритм построения триангуляции Делоне имеет сложность O(N logN), думаю, что быстродействие будет вполне достаточное, тем более что это можно делать на стадии загрузки/компиляции карты.
Насчет базы - хорошо бы таки прикрутить ей возможность выбирать содержимое произвольного полигона. Насколько я понимаю, большинство людей предпочло бы выкачивать либо административными областями, либо рисуя произвольный ограничивающий многоугольник.
Как бы консолидироваться, а? Я, возможно, тоже мог бы что-нибудь полезное делать для разработки. Мысли об этом давно бродят в голове, но понимаю, что в одиночку не потяну - не хватит времени и сил.

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

Да, на стадии загрузки можно обсчитать триангуляцию, в навигашке, думаю, такое прокатит на ура!)
Вот в редакторе это наверное иногда нужно будет пересчитывать быстро, например при редактировании контура москвы (который мне попадается, это лишь контур? или все же полигон, кстате) нужно разбивать весь полигон заного или частично, если точку какую-нибудь изменили, удалили/добавили.
Но думаю Вы правы, тут и без новомодных штук производительности должно быть достаточно.

Одному конечно очень трудно! Можно попробовать завести проект на каком-нибудь Google Code, SourceForge, GitHub… или даже лучше свое что-нибудь запустить с svn’ом и форумом. Есть сервачок, который крутится круглосуточно, из инета доступен практически всегда. Могу попробовать настроить. Для тестовой базы OSM’а хочу выделить отдельный комп, но пока даже “прототип” в WMware не собрал)
Вообще все на уровне экспериментов, сейчас ничего работающего нету… в свободное время вожусь ради интереса) Вероятности того что получится что-то реальное стремится к нулю)))