Тест

Тест

Inform++ стал Esri Silver Tier Partner

http://partners.esri.com/PartnerDetail?id=a2T70000000TcsCEAS - наша партнерская страница

Геотаргетирование информационных систем

К пониманию геотаргетирования:

• Человек тем более интересуется объектами, чем ближе они к нему в пространстве и времени.
• Придание информационным объектам пространственной и временной привязки позволяет перевести геометрические параметры, как индивидуальные, так и множественные, в естественный язык. 
• Примеры топологических отношений. Ближе-дальше, внутри-снаружи, выше-ниже, раньше-позже, плотность объектов,.. Список достаточно длинный, и каждая сравнительная форма дает нам определенный срез искусственного разума.
• Особенность появления таких понятий в том, что они создаются автоматически, как вариант, по идентифицирующему запросу к списку пространственных объектов. Никто их не произносит и не записывает.
• Существование сетей смартфонов с пространственной и временной идентификацией позволяет производить геотаргетированную информацию и ее потреблять. Создание в полной мере геотаргетированной информационной системы соответствует актуальным технологических достижениях в аппаратной и программной области.

GCL. Часть 3. Объекты классических ГИС.

Geodata Control Language - GCL

Компоновка - раздел, отвечающий за представления объектов и печатные формы

XML	JSON
<layout>  <dynamic>...   </dynamic>  <static>...   </static> </layout>	{   "layout": {     "dynamic": "...   ",     "static": "...   "   } }

<dynamic> - динамическое представление (базовое)

 <static> - статическое представление (препресс)

Компоновка позволяет включать множественное представление данных, достаточное для создания атласов и других сложных объектов. За счет возможности внедрения программного кода возможна установка связи между элементами компоновок.

Стиль

<style>.../style>

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

GCL. Часть 2. Работа с вычисляемыми полями

Geodata Control Language - GCL

Часть 2 Работа с вычисляемыми полями

Вычисления в объектах

Одно из важных свойств программного кода - возможность создавать вычисляемые поля. Например, в приведенном примере поле <ab> является вычисляемым и равно произведению полей <a> и <b>.

XML	JSON
<tags>   <index>     <a>300</a>     <b>10</b>     <ab>      <code>a*b</code>     </ab>   </index>  </tags>	{   "tags": {     "index": {       "a": "300",       "b": "10",       "ab": { "code": "a*b" }     }   } }

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

Хранение кода. Наследование.

Базовый объект (предок) может хранить код для наследуемых объектов. Предпочтительный вариант - весь код и определения полей в базовом абстрактном классе, а в его потомках уже значения.

XML	JSON
<object identify="base"> <tags>   <index>     <a type="float" />     <b type="float" />     <ab>      <code>a*b</code>     </ab>     <!-- Или -->      <ab code="a*b"/>     </index>  </tags> </object>	{   "object": {     "-identify": "base",     "tags": {       "index": {         "a": { "-type": "float" },         "b": { "-type": "float" },         "ab": [           { "code": "a*b" },           { "-code": "a*b" }         ]       }     }   } }

XML	JSON
<object parent="My parent"> <tags>   <index>     <a>300</a>     <b>10</b>   </index>  </tags> </object>	{   "object": {     "-parent": "My parent",     "tags": {       "index": {         "a": "300",         "b": "10"       }     }   } }

Язык управления геоданными. Введение. Geodata Control Language - GCL

описание нового языка (подхода) управления геоданными GCL

Если предложите название языка лучше - буду благодарен.
Попробую выложить черновик и дальше развивать

Язык управления геоданными
Geodata Control Language - GCL

Введение
Базовые понятия и гипотезы

Поле и вещество.

Растр является полем а вектор - веществом. 

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

Векторные географические данные являются объектами.

Для чего это надо

Для обеспечения интерактивности в поведении географического объекта.

Географические объекты разной природы, например труба и задвижка, могут принимать и передавать события. Линейный объект трубы может принимать событие закрытия точки задвижки и изменять свой стиль. Имея стандарт описания как географических свойств объекта, так и его поведения, мы получаем, например, возможность создавать более качественные программные пространственные системы и решать новые задачи. Прикладной аспект видится весьма актуальным, вернусь к этому моменту при необходимости.

Расширениями классического формата геоданных, типа shp или kml в GCL является процедурная часть и события.

Процедуры отвечают за операции с собственными данными объекта и с методами других объектов GCL.

Предложение стандарта языка управления геоданными

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

Таким образом, первичный географический объект содержит следующее:

1. Геометрия (пространственная информация)
2. Признаки (атрибуты)
3. Процедуры (методы)
4. События (In Out)

Все эти элементы для начала содержатся в XML или JSON подобных форматах. Думаю, конечные тонкости формата хранения географических объектов будут определяться наличием хороших библиотек для работы с различными форматами. Предпочту вести примеры на диалекте XML-HTML5 и, надеюсь, что это будет удобно и легко переводимо.

Прототип абстрактного класса

<!--путь к стандарту описания тегов и методов поведения базового объекта xsd -->
<!--регистрационные данные внешних сервисов для процедур и данных-->
<!--параметры наследования и интерфейсы для внешних вызовов-->

XML	JSON
<new> <object>   <name>myobj1</name>   <ann>My first object</ann>  <geometry>.....</geometry>  <tags>   <index>....</index>   <cloud>....</cloud>  </tags>  <events>...</events>  <code>...</code> </object> .... </new> ...	{   "new": {     "object": {       "name": "myobj1",       "ann": "My first object",       "geometry": ".....",       "tags": {         "index": "....",         "cloud": "...."       },       "events": "...",       "code": "..."     }   } }

<new> - область объявления объектов
<tags> - область объявления описательной информации.

<index> - классическая атрибутивная информация для зеркалирования shp. Она типизирована и ориентирована на пространственный-временной-признаковый анализ.

<cloud> - неупорядоченная и частично упорядоченная информация
<events> - область событий
<in>,<out> - события входа выхода
<code> - область управляющего программного кода

На гитхабе https://github.com/Valery35/gcl

Неогеография. Немного дополнений.

http://www.neogeography.ru/rus/principles/neogeography-definition.html

Прошло несколько лет с тех пор, как активно занимался поддержкой создания новой науки. Было интересно, но жизнь внесла свои коррективы. Сейчас отошел от интернет-решений, работаю с горнодобывающими корпорациями, и наш бизнес вполне состоялся. Программные проекты прошлых лет (KMLer, Typeconvert, Slice3D, KML2KML ...) мы по прежнему поддерживаем и открыты для контактов. Порадовало, что в последние годы наше программное начали покупать в СНГ.

Думать и развиваться себе не запретишь, поэтому иногда возвращаюсь к неогеографии. Итак.

Необходимость неогеографии вижу прежде всего в том, что без появления новых фундаментальных понятий простое технологическое развитие быстро останавливается. Это хорошо видно на примере Google. Прорывные идеологические решения уровня Google Earth + SketchUp, подчиняясь законам бизнеса, переросли в технологические уровня Android+Glass.

Из нового. В любой науке должен быть базовый язык. В неогео в дополнение к языкам разметки данных нужна процедурная объектная модель (основа). Язык управления данными, поддерживающий интерактивность географических объектов вне зависимости от средств визуализации. Пусть это будет что-то, похожее на JS, Dart или Python. Это не отменяет развитие географических сервисов и наполнение баз данных.