SDK прослойка для различных ГИС

[Dorofeev]

Я не считаю себя специалистом в области разработки ПО, т.к. не имею специального образования и начал серьезно заниматься этим сравнительно недавно. Но я работаю над собой и постепенно беру на вооружение приемы, используемые профессиональными разработчиками.
Собственно есть такая методика разработки, особенно популярная при работе с БД, когда программа строится по модульной архитектуре и общение между модулями производится с помощью интерфейсов.
Например : Данные - Провайдер доступа к данным и методам(Классы данных, методы манипуляции ими) - Бизнес объекты(Классы - прототипы реальных объектов) - Бизнес логика(Методы манипулирующие бизнес-объектами) - Представление (графический интерфейс).
Благодаря такой архитектуре можно с легкостью переводить программу с одного типа БД на другую, использовать как Windows Forms так и web интерфейс.
Меня интересует использование такой архитектуры применительно к разработке дополнений на С# для различных ГИС(Например ArcGis, MapInfo, MapWindow). А конкретно, реализация общего для нескольких ГИС шаблона провайдера доступа к данным и методам ГИС. Использование такого подхода позволит разрабатывать плагин сразу для нескольких ГИС, применяя одну и ту же объектную модель, бизнес логику и представление, при этом используя различную реализацию методов шаблона провайдера доступа к данным и методам ГИС.
При работе с БД программисты обычно сами проектируют и реализуют подобные шаблоны, т.к они содержат не так много операций(соединение с БД, манипуляция таблицами, запросы). В ГИС помимо операций присущих работе с БД, необходима реализация spatial запросов, методов геообработки, работы с проекциями. Поэтому проектирование такой структуры для меня довольно проблематично.
Может кто-то встречал в сети реализацию задачи подобного рода?

[yellow-sky]

Извиняюсь заранее, если мой ответ будет немного не по теме.
Как я понял, вы хотите универсальный интерфейс(программный) для различных геоинформационных программных продуктов. (Признаюсь сразу - я таких не видал, хотя очень даже возможно такое и разрабатывается).
Приведенный вами пример с СУБД не совсем корректен на мой взгляд, и вот почему. СУБД, а вернее РСУБД - достаточно стандартизованная область и имеет хорошо очерченные границы. Даже если вы рассмотрите вариант хранения геоданных в СУБД, то вы обнаружите достаточно схожие наборы процедур и типов данных. Это позволяет обобщить часто используемые приемы работы с данными в "модули" или провайдеры данных.
Если же мы рассматриваем программные продукты\фреймворки\итд - то тут все намного сложнее. Особенно когда вы затрагиваете проприетарный софт. Давайте рассмотрим маленький пример - попробуем создать универсальное описание\модель проекций в различных ПО. АркГИС имеет очень хороший движок описаний проекций. Это позволяет создавать свои проекции, незаложенные в нем изначально. А теперь рассмотрим ГИС Ингео. Лет 5-6 назад, эта ГИС могла работать только с местными прямоугольными СК (надеюсь сейчас это уже и не так). Представляете какие ограничения накладывает програмная модель Ингео на описание проекций? Причем создаваемая нами модель\метамодель должна это учитывать. В последствии, когда мы рассмотрим все желаемые ГИС у нас образуется гигантская гора особенностей\возможностей\ограничений работы с проекциями, которые нам нужно хорошо понять, учесть и спроектировать универсальную прослойку, которая даст возможность полноценно работать с любой из рассмотренных ГИС. Все это вытекает из слабой стандартизации области. Многие проприетарные ГИС развивались по своему, самобытному пути, реализовывали свои варианты работы с геоданными\проекциями и тд. С открытыми\свободными проектами намного проще. Практически все свободные продукты тяготеют к стандартизации или же к использованию хорошо развитых библиотек. В плане проекций это конечно же Proj4. Поэтому проекцию, выбранную в QGIS, вы с легкостью примените в PostGIS или Mapserver. Даже если вы опишите новую проекцию средствами Proj4, остальные продукты смогут ей пользоваться - так как они используют Proj4 как библиотеку при любых действиях проектирования\перепроектирования.
И так можно рассматривать любую область ГИС - форматы геоданных, геопроцессинг, визуализация, построении пользовательского интерфейса и тд - каждый программный продукт имеет серьезные отличия от своих конкурентов, порой принципиальные. Я слабо представляю себе фреймворк, который сможет служить прослойкой для всех продуктов. Это достаточно сложная структура, которая должна быть на порядок совершеннее всех включаемых в себя ГИС.

[Dorofeev]

Да, я забыл уточнить, что эта прослойка должна работать с схожими по архитектуре ГИС. Из таковых распространенных, где возможна разработка под DotNet, я могу припомнить ArcGis, MapInfo, AutoCadMap, MapWindow(СПО). Так что список невелик и я думаю, объединить их общим framework`ом(минимальным общим для всех функционалом) возможно.

[yellow-sky]

Возможно то конечно возможно, но вопрос, а зачем это нужно?
Если вам необходим такой фреймворк для написания одного плагина под все ГИС продукты - по-моему трудозатраты для написания самого фреймворка будут намного больше чем написание самого этого плагина для каждой ГИС в отдельности. Даже если нужно написать 5ть плагинов, то думаю и это не окупит всех трудов по разработке фреймворка. Его необходимо будет постоянно поддерживать в актуальном состоянии, а плагины будут требовать все более специфичного функционала. Учтите также, что ГИС расширения обычно достаточно критичны к производительности, а каждая прослойка будет сжирать время на трансляцию данных\команд.
Мое личное мнение - каждый ГИС продукт силен в своей области применения, в своем специфичном окружении, и писать универсальную прослойку не имеет ни какого смысла.

[JEY]

Создание общего "фреймворка" для различных программных продуктов для ГИС, может показаться пустой затеей, но OGC выпустило целый набор документов, которые стандартизируют этот процесс. Это не новость...

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

Теперь немного о .NET Framework. Согласен, что из всех свободных проектов, лишь немногие поддерживают эту платформу. Разработчики .NET довольно часто сталкиваются с тем, что не могут непосредственно использовать в своих разработках исходный код того или иного решения, уже не говоря о библиотеках, которые оказываются несовместимы с .NET Framework из-за того, что являются неуправляемым кодом (unmanaged code).

Кто из нас не искал .NET версии таких популярных решений как тот же самый Proj? А Mapnik? Я пытался найти версию .NET для Anti-Grain Geometry (известный как AGG). Я ее нашел, но до полного функционала оригинальной версии, мне придется еще много поработать.

Мне кажется, что в этом предложении есть определенный смысл!