Вопросы по исходному коду

[vdemidov]

Может ввод напрямую через плагин sas будет несложно реализовать? Существую ли плагины для импорта меток и полигонов и парочка примерчиков?

Плагинов пока нет. Можете просто реализовать импорт на Delphi. Модули u_VectorItemTreeImporter*. Для парсинга JSon уже есть библиотека SuperObject (используется в u_GeoCoderByYandex и других местах). Реализовать, думаю будет совсем не сложно.

[DJ VK]

Парсер Kml
u_KmlInfoSimpleParser
иерархию при импорте сохраняет или все в 1 категорию пихает?

как вообще категория меток учитывается? Я вижу только

Код: Выделить всё

FVectorDataFactory.BuildItem(
          AVectorDataItemMainInfoFactory.BuildMainInfo(AIdData, AName, ADesc),
          nil,
          VGeometry
        );

[vdemidov]

Парсер Kml
u_KmlInfoSimpleParser
иерархию при импорте сохраняет или все в 1 категорию пихает?

Не сохраняет. Это парсер используется только для викимапии и панарамио.
Как я уже писал, смотреть нужно юниты u_VectorItemTreeImporter*.pas

Нужно создавать дерево из элементов TVectorItemTree
То есть, грузим все точки категории в массив IVectorItemSubset, все подкатегории в отдельные IVectorItemTree в IInterfaceListStatic, а потом создаем соответствующий TVectorItemTree.

[DJ VK]

Парсер Kml
u_KmlInfoSimpleParser
иерархию при импорте сохраняет или все в 1 категорию пихает?

Не сохраняет. Это парсер используется только для викимапии и панарамио.
Как я уже писал, смотреть нужно юниты u_VectorItemTreeImporter*.pas

Нужно создавать дерево из элементов TVectorItemTree
То есть, грузим все точки категории в массив IVectorItemSubset, все подкатегории в отдельные IVectorItemTree в IInterfaceListStatic, а потом создаем соответствующий TVectorItemTree.

Это очень сложно.
Надеюсь что-нибудь с Вашей помощью да получится.

скрытый текст: показать

Я в своих программах всегда стремлюсь поделить такого вида задачи на две части, в т.ч потому, что работаю часто в паре.
В нашем случае это будет так:
1. Парсер только строит дерево сущностей, которое должно быть внедрено.
например, TTreeNodes c типизированным Record вместо TObject.
Категория, Имя, Описание, Тип.
2. Ядро программы от всех парсеров получает однотипное дерево, и вклеивает в нужые категориии.
Как итог, ядро программы, которое не я обычно делаю и мне легко говорить, совсем чуть-чуть усложняется.
Но зато парсеры потом создаются очень быстро.
Совсем не забивать свою голову внутренними сущностями программы - вот идеал. И для отладки не нужно тысячу uses=include тянуть. Вообще не нужна планета для этого и все её ежедневночные дампы и reqiures.

Мне предстоит неделю или несколько даже пытаться разобраться в десятках или сотнях абсолютно мне чуждых классов. Да еще и под отладчиком их смотреть. А ведь вместо этой неприятной для меня работы, я мог бы уже грызть дальше Esri Shp и другие, если бы...
я не жалуюсь, это скорее сожаление о довольно сложной и враждебной структуре программы (без поддержки плагинов чуть ли не на любой чих.)
Я с 90х программирую и то лишь на 80 % могу самостоятельно встраивать в SASПланету свой код. И никакие новички большой помощи не окажут при таком подходе. Выборочно и крайне редко.

ну и неудобно отсутсвие некого unstable репозитория для недоделанных до конца дополнений, которые в конечном итоге, после совместной доработки сообществом, могли бы дополнить таки программу.
Антибан г**гля кстати работает как часы уже полгода почти. Но "стараниями" сообщества доступен лишь мне одному
Я не оспариваю законность претензий. Я просто говорю, что продуктивнее коллективное взаимодействие без жесткого разграничения прав и обязанностей и взаимовыручка.

Предлагаю уделять немного внимания допиливанию таких вот нововеедений. И часть кода внедрять не коммитами и контролем версий, а Бейонд компэром прямо в папку с отлаживаемым проектом.

Работа по улучшению программы в 4 этапа.
1. обсуждение новых бункций и алгоритмов их работы - багтрекер.
2. Публикация фрагментов будущего кода - надо площадку.
3. Публикация модифицированных исходников программы сделанных пользователями - надо площадку.
4. Публикация готовых коммитов полностью готовых улучшений - это есть на битбукете

2й и 3й пункт помогают ускорить процесс публикации новых алгоритмов., целевая версия которых запредельна в 1м пункте.

