Начиная с версии 2008 (и пока что заканчивая ей) MS SQL Server имеет встроенную поддержку пространственных данных. Прекрасно!

На данный момент времени уже существует несколько СУБД, предлагающих индексированное хранение пространственных данных. Наверное, самые популярные из них, это: «народная» MySql и PostGIS.

Программируя на c#, естественно, в очень многих случаях, отдаёшь предпочтение продуктам и решениям Microsoft. Причины просты: полнее поддержка одних технологий другими, хорошая документация, более полная реализация, например провайдеров данных, и гораздо меньшая глючность. Я выбрал SQL Server. Заодно захотелось освоить LINQ в общем и LINQ to SQL в. частности.

Поначалу всё было хорошо. Для меня хороший старт сделала, обнаруженная на msdn, статья «LINQ to SQL: .NET Language-Integrated Query for Relational Data».
Но я не сильно удивился, когда «всё хорошо» закончилось.

Для хранения геометрических данных в SQL Server были введены два дополнительных типа: geometry и geography. Первый используется для хранения геометрических объектов, описанных в декартовой системе координат, а второй — для геометрических объектов заданных географическими координатами (широта/долгота).
Такое разделение, по всей видимости, пришлось сделать из-за того, что пространственный индекс реализован в SQL Server на основе B-деревьев. При использовании этого индекса пространство шаблонно разбивается сеткой несколько раз и в «ячейки» этой сетки сохраняются ссылки на геометрические объекты. И оказалось невозможно строить универсальное разбиение и для прямоугольной системы координат и для эллипсоидальной. В MySql, например, выбран другой алгоритм индексирования, основанный на R-деревьях, работающий на совершенно другом принципе, и используется один тип данных. Какой способ индексирования лучше, а какой хуже — не очевидно, так что пока не понятно на кого ругаться и стоит ли.

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

Я не смог найти в интернет решения, обходящего эту проблему, поэтому пришлось изобрести его самому. Здесь нет никаких удивительных ходов, но есть детали, которые, думаю, будут интересны. Также в этой большой заметке, для вашего интереса, я чуть-чуть опишу работу с LINQ to SQL.

Впечатлился видео. Делюсь мыслями.

1. Первые геосистемы учились понимать плоскую географическую привязку. Много приколов возникало в связи с тем что Земля круглая а «бумага» плоская.

Привет! Появилась необходимость на одном из серверов в нашей сети сделать «что-то вроде openstreetmap.org», но так, чтобы все это продолжало работать и без подключения к Интернету.
К сожалению я не нашел хорошего мануала на «Великом и Могучем» о том, как это реализовать, потому, потратив на это два дня, решил рассказать о том как мне это удалось.

В процессе разботы над одной задачей в проекте Карты Mail.Ru возникла необходимость чтения формата WKB. Конечно, можно было воспользоваться GDAL, но нужно было только чтение, а все остальные возможности были излишни. Так и родился этот небольшой велосипед.
Хочу сразу предупредить, что функциональность реализована только в необходимых рамках и поддерживаются только базовые типы, такие как:

• точка
• линия
• полигон
• мультилиния
• мультиполигон

Не поддерживается перекодировка порядка следования байт в слове. А так — бери и пользуйся.

Вообще-то эта новость почти всем заинтересованным лицам уже известна. И теперь, когда мы почти уладили все формальности, пришло время поговорить об этом закрытии. Мы знаем, что многие из вас ценили наш сервис: искали адреса, строили маршруты, использовали автомобильный навигатор.

Но, к сожалению, несмотря на все свои преимущества, проект оказался неспособен конкурировать с лидерами сегмента и не вписался в новую стратегию компании. Поэтому его решили закрыть.

Как разглядеть за деревьями лес: создание трехмерного изображения мировых лесов.

Seeing Forests for the Trees and the Carbon: Mapping the World’s Forests in Three Dimensions
By Michael Carlowicz Design by Robert Simmon January 9, 2012
Перевод Lockywolf, 2012-13

Деревья охлаждают и увлажняют воздух вокруг себя, а также обогащают его кислородом. Они уменьшают скорость ветра и заслоняют землю от прямых солнечных лучей. Лес является домом для бесчисленного количества видов. Лес укрепляет почву и замедляет движение подземных вод. Для человека лес – источник пищи, топлива, медикаментов и строительных материалов.
Именно количество лесов определяет углеродный бюджет Земли.


