Пространные размышления об идентификаторах, времени и базах геоданных с нечеткими тегами

Случилось так, что у меня выпало немного свободного времени, а в детстве я не наигрался в конструктор. В результате на свет появилось нечто похожее на картографический фреймворк, о котором я писал в предыдущем посте и несколько мыслей о данных OpenStreetMap. Мысли я хотел-было изложить на Хабре, но излагаю их тут. Во-первых, мне чрезвычайно по душе атмосфера конструктивной анархии, а во-вторых, я не дописал раздел про типы данных. О линиях как редуцированных полигонах я напишу как-нибудь в другой раз, а пока речь пойдет о точках и отношениях.

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

Прежде всего, совершенно не устраивал формат данных. geojson-формат простой, но хотелось сделать его еще проще. В результате я написал скрипт, позволяющий хранить в вики данные в формате [‘1′,’2′,’3′,’4′,’5′,’…’,], а сам geojson формировать и подгружать в leaflet программно. При таком формате требуется фиксированное положение данных о широте и долготе, например [‘lat’,’long’,’3′,’4′,’5′,’…’,] или [‘id’,’lat’,’long’,’3′,’4′,’5′,’…’,]. Последний вариант с id выглядел более привычным для человека, работающего с данными OSM. Но этот-же вариант заставил крепко задуматься, а нужен ли вообще идентификатор точки?

Паспортный контроль
Самое большое число в мире, вопреки известному анекдоту, получится если склеить в одну строку номера всех выданных за жизнь документов, начиная от свидетельства о рождении и заканчивая свидетельством о смерти. Я никогда не понимал, зачем нужен номер паспорта (будто у меня много полных тезок, которые родились в том же городе, в тот же день и получили паспорт в то же время в том же отделении). А уж зачем нужен номер точки с географическими координатами тем более непонятно. «Но ведь координаты могут быть изменены!» — скажете вы. Согласен. Но мы пришли с вами не к противоречию, а к осознанию двух подходов к кодированию пространственных данных. По аналогии их можно назвать объектоцентрическим и геоцентрическим. Каждый элемент массива геоданных соответствует в первом случае объекту картирования, а во-втором случае месту на поверхности Земли. В первом случае у точки могут измениться координаты, но всегда присутствует атрибут, позволяющий идентифицировать эту точку. Во-втором случае, обязательного атрибута может не быть, его роль выполняют координаты. Перемещение объекта в пространстве можно рассматривать как удаление атрибутов у прежней точки и добавление атрибутов новой точке.

Число объектов в геоцентрической базе геоданных конечно и зависит от выбранной точности измерения координат. Скажем, при измерении координат с точностью до одной стотысячной градуса, заполненная база геоданных будет содержать в себе примерно шесть с половиной квинтиллионов объектов. В объектоцентрической базе такого предела нет — если не внедрять такой типично геоцентрический тип данных как отношение, число объектов может расти бесконечно. Кстати, вот вам и предел развития современной базы OpenStreetMap: 6,48 × 10¹⁸ отношений. Это примерно четверть от количества всех атомов в наблюдаемой Вселенной, так что если вы никогда не редактировали карту OpenStreetMap — советую поспешить, пока еще есть возможность.

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

Ежедневно из базы OSM картографы удаляют огромное количество объектов, нанесенных правильно, но не актуально. Возле моего дома долгое время была автозаправка проставленная на карте. Однажды автозаправки не стало и я удалил с карты точку. Но едва JOSM высветил мне окошко успешности сохранения правок, я понял, что сделал что-то не так. Влечет ли необходимость поддержания базы геоданных в актуальном состоянии автоматическое удаление данных, потерявших актуальность? Конечно же нет. Сейчас точки OpenStreetMap напоминают рыбацкие поплавки: они все на одном уровне, но из глубины к каждому из них тянется леска разной длины. Только в одном случае леска непрерывная (круглосуточные магазины), а в другом штриховая (магазины с ограниченным временем работы).

Понятие актуальности неприменимо к таким данным как OSM. Актуальность — есть соответствие данных реальности в определенный промежуток времени. Но поскольку такой промежуток правилами сообщества не установлен с формальной точки зрения уместно как наносить корчмы пятнадцатого века (если «срок актуальности» измеряется тысячелетиями), так и удалять закрытые на ночь киоски. Только не воспринимайте это как призыв к действию.

«Режим работы», а вернее «режим существования» не только присущ всем пространственным объектам, но и является такой-же неотъемлемой характеристикой как широта, долгота и высота.

Слабозаросшая обочина дороги
Система «ключ-значение» безусловно создана в лучших традициях Карла Линнея. Но и недостатки ей присущи ровно те-же самые. Таксономия данных OpenStreetMap почти полностью исключает возможность существования объектов переходного типа. Особенно это касается природных объектов, для которых дискретность вообще достаточно условное явление. Например, промежуточный тип покрытия между surface=ground и surface=grass худо-бедно можно указать (поставив оба значения), но вот дальнейшее деление возможно только с помощью добавления новых значений. Это типичная проблема классификаций, основанных на булевой логике: будучи примененной к естественным объектам, такая классификация непременно либо слишком груба, либо излишне подробна.

А не присовокупить ли к паре «ключ+значение» значение истинности, характерное для нечеткой логики? Тогда едва заросшая травой поверхность дороги будет обозначаться «surface=grass=0.1», а заросли травы, под которыми дорога едва проглядывается будут иметь обозначение «surface=grass=0.9». Нотация, конечно может быть и другой, важнее то, что такой подход позволяет нам наносить на карту объекты, относящиеся одновременно к двум и более классам.
Слабозаросшая обочина дороги
Дабы финализировать сей трактат, продемонстрирую вам образец данных в формате feeneek:

['tipe','lat','long','height','time','author','license','link','note','data1',],
['tipe','lat','long','height','time','author','license','link','note','data2',],
['tipe','lat','long','height','time','author','license','link','note','data3',],
['tipe','lat','long','height','time','author','license','link','note','data4',],
...,...

tipe — тип данных;
lat — широта;
long — долгота;
height — высота или уровень (в зависимости от применения);
time — время в формате: 66666620160323220305 (2016 год, февраль, 23-е число, 22:03, 05 секунд);
author — автор;
license — лицензия данных;
link — ссылка на внешний документ;
note — комментарий к точке;
datax — атрибутивная информация.

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

Добавить комментарий

Ваш e-mail не будет опубликован.

2 comments

  1. Элвис Пресли:

    А я говорил тебе пить меньше надо…