Вопросы.
1. Возможно как-то поддержать ввод доп.настроек пользователем для данного формата импорта ?
2. Есть конкретный пример TVectorItemTree или парсер где все это уже строится, и можно просто взять и подменить поля конкретных меток?
3. Как трактовать MultiPoint и MultiLineString. (Набор точек и набор незамкнутых линий)?
4. Сериализация может и упрощает задачу, но ограничивает область применения - 1 парсер на 1 узкоспецифичный вид GeoJSON. Вручную ведь не сильно медленнее ?
5. Как обрабатывать массив массивов в superobject?
[a, b] - массив значений. Метод d
[{},{}] - массив объектов. метод o
[[],[]] - Массив массивов/ метода нет???

[vdemidov]

Я в своих программах всегда стремлюсь поделить такого вида задачи на две части, в т.ч потому, что работаю часто в паре.
В нашем случае это будет так:
1. Парсер только строит дерево сущностей, которое должно быть внедрено.
например, TTreeNodes c типизированным Record вместо TObject.
Категория, Имя, Описание, Тип.
2. Ядро программы от всех парсеров получает однотипное дерево, и вклеивает в нужые категориии.
Как итог, ядро программы, которое не я обычно делаю и мне легко говорить, совсем чуть-чуть усложняется.
Но зато парсеры потом создаются очень быстро.
Совсем не забивать свою голову внутренними сущностями программы - вот идеал. И для отладки не нужно тысячу uses=include тянуть. Вообще не нужна планета для этого и все её ежедневночные дампы и reqiures.

Ну так именно это и сделано. Ядро программы получает дерево из IVectorItemTree, в которых есть только названия категорий (параметры категорий не предусмотрены для импорта вообще) и сами метки каждой из категорий. Причем у меток не обязательно должны быть все атрибуты, а только геометрия, название и описание. А уже потом по этому дереву ядро программы создает недостающие категории, переназначает параметры оформления в соответствии с настройками импорта и запихивает метки в базу.

Мне предстоит неделю или несколько даже пытаться разобраться в десятках или сотнях абсолютно мне чуждых классов. Да еще и под отладчиком их смотреть. А ведь вместо этой неприятной для меня работы, я мог бы уже грызть дальше Esri Shp и другие, если бы...
я не жалуюсь, это скорее сожаление о довольно сложной и враждебной структуре программы (без поддержки плагинов чуть ли не на любой чих.)

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

ну и неудобно отсутсвие некого unstable репозитория для недоделанных до конца дополнений, которые в конечном итоге, после совместной доработки сообществом, могли бы дополнить таки программу.

Делаете свой форк, а он в любом случае понадобится, и там хоть в одиночку, хоть с помощью всей планеты допиливаете фитчи, а когда они полностью готовы формируете окончательные коммиты и отпраляете пулл-реквест.

Антибан г**гля кстати работает как часы уже полгода почти. Но "стараниями" сообщества доступен лишь мне одному

Потому и работает до сих пор, что не доступен широким массам. Кому нужно - сам допилит. Я занимаюсь ядром приложения, а не отдельными фитчами рассчитанными на конкретные сервисы.

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

Так не бывает. Хотя как я уже писал форк делать придется в любом случае. А в своем форке можете делать все что угодно и никто не запретит и не ограничит.

Предлагаю уделять немного внимания допиливанию таких вот нововеедений. И часть кода внедрять не коммитами и контролем версий, а Бейонд компэром прямо в папку с отлаживаемым проектом.

Уделяйте. Внедряйте.

1. обсуждение новых бункций и алгоритмов их работы - багтрекер.

Чего не хватает?

2. Публикация фрагментов будущего кода - надо площадку.

Уже есть битбукет. С возможность комментирования оналйн и тд.

3. Публикация модифицированных исходников программы сделанных пользователями - надо площадку.

Тут сложнее. Тут и вопрос доверия к чужим изменениям и к чужому коду. ИМХО для попробовать достаточно выложить собранный exe на любой обменники или даже приаттачить в багтрекере.

В общем вопрос не в технических средствах.

1. Возможно как-то поддержать ввод доп.настроек пользователем для данного формата импорта ?

Пока никак, точнее там есть какие-то костыли, но именно костыли. Если есть предложения говорите.

2. Есть конкретный пример TVectorItemTree или парсер где все это уже строится, и можно просто взять и подменить поля конкретных меток?

u_VectorItemTreeImporterXML.pas

3. Как трактовать MultiPoint и MultiLineString. (Набор точек и набор незамкнутых линий)?

MultiPoint как хотите. Пока такой сущности в САС нету. Можно размножить на несколько отдельных точек.
MultiLineString как мультилинию.

. Сериализация может и упрощает задачу, но ограничивает область применения - 1 парсер на 1 узкоспецифичный вид GeoJSON. Вручную ведь не сильно медленнее ?

