Третье измерение OpenStreetMap
В заметке UN Dispatch рассказывают про странные названия улиц столицы Афганистана на картах Apple. «Bad Monkey», «MoJo Way», вот это всё. Причина? Помните, как Эппл взял карты OSM, но древнейшие, от 2010 года? Оказалось, как раз в это время первые мапперы Кабула решили пошутить, дав свои названия нескольким улицам. С тех пор карта значительно подросла и посерьёзнела, вот только пользователи айпадов оценивают её по устаревшим данным. Это хороший повод дополнить известное утверждение:
Нельзя взять слепок данных и сказать: это — OpenStreetMap. Он теряет свою суть, своё главное отличие от остальных картографических данных в момент, когда вы его загружаете. Наш проект существует в трёх измерениях, и как нельзя от данных отнять широту или долготу, OSM лишается смысла, если его данные обрезать по оси времени. Участники это хорошо понимают, ожидая от всех сервисов на базе OpenStreetMap как минимум ежедневного обновления, в худшем случае — ежемесячного. Каждую секунду сотни человек существенно изменяют карту, что складывается в полгигабайта правок ежедневно, 0.2% от всех данных. Да, у нас масса ошибок, но в контексте третьего измерения они несущественны, поскольку обратная связь мгновенна. Обрежь время — и данные OSM превращаются в неполный, неудобный, местами просто неверный склад геоданных. Именно его часто сравнивают с альтернативами, коммерческими картографическими данными, ведь они точно так же лишены третьего измерения, имитируя его версионностью.
То же верно и для обратного процесса, импорта чужих данных в OSM. Многие энтузиасты рассматривают импорт как единичное вливание данных, «сделал дело — гуляй смело». В итоге на карте появляются двумерные кладбища данных, за которыми никто не присматривает. Источники импортов обновляются: так, пока американцы ковыряются в TIGER от 2005 года, уже вышел значительно превосходящий его по качеству TIGER 2012. Несколько стран импортировали покрытие CORINE 2006 года, которое неминуемо обновят, но иначе как всё удалить и импортировать заново, данные в OSM не обновить. А править руками импортированное настолько муторно, что этим никто не занимается. Большие импорты остаются зафиксированными во времени, они не становятся частью OSM, торча из него спустя годы, когда участник, загрузивший их, уже давно покинул проект.
Поэтому мы так осторожны с предложениями бесплатных геоданных для проекта и не спешим немедленно всё загружать, скорее наоборот, предостерегаем от этого других. Лучший способ добавить ваши POI — открыть обновляемый набор их координат и метаданных, которые осмеры будут синхронизировать в полуавтоматическом режиме, а то и вручную, через валидаторы вроде этого. Идеальный способ добавить нам пространственный слой, вроде лесов и полей или зон использования воздушного пространства, — открыть его отдельным набором и подключать во время отображения, не захламляя общую базу очередной нередактируемой и мешающей обычным участникам кучей объектов.
Нельзя взять слепок данных и сказать: это — OpenStreetMap. Он теряет свою суть, своё главное отличие от остальных картографических данных в момент, когда вы его загружаете. Наш проект существует в трёх измерениях, и как нельзя от данных отнять широту или долготу, OSM лишается смысла, если его данные обрезать по оси времени. Участники это хорошо понимают, ожидая от всех сервисов на базе OpenStreetMap как минимум ежедневного обновления, в худшем случае — ежемесячного. Каждую секунду сотни человек существенно изменяют карту, что складывается в полгигабайта правок ежедневно, 0.2% от всех данных. Да, у нас масса ошибок, но в контексте третьего измерения они несущественны, поскольку обратная связь мгновенна. Обрежь время — и данные OSM превращаются в неполный, неудобный, местами просто неверный склад геоданных. Именно его часто сравнивают с альтернативами, коммерческими картографическими данными, ведь они точно так же лишены третьего измерения, имитируя его версионностью.
То же верно и для обратного процесса, импорта чужих данных в OSM. Многие энтузиасты рассматривают импорт как единичное вливание данных, «сделал дело — гуляй смело». В итоге на карте появляются двумерные кладбища данных, за которыми никто не присматривает. Источники импортов обновляются: так, пока американцы ковыряются в TIGER от 2005 года, уже вышел значительно превосходящий его по качеству TIGER 2012. Несколько стран импортировали покрытие CORINE 2006 года, которое неминуемо обновят, но иначе как всё удалить и импортировать заново, данные в OSM не обновить. А править руками импортированное настолько муторно, что этим никто не занимается. Большие импорты остаются зафиксированными во времени, они не становятся частью OSM, торча из него спустя годы, когда участник, загрузивший их, уже давно покинул проект.
Поэтому мы так осторожны с предложениями бесплатных геоданных для проекта и не спешим немедленно всё загружать, скорее наоборот, предостерегаем от этого других. Лучший способ добавить ваши POI — открыть обновляемый набор их координат и метаданных, которые осмеры будут синхронизировать в полуавтоматическом режиме, а то и вручную, через валидаторы вроде этого. Идеальный способ добавить нам пространственный слой, вроде лесов и полей или зон использования воздушного пространства, — открыть его отдельным набором и подключать во время отображения, не захламляя общую базу очередной нередактируемой и мешающей обычным участникам кучей объектов.
А старение данных — проблема, и с ней еще придется столкнуться, даже вне связи с импортами.
Например, для тех же ПОИ.
Безусловно так. Всякое старье так или иначе нужно удалять.
Можно такой аттракцион устраивать раз в три года, с удалением старья просто по таймштампу (дате последнего редактирования).
А импортировать что-то что меняется раз в 50 лет, как водные и растительные объекты, по моему нестрашно даже если их следующие 40 лет никто не будет трогать )
Возможно надо ввести специальный тег branch ? Который не будет содержаться в вырезках и будет поддерживаться редакторами, что можно включить-отключить. Как только некоторые объекты проверены, тег удаляется и становится полноценной частью OSM.
Я веду к тому, что не должно быть у нас постоянный production! Должно быть место где можно положить временные изменения и они не затронут программы, которым нужны «хорошие» данные каждый день.
Важно не то, откуда данные, а то, на сколько легко они верифицируются и обновляются. Дороги в OSM появляются часто еще до их строительства (как строящиеся), а объекты других типов — с годовой задержкой.
В какой-то ситуации импортированные данные могут быть «подхвачены», а в какой-то, действительно, «повиснут в воздухе».
Теоретически, импорт может осуществляться периодически, с заменой старых версий объектов на новые и т. п., но это требует несколько более сложного механизма, нежели простое копирование, как это обычно бывает.
Ещё до ОСМ 6 лет назад я составил каталог точек в gpx с магазинами 24 часа определённого типа по Питеру, их получилось 350 штук, за год 160 изменилось, около 25 вовсе пропало, остальные сменились бренды, тип магазина, владелец и т. п.
И регулярно проверять POI это одно из самых сложных в ОСМ, так как POI требует подойти, зайти, сфоткать, часто ты едешь мимо и видишь лишь вывеску. А ещё бывает когда магазина уже нет, но вывеска на крыше дома так и осталась — отсюда откровенные fake, не намерянные конечно, но fake.
Ещё один микро пример, не далеко от моего дома есть трасса, шоссе длиной 9 километров всего-то казалось бы. Так вот за год на нём меняются очень многие POI, например заправки. Вообще в радиусе наверное 10-20 км от города, POI меняются очень часто.
Итого видать нужно средство, может быть даже ставить в POI check_date или что-то подобное. Причем мечта чтобы этот процесс был упрощён, аля я пришел с андроидом, вижу — да магазин есть, и тыкаю есть, и от моего логина обновляется пресловутый «check_date» или его аналог.
И да многих POI нужных простым людям нет в дубль гисе, так что тут бабка на двое сказала.