OpenStreetMap: прошлое, настоящее и будущее

в 13:01, , рубрики: OpenStreetMap, OSM, базы данных, Геоинформационные сервисы, картография, Программирование

Скажу сразу: я не пользователь OSM и, тем более, не участник проекта. Тем не менее, я считаю, что знаю о нём достаточно много, и хочу изложить свои соображения в виде обзорной заметки по статьям, которые мне удалось здесь обнаружить. Своего рода полемика с авторами этих статей и комментариев к ним. Точнее, с их тезисами — важно ведь не КТО сказал, а ЧТО сказано.

Часть первая: Начало

Началось это, видимо, с «The Shuttle Radar Topography Mission (SRTM) that flew onboard the Space Shuttle Endeavour during an 11-day mission in February of 2000». Затем Стив Кост, по примеру Википедии, в июле 2004 года создал проект OpenStreetMap (ещё до появления Google Maps, разумеется). После чего началось «триумфальное шествие советской власти»: для использования в OSM свои спутниковые снимки сделали доступными по лицензии CC-BY-SA компании NearMap, NOAA, GeoEye, DigitalGlobe, ErosB, Google (!), US Census TIGER, AND, MassGIS, GeoBase и многие другие. Поголовье волонтёров тоже растёт, как на дрожжах. Ещё немного, ещё чуть-чуть — и вся планета будет оцифрована и предоставлена в безвозмездное пользование всем-всем-всем!

Часть вторая. Наши дни

Хотели как лучше, а получилось как всегда. Навалились гурьбой, стали руки вязать, а потом уже все позабавились.

Так называемый «крупный бизнес» явно почуял поживу, и ГИСы стали плодиться, как тараканы: Google Maps, Яндекс Maps, Рамблер Maps, Mail.Ru Maps aka Maps.me, Яндекс.Народная карта, Apple Maps, Bing Maps, Yahoo! Maps и прочая, и прочая, и прочая. Вдруг заговорили про ГИТ — «геоинформационные технологии» (это примерно то же самое, что и куда более широко и шумно распиаренные «нанотехнологии», о которых сегодня молчат в тряпочку), про «пространственные базы данных» (можно подумать, пространственные БД чем-то отличаются от любых других), про «экологический мониторинг» (популярное нынче средство для распила бабла) и т.д. Появилась даже «пространственная экономика» плюс целая индустрия автомобильных, пешеходных, велосипедных и прочих нафигаторов. Одним словом, тренд сменился на прямо противоположный: если раньше какие-то «частные лавочки» (например, Japan KSJ2 Import или специализирующийся по Северной Америке TIGER) сливали данные в общий котёл OSM, причём безвозмездно, то сейчас они расползаются по крупным компаниям, предоставляющих эти данные уже за деньги, и чуть ли не каждая из них готова пожрать всех своих конкурентов до единого (некоторых уже сожрали). OpenStreetMap среди этого столпотворения стала почти не видна, даже если не добавлять сюда стремительно размножающийся зоопарк «геософта»: Mapnik, Maperitive, CloudMade, JOSM, Cartagen, Potlatch, Merkaartor, Vespucc, Go Map!!, OsmAnd, Navit, и прочие GNOME Maps.

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

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

Мы выяснили, что на первом этапе в OSM стекались данные от разных компаний, а расползаются от неё в виде конкурентов уже всякие API. Почему? Да потому, что это позволяет «под шумок» объявить своей интеллектуальной собственностью не только сам сервис (как правило, довольно поганый, как и у самой OSM), но и все завёрнутые в него геоданные. А данные наверняка ворованные: вот режь меня, жги меня — я не верю, что каждый из них (или хотя бы один из них) собрал свою собственную карту силами только своих волонтёров (кстати, присваивать их труд тоже неприлично)! Что? Только свои? А если найду? Базы данных — В СТУДИЮ! Ах, не дадите? Ну, тогда извините — здесь работает «презумпция виновности».

OSM даёт доступ ко всей информации, а остальные — лишь то, что соблаговолит выдать серверный софт в ответ на запрос, что создаёт (по крайней мере, теоретическую) возможность для различных манипуляций с информацией. Об остальных «прелестях» доступа к данным только через API уже рассказывалось в статьях здесь, на Хабре. Например: Дело в том, что на этот раз нам нужно обработать примерно 5 миллионов адресов. А может быть и 50 — это сразу было не ясно. Как известно, Google забанит ваш IP примерно через 10 тысяч адресов, Яндекс поступит с вами аналогично, хотя возможно и несколько позже (25 тыс запросов в день вроде). И кроме того, оба API это REST, а значит это сравнительно медленно. И даже если купить платную подписку, скорость от этого не увеличится ни на грош.