(Photograph ©2007 :Duncan.)
Можно ли скомпенсировать количество выбрасываемого углерода путем «озеленения ландшафта»? Нужно ли сажать деревья, или сократить вырубки? Важно ли, в какой точке планеты?

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

Считается, что большая часть выбрасываемого, как из-за естественных процессов, так и из-за деятельности человека, в атмосферу углерода имеет лесное происхождение. Леса покрывают около 30 процентов поверхности Земли, на них приходится около 50 процентов растений, покрывающих Землю. Почти 45 процентов всех запасов углерода на Земле находится в лесах.


(Map by Robert Simmon, based on data from the MODIS Land Cover Group, Boston University.)
Леса покрывают 30 процентов поверхности Земли.

Больше или меньше был в прошлом запас углерода в лесах? Увеличится ли он со временем?

Данная статья написана в продолжение серии, повествующей о прототипировании простого и производительного динамического web map сервера. Ранее рассказывалось о том, как в нем устроены пространственные индексы, а так же о том, как можно просто так вот взять и нарисовать пространственный слой. Сейчас мы сделаем это чуть изящнее.

Hi, %habrauser%.
Столкнулся я на днях с интересной задачей — пользователь вводит строку, которая может быть улицей с домом, просто улицей или вообще не улицей, а нам надо узнать имел ли он ввиду улицу с домом и соответствующее ему подсказать.

— Казалось бы чего проще — разбей строку по пробелу и наслаждайся — подумал Штирлиц
— А как насчет улицы Павла Корчагина — шепнула птица Обломинго
— Эм, ну номер дома же наверняка число — сказал Штирлиц
— Ага, корп1 — хорошее число
— Мдя, придется изобретать велосипед

С приходом весны и дождей на улице в глаза все чаще бросается одна проблема. Вот эта:



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

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

Шел я как-то по дорожке и вяло размышлял на тему того, что опять придется или тащиться в обход, или пачкать обувь. С возмущения типа «вот же дураки это проектируют» мысль плавно перетекла на слышанную когда-то байку про некий наукоград, где дорожки во дворах сперва не сделали вовсе, а потом просто заасфальтировали протоптанные людьми тропинки, получив сеть удобных жителям маршрутов. А оттуда мысль перекочевала к идее «а почему бы не сделать то же самое, но на компьютере?». Разработать программу, которая по заданной карте предскажет, где люди будут топтать газоны и где неплохо бы сделать асфальтовое покрытие?

Под катом — описание алгоритма и пара примеров его работы для реальных питерских дворов.

Хочу рассказать читателям хабра-сообщества как используя CLR библиотеку Microsoft.SqlServer.Types можно формировать тайлы для электронной карты. В статье пойдёт речь о генерации списка картографических тайлов для их дальнейшего рендеринга. Будет описан алгоритм генерации тайлов по геометрии объектов, хранящейся в базе данных MS SQL 2008. Весь процесс рендеринга шаг за шагом будет рассмотрен на примере в конце статьи.

Содержание

---

Проблема
Исходные данные
Решение
Хранилище тайлов
Этапы подготовки тайлов
Используемые функции
Пример с ломаной линией
Проверка пересечения
Таблицы для хранения образов тайлов
Размещение иконки на тайле
Объединение тайлов
Отрисовка геометрии на тайле
Заключение

Хабр, и снова привет! В прошлом году я уже писал одну статью, после этого было несколько попыток написать новую, но все не выходило. Наконец появилась более или менее сформированная мысль, которую я и постараюсь оформить в виде полноценной статьи. Речь пойдет о работе с устройствами, точнее о том, как мы смогли связать базу данных используемого оборудования, их географическое расположение с используемым биллингом. Интересующиеся — под кат.

Некоторое время назад я опубликовал тут свою статью, посвященную проблеме благоустройства дворов: habrahabr.ru/post/257563
В статье рассматривался алгоритм, позволяющий по плану местности предсказать, где пешеходы будут сходить с дорожек и топать по газонам, разнося грязь и портя всю красоту. Алгоритм представлял собой симуляцию движения пешеходов на заданной местности с помощью доработанного A* и модифицируемого во время движения навигационного графа.

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

Продемонстрирую процесс применения сервиса на примере вот этого участка проспекта Стачек в Санкт-Петербурге:



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

