Главная

ТЗ

Главная
География
Интерфейс
ТЗ
Начало
Очистка
Верификация
Описания
Эксперимент

Карта

Техническое задание




Назад...   Далее...

Земля у нас шар, а окно видимости плоское. Координаты объектов в базе заданы в виде "широта-долгота", и это нам представляется не вполне разумным. Объёмы карты (по крайней мере, самого малого масштаба) просто гигантские, но пользователю нужно обеспечить эффективный доступ к любому уголку планеты для карты любого масштаба - как для чтения, так и для редактирования. Какой из всего этого вывод? На мой взгляд, очевидный: каждая из карт разрезается на дольки в размер более-менее терпимого объема (в смысле скорости закачки) - скажем, килобайт по сто. Разрезается именно на сервере, т.е. одни и те же куски передаются одинаковыми для всех пользователей. Ещё один момент: хотя координаты являются числами и, следовательно, могут храниться в двоичном формате, браузеру придётся передавать только текст. Решение этой проблемы давно известно: двоичные данные передаются в кодировке base64, когда из 8 бит байта несут информацию только 6. Правильнее сказать, целых 6 - формат весьма компактный. Вот такую 64-разрядную систему счисления мы и будем использовать.

Координаты объектов на карте лучше всего задавать так, чтобы объём передаваемых данных был минимальным. Нам представляется удачным решение, когда широта и долгота (или, на плоскости, X и Y) задавались бы одним символом (в формате base64), что позволяет позиционировать элемент как клетку шахматной доски размером 8*8 (единиц длины соответствующего масштаба). То есть двумя символами мы можем позиционировать элемент уже на карте 64*64, тремя - 512*512, а восемь символов (девятый - код самой карты, как будет показано ниже) обеспечивают нам точность указания координат 134217728*134217728, что более, чем достаточно даже для самой точной карты (для планеты Земля это означает позиционирование объектов с точностью менее полуметра). Вам мало? Можете добавить ещё 2-3 символа! А я бы ещё и убавил один - точности в пару шагов тоже предостаточно.

