вторник, 27 апреля 2010 г.
Всероссийская партнерская СПО программа
Компания PingWin Software (входит в ГК АйТи) объявляет о старте партнерской программы, направленной на консолидацию усилий всех российских компаний в области внедрения и технической поддержки свободного программного обеспечения (СПО). Основой для сотрудничества является разработка и продвижение пакета услуг в области СПО, наиболее полно соответствующего реальным потребностям российских пользователей.
Qt и OpenCL.
Взято отсюда.
OpenCL — это открытый набор библиотек для параллельного программирования в гетерогенной среде.
OpenCL — это открытый набор библиотек для параллельного программирования в гетерогенной среде.
Начнём с конца. Что значит «в гетерогенной среде»? OpenCL позволяет запускать C-код на вычислительных мощностях вашей видеокарты. Или же на вашем центральном процессоре — ему всё равно.
Что же касается параллельного программирования — OpenCL предназначен не просто для того, чтобы производить вычисления на GPU, но и для распределения нагрузки между всеми ядрами CPU и GPU, до которых он только сможет дотянуться. Идея в том, что программисту не нужно предпринимать дополнительных усилий по написанию очередей обработки — OpenCL делает это для вас, и ваше приложение без каких-либо изменений масштабируется для выполнения на одном, двух или же на двадцати четырёх ядрах.
Разработчики Qt заинтересовались возможностями OpenCL, и недавно они представили библиотеку QtOpenCL.
понедельник, 26 апреля 2010 г.
Геоинформационные системы как веб-сервисы. Что такое WMS и WFS?
Последнее время, в интернете, мне всё чаще стали попадаться на глаза такие понятия как WMS и WFS. Итак, что-же это за аббревиатуры?
- Web Map Service (WMS) это стандартный протокол для обслуживания связанных картографических изображений в сети интернет которые генерируется специальным (map) сервером использующим данные из базы данных геоинформационной системы (GIS). Данная спецификация была разработана и впервые опубликован Open Geospatial Consortium в 1999 году. Читать далее...
- Web Feature Service Interface Standard (WFS) обеспечивает интерфейс позволяющий запрашивать географические данные через Интернет с помощью независимых от платформы вызовов (calls). Разработан так-же Open Geospatial Consortium. Читать далее...
Ограничения на использование сервиса Google Maps
Как говорит один пользователь форума GIS-Lab.info:
Лицензия на использвание сервиса Google.Maps запрещает любое использование предоставленных данных (и снимков в том числе), кроме просмотра, проложения маршрута,и использования других функций сервиса в браузере, печати результирующего изображения (с маршрутом, например, или интересующим участком изображения Земли).
Лицензия на использвание сервиса Google.Maps запрещает любое использование предоставленных данных (и снимков в том числе), кроме просмотра, проложения маршрута,и использования других функций сервиса в браузере, печати результирующего изображения (с маршрутом, например, или интересующим участком изображения Земли).
Как сделать, чтобы Google индексировал Ajax приложения?
Я думаю что многие сталкивались с проблемой индексации гуглом ajax приложений. Вот решение.
2. Set up your server to handle requests for URLs that contain
Step-by-step guide
1. Indicate to the crawler that your site supports the AJAX crawling scheme
The first step to getting your AJAX site indexed is to indicate to the crawler that your site supports the AJAX crawling scheme. The way to do this is to use a special token in your hash fragments (that is, everything after the # sign in a URL): hash fragments have to begin with an exclamation mark. For example, if your AJAX app contains a URL like this:
www.example.com/ajax.html#mystate
it should now become this:
www.example.com/ajax.html#!mystate
When your site adopts the scheme, it will be considered "AJAX crawlable." This means that the crawler will see the content of your app if your site supplies HTML snapshots.
2. Set up your server to handle requests for URLs that contain _escaped_fragment_
Suppose you would like to get
www.example.com/index.html#!mystate indexed. Your part of the agreement is to provide the crawler with an HTML snapshot of this URL, so that the crawler sees the content. How will your server know when to return an HTML snapshot instead of a regular page? The answer is the URL that is requested by the crawler: the crawler will modify each AJAX URL such as
www.example.com/ajax.html#!mystate
to temporarily become
www.example.com/ajax.html?_escaped_fragment_=mystate
You may wonder why this is necessary. There are two very important reasons:
- Hash fragments are never (by specification) sent to the server as part of an HTTP request. In other words, the crawler needs some way to let your server know that it wants the content for the URL
www.example.com/ajax.html#!mystate(as opposed to simplywww.example.com/ajax.html). - Your server, on the other hand, needs to know that it has to return an HTML snapshot, rather than the normal page sent to the browser. Remember: an HTML snapshot is all the content that appears on the page after the JavaScript has been executed. Your server's end of the agreement is to return the HTML snapshot for
www.example.com/index.html#!mystate(that is, the original URL!) to the crawler.
Note: The crawler escapes certain characters in the fragment during the transformation. To retrieve the original fragment, make sure to unescape all %XX characters in the fragment (for example, %26 should become '&', %20 should become a space, %23 should become #, and %25 should become %).
Now that you have your original URL back and you know what content the crawler is requesting, you need to produce an HTML snapshot. How do you do that? There are various ways; here are some of them:
- If a lot of your content is produced with JavaScript, you may want to use a headless browser such as HtmlUnit to obtain the HTML snapshot. Alternatively, you can use a different tool such as crawljax or watij.com.
- If much of your content is produced with a server-side technology such as PHP or ASP.NET, you can use your existing code and only replace the JavaScript portions of your web page with static or server-side created HTML.
- You can create a static version of your pages offline, as is the current practice. For example, many applications draw content from a database that is then rendered by the browser. Instead, you may create a separate HTML page for each AJAX URL.
It's highly recommended that you try out your HTML snapshot mechanism. It's important to make sure that the headless browser indeed renders the content of your application's state correctly. Surely you'll want to know what the crawler will see, right? To do this, you can write a small test application and see the output, or you can use a tool such as Fetch as Googlebot.
To summarize, make sure the following happens on your server:
- A request URL of the form
www.example.com/ajax.html?_escaped_fragment_=mystateis mapped back to its original form:www.example.com/ajax.html#!mystate. - The token is URL unescaped. The easiest way to do this is to use standard URL decoding. For example, in Java you would do this:
mydecodedfragment = URLDecoder.decode(myencodedfragment, "UTF-8");
- An HTML snapshot is returned, ideally along with a prominent link at the top of the page, letting end users know that they have reached the
_escaped_fragment_URL in error. (Remember that_escaped_fragment_URLs are meant to be used only by crawlers.) For all requests that do not have an_escaped_fragment_, the server will return content as before.
3. Handle pages without hash fragments
Some of your pages may not have hash fragments. For example, you might want your home page to be
www.example.com, rather thanwww.example.com#!home. For this reason, we have a special provision for pages without hash fragments. In order to make pages without hash fragments crawlable, you include a special meta tag in the head of the HTML of your page. The meta tag takes the following form:name="fragment" content="!">
This indicates to the crawler that it should crawl the ugly version of this URL. As per the above agreement, the crawler will temporarily map the pretty URL to the corresponding ugly URL. In other words, if you place
www.example.com, the crawler will temporarily map this URL to www.example.com?_escaped_fragment_= and will request this from your server. Your server should then return the HTML snapshot corresponding to www.example.com. Please note that one important restriction applies to this meta tag: the only valid content is "!". In other words, the meta tag will always take the exact form: 4. Consider updating your Sitemap to list the new AJAX URLs
Crawlers use Sitemaps to complement their discovery crawl. Your Sitemap should include the version of your URLs that you'd prefer to have displayed in search results, so in most cases it would be
http://example.com/ajax.html#!foo=123. Do not include links such ashttp://example.com/ajax.html?_escaped_fragment_=foo=123 in the Sitemap. Googlebot does not follow links that contain_escaped_fragment_! If you have an entry page to your site, such as your homepage, that you would like displayed in search results without the #!, then add this URL to the Sitemap as is. For instance, if you want this version displayed in search results:
http://example.com/
then include
http://example.com/
in your Sitemap and make sure that
5. Optionally, but importantly, test the crawlability of your app: see what the crawler sees with "Fetch as Googlebot".
Google provides a tool that will allow you to get an idea of what the crawler sees, Fetch as Googlebot. You should use this tool to see whether your implementation is correct and whether the bot can now see all the content you want a user to see. It is also important to use this tool to ensure that your site is not cloaking.
В Google Maps добавлены значения высот.
Наконец-то! Как сообщается в официальном блоге Google - теперь в Google Maps есть возможность указывать высоты.
Просмотреть увеличенную карту
Просмотреть увеличенную карту
четверг, 22 апреля 2010 г.
ArcGIS и GIS Cloud — геоинформационные системы в облачных вычислениях. Видео.
Cloud computing is rapidly emerging as a technology almost every industry that provides or consumes software, hardware, and infrastructure can leverage. The technology and architecture that cloud service and deployment models offer are a key area of research and development for GIS technology.
Что такое облачные ГИС?
Although there are several variations on the definition of cloud computing, some basic tenets characterize this coming revolution.
Cloud computing furnishes technological capabilities—commonly maintained off premises—that are delivered on demand as services via the Internet.
Cloud GIS offerings can range from data storage to end-user Web applications to other focused computing services. ESRI considers cloud computing and technology important in the development and vision of the ArcGIS platform.
ArcGIS как ГИС в облачных вычислениях.
http://www.esri.com/news/arcwatch/0110/feature.html
Презентация проекта GIS Cloud
http://www.giscloud.com/
GIS Cloud is world's first full featured web based Geographic Information System (GIS) powered by Cloud Computing with advanced capability of creating, editing, uploading, sharing, publishing, processing and analyzing geospatial and attribute data.
Its purpose is to help in making best possible life and business decisions and tackle problem solving through data visualization and geoprocessing.
Until now full featured GIS existed only in the world of classic desktop applications. GIS Cloud is Software as a Service (SaaS) available in free and pay-per-use model.
GIS Cloud WebMap Engine vs. Google Maps Engine (Zoom Slider Comparison) from GIS Cloud on Vimeo.
Что такое облачные ГИС?
Although there are several variations on the definition of cloud computing, some basic tenets characterize this coming revolution.
Cloud computing furnishes technological capabilities—commonly maintained off premises—that are delivered on demand as services via the Internet.
Cloud GIS offerings can range from data storage to end-user Web applications to other focused computing services. ESRI considers cloud computing and technology important in the development and vision of the ArcGIS platform.
ArcGIS как ГИС в облачных вычислениях.
- Use online maps and tools that are a built-in part of your ArcGIS experience—regardless of whether you are using ArcGIS Desktop, a mobile device, a browser, or if you are developing applications using the ArcGIS Web Mapping APIs.
- Find, share, organize, and use maps, apps, and other resources via ArcGIS.com—a Web-based gateway into the ArcGIS system.
- Discover, share, and present geographic information using ArcGIS Explorer Online, a new browser-based version of ArcGIS Explorer.
- Use ArcGIS Server on the Amazon cloud.
http://www.esri.com/news/arcwatch/0110/feature.html
Презентация проекта GIS Cloud
http://www.giscloud.com/
GIS Cloud is world's first full featured web based Geographic Information System (GIS) powered by Cloud Computing with advanced capability of creating, editing, uploading, sharing, publishing, processing and analyzing geospatial and attribute data.
Its purpose is to help in making best possible life and business decisions and tackle problem solving through data visualization and geoprocessing.
Until now full featured GIS existed only in the world of classic desktop applications. GIS Cloud is Software as a Service (SaaS) available in free and pay-per-use model.
GIS Cloud WebMap Engine vs. Google Maps Engine (Zoom Slider Comparison) from GIS Cloud on Vimeo.
среда, 21 апреля 2010 г.
Как добавить свой модуль на drupal.org
Кросспост отсюда.
Этап 1.
Для начала, как можно подробнее опишите о что делает ваш модуль и для чего он нужен. Затем переведите все это на английский язык. И добавьте в ваш модуль файл README.TXT, где и будет это описание. Это же описание добавите на страницу вашего проекта.
Этап 2.
Во все файлы модуль добавьте первую строку, по принципу:
для PHP и JavaScript файлов внутри
// $Id$
в файлах CSS
/* $Id$ */
в файле .info
; $Id$
в текстовых файлах
$Id$
Загляните в Системный Журнал (admin/reports/dblog) на наличие PHP ошибок в вашем модуле. При помощи модуля Coder проверьте код вашего модуля и поправьте где нужно.
Этап 3.
Зайдите или зарегистрируйтесь на drupal.org, перейдите на страницу CVS application form и заполните необходимые поля. Дальше либо смотрите почту, либо загляните в ваш трекер и увидите там сообщение с темой «Ваше_Имя_Пользователя [Ваше_имя_пользователя]». Упаковываете ваш модуль в ZIP или GZIP и прикрепляете в первом камменте меняя статус на “needs review”. А дальше по стандартной процедуре будет вопрос(ы), отвечая на которые ставьте статус „needs review“. Как только получите статус “fixed”, значит вы получили CVS аккаунт. Проверьте почту ответ будет там.
Этап 4.
Как только вам дадут понять, что вы получили CVS аккаунт, вы сможете добавлять страници проектов и все что для этого нужно. На странице "Create content" добавятся:
Book page — для написания более подробной инструкции к вашему модулю — handbook;
Image — для скриншотов к модулю;
Project — сам проект;
Project release — для создания релиза проекта.
При создании проекта обязательно заполняйте поле CVS directory оно обязательное (хотя и написано что можно не заполнять), например /modules/короткое_название_модуля/.
Этап 1.
Для начала, как можно подробнее опишите о что делает ваш модуль и для чего он нужен. Затем переведите все это на английский язык. И добавьте в ваш модуль файл README.TXT, где и будет это описание. Это же описание добавите на страницу вашего проекта.
Этап 2.
Во все файлы модуль добавьте первую строку, по принципу:
для PHP и JavaScript файлов внутри
// $Id$
в файлах CSS
/* $Id$ */
в файле .info
; $Id$
в текстовых файлах
$Id$
Загляните в Системный Журнал (admin/reports/dblog) на наличие PHP ошибок в вашем модуле. При помощи модуля Coder проверьте код вашего модуля и поправьте где нужно.
Этап 3.
Зайдите или зарегистрируйтесь на drupal.org, перейдите на страницу CVS application form и заполните необходимые поля. Дальше либо смотрите почту, либо загляните в ваш трекер и увидите там сообщение с темой «Ваше_Имя_Пользователя [Ваше_имя_пользователя]». Упаковываете ваш модуль в ZIP или GZIP и прикрепляете в первом камменте меняя статус на “needs review”. А дальше по стандартной процедуре будет вопрос(ы), отвечая на которые ставьте статус „needs review“. Как только получите статус “fixed”, значит вы получили CVS аккаунт. Проверьте почту ответ будет там.
Этап 4.
Как только вам дадут понять, что вы получили CVS аккаунт, вы сможете добавлять страници проектов и все что для этого нужно. На странице "Create content" добавятся:
Book page — для написания более подробной инструкции к вашему модулю — handbook;
Image — для скриншотов к модулю;
Project — сам проект;
Project release — для создания релиза проекта.
При создании проекта обязательно заполняйте поле CVS directory оно обязательное (хотя и написано что можно не заполнять), например /modules/короткое_название_модуля/.
Drupal Webform теперь поддерживает Mollom. Видео.
Наконец-то! Теперь модуль для Drupal Webform поддерживает систему анализа контента Mollom!
Mollom — стартап и веб-сервис, анализирующий качество содержимого, отправляемого на веб-сайты. Сюда включаются: комментарии, сообщения, отправляемые через контакт-формы, блоги, сообщения на форумах и прочее.
Это значит что Mollom теперь предоставляет такие хуки как hook_mollom_form_list, hook_mollom_form_info и hook_mollom_form_info_alter для того, чтобы обеспечить лучшую защиту созданных форм.
Mollom — стартап и веб-сервис, анализирующий качество содержимого, отправляемого на веб-сайты. Сюда включаются: комментарии, сообщения, отправляемые через контакт-формы, блоги, сообщения на форумах и прочее.
Это значит что Mollom теперь предоставляет такие хуки как hook_mollom_form_list, hook_mollom_form_info и hook_mollom_form_info_alter для того, чтобы обеспечить лучшую защиту созданных форм.
вторник, 20 апреля 2010 г.
Drupal и семантический веб. Видео.
Видео показывает как работает Drupal (начиная с 7 версии) с семантическим вебом.
Среди новых возможностей Druapl 7 Dryes Buytaert отметил поддержку RDF, что является святым граалем для главных разработчиков сети WWW. RDF теги могут быть добавлены для любого содержимого в этой CMS. RDF позволит превратить Интернет в огромную семантически связанную сеть.
Среди новых возможностей Druapl 7 Dryes Buytaert отметил поддержку RDF, что является святым граалем для главных разработчиков сети WWW. RDF теги могут быть добавлены для любого содержимого в этой CMS. RDF позволит превратить Интернет в огромную семантически связанную сеть.
четверг, 15 апреля 2010 г.
Анатомия облачных систем с открытым кодом.
Очень хорошая статья о cloud computing. Перевод.
среда, 14 апреля 2010 г.
GML — язык географической разметки, разрабатываемый Open GIS Consortium.
GML (англ. Geography Markup Language) — язык географической разметки, разрабатываемый Open GIS Consortium. Википедия.
The Geography Markup Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. Note that the concept of feature in GML is a very general one and includes not only conventional "vector" or discrete objects, but also coverages (see also GMLJP2) and sensor data. The ability to integrate all forms of geographic information is key to the utility of GML.
The Geography Markup Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. Note that the concept of feature in GML is a very general one and includes not only conventional "vector" or discrete objects, but also coverages (see also GMLJP2) and sensor data. The ability to integrate all forms of geographic information is key to the utility of GML.
GeoJSON — диалект JSON для описания геопространственных данных.
Взято отсюда. (Автор: Кристофер Андрюс, перевод ГИС Консалт Груп, О.Хрипко)
Несколько лет назад, когда я (Кристофер Андрюс – прим. Переводчика) работал в компании - системном интеграторе, занимавшейся продажей и внедрением сервисно-ориентированных архитектур и веб-сервисов, мне казалось, что большинство организаций уже осознали значимость и необходимость системной и информационной интеграции. В то время, я мог бы заключить, что концепция соместимности форматов получила всеобщее признание в сфере геопространственных технологий,… - и оказался бы неправ.
Количество проектов на 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» уже ожидает удачного случая, чтоб выйти на арену электронных технологий картографирования.
Несколько лет назад, когда я (Кристофер Андрюс – прим. Переводчика) работал в компании - системном интеграторе, занимавшейся продажей и внедрением сервисно-ориентированных архитектур и веб-сервисов, мне казалось, что большинство организаций уже осознали значимость и необходимость системной и информационной интеграции. В то время, я мог бы заключить, что концепция соместимности форматов получила всеобщее признание в сфере геопространственных технологий,… - и оказался бы неправ.
Количество проектов на 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» уже ожидает удачного случая, чтоб выйти на арену электронных технологий картографирования.
Подписаться на:
Сообщения (Atom)