Толстый и тонкий

В начале марта Иван Мельников спросил в твитере: «это правда, что самое большое и маленькое здания в OSM — ошибки?» Давайте выясним.

Тег building — самый популярный в базе, если не считать бессмысленного source: 77 миллионов линий, 45% от всех линий OSM. Osmosis отфильтровал 80% планеты, оставив 3,8 гигабайта, которые osm2pgsql за два дня развернул в базу в 25 раз толще. То есть вся планета потребовала бы полтерабайта. Попутно я узнал, что в среднем на 10 зданий приходится 53 узла, без учёта общих точек (по отдельности получится около 60-61 узла, как пишет статистика гис-лаба). 1/4,4 всех точек в базе принадлежит зданиям, и лишь у 37 идентификаторы меньше миллиона.

Я обрабатывал отдельно отношения и линии. Первых оказалось совсем немного, 85 тысяч. Из трёх самых больших мультиполигонов зданий два — автозаводы близ Торонто: General Motors (563 тыс. м²) и Toyota (284 тыс. м²). Второе по размеру «здание» — крепостная стена Сианя, древней столицы Китая: 322 тыс. м². Все эти мультиполигоны правильные, хотя в Канаде одним контуром обведены по три здания, а стоит ли стену обозначать как building — непонятно.



На этой фотографии заснято самое большое по площади основания здание: фабрика Boeing в Эверетте, США. Официально 398 тыс. м², в OSM — 385, в пределах погрешности. Однако у нас оно не входит даже в первую сотню. Топ-5 на 14 февраля таков: Как видно, эта часть теории подтверждается. Теперь обратимся к другому концу рейтинга. Главная проблема с мелкими полигонами — что площадь некорректных геометрий (с самопересечениями, дубликатами рёбер и т. п.) вычисляется как очень малая, но не нулевая. Если верить сортировке по столбцу площади, то да, самые маленькие <любые типы объектов> — ошибки. Но интереснее найти настоящие здания. Таким среди мультиполигонов будет ромбовидное здание, созданное Komяpой: 0,026 м². После него идут два правильных, но очень маленьких мультиполигона в Жироне, Испания, площадью 0,48 и 0,55 м², и дом в Калифорнии с двухсантиметровым стенами (0,68 м²): его контур inner едва меньше outer.

Познакомьтесь с самым маленьким (на 14 февраля) зданием в OpenStreetMap: домик в Словакии площадью 0,023 мм². На карте он выглядит бледной точкой. Даже используя буферизацию, не удалось избавиться от всех кривых геометрий, но второе и третье места по площади занимают дома в Сан-Франциско: 1.8 и 3,2 мм². Остальные здания рекордных размеров вы можете поискать самостоятельно.

В итоге, как резюмируют на MythBusters, CONFIRMED: сколько ни исправляй ошибки, самые большое и маленькое здания в OpenStreetMap не соответствуют зданиям на местности.
Поделиться
Отправить
10 комментариев
Ivan
«если не считать бессмысленного source». Поясните, пожалуйста. На мой вгляд он весьма осмысленный, иначе хрен разберешь, по каким данным нарисовано и стоит ли исправлять если, скажем, в бинге все выглядит по-другому.
Илья Зверев
Редкий объект в OSM имеет одну версию. Разные люди рисуют по разным источникам. Если кто-то обвёл дом по кадастру, другой проставил номер из открытого портала области, третий подвинул половину точек по бингу, четвёртый проставил этажность по панорамам, третий по данным городского сайта обозначил в здании школу — какое значение тега source должно быть?
fserges
Забавная статья :)
Elkim
>Остальные здания рекордных размеров вы можете поискать самостоятельно.
А там такое: «аЁаАаМб‹аЕ аБаОаЛбŒбˆаИаЕ аИ аМаАаЛаЕаНбŒаКаИаЕ аЗаДаАаНаИб аВ OpenStreetMap». :(

Пните кого надо, если знаете кого, что бы вписали уже charset в html’ку. (http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B8_%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D0%BE%D0%B2_%D0%B2_HTML)
Ivan
Илья, в таком случае я бы хотел в source увидеть перечисленными все источники информации. Потом, в случае дорог и природных объектов вероятность внесения информации из более чем двух источников (bing/survey) сильно меньше.
yuryleb
building:source=bing
building:levels:source=pano
addr:source=rgis
name:source=site ?

Кстати, все подобные изменения обычно вносятся разными changeset’ами, и у каждого может быть свой source
AlexTheTux
А чего *Komяpa* статьи портит ?
Александр Качкаев
Иван, просто ставьте тег source к самой правке, а не к объектам, которые вы создаёте или меняете. Так делают некоторые пользователи, в случае необходимости перечисляя несколько источников через точку с запятой: http://www.openstreetmap.org/browse/changeset/15363757 Согласен с Ильёй, что source в свойствах точки, линии или отношения — лишний тег, к тому же его значение очень редко отражает действительность.

На заре ОСМа к объектам ещё часто добавлялся тег created_by, указывающий на версию редактора. Это свойство до сих пор кое-где встречается: http://www.openstreetmap.org/browse/way/8076564 Значение тега спокойно кочует себе от правки к правке, теряя всякий смысл и пользу и засоряя базу: http://www.openstreetmap.org/browse/way/4390593/history Массовой вычисткой этого тега никто не занимается (в этом нет смысла), но если он встретится вам во время правки какого-нибудь объекта, спокойно можете его удалить.
akks
У source есть один значительный плюс — его видно, в отличие от комментариев пакета правок :)
Например, когда всякая природа рисуется по Landsat/Yahoo/IRS/Bing, знатть про конкретный объект, откуда он срисован, весьма полезно.
Для мелких дорог это тоже важный тег, т. к. может служить для проверки надёжности информации.
Ну, а когда дома пачками стоят — тут смысл source лишь в защите от подозрений и при наличии Bing теряется.
Sergey Astakhov
> Массовой вычисткой этого тега никто не занимается (в этом нет смысла), но если он встретится вам во время правки какого-нибудь объекта, спокойно можете его удалить.

JOSM занимается, при любой правке. Он, перед загрузкой на сервер изменённых объектов, автоматически удаляет у них created_by (и ряд других тегов).
freeExec
Ну вот пришёл в понедельник почитать, а тут уже половину ляпов выпилили :(
П.С. Раз уж akks упомянул, то не лишним будет добавить в JOSM коменты правки при просмотре истории объекта.