Позиция OSM представляется мне безупречно чистой и наверняка сидит в печёнках у всех конкурентов: данные доступны по открытой лицензии ODbL и имеют два главных условия использования: обязательная ссылка на источник данных (участники OpenStreetMap) и в случае публичных производных данных они должны быть также опубликованы по лицензии ODbL. Мало того, использование для создания карт информации из несвободных сервисов, подобных Google Maps, без разрешения правообладателя запрещено. Наконец, карты OpenStreetMap используют такие сайты и организации как Организация Объединённых Наций, Википедия, Microsoft Bing Maps, Федеральное космическое агентство России, MapQuest, Викимапия (Ого! Они что, ориентацию поменяли?), Оксфордский университет, сайт президента США и другие.

Но хватит дифирамбов — «теперь поговорим о дряни».

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

Согласен: количество ошибок там просто гигантское: гораздо больше, чем думает только что процитированныйин! И выявить их не так-то просто: данные, хоть и текстовые, но мультиязычные — приблизительно на 40-50 языках. Кроме того, там очень много дублей и просто мусора. Это даже если забыть, что ошибки в данных имеют пакостную тенденцию накапливаться (и даже порождать ошибки наведённые), а сами данные постоянно изменяются, дополняются, устаревают. Но кто вам сказал, что у этих «проприетарных» систем нет ошибок? Или что их там хотя бы меньше? Они просто не видны, как и сами данные. Зато недостоверность информации в открытой системе можно исправить, а в закрытой — нет. Так что, по крайней мере, потенциально OSM всё равно лучше любого другого «аналога» — она верифицируема!

Когда-то (несколько лет назад) я посмеивался, что в базе OSM обнаружено аж 17 Южных полюсов! Решил проверить, как сейчас, качнул Антарктиду (30.03.2019) и получил… 50 полюсов. Прописью: ПЯТЬДЕСЯТ! Не верите? Смотрите!

1. node id=1042050310 lat=-90.0 lon=0.0
2. node id=4028080674 lat=-90.0 lon=-23.1236527
3. node id=4055651342 lat=-90.0 lon=19.0
4. node id=4055651343 lat=-90.0 lon=19.0
5. node id=4055651344 lat=-90.0 lon=19.0
6. node id=4055651345 lat=-90.0 lon=19.0
7. node id=4055651346 lat=-90.0 lon=19.0
8. node id=4055651347 lat=-90.0 lon=19.0
9. node id=4055651348 lat=-90.0 lon=19.0
10. node id=4055651349 lat=-90.0 lon=19.0
11. node id=4324771561 lat=-90.0 lon=1.1844246
12. node id=4324771562 lat=-90.0 lon=105.6989404
13. node id=4324771563 lat=-90.0 lon=132.4186852
14. node id=4324771564 lat=-90.0 lon=137.780023
15. node id=4324771565 lat=-90.0 lon=143.3682855
16. node id=436012592 lat=-90.0 lon=0.0
17. node id=5478583892 lat=-90.0 lon=33.2303881
18. node id=5478583893 lat=-90.0 lon=158.3249615
19. node id=5478583894 lat=-90.0 lon=-86.5237898
20. node id=5478583895 lat=-90.0 lon=48.2165046
21. node id=5478583904 lat=-90.0 lon=45.5704167
22. node id=5478583905 lat=-90.0 lon=72.694447
23. node id=5478583906 lat=-90.0 lon=-4.6036415
24. node id=5478583907 lat=-90.0 lon=156.4156146
25. node id=5478583908 lat=-90.0 lon=174.4279763
26. node id=5478583909 lat=-90.0 lon=-25.4418087
27. node id=5478583910 lat=-90.0 lon=90.8751034
28. node id=5478583911 lat=-90.0 lon=81.7634245
29. node id=5478583912 lat=-90.0 lon=-40.8082874
30. node id=5478583913 lat=-90.0 lon=-85.5106502
31. node id=5478583914 lat=-90.0 lon=-112.6347103
32. node id=5478583915 lat=-90.0 lon=-35.3366556
33. node id=5478583916 lat=-90.0 lon=163.6440556
34. node id=5478583917 lat=-90.0 lon=145.6316657
35. node id=5478583918 lat=-90.0 lon=-14.4985701
36. node id=5515059773 lat=-90.0 lon=152.6074683
37. node id=5515059774 lat=-90.0 lon=125.0793442
38. node id=5515059775 lat=-90.0 lon=-19.8055055
39. node id=5515059776 lat=-90.0 lon=125.378694
40. node id=5515059777 lat=-90.0 lon=96.2779594
41. node id=5515059778 lat=-90.0 lon=9.34518
42. node id=5515059779 lat=-90.0 lon=-47.4747063
43. node id=5515059780 lat=-90.0 lon=-49.0473178
44. node id=5515059781 lat=-90.0 lon=8.9047508
45. node id=5515059782 lat=-90.0 lon=166.9006628
46. node id=5515059783 lat=-90.0 lon=-165.5712167
47. node id=5515059784 lat=-90.0 lon=-20.6863713
48. node id=5515059785 lat=-90.0 lon=-165.8705753
49. node id=5515059786 lat=-90.0 lon=-136.769845
50. node id=5515059787 lat=-90.0 lon=-49.8370691

