Просмотр кода страницы Идеи для разработчиков геопространственного ПО с открытым исходным кодом

{{Организационное|ideadev}}

== Введение ==
Данная страница предназначена для аккумулирования идей и запросов на разработку/доработку ПО с открытым исходным кодом в области ГИС.
Идеи сведены в задачи, задачам даны краткое пояснение. Если нажать на название задачи, будет выполнен переход к более детальному описанию. 

Задачам выставлены уровни сложности, в зависимости от расчетного количества времени на решение и необходимости специальных знаний (теории, практики существующих решений). В расчетное время не входит время на освоение языка программирования.

* 1 - начальный, задача может быть решена за 1-2 недели, специальных знаний не требуется и они приобретаются очень быстро.
* 2 - начальный+, задача может быть решена за месяц, требуется порядка недели на освоение базы
* 3 - средний, задача решается за 2-3 месяца, требуется минимум месяц на освоение базы
* 4 - продвинутый, задача решается за 4-6 месяцев, требуется минимум два месяца на освоение базы
* 5 - очень сложный, задача решается за 6-12 месяцев, требуется 3-4 на освоение базы

2-3 примерно соответствует уровню курсового проекта, 4-5 - дипломной работы.

Сложность устанавливалась экспертным путем.

=== QGIS ===
Задачи связанные с разработкой в рамках ПО ГИС Quantum GIS (QGIS)
{| class="wikitable"
! Кратко !! Подробнее !! Язык !! Сложность !! Обсуждение !! Взялся
|-
| [[#Генератор отчетов|генератор отчетов]]
| полноценный генератор отчетов, что-то похожее на Fast/FreeReport
| C++/Python
| 4
|
|
|-
| [[#Режим Wireframe|Режим Wireframe]]
| возможность переключать «на лету» стиль отрисовки слоя (сложный/простой)
| C++
| 3
|
| не актуально, в 2.10 что-то подобное уже есть
|-
| [[#Генерализация на лету|генерализация линейных (и полигональных?) слоёв «на лету»]]
| упрощение сложных объектов перед отрисовкой
| C++
| 3
|
| не актуально, в 2.10 что-то подобное уже есть
|-
| [[#threading_branch|пересмотр и доработка ветки threading_branch]]
| адаптация и интеграция существующего кода
| C++
| 4
|
| не актуально, в 2.10 что-то подобное уже есть
|-
| поддержка Tile Cache
| поддержка протоколов OGC WMS-C/TMS
| C++
| 4
|
|
|-
| [[#Визуальный привязчик растров|Визуальный привязчик растров]]
| дальнейшее развитие инструмента привязки растров
| C/C++
| 3
|
|
|-
| использование многопопоточности и OpenCL в fTools и других библиотеках QGIS
| для повышения скорости обработки больших объемов данных
| С/C++
| 4
|
|
|-
| [[#Топологически корректное упрощение|генерализация векторных данных с сохранением топологии]]
| сейчас возможна генерализация без учета топологии, что для смежных полигонов неприемлемо
| C++
| 3
|
|
|-
| [[#Экспорт в MBTiles|Экспорт в MBTiles]]
| GDAL поддерживает чтение формата MBTiles, нужно сделать экспорт в него.
| C++
| 3
|
| не актуально, в Qtiles сделано
|-
| [[#Кусочно-линейное редактирование гистограммы|Кусочно-линейное редактирование гистограммы]]
| Расширенная настройка гистограммы изображения
| C++
| 3
|
|
|-
| Привязка векторных файлов по точкам в QGIS
| Необходимо разработать плагин для QGIS представляющий собой инструмент для привязки векторных файлов к местности. Инструмент должен работать аналогично привязке растровых файлов.
| C++/Python(?)
| 2
|
|
|-
| Шторка в QGIS
| Необходимо разработать плагин для QGIS представляющий собой инструмент для отображения части растрового слоя. Слой делится горизонтально или вертикально относительно курсора мыши. При движении курсора часть растрового слоя показывается, а часть нет. 
| C++/Python(?)
| 3
|
|
|-
| [[#Исправление некорректных планарных геометрий|Исправление некорректных планарных геометрий]]
| Портирование инструмента проверки и исправление ошибок планарных геометрий для избавления от наложений и сливеров.
| C++/Python(?)
| 3
|
|
|-
| Схематическое отображение
| Один из способов отображения данных является схема. Схема должна строится по связанным (сетевым) данным автоматически. Каждый элемент схемы должен иметь свое представление на карте. Пример реализации ArcScematics.
| C++/Python(?)
| 5
|
|
|-
| Генерализация при отображение модели
| При отображении коридоров трубопроводов или ЛЭП на больших масштабах они сливаются. Отображение должно позволять оценить, как географическое положение, так и количество труб и их состояние. Пример: http://www.neftekarta.ru/content/images/preview/76ee3de97a1b8b903319b7c013d8c877/800_560/1251307788.gif
| C++/Python(?)
| 4
|
|
|}

=== GDAL ===
GDAL - [http://www.gdal.org Geospatial Data Abstraction Library]

{| class="wikitable"
! Кратко !! Подробнее !! Язык !! Сложность !! Обсуждение !! Взялся
|-
| [[#Коррелятор|Коррелятор]]
| Поиск связующих точек
| С/С++
| 3
|
| Андрей Мигаль. Ментор: [[Участник:Bishop|Дмитрий Барышников]]
|-
|[[#Уравнивание сети триангуляции|Уравнивание сети триангуляции]]
| В случае поиска связующих точек, образуется сеть триангуляции. При этом, встает задача уравнивание этой сети для случая тройного и более перекрытия.
| С/С++
| 3
|
|
|-
| [[#Драйвер GDAL|Драйвер SXF для OGR]]
| Необходимо реализовать или доработать существующие варианты драйвера формата SXF для библиотеки GDAL/OGR. Документация на формат содержится в следующих документах: [http://gistoolkit.ru/download/doc/sxf4txt.pdf Открытый формат цифровой информации о местности. Структура текстового файла TXF] и [http://gistoolkit.ru/download/doc/sxf4bin.pdf Векторный формат SXF. Структура данных в двоичном виде]. Подробнее о библиотеке GDAL читаем на [http://gdal.org официальном сайте].
| С/С++
|4
|
| не актуально, в 1.11 есть
|-
| [[#Драйвер GDAL|Драйвер OSM XML для OGR]]
| Необходимо реализовать или доработать существующие варианты драйвера формата OSM XML для библиотеки GDAL/OGR.
| С/С++
|4
|
|
|-
| Многопоточный тайлинг
| Как оказалось, при приличном количестве больших растров создание тайлов с определенными уровнями для картографических веб серверов довольно ресурсная задача. Предлагается сделать этот процесс многопоточным или вообще на видеокарте обсчет.
| С/С++/OpenCL
|3
|
|
|-
| [[#Создание DEM по стерео изображениям|Создание DEM по стерео изображениям]]
| Собранные при помощи коррелятора связующие точки изображений позволяют вычислять высоту объектов. Когда на изображении зафиксирован высокий объект, то его основание будет иметь одинаковые координаты на местности, а вершина разные. Из этого можно получить высоту объекта.
| С/С++
|5
|
|
|-
| [[#Добавление поддержки форматов метаданных|Добавление поддержки форматов метаданных КА Kompsat-2]]
| В настоящий момент имеется снимок с КА Kompsat-2 с метаданными в комплекте. Необходимо добавить поддержку метаданных с этого КА в GDAL с проверкой работы в wxGIS в диалоге свойств растра и инструменте геообработки "Ортокоррекция"
| С/С++
|2
|
| не актуально, в 2.0 есть
|-
| [[#Добавление поддержки форматов метаданных|Добавление поддержки форматов метаданных серии КА типа DMC]]
| Существует серия КА типа DMC. Необходимо добавить поддержку метаданных с этих КА в GDAL с проверкой работы в wxGIS в диалоге свойств растра и инструменте геообработки "Ортокоррекция"
| С/С++
|2
|
|
|}

=== OGR ===
{| class="wikitable"
! Кратко !! Подробнее !! Язык !! Сложность !! Обсуждение !! Взялся
|-
| [[#Выборка сложными границами|Выборка сложными границами]]
| Оптимизация выборок полигонами со сложными границами
| С/С++
| 3
|
| 
|}

=== Разное ===

{| class="wikitable"
! Кратко !! Подробнее !! Язык !! Сложность !! Обсуждение !! Взялся
|-
| Анализ производительности формата  SpatialLite
| Существует мнение что формат SpatialLite очень медленный. Необходимо провести анализ производительности формата.
| Любой
|2
|
| 
|-
| [[#Создание десктопного индексатора геопространственных файлов|Создание десктопного индексатора геопространственных файлов]]
| Для индексации и быстрого поиска файлов предлагается использовать существующие поисковые движки на основе открытого программного обеспечения. Например [http://sphinxsearch.com Sphinx] или [http://www.dataparksearch.org/ DataparkSearch]. Выбранный поисковый движок должен быть доработан или его функционал должен использоваться в программе службе/сервисе/демоне.
| С/С++
|3
|
|
|-
| [[#Анализ открытых решений для организации версионности в PostGIS|Анализ открытых решений для организации версионности в PostGIS]]
| Существует ряд решений для организации версионности в PostGIS. Например, версионность [http://habrahabr.ru/post/137161/ средствами PostgreSQL],  [http://www.kappasys.ch/cms/index.php?id=23&L=5 pgVersion], [http://docs.codehaus.org/display/GEOTOOLS/Versioning+Postgis Versioning Postgis datastore], [http://slashgeo.org/2012/10/02/Distributed-Versioning-Geospatial-Data-New-Approach-Implementation-and-Development Distributed Versioning for Geospatial Data: A New Approach, Implementation and Development]. Необходимо провести анализ. 
| Любой
|2
|
|
|-
| [[#Построение вогнутых оболочек в PostGIS при помощи α-полигонов|Построение вогнутых оболочек в PostGIS при помощи α-полигонов]]
| Реализация алгоритма построения α-полигонов как функции PostGIS или самостоятельной. 
| С/C++
|3
|
|
|-
| Параллельная обрезка по нескольким полигонам в osmosis
| Текущая реализация обрезки по полигону в osmosis [http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--bounding-polygon_.28--bp.29] работает с одним полигоном, однако довольно часто требуется из одного дампа вырезать несколько областей. Добавление параллельной работы с несколькими полигонами обрезки поможет значительно ускорить этот процесс.
| Java
|3
| 
|
|-
| Реализация поддержки SLD в map-файлах MapServer
| Поддержка SLD в MapServer в принципе присутствует, но [http://osgeo-org.1560.n6.nabble.com/will-Mapserver-ever-support-SLD-inside-Mapfile-td4983265.html необходимо] добавить поддержку в map-файл.
| C
|4
|
|
|-
| [[#Анализ существующих решений по организации сетевой модели геоданных (интеллектуальной модели)|Анализ существующих решений по организации сетевой модели геоданных (интеллектуальной модели)]]
| Необходимо рассмотреть существующие решения по организации функционала сетевой модели геоданных в ГИС.
| C/C++
|3
| 
| статья недописана?
|-
| [[#Создание сетевой модели геоданных (интеллектуальной модели)|Создание сетевой модели геоданных (интеллектуальной модели)]]
| Существует понятие сетевой модели (network model) когда геометрии не только имеют пространственную привязку но и связаны друг с другом.
| C/C++
|3
| 
| не актуально, в GDAL 2.0 уже есть
|-
| [[#Определение места съемки|Определение места съемки]]
| По обычной фотографии и известном месте съемки необходимо автоматизировано определять местоположение в момент съемки.
| C/C++
|3
| 
|
|}

[[Категория:Служебные]]

==Подробнее==
===Генератор отчетов===
Сейчас есть только «компоновки» (макеты карты), которые позволяют создавать печатные карты с некоторыми элементами оформления. Возможность создания более-менее сложных отчетов (карта, форматированный текст, данные из атрибутивных таблиц, графики, выполнение расчетов) отсутствует. В качестве образца можно взять Fast/FreeReport, NCReport, CrystalReport

===Визуальный привязчик растров===
Цель: ускорение и облегчение процесса привязки<br />
Географическая привязка изображений на лету. Текущий инструмент - статический, работает так, загружаем растр в спец. модуль, расставляем точки, выбираем настройки, запускаем процесс трансформации, ждем, получаем результат - оцениваем точность.
Визуальный процесс привязки работает так: загружаем растр в канвас, ставим первую точку - растр делает shift, ставим вторую точку, растр делает scale, ставим третью - растр делает transform и все на лету, при двигании точек соответственно перетягивается растр.

С точки зрения алгоритмов все в QGIS для этого уже есть.

===Режим Wireframe===
Цель: ускорение работы с векторными слоями<br />
Скорость отрисовки векторных слоёв при прочих равных условиях зависит от сложности и количества используемых условных знаков. В некоторых ситуациях (например, при редактировании) нет необходимости во всех красивостях, но важна скорость отрисовки. Необходимо реализовать переключение на простые стили (тонкая линия, полигон без заливки, окружность малого радиуса без заливки) и обратно по запросу пользователя.

===Генерализация на лету===
Цель: ускорение работы с векторными слоями<br />
Еще один способ повысить скорость отрисовки - генерализация (упрощение) объектов. Пока только для линейных слоёв. Т.е. перед тем как выполнить отрисовку уменьшаем количество узлов в линии, и за счет некоторого огрубления получаем выигрыш в скорости. При этом необходимо учитывать, что при переходе в режим редактирования должны показываться все узлы, а не только оставшиеся после генерализации

===threading_branch===
Цель: ускорение работы<br />
Многопоточная отрисовка и оптимизация. Изначально работа была сделана в рамках GSoC 2010, но по ряду причин так и не была влита в основное дерево. Код давно не синхронизировался с текущим деревом

===Топологически корректное упрощение===
При упрощении смежных полигонов не учитывается топология, что делает инструмент бесполезным при решении ряда задач. Ссылка в тему http://gis.stackexchange.com/questions/178/simplifying-adjacent-polygons

===Экспорт в MBTiles===
Начиная с версии 2.0 GDAL поддерживает чтение формата MBTiles - тайлового растрового формата для пространственных данных хранящего набор тайлов соответствующих отрисовке карты на разных масштабах в едином файле базы данных SQLite. На сегодняшний день такие тайлы могут создаваться только в TileMill, логичным представляется экспорт настроенного проекта QGIS в этот формат для дальнейшей публикации в Web и использования там, где этот формат можно читать.

===Коррелятор===
В настоящее время осуществляется сбор большого количества данных ДЗЗ с БПЛА и самолетов. В большинстве случае - это кадровая съемка. Для формирования единого бесшовного изображения встает задача поиска связующих точек изображений на маршруте и межмаршрутных изображений или просто создание панорам. Необходимо расширить библиотеку GDAL таким алгоритмом.

Задача разрабатывалась на [http://trac.osgeo.org/gdal/wiki/Correlator Google Summer of Code 2012].

=== Уравнивание сети триангуляции ===
Собранные с использованием [[#Коррелятор|Коррелятора]] точки образуют сеть триангуляции. Причем, соответствующие точки с разных изображений будут иметь отличающиеся географические координаты. Для однозначного позиционирования изображений на местности, сеть точек нужно уровнять. Тогда изображения "лягут" на свои места и стыки межу ними будут мало заметны.

===Создание DEM по стерео изображениям===
DEM (Digital elevation model) - цифровая модель местности. В классическом виде представляет собой геоприявязанный растр в каждой ячейки которого содержится высота. По стерео изображениям можно извлечь данные о высоте и даже по объему.

===Драйвер GDAL===
GDAL - это библиотека для работы с географическими форматами файлов данных. GDAL распространяется Open Source Geospatial Foundation на условиях лицензии X/MIT , то есть является проектом с открытым исходным кодом. Как библиотека, GDAL предоставляет вызывающему приложению единую обобщённую модель данных для всех поддерживаемых форматов файлов данных. Поддержка форматов добавляется через так называемые "драйверы". Имеются руководства по написанию драйверов для [http://gdal.org/ogr/ogr_drivertut.html векторных] и [http://gdal.org/gdal_drivertut.html растровых] источников геоданных. Кроме того, исходные коды открыты и любой желающий может ознакомится с существующими реализациями драйверов.

===Добавление поддержки форматов метаданных===
Библиотека GDAL позволяет читать и выдавать через API метаданные для данных дистанционного зондирования. Более подробно о метаданных рассказано в статье [[Ортокоррекция космических снимков с использованием RPC|Ортокоррекция космических снимков с использованием RPC]]. Необходимо добавить поддержку метаданных для комплектов поставки с различных КА.

===Кусочно-линейное редактирование гистограммы===
Текущие средства работы с гистограммой достаточно простые, есть только обрезка и растяжение по стандартному отклонению, эквализация. Предлагается добавить возможность работы с гистограммой с помощью кусочно-линейных преобразований позволяющих настраивать отдельные области гистограммы за счет ручного указания изменяемых областей.

===Исправление некорректных планарных геометрий===
Существует новое решение (pprepair) для решения проблемы исправления топологической структуры планарных геометрий. К сожалению, это решение использует CGAL. Задача минимум, перевести его на GEOS/OGR например в виде плагина для QGIS или отдельного приложения. [http://geospaced.blogspot.com/2012/09/fixing-polygons-with-pprepair.html Подробнее о pprepair].

Уже есть [https://github.com/tudelft3d/prepair-qgis плагин] для QGIS, использующий ''prepair''.

===Создание десктопного индексатора геопространственных файлов===
Для быстрого поиска файлов обычно используют индексирование. Это программа, которая периодически запускается и по каким либо характеристикам выполняет извлечение ключевой информации с записью в базу данных. Далее к этой базе можно обращаться и осуществлять очень быстрый поиск данных. Предлагается использовать существующие поисковые движки на основе открытого программного обеспечения, например [http://sphinxsearch.com Sphinx] или [http://www.dataparksearch.org/ DataparkSearch]. Выбранный поисковый движок должен быть доработан или его функционал должен использоваться в программе службе/сервисе/демоне. Для проверки функционала должна быть разработана программа (наиболее простой случай - консольная утилита) для  выдачи списка файлов по переданным параметрам.

===Анализ открытых решений для организации версионности в PostGIS===
Существует ряд решений для организации версионности в PostGIS. Например, версионность [http://habrahabr.ru/post/137161/ средствами PostgreSQL],  [http://www.kappasys.ch/cms/index.php?id=23&L=5 pgVersion], [http://docs.codehaus.org/display/GEOTOOLS/Versioning+Postgis Versioning Postgis datastore], [http://slashgeo.org/2012/10/02/Distributed-Versioning-Geospatial-Data-New-Approach-Implementation-and-Development Distributed Versioning for Geospatial Data: A New Approach, Implementation and Development]. Необходимо провести анализ. В результате анализа должна быть написана статья с описанием текущего состояния и предложены теоретические подходы к организации версионности.

===Построение вогнутых оболочек в PostGIS при помощи α-полигонов===
Существующие реализации: [http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Alpha_shapes_2/Chapter_main.html CGAL] - лицензионные противоречия, [http://procomun.wordpress.com/2011/04/07/alpha-shapes-with-lattice/ CRAN R - Lattice] - производительность и CRAN R плохо подходит для массовой работы с геоданными, [http://www.postgis.org/docs/ST_ConcaveHull.html ST_ConcaveHull] - использует алгоритм со страным параметром в процентах и невозможно однозначно сказать какими свойствами будет обладать полигон при том или ином параметре. Код - эвристический алгоритм на PL/SQL. При обработке больших геометрий приходится резать на кусочки. В случае с ST_ConcaveHull кусочки не согласованы между собой.

===Анализ существующих решений по организации сетевой модели геоданных (интеллектуальной модели)===
Необходимо рассмотреть существующие решения по организации функционала сетевой модели геоданных в ГИС. Рассматриваются как проприетарные так и открытые ГИС. В результате анализа должна быть написана статья с описанием текущего состояния и предложены теоретические подходы к организации сетевой модели геоданных.

===Создание сетевой модели геоданных (интеллектуальной модели)===
Существует понятие сетевой модели (network model) когда геометрии не только имеют пространственную привязку но и связаны друг с другом. Например, система трубопроводов и кранов. При перекрытии крана, часть труб меняет свое состояние (с водой / без воды). На основе анализа необходимо осуществить реализацию в библиотеке GDAL/OGR сетевой модели.

===Определение места съемки===
В оптической системе световой поток преломляется. В результате этого параллельные линии выглядят не параллельно. Если оператор отметит на фотографии такие линии, то они сойдутся в фокусе фотоаппарата. А по космической/авиационной съемке можно определить местоположение объектов и снимавшего в пространстве.

===Выборка сложными границами===
Текущая производительность OGR при выборке объектов полигонами со сложными границами очень невелика. Один из вариантов решения - двухпроходный подход, когда делается сначала простым прямоугольным охватом, а затем уже проверяется точное вхождение. Создание индексный *.qix файлов по какой-то причине не помогает. Возможно это просто баг OGR.