Взято отсюда. (Автор: Кристофер Андрюс, перевод ГИС Консалт Груп, О.Хрипко)
Несколько лет назад, когда я (Кристофер Андрюс – прим. Переводчика) работал в компании - системном интеграторе, занимавшейся продажей и внедрением сервисно-ориентированных архитектур и веб-сервисов, мне казалось, что большинство организаций уже осознали значимость и необходимость системной и информационной интеграции. В то время, я мог бы заключить, что концепция соместимности форматов получила всеобщее признание в сфере геопространственных технологий,… - и оказался бы неправ.
Количество проектов на IT рынке по разработке совместимых форматов и стандартов эти форматы описывающих, связанных с ГИС-системами, заметно растёт. Необходимость разработки совместимых геопространственных решений вызывает бурные дискуссии и привлекает всё новые инвестиции в сферу разработки программ с открытым кодом, о чём свидетельствуют публикации в профессиональных изданиях, повестки конференций и иная отраслевая литература. Появление таких разработок, как Feature Data Objects (FDO), транзакций Web Feature Service (WFS-T) и OpenLayers свидетельствует о возросшем влиянии технологий доступа, передачи и визуализации информации, готовых к интеграции, на существующий рынок IT.
Изучив некоторые из этих технологий, нельзя не отметить, насколько трудный путь они преодолели, прежде чем стать общепринятыми или стандартизованными. В индустрии IT заимствование технологий из смежных областей представляет собой абсолютно естественный процесс. Например, несмотря на то, что расширяемый язык разметки (XML) изначально был разработан для зарождавшейся сферы публикаций в Интернет, сейчас XML используется в качестве стандарта передачи информации между приложениями.
На ранних этапах развития ГИС, геопространственные технологии развивались в основном в рамках IT. Реже технологии могли быть заимствованы из смежных областей, таких как оборона или природопользование. В последние же годы, вторжение крупных корпораций, не специализировавшихся ранее на разработке геопространственных решений, в нашу некогда узкую сферу деятельности привнесло новые идеи и новые технологии, одновременно увеличив рыночный спрос на ГИС и ГИС-подобные продукты и сервисы. Этот возросший спрос, часто ассоциируемый с "феноменом Google Maps", является одной из основных причин увеличения потребности в интеграции технологий картографирования с господствующими IT системами. По мере того, как рынок ГИС старается удовлетворить этот возникший спрос, мы наблюдаем быстрое внедрение новых технологий в область геопространственных решений. Так, удачные ГИС-решения, нашедшие своё применение в господствующих отраслях IT, с одной стороны, и геопространственные технологии, меняющиеся под воздействием необходимости создания динамичных процессов, с другой, заставляют нас искать новые инструменты и методы, которые позволять успешно адаптироваться в возросшему рыночному спросу.
GeoJSON - От AJAX к альтернативе XML
Одним из наиболее интересных, на наш взгляд, развивающихся стандартов геопространственных технологий, является GeoJSON (читается как jee-oh-jay-son, иногда с ударением на последнем слоге). У этой технологии, есть все задатки, чтобы перерасти в жизнеспособный язык передачи информации (например, язык передачи сообщений между ПО одного компьютера и ПО другого компьютера), который будет более компактным, чем XML, и вместе с тем более удобочитаемым для человека. Значение этого свойства - компактности - особенно возрастает, если речь идет о больших объёмах геопространственных данных. (Необходимость того, чтобы язык передачи информации от компьютера к компьютеру был удобочитаемым для человека, является распространённым требованием многих организаций, занимающихся стандартами в сфере IT, которая скорее свидетельствует о нежелании разработчиков ПО потерять контроль в данной области, чем о реальной потребности в удобочитаемости этого кода (языка)). История создания GeoJSON уходит корнями в ранний период коммерческих войн между разработчиками web-браузеров, когда было много хороших идей, но не хватало средств для их полноценной реализации, с одной стороны, и пропускной способности Интернет-канала, с другой. В середине 1990-ых Netscape и Microsoft создали инструменты, с помощью которых попытались превзойти своих конкурентов по функциональности и возможностям Web-браузеров. Эти ранние Интернет-гигнаты осозновали потенциал Интернета. Именно они создали инструменты, позволившие разработчикам повысить показатели динамической функциональности Web-страниц и улучшить условия передачи информации от браузера к серверу и обратно. Netscape создал JavaScript в качестве инструмента для обеспечения такой диалоговой функциональности Web-страницы, при которой не возникало бы необходимости обращения к серверу после каждого действия пользователя. Netscape также внедрил ещё один механизм, который получил название Асинхронный JavaScript и XML (АJAX), который позволил разработчикам отправлять информацию на сервер и получать ответ, не обновляя Web-страницу целиком. Хотя Microsoft и приемник Netscape, Firefox, продолжают работать по немного различным схемам, почти все известные Интернет-браузеры используют систему асинхронного взаимодействия пользователя и браузера, которая схожа со схемой, предложенной Netscape и получившей название " AJAX". AJAX приобрёл популярность в первой половине 2000-ых, когда несколько маленьких компаний и одна крупная, решительно настроенная компания признали очень важной характеристикой ПО возможность обмена данными с сервером без необходимости обновления всей страницы. Совмещённые с JavaScript и иными инструментами, AJAX позволил разработчикам выстраивать структуры запросов, способные проверить пароль, орфографию и обновить информацию, не вынуждая пользователя ждать полного обновления страницы. Запуск Gmail, а затем и Google Maps подтвердил пригодность технологии AJAX для использования в Сети, после чего технологию AJAX стали активно внедрять в геопространственные проекты. Методы, основанные на технологии AJAX, стали повсеместно использоваться для усовершенствования Интернет-карт, созданных ещё с использованием ранних Java-технологий.
JSON против. XML
В то время как возможность динамического обмена данными с сервером открывает всё новые возможности для развития сети Интернет, разработчики, стремясь передавать всё больше данных через Интернет, чтобы создавать "прикольные" приложения, вынуждены тщательно изучать количественные и технические характеристики механизмов передачи Web-сообщений. Несмотря на то, что "X" в слове AJAX подразумевает "XML", для использования XML необходимо перевести программный код, или "объектные" данные в формат XML, послать через Интернет, а затем перевести обратно в формат “объекта”. XML по своей структуре также включает большое количество дополнительных характеристик (параметров), которые могут существенно увеличить размер сообщения. Оказывается, для технологии AJAX на самом деле не нужен XML. Практически любой текст, отформатированный или нет, можно передать от сервера к браузеру используя ряд схожих инструментов. Разработчики начали искать альтернативы XML для передачи сообщений, и очевидный вариант укрылся за буквой "J" в слове AJAX, которая обозначает JavaScript. Скомпилированный и запускаемый динамически в приложении браузера код JavaScript может быть изменен непосредственно во время работы Web-страницы таким образом, что изменения в работе программы могут быть внесены разработчиком прямо в момент выполнения команды. Например, изменения могут быть проведены в тот момент, когда запрос обращается к серверу, чтобы определить, какие пункты меню должны быть отражены на экране, а затем выводит те пункты, которые доступны для конкретного пользователя. Подобная возможность написать код, который способен самостоятельно изменяться, предполагает, что на определенном уровне структура данных этого кода, которая может быть подвержена само-изменению, должна быть удобочитаема для человека. В действительности, объекты JavaScript обладают определённым фиксированным буквенным выражением, именуемым JavaScript Object Notation (JSON). В сравнении с XML, JSON оказывается довольно компактным, хоть и обладает рядом ограничений, которых в свою очередь лишён XML. Однако, когда разработчики заметили, что преобразуют данные из Python, Java или .NET в XML, а только затем, чтоб отразить информацию на Web-странице,,в JSON, они стали постепенно исключать промежуточное преобразование и переводить информацию напрямую из Python в JSON. В настоящий момент в сети существует много различных модификаций object-data-to-JSON конвертеров. Разработчики экспериментируют с JSON в качестве языка взаимодействия систем, поскольку JSON легко можно модифицировать под многие форматы представления данных, и он зачастую позволяет разработчикам создавать более компактные сообщения, чем с использованием XML. К тому же, я подозреваю, многие разработчики обеспокоены возросшей популярностью XML как "модной фичи" несмотря на его громоздкость. JSON же, надо полагать, в сфере IT задержится.
Пилотная технология: GeoJSON
Несовпадение интерфейса типа Google с громоздкими технологиями передачи данных, такими как XML, предоставило разработчикам геопространственных технологий широкое поле для поисков альтернативных инструментов передачи географической информации с использованием веб-приложений и других систем. Технология JSON представляет собой осознанный выбор, который быстро нашёл себе применение во многих языках программирования, таких как PHP, PERL и Python, на основе которых разрабатывается большая часть проектов в области геопространственных технологий. В последнее время в области геопространственных технологий начали проводиться исследования с использованием географического диалекта JSON – GeoJSON, направленные на упорядочение представления пространственных данных в формате JSON. Предварительная версия текущей спецификации с примерами доступна в сети Интернет. GeoJSON не является в полной мере новым языком, а скорее представляет собой диалект технологии представления объектов, основанной на JSON, так же, как и GML является специализированной версией XML для представления географических объектов. По мере того, как GeoJSON будут приспосабливать для использования в той же области, в которой сейчас используется GML, возможно, он будет дополнен поддержкой много ступенчатых транзакций и более сложных типов геометрии. Несмотря на то, что этот стандарт находится пока на стадии разработки, следует отметить, что GeoJSON уже используется в таких проектах, как GeoServer, а также предложен для включения в MapGuide Open Source. Вероятно, самым значимым событием для GeoJSON стало дополнение программы FME выпуска 2008 корпорации Safe Software Inc. функцией поддержки форматов JSON и GeoJSON. Бета-версии JSON и GeoJSON с доступными опциями чтения и записи уже доступны для скачивания на сайте компании Safe. Президент компании Safe, Don Murray, пояснил мне следующее: «Корпоративной стратегией компании Safe является поддержка как можно большего количества форматов как действующих, так и будущих… GeoJSON как раз попадает в число потенциальных технологий будущего. Некоторые новые технологии оказываются невостребованными, и наши усилия в отношении таких технологий можно рассматривать как пустую трату времени, но это именно так цена, которую мы вынуждены платить, чтоб оставаться на передовых позициях в области совместимости форматов». Далее Murray заявил: «Еще одна вещь, которую мы планируем запустить в будущем FME Server, это обеспечить возможность конвертации данных в формат GeoJSON из любого другого формата, включая WFS и GeoRSS». C помощью FME станет возможной конвертация данных из любого формата в программу, поддерживающую формат GeoJSON, что несомненно приведёт к увеличению спроса на этот новый формат.
От концепции до господствующей тенденции за год... Что же дальше?
По существу, технология GeoJSON была производной от JSON, а после включения в бета-версию программы FME 2008 стала одной из основных геопространственных технологий меньше чем за год. Удивительно, что функция «Запрос комментария» (RFC) в GeoJSON до сих пор ни одобрена, ни утверждена ни одним официальным комитетом по разработке стандартов в области геопространственных технологий. В настоящий момент резкое увеличение количества проектов в области совместимости данных и в области разработки Web-технологий, причем зачастую в компаниях, которые не специализировались ранее в сфере ГИС, дало мощный толчок развитию ГИС-области. Сосредотачиваемся ли мы на классических аналитических аспектах ГИС или обращаемся к внедрению ГИС в систему интеграции данных, охватывающую весь технологический процесс предприятия, любая потребность неизбежно приведёт к появлению новой технологии и её продвижению до статуса господствующего стандарта. Именно геопространственное сообщество должно сформировать организации для стандартизации форматов, которые бы обладали определённой ловкостью, чтобы не отставать от развития технологии, и одновременно здравый смысл, чтобы принимать адекватные решения. Станет ли GeoJSON подлинным стандартом технологии доподлинно неизвестно, однако совершенно точно, что следующий «GeoJSON» уже ожидает удачного случая, чтоб выйти на арену электронных технологий картографирования.