«Давным-давно, кажется, в прошлую пятницу» автору попалась на глаза статья, в которой сравниваются разные популярные методы индексации небесных объектов. По причине неровного дыхания к этой теме пришлось разбираться в тонкостях и делать выводы.

Вы спросите: «Кому вообще интересны эти небесные объекты?» и даже: «Ну и при чём здесь 2ГИС?» и будете отчасти правы. Ведь методы пространственного индексирования являются универсальной ценностью.

Обычно, имея дело с геоданными, мы работаем с локальной проекцией на плоскость и тем самым отмахиваемся от искажений. В масштабах планеты это сделать труднее — начинают выпирать астрономические проблемы.
Что касается объёмов данных, уже сейчас в OSM более 4 млрд точек и 300 млн дорог. Это соизмеримо с масштабами, характерными для звёздных объектов. Да и помимо всего прочего, звёздные атласы — отличный стенд для разработки и отладки пространственных алгоритмов.

Обещанные тонкости и выводы под катом.

Всем привет! Это блог компании "Техносерв". В процессе производства на проектах, которые мы выполняем, рождаются интересные технологические кейсы. Их скопилось такое количество, что мы решили начать делиться ими с миром. И да, это наша первая публикация.

Честь начать блог выпала мне, и я пишу о том, что мне близко и любимо: о геоинформационных технологиях. Я работаю в департаменте Больших Данных, где занимаюсь разработкой высоконагруженных геоинформационных систем и сервисов на базе движков для распределенных вычислений. О высоких материях мы еще поговорим, а сегодня плавно начнем погружение в ГИС.

Все чаще и чаще у аналитиков данных (или как еще их называют — Data Scientist) появляется потребность в визуализации данных на карте. Какой инструмент сейчас считается наиболее удобным для работы аналитика? Конечно же, тетрадки! До последнего времени возможностей по визуализации геоданных было не так много. Можно было делать статические растры в matplotlib, иногда можно было добавлять даже базовые карты. Интересной оказалась библиотека для работы с Leaflet, где можно открывать geojson-файлы. Сегодня же я хочу рассказать об ArcGIS API for Python от компании Esri.

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

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

Что такое NUTS?

NUTS расшифровывается как Nomenclature of Territorial Units For Statistics. Это стандартизированная система административно-территориального деления, принятая странами Евросоюза. История вопроса уходит в 1970-е, когда родилась идея сделать регионы различных стран Европы сопоставимыми. В более или менее законченном и широко употребимом виде система появилась лишь на рубеже веков. Существуют три основных уровня NUTS (см. рис. 1), и наиболее распространенным в региональном анализе оказывается NUTS-2.

Рисунок 1. Иллюстрация принципа выделения регионов NUTS различного иерархического уровня

Хочу поделиться опытом работы с данными JS-картографическими фреймворками, надеюсь материалы помогут сделать выбор в вопросе: какую библиотеку использовать именно в вашем проекте. Чтобы не утомлять, разобью его на несколько логических частей. Начнем с основного и исходного — кода.

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

Тепловая карта — картограмма, визуально показывающая интенсивность какого-либо точечного показателя в пределах территории на карте. Интенсивность кодируется цветом и прозрачностью. Наверняка вы не раз видели такие картинки. Так вот, что если вам нужно сделать такую картограмму, а данных на руках у вас нет. Heatmap Painter позволит вам в интерактивном режиме накидать данные на карту и сохранить результат для дальнейшего использования. Штука весьма интересная и может пригодится много кому: разработчикам, аналитикам, дизайнерам. О том как это работает и как использовать читайте далее.

Пару дней назад Максим Дубинин и Иван Ковалев официально выпустили свой долгострой — Nextgis Crowd — опенсорсный редактор геоданных.



github.com/nextgis/nextgiscrowd

NextGIS Crowd (NGC) позволяет совместно редактировать расположение и описание точек с любым наборов атрибутов. Последние несколько лет NGC успешно использовался в краудсорсинговом проекте УИК ГЕО для сбора информации по участковым избирательным комиссиям (помните, тогда были выборы? ) — сотня юзеров внесла десятки тысяч УИКОВ с описанием (не без помощи некоторой автоматизации ;)

Как поставить?

Вышел небольшой open-source построитель пешеходных маршрутов для людей с ограниченными возможностями.

Сразу ссылка на исходники: https://github.com/korifey/Smooth