Причём 8 Южных полюсов были занесены в базу 2016-03-11 в 23:52:59, 10 — 2018-03-14 в 18:09:21, 9 — 2018-03-14 в 18:09:22, 15 — 2018-03-29 в 20:30:33. Это даже смахивает на вандализм (тем более, что у таких узлов и айдишки часто идут подряд). Впрочем, и без вандализма всякого дерьма в БД OSM предостаточно.

Второе, за что ругают OSM — это низкий уровень сервиса для конечного пользователя. Не хочу это даже обсуждать: вполне возможно, что он хуже многих других — возможно, даже самый плохой — какая разница? Должны же конкуренты хоть чем-то отличаться в лучшую сторону! Но, повторяю, OSM — это база данных, а всё остальное лишь «надстройка над базисом».

Ещё одна претензия к OpenStreetMap звучит примерно так: Схема тегирования в OSM является одновременно самым главным её архитектурным преимуществом, поскольку позволяет описать фактически любые свойства объекта, т.к. реально никто не ограничивает вас в выборе новых тегов для новых свойств объектов; и одновременно самым больным её местом, поскольку любая свобода в выборе способов обозначения всегда порождает религиозные войны различных групп пользователей, так и не сошедшихся во мнении, как обозначать тот или иной спорный объект.

Или:

Иногда такое вот использование привычного естественного языка ведет если не к катастрофическим для семантики результатам, то к чему-то, что достойно эпитета «крайняя неопределенность».

Или даже:

«Любые тэги» — самое большое проклятие осма. Видно, что изобретали его люди с линуксом головного мозга. Основное ядро должно быть тщательно продумано и стандартизировано. Мне казалось, что это аксиомная аксиома.

А вот мне кажется, что эта «аксиомная аксиома» убивает проект на корню! И здесь я намерен жёстко защищать позицию OSM: это ещё вопрос, у кого там «линукс головного мозга»! Вот скажите мне: почему вообще противопоставляются эти понятия? Естественный язык — хорошо, формальные классификации — тоже хорошо! А принцип OSM «any tags you like» просто великолепен! И тот факт, что первично в этом проекте наполнение картографической базы данных, а не то, как содержимое этой базы отображает стиль Standard на osm.org тоже замечательно! Волонтёры делают гигантскую, грандиозную работу поистине чудовищной трудоёмкости — и что, мы будем брезгливо морщить носы и указывать им, как им, по нашему мнению, следует заносить или редактировать данные?! Нет, мы должны поклониться им низко в ноженьки и предоставить возможность работать так, как удобно именно им! И никак иначе!

Будете возражать? Будете говорить, что база должна сохранять более или менее стройную семантику данных? Что в разных странах одинаковые объекты могут значительно различаться по составу и содержанию тегов? Что нечёткая процедура назначения тегов противоречит еще одному важному принципу OSM: верифицируемости, который гласит, что любое обозначение, внесенное в базу, должно быть таким, что другой участник проекта мог бы его подтвердить, то есть однозначно обозначить тем же самым образом? А вы уверены, что это вообще в принципе возможно? Опять путаем понятия «смысл» и «значение»…

Теги одного объекта должны быть уникальными, т.е. объект не может содержать два одинаковых тега с разными значениями, например highway=primary и highway=secondary в пределах одного объекта недопустимо.

