Третье измерение 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 — открыть обновляемый набор их координат и метаданных, которые осмеры будут синхронизировать в полуавтоматическом режиме, а то и вручную, через валидаторы вроде этого. Идеальный способ добавить нам пространственный слой, вроде лесов и полей или зон использования воздушного пространства, — открыть его отдельным набором и подключать во время отображения, не захламляя общую базу очередной нередактируемой и мешающей обычным участникам кучей объектов.
Поделиться
Отправить
10 комментариев
Zkir
Версионность не пустая вещь, и я ее даже поддерживаю, в меру сил)

А старение данных — проблема, и с ней еще придется столкнуться, даже вне связи с импортами.
Например, для тех же ПОИ.
Hind
Осм имеет все шансы самому стать нередактируемой кучей объектов. Не мешайте ему своими импортами. :3
Wowik
Вывод: проход злого бота был полезен, ибо спровоцировал обновление данных в ОСМ, т. е. синхронизацию с действительностью и другими источниками (бинг, к примеру), которые не очень давно обновились/появились
Zkir
>Вывод: проход злого бота был полезен.
Безусловно так. Всякое старье так или иначе нужно удалять.

Можно такой аттракцион устраивать раз в три года, с удалением старья просто по таймштампу (дате последнего редактирования).
Silver
POI в OSM вообще штука априори устаревшая и не заслуживающая никакого доверия. Дубль Гис обзванивают все организации из своего справочника каждые 3 месяца и то запросто попадаются устаревшие данные. А в OSM значительную часть ПОИ вносят те кто зашли сюда первый и последний раз и по сути это тотже импорт, который никто не верифицирует во времени.

А импортировать что-то что меняется раз в 50 лет, как водные и растительные объекты, по моему нестрашно даже если их следующие 40 лет никто не будет трогать )
Vort
Для борьбы с устаревшими данными скорее нужно что-то типа валидатора — какой-то инструмент, позволяющий оценить степень достоверности данных. Также не помешал бы механизм, схожий с патрулированием в Википедии — многие участники обладают информацией об актуальности того или иного объекта, но механизма для удобного применения таких знаний нет.
vshcherb
Честно говоря проблема устаревших данных слишком переоценена (там где было кафе, скорее всего и останется, а офисы рисовать всегда чревато), а проблема импортов недооценена. Однажды импортированное никуда не девается и лежит мертвым грузом. Потом эти слои объектов просто рушат рендеринг, а дубликаты дорог подтачивают роутинг.

Возможно надо ввести специальный тег branch ? Который не будет содержаться в вырезках и будет поддерживаться редакторами, что можно включить-отключить. Как только некоторые объекты проверены, тег удаляется и становится полноценной частью OSM.

Я веду к тому, что не должно быть у нас постоянный production! Должно быть место где можно положить временные изменения и они не затронут программы, которым нужны «хорошие» данные каждый день.
BushmanK
С точки зрения устаревания, импорты всего лишь портят общую картину. Данные могут протухнуть с одинаковым успехом, будь это данные третьей стороны или внесенные пользователями (яркий пример — когда начинается снос зданий и строительство новых вместо них, изменения могут быть отражены в OSM через год и более).
Важно не  то, откуда данные, а то, на сколько легко они верифицируются и обновляются. Дороги в OSM появляются часто еще до их строительства (как строящиеся), а объекты других типов — с годовой задержкой.
В какой-то ситуации импортированные данные могут быть «подхвачены», а в какой-то, действительно, «повиснут в воздухе».
Теоретически, импорт может осуществляться периодически, с заменой старых версий объектов на новые и т. п., но это требует несколько более сложного механизма, нежели простое копирование, как это обычно бывает.
GaM
Тема правильная, но устаревание данных это реально не только проблема импортов — это проблема вообще.
Ещё до ОСМ 6 лет назад я составил каталог точек в gpx с магазинами 24 часа определённого типа по Питеру, их получилось 350 штук, за год 160 изменилось, около 25 вовсе пропало, остальные сменились бренды, тип магазина, владелец и т. п.
И регулярно проверять POI это одно из самых сложных в ОСМ, так как POI требует подойти, зайти, сфоткать, часто ты едешь мимо и видишь лишь вывеску. А ещё бывает когда магазина уже нет, но вывеска на крыше дома так и осталась — отсюда откровенные fake, не намерянные конечно, но fake.
Ещё один микро пример, не далеко от моего дома есть трасса, шоссе длиной 9 километров всего-то казалось бы. Так вот за год на нём меняются очень многие POI, например заправки. Вообще в радиусе наверное 10-20 км от города, POI меняются очень часто.
Итого видать нужно средство, может быть даже ставить в POI check_date или что-то подобное. Причем мечта чтобы этот процесс был упрощён, аля я пришел с андроидом, вижу — да магазин есть, и тыкаю есть, и от моего логина обновляется пресловутый «check_date» или его аналог.

И да многих POI нужных простым людям нет в дубль гисе, так что тут бабка на двое сказала.
Ганьков Андрей
Думаю что большую часть проблемы с устареванием POI, может решить увеличение популярности в целом OSM и программы osmAnd, ну и популяризации среди пользователей идеи сообщать об ошибках. Да очень многие не будут заморачиваться и разбираться с редактированием карты, а тем более большенство не сможет править карту правильно, но сообщить о том что магазина уже нет, может почти каждый.