В чем вопрос то?

5. Как обрабатывать массив массивов в superobject?

Понятия не имею. Спросите у разработчиков superobject

[DJ VK]

Дерево получил (пока что ttreeview). с суперобъектом разберусь.

u_VectorItemTreeImporterXML.pas неудачный пример
Большая часть его работы спрятана в недрах XmlVectorObjects и VSAGPS
А примера попроще нет.

1.метка создается судя по всему не напрямую, а через "фабрику" ?

Код: Выделить всё

VItem :=
        FDataFactory.BuildItem(
          FVectorDataItemMainInfoFactory.BuildMainInfo(FIdData, VName, VDesc),
          VAppearance,
          VGeometry
        );

2. У меня для каждой метки есть уникальный id( int64. По ним строится иерархическое дерево.) - куда его запихнуть при построении?

3. у меток в файле нет никаких параметров цветовой окраски. вместо VAppearance подставлять nil ?

[vdemidov]

u_VectorItemTreeImporterXML.pas неудачный пример
Большая часть его работы спрятана в недрах XmlVectorObjects и VSAGPS
А примера попроще нет.

Увы. Никто пока не реализовал. Первым будешь. На самом деле, все сводится к простому рекурсивному построению дерева. В принципе можешь посмотреть в функциях CategoryTreeToMarkTreeHelper и CategoryListToCategoryTree, которые строят дерево категорий по списку со сложными именами, а потом по этому дереву уже результирующее с метками.

1.метка создается судя по всему не напрямую, а через "фабрику" ?

Через фабрику только что бы не морочиться каждый раз отдельно с хешами и пробрасыванием вычисления хэшей. Но ИМХО тебе так даже проще будет.

2. У меня для каждой метки есть уникальный id( int64. По ним строится иерархическое дерево.) - куда его запихнуть при построении?

А зачем он тебе?
Пока есть два варианта.
Свой вариант наследник IVectorDataItemMainInfo, который будет хранить нужные тебе айдишки. Но они доживут только до сохранения в базу, после чего будут пересозданы так как в базе все равно такого поля нет.
Или просто в текст описания запихнуть в какой-то тег.

3. у меток в файле нет никаких параметров цветовой окраски. вместо VAppearance подставлять nil ?

Да. Именно так. Если данных нет, то потом движок создаст их на основе настроек импорта.

[vdemidov]

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

[vdemidov]

2. У меня для каждой метки есть уникальный id( int64. По ним строится иерархическое дерево.) - куда его запихнуть при построении?

А зачем он тебе?
Пока есть два варианта.
Свой вариант наследник IVectorDataItemMainInfo, который будет хранить нужные тебе айдишки. Но они доживут только до сохранения в базу, после чего будут пересозданы так как в базе все равно такого поля нет.
Или просто в текст описания запихнуть в какой-то тег.

Если тебе только для построения дерева, то проще держать отдельный внешний словарик на время пока идет импорт.

[DJ VK]

А в программе наоборот, класс геометрии мультиточки и нету класса геометрии точки.

TGeometryLonLatMultiPoint = class(TGeometryLonLatBase, IGeometryLonLat, IGeometryLonLatMultiPoint)
private
function GetEnum: IEnumLonLatPoint;
function IsSameGeometry(const AGeometry: IGeometryLonLat): Boolean;
function IsSame(const APoint: IGeometryLonLatMultiPoint): Boolean;
function GetGoToPoint: TDoublePoint;
public
constructor Create(
const ABounds: ILonLatRect;
const AHash: THashValue;
const APoints: IDoublePoints
);
end;

это я так понимаю если напрямую делать не используя TGeometryLonLatFactory.

в целом уже понятно, что геометрия будет одним из классов TGeometryLonLat*** с указателем приведенным к IGeometryLonLat, а метка целиком TVectorItemTree. Можно даже дерево с ними получить на основе TTreeView для отладки.

Теперь как можно подробнее, пожалуйста, про структуру категорий и про деревья.

TVectorItemSubsetBuilderFactory Create
получаем TVectorItemSubsetBuilder через Build
и добавляем в него через Add метки TVectorItemTree полученные выше.
Это линейная структура. а как сделать разветвленную ?

скрытый текст: показать

Сейчас строится дерево, но оно нужно лишь чтобы вычислить путь (подкатегорию) для каждой метки.
например, такой: \Россия\ЦФО\Московская обл.\Дмитровский р-н\гп Икша
Метка не содержит в названии ничего о родительских объектах, и непонятно поселение какого района и области.
зато построив дерево сразу все становится ясно, куда ее класть и как переименовать до полного пути.
мне в итоге нужны отдельные подкатегории для каждого уровня иерархии.