И все, конечно, дружно послушаются и будут это строго соблюдать? Сами-то хоть в это верите? Или способны однозначно определить, что там за highway: primary, secondary или ещё какая? А ничего, что у тега highway более 500 значений, из которых немало в разы более популярных, чем только что названные? Там 11 миллионов «unclassified», 15 миллионов «track», 23 миллиона «service», 43 миллиона «residential», не говоря уже про всякие street_lamp, living_street, traffic_signals, bus_stop и другие. А что наряду с обычным building=yes существует несколько тысяч building=да — с этим что прикажете делать? А знаете, что общее количество тегов в базе данных превышает 50 тысяч и что там, рядом с многомиллионниками (amenity, barrier, landuse, maxspeed, natural, oneway, power, surface и другие) соседствует порядка 20 тысяч тегов, которые встречаются лишь один раз на всю БД? А что популярные данные (foot=yes, access=private, waterway=stream, тот же highway=secondary, building=house, oneway=no, surface=asphalt, power=tower, ...) тегами как раз и не являются? Неужели кто-то всерьёз думает, что всё разнообразие данных в OSM возможно описать на какой-то несчастной страничке Вики и, тем более, заставить всё сообщество её соблюдать?

Полилиния может быть либо объектом way, содержащим node, либо relation, содержащим way, т.е. не может быть relation содержащим и way и node одновременно, однако может быть объектом relation, содержащим одновременно way и другие relation, содержащие только объекты way.

Так-таки и не может? А знаете, сколько их на самом деле? 9 478 938 ссылок на 6 163 522 узла (node) из 2 106 305 отношений (relation), причём — держитесь крепче! — 1 794 837 (85%) из них содержат именно и way и node одновременно, а 106 219 из оставшихся имеют в качестве дочерних элементов только тип node. Актуальность данных — декабрь 2018 года.

Много разговоров ведётся также на тему определения площадных и линейных объектов, и вообще того, как должно быть, но почти никто не интересуется тем, как есть на самом деле. А потому ценность таких разговоров равна нулю, если не вообще отрицательная.

Ещё одно замечание перед тем, как перейти к «светлому будущему»:
Файл, содержащий векторные данные на всю планету Planet.osm в несжатом формате OSM XML занимает более 1ТБ, в формате XML, сжатом bz2, занимает 41.8ГБ, а в бинарном формате PBF 18.1ГБ. Все эти форматы хранят одни и те же данные.

Это не совсем так: и вся планета занимает менее терабайта (даже менее 900 гигов), и насчёт остального вот свежие данные:

Latest Weekly Planet XML File 75 GB, created 3 days ago.
Latest Weekly Planet PBF File 44 GB, created 3 days ago.

В любом случае, на мой взгляд, это не повод ковыряться в бинарных форматах (особенно, если их не просто читать, а модифицировать) — тем более, что вполне возможно сократить объём БД в несжатом формате примерно на порядок.

Часть третья. Чем дело кончится

Очевидно, что проект OpenStreetMap будет разгромлен наголову — у него просто нет ни малейших шансов! Слишком уж много денежных мешков ввязались в драку за потребителя. OSM давно уже обсуждается именно как сервис, но не как база данных, со всеми вытекающими. И даже те, кто работает с ней, как с базой, рассматривают её лишь как хранилище данных, как источник для своей выборки, который read only, и уже в выборке что-то там модифицируют, что-то считают, что-то показывают пользователю… а база остаётся прежней — тем же самым дерьмом, которым она была до всех этих трепыханий. А потом сами же жалуются, что результаты расчётов быстро устаревают так как OSM изменяется каждый день. Сизифов труд, однако! Зато огромная армия программистов может заниматься этим практически вечно, демонстрируя тем самым свою нужность, свою востребованность.

Так, может быть, есть ещё какие-то шансы спасти OSM от разгрома? Думаю, только один: программисты должны направить свои усилия на то, чтобы редактировать саму базу, а не всякие примочки, надёрганные из неё. Работать надо в режиме «кентавра», чтобы люди занимались своим делом, а процессоры — своим. Чтобы привести OSM к нормальному состоянию: исправить ошибки, структурировать данные, сделать их обработку удобной как для человеческих мозгов, так и для компьютерных. Как это сделать? Это уже тема другой статьи.

Или даже целого цикла статей. Впрочем, это всё равно утопия…

Спасибо всем, кто дочитал это до конца.

Автор: rybvv

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js