А как получить стартовый набор (плоских) карт самого грубого масштаба? Очень просто!

  1. Разрежем Землю по экватору и избавимся от отрицательных значений широты. Отныне лишь один бит будет определять, северное это полушарие или южное (сам экватор отнесём к северному полушарию, чтобы не дублировать лежащие строго на нём объекты).
  2. Сделаем ещё две пары сечений: по 32-му и 64-му градусу по широте. Теперь планета поделена на 6 областей: две "полярные шапки", две "приэкваториальные" области и две зоны "средней полосы".
  3. На каждую из "полярных шапок" посмотрим сверху (это называется "азимутальная проекция"). Мы увидем круг с центром в полюсе, граница которого проходит по 64-й параллели. Опишем вокруг этого круга квадрат - так, чтобы он касался круга в точках пересечения этой параллели с Гринвичем и 90-м мередианом, а сами эти меридианы (в азимутальной проекции они выглядят как прямые) разрежут этот квадрат на 4 равные части. Это и будут карты самого грубого масштаба.
  4. Оставшийся "бочонок" (Земля без "полярных шапок) разрежем по мередианам с шагом 30 градусов, начиная от Гринвича. Таким образом, планета разрезана на (12+12+4) * 2 = 56 почти плоских карт, каждую из которых (и каждую из дочерних) мы при дальнейшем позиционировании считаем квадратом 8*8. Код дочерней карты также передаётся одним символом, т.е. дочерняя карта соотносится с родительской как клетка шахматной доски с самой доской.

А теперь посмотрим, с какой точностью заданы коордиаты объектов в базе данных OSM. МАМА ДОРОГАЯ! Семь знаков после запятой! Господа, да вы что, СДУРЕЛИ?! Вы действительно указываете координаты очертаний домов, береговой линии континентов и всё остальное с точностью до долей сантиметра?! Позвольте вам не поверить! Впрочем, можно и поверить: пусть даже это не полный бред, а чистая правда, но скажите мне, кому и зачем нужна такая сумасшедшая точность? Это же идиотизм! Нет, мы пойдём другим путём!(с)

Теперь вспомним, что земная поверхность у нас весьма неоднородна. Что-то мне подсказывает, что информационная насыщенность квадратного километра карты в центре Парижа будет несколько выше, чем у такого же километра в центре Тихого океана. Что будем делать? Правильно: вовсе не обязательно, чтобы все дольки этой "шоколадки" имелись в наличии. Если на соответствующей карте объектов слишком мало, они просто прописываются на родительской карте, а эта в БД не хранится и пользователю не передаётся. Как узнать, что информация на карте предназначена для одной из дочерних? Элементарно! Формат записи координат объектов на карте любого масштаба один и тот же, поэтому если объект указан для дочерней карты на карте родителя, его код удлиняется на один байт (идентификатор карты относительно родителя + координаты), для внука - ещё на один, и так до шести (если объект для карты самого мелкого масштаба указан на карте самого крупного). Иначе говоря, длина идентификатора объекта не превышает 8 байт для любой карты или 9 байт в "абсолютных" координатах (для всей БД в целом) - это даже меньше, чем длина большинства идентификаторов узлов, представленных сейчас в БД. Но ведь наш идентификатор содержит теперь всю информацию о его географическом положении! Стало быть, следующие два поля структуры node (lat/lon) больше не нужны, и потому подавляющее большинство узлов становятся литеральными объектами (не адресуемыми самостоятельно в БД и существующие только в составе родительских объектов, каковыми для узлов являются траектории). Нам больше не нужно копаться в БД, чтобы по идентификатору узла получить его координаты, да и объём базы узлов сократится примерно втрое и, соответственно, объём всей БД примерно на треть! Даром! Наконец, автоматически убираются ошибки в данных вида, когда узлы с разными идентификаторами имеют одинаковые координаты или, наоборот, для одного и того же идентификатора в разных местах БД указаны разные координаты.

Кроме узлов, в базе OSM имеется ещё два типа данных: way и relation. Данные первого типа позволяют прорисовывать на карте линии (точнее, ломаные, в т.ч. замкнутые) и представляют собой обычные массивы идентификаторов узлов. Данные типа relation тоже описывают очерчиваемые линиями объекты, но могут содержать в качестве дочерних элементов не только узлы, но и данные остальных типов. Кроме того, все три типа могут иметь описания, представленные в модели EAV (Entity-Attribute-Value). Структурно в базе данных больше ничего нет.

Важный нюанс: точка, заданная координатами на текущей карте или на любой из родительских вышеописанным способом - это одна и та же точка: она предназначена для карты одного и того же масштаба. А вот точки (линии, отношения), заданные для для карт разных масштабов - это уже другие, живущие собственной жизнью геометрические объекты! Даже если они описывают один и тот же объект логического уровня. Пример: очертания какого-либо озера на карте мелкого масштаба могут описываться данными типа relation - например, по причине имеющегося ограничения на количество точек (не более 2000) в данных типа way. На карте более крупного масштаба то же озеро может уже "уместиться" в объект типа way, на ещё более крупном - выродиться в точку, а на остальных вообще исчезнуть с карты. А вот описание этого объекта (внегеометрическое), разумеется, должно быть одним и тем же объектом, связанным с его геометрическими описаниями на каждой из карт, где он присутствует.

Кстати, а есть ли что-нибудь ещё в мире, кроме этого OpenStreetMap? Ага, основными конкурентами проекта являются Wikimapia, Google Map Maker и Яндекс.Народная карта. Посмотрим... В отличие от OpenStreetMap и Викимапии, созданные пользователями данные не могут свободно использоваться на своих ресурсах третьими лицами (или самими пользователями), для этого требуется согласие администрации Яндекса... ну и хрен с вами, ребятки! В отличие от OpenStreetMap, Google считает созданную сообществом карту личной интеллектуальной собственностью... и вас туда же, ворюги несчастные! Викимапия представляет собой интерактивную карту на основе Google Maps AP... ах, это просто надстройка, причём доступа к полной БД, похоже, вообще нет... ладно, не очень-то и хотелось! И так понятно, что супротив NASA никто всерьёз рыпнуться не может. Тем более, что Фонд свободного программного обеспечения призывает всех вносить свой вклад в проект OpenStreetMap с целью создания свободной альтернативы проприетарной Google Earth, задача замены которой находится в списке высокоприоритетных проектов Фонда. OpenStreetMap описывается как ответ Google и коммерчески ограниченным геоданным от мира свободного программного обеспечения. Ну, что же, лозунги красивые... поможем?
Назад...   Далее...

28.03.2019 09:48
 
`