Методы хранения нетайлового GIS-контента и работа с ним

[rokki]

При создании области закачки, хотелось бы видеть на карте ее границы и с полупрозрачной заливкой, а также иметь возможность присвоить области имя - описание с автоматическим добавлением в имя координат левого верхнего - правого нижнего угла. Например " Имя_области_(координаты, координаты)" При склейке, желательно чтобы имя(имена) склеиваемых фрагментов носили имя этой области.

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

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

[feya]

rokki
Ну область можно нарисовать и сохранить в базу меток (и назвать ее можно как вздумается), а далее с ней уже работать.

[rokki]

rokki
Ну область можно нарисовать и сохранить в базу меток (и назвать ее можно как вздумается), а далее с ней уже работать.

В базе меток по идее должны храниться точки интереса. Зачем делать венигрет в одну корзину? Не проще ли сделать визуализацию области? Тем более непонятно отсутствие визуализации области при наличие функции сохранения этой области. Юзер сохраняет область закачки, через день уже не помнит визуально границ этой области. Кроме того, имея отображение области и возможность ее перемещения мышкой по карте можно выстраивать точные мозаики для закачки. Без визуализации очень неудобно!

Кстати в базе меток kml до сих пор нет сортировки по имени... Это очень неудобно...У меня напримеор в одном файле около 500 точек ... созданных в ГЕ. Чтобы найти нужную, приходится отсматривать все. Это жесть )))

[svp]

rokki
Ну область можно нарисовать и сохранить в базу меток (и назвать ее можно как вздумается), а далее с ней уже работать.

В базе меток по идее должны храниться точки интереса. Зачем делать венигрет в одну корзину?

В данном случае в базе меток хранятся не только точки, но и пути с полигонами. Это значит, что "База Меток" -- неправильный термин, и нужно его пересмотреть.
Так называемая "База меток" сейчас представляет собой винегрет только потому, что нет нормальной древовидной группировки меток, путей и полигонов. Группировка и механизмы хранения такого контента уже предусмотрены в формате KML. Следовательно нужно не добавлять новые избыточные уникальные механизмы (читай изобретать велосипеды), а озаботиться корректной и более полной поддержкой уже давно придуманного и распространённого формата KML.

Не проще ли сделать визуализацию области?

Визуализация области уже реализована. Это видимые полигоны в KML. Уже есть возможность производить операции над областью каждого полигона.
Не хватает только сохранения выделений в KML (причём в соответсвующую папку в дереве, чтобы не путать с другими полигонами).
Пока нет удовлетворительной поддержки KML-формата можно реалищовать компромиссный варинат:

1. Реализовать возможность сохранения выделения в полигоны т.н. "базы меток".
2. Для каждого элемента "базы" хранить его путь в виртуальном дереве групировки.
3. Сделать окошко со списком всех меток, путей и полигонов "базы меток".
   При открытии этого окна каждый раз следует собирать дерево на основе пути элемента "базы".

Тем более непонятно отсутствие визуализации области при наличие функции сохранения этой области.

Именно! Нужно, чтобы область могла сохраняться в полигон.

Ещё выше по ветке было предложение хранить последнее выделение как файл LastSelection.kml. Сделать также возможность пересохранения этого файла в каталог с KML. Операции над KML-полигонами уже доступны.
Пожалуй это второй компромиссный вариант.

[rokki]

Ну коли имеется возможность создавать полигоны и потом используя их загружать тайлы, тогда зачем в платнете есть вторая функция выделения области ? Все таки мне кажется что логичнее было бы области выделения под закачку-склейку реализовать отдельно. А точки интереса и треки - это уже другая песня, которой и без полигонов хватает задач. Там неплохо было бы сделать древовидную структуру с возможностью каталогизации по папкам.

Другими словами нужно разделить точки интереса с треками (что предназначено больше к навигации) и областями - полигонами (закачка и склейка карт) Сохранение в файл области уже есть. Этого в принципе достаточно для работы. Просто нужно добавить множественную загрузку-выгрузку этих областей, чтобы все это не висело в памяти... Что надо подгрузил - поработал -выгрузил.

Или пойти другим путем-ввести понятие "проекта" куда пишутся и точки и области и треки... Работаем с конкретной областью на карте - сохраняем проект. Так мне кажется будет удобнее и понятнее. В каждом проекте только то что нужно а не в кучу

[svp]

Ну коли имеется возможность создавать полигоны и потом используя их загружать тайлы, тогда зачем в платнете есть вторая функция выделения области ?

Уверен со временем сегодняшняя реализация функции выделения отвалится как архаичная.

Все таки мне кажется что логичнее было бы области выделения под закачку-склейку реализовать отдельно. А точки интереса и треки - это уже другая песня, которой и без полигонов хватает задач.

Не надо путать внутреннюю реализацию с интерфейсом. В интерфейсе функция выделения и функция рисования полигонов должны быть разделены. Но реализовать технически их можно за счёт одного механизма. И хранить полигоны можно одинаковым совместимым методом. Это эффективно и лаконично.
Все эти вещи можно разбить по дереву:

+ Точки
+ Пути
+ Полигоны
+ Выделения (которые тоже полигоны)

И внутри каждого их этих узлов любая структура подкаталогов.
Как в Google Earth. Совершенно ничего изобретать не придётся.

Просто нужно добавить множественную загрузку-выгрузку этих областей, чтобы все это не висело в памяти... Что надо подгрузил - поработал -выгрузил.
Или пойти другим путем-ввести понятие "проекта" куда пишутся и точки и области и треки... Работаем с конкретной областью на карте - сохраняем проект.

Ну так это всё уже придумано! Проект -- это тот же KML-файл. При его подключении прога затягивает его к себе в дерево. Если надо какую-то ветвь дерева погасить, просто щёлкаем по галочке на корневом узле ветви и всё. Чем не устраивает механизм GE? Отвечу сам: единственно тем, что его ещё нет в Планете.

[rokki]

Ну так это всё уже придумано! Проект -- это тот же KML-файл. При его подключении прога затягивает его к себе в дерево. Если надо какую-то ветвь дерева погасить, просто щёлкаем по галочке на корневом узле ветви и всё. Чем не устраивает механизм GE? Отвечу сам: единственно тем, что его ещё нет в Планете

а зачем из программы делать ГЕ ? оно уже есть... )))

[svp]

а зачем из программы делать ГЕ ? оно уже есть... )))

Никто не предлагает делать GE. Предлагается пользоваться совместимыми обкатанными распространёнными решениями, а не изобретать уникальные глючные велосипеды, на каждый из которых придётся ещё писать по кнвертеру.

[rokki]

а зачем из программы делать ГЕ ? оно уже есть... )))

Никто не предлагает делать GE. Предлагается пользоваться совместимыми обкатанными распространёнными решениями, а не изобретать уникальные глючные велосипеды, на каждый из которых придётся ещё писать по кнвертеру.

совместимость определяется наличием плагинов экспорта. Надо в кмл - пожалуйста, надо в ози - пожалуйста. А не построением ядра на приципах и механизмах уже реализованных в других прогах. Базу точек, треков, полигонов не надо делать на кмл. Надо делать базу на мускле, с тем чтобы потом ее расшаривать для совместного онлайн доступа... Чего нет ни в одной подобной программе ) А не делать этого - глобальная ошибка разраба.)) Зачем делать клон ГЕ? Смысла не вижу... Оно легче... это понятно )))Но бессмысленно )) Уникальность приложения определяется уникальным функционалом...
Вы же предлагаете "надергать" готовых решений. Это не правильно )) Хотя и проще ))

[svp]

Базу точек, треков, полигонов не надо делать на кмл. Надо делать базу на мускле, с тем чтобы потом ее расшаривать для совместного онлайн доступа... Чего нет ни в одной подобной программе ) А не делать этого - глобальная ошибка разраба.))

Базы MySQL в чистом виде не достаточно, чтобы получить удобное средство обмена контентом. Такая задача отлично формализуется в виде отдельного сервиса, поодержку которого можно было бы сделать не только Планетой, но и другими приложениями, которые, возможно, появятся.
Про Планету уже не раз говорили, что она не идеал архитектуры. Не исключено, что появятся более совершенные её клоны. Что тогда делать с накопленным контентом в MySQL?
Побыстрее накидать в кучу разного функционала -- это неправильный метод разработки. Нужно дробить задачу на как можно большее количество отдельных простых и самостоятельных подзадач. Тогда вся работа имеет шанс не быть погребённой под тоннами собственного устаревающего кода.
Резюмирую:
Нужен обмен гис-контентом, значит нужен продуманный самостоятельный сервис для этого. Это отдельная задача по сложности в реализации не уступающая разработке SAS.Планеты.
Пример такого сервиса -- wikimapia.
Для Планеты не хватает авторизации и фильтрации контента.