Нормализация данных (пилотный проект — Спб и ЛО)

fserges · 2011-03-08T11:43:26.000Z

Первые две итерации завершены. По нескольким регионам (Ленинградская, Московская, Новосибирская, Владимирская области, Краснодарский край) был составлен словарь тегов. 236 ключей и 927 значений довольно неплохо описывают реальность. Непонятными оказываются порядка 0.5% данных что для начала неплохо.

Хотел проверить - а как мой словарь работает на “буржуйских” данных. Но оказалось что их файлы .osm гораздо больше наших (даже файл Финляндии в 2 раза больше Москвы и Московской области) и вычислительные ресурсы оказались узким горлышком. Поэтому пришлось полностью переделать базу данных с точки зрения оптимизации. База данных из красивой и понятной превратилась в оптимизированную, в которой не особо то и разберёшься. Но в результате она стала меньше где-то на 30% да и скорость обработки выросла пропорционально. Для обработки стран средней величины уже должно хватить. Впрочем, для обработки крупных стран придётся делать ещё одну оптимизацию. Но там уже будет статистическая оптимизация, с преобразованием данных (идеология в духе алгоритма Хаффмана) и это уже будет перед промэксплуатацией, т.к. база будет что чёрт ногу сломит.

А сейчас работаю над сочетанием тегов. Задача полностью не разрешима в рамках идеологии OSM, но до некоторого практического уровня валидатор довести можно. Например, регулярно в данных находятся сочетания типа highway=* и building=yes и т.п.

Faier · 2011-03-08T11:56:34.000Z

Zverik:

я ставлю addr:street без housenumber, когда знаю, что дом прописан по улице, но в номере не уверен. Это не ошибка

Я в таких случаях ставлю “addr:housenumber=00” , очень удобно.
а) теги собраны правильно
б) наглядно на карте сразу видно что номер дома неизвестен (неточен) и проезжая мимо можно глянуть
в) опять же на карте видно, что это именно дом, а не скажем служебное здание или еще что-либо

andriano · 2011-03-08T16:46:41.000Z

Faier:

Zverik:

я ставлю addr:street без housenumber, когда знаю, что дом прописан по улице, но в номере не уверен. Это не ошибка

Я в таких случаях ставлю “addr:housenumber=00” , очень удобно.
а) теги собраны правильно
б) наглядно на карте сразу видно что номер дома неизвестен (неточен) и проезжая мимо можно глянуть
в) опять же на карте видно, что это именно дом, а не скажем служебное здание или еще что-либо

Спасибо.
Вот здесь http://forum.openstreetmap.org/viewtopic.php?id=11467 я как раз столкнулся с тем, что существование записей такого вида входит в конфликт с концепцией, принятой для упаковки данных.
И придерживаюсь мнения, что в данном случаен имеет место умышленное искажение информации. Хотя для кого-то, это, возможно, и удобно.
На мой взгляд, отсутствие информации значительно лучше, чем искаженная информация. Из каких благих целей бы эта информация не искажалась.

andriano · 2011-03-08T16:50:39.000Z

fserges:

… был составлен словарь тегов. 236 ключей и 927 значений довольно неплохо описывают реальность. Непонятными оказываются порядка 0.5% данных что для начала неплохо.

А можно ознакомиться с этим списком?
И еще, из 236 ключей и 927 значений можно составить 218772 комбинаций. Каким образом определяется, какие из этих комбинаций допустимы, а какие - нет?
И каким образом обрабатывается ситуация, когда для определенного ключа допустимы произвольные значения?

fserges · 2011-03-08T17:21:44.000Z

Когда работа будет завершена то я размещу подробный отчёт, думаю что на вики. Пока всё сыровато чтобы выкладывать, так как все будут видеть кучу мелких погрешностей и делать неверный вывод - “сколько там косяков, наверное вся работа кривая”. А вот этого бы не хотелось.

По поводу комбинаций тегов. Полное решение задачи может и возможно теоретически, но по-крайней мере крайне сложно практически. Даже если предположить, что удастся всё подробно расписать относительно одного объекта, то придётся разбираться с комбинацией объектов. Взять тот же building=yes. Ничто не мешает навесить на контур здания shop=* или amenity=*. И каждый дополнительный тег может привнести свои собственные комбинации. В реальных данных на контур building=yes, например, ещё накладываются man_made, landuse, highway. Где проходит грань между допустимыми и недопустимыми комбинациями тегов, особенно если учесть что “any tag you like”? В файле Владимирской области, например, 17 зданий, они же landuse, 4 здания highway, 5 населённых пунктов помечены тегом layer, 105 веев имеют только тег addr:housenumber и ничего более (нет addr:street) и т.п. Вообще комбинации порой весьма причудливы

Я придерживаюсь единственного рационального (с моей точки зрения) подхода - строю частотные таблицы и далее, сопоставляю сочетания с документацией. Если потенциально сочетание возможно (с моей точки зрения), то сочетание пропускается, если нет - то отбраковывается. Валидатор получается довольно грубым, но во многом это в силу свободности семантики языка OSM и трактовки правил. Нужно не забывать что и русском языке складывая валидные слова языка можно получить бессмыслицу, “мама ныла раму”. Но с другой стороны парадоксальные сочетания слов иногда имеют смысл, скажем, “папа глушил водку”

fserges · 2011-03-12T19:16:41.000Z

Работа потихоньку идёт. Каждая следующая итерация это всё больший уровень абстракции и резко возрастающий объём исключений и нелогичностей. Но лёгкой прогулки и не ожидалось.

Хотя валидатор будет запускаться только по СПб и ЛО, он обкатывается и на других странах. Недавно прогонял Бельгию. Хотя в планах нет глобальной экспансии, но разрабатывая сложную вещь нужно в архитектуру решения закладывать масштабируемость. Вдруг окажется полезным?

Но к сожалению, есть одно но. Я уезжаю в командировку и отпуск и где-то на 1.5 месяца выпадаю из нормального ритма жизни. В частности, доступ к ОСМ да и компьютеру вообще будет ограничен. Так что в ближайшее время новостей не будет. Когда все поездки закончатся, надеюсь опубликовать результаты исследования.

fserges · 2011-03-12T19:59:23.000Z

На затравку несколько ошибок из пробного прогона валидатора:

И т.п.
Возможно - не всё ошибки, но сочетания непривычные

Surly · 2011-03-12T20:37:48.000Z

fserges:

Забор (не дорога) с ограничение скорости - http://www.openstreetmap.org/browse/node/1192706200

Может быть, здесь ошибки нет. Это ворота, а не забор; и если на воротах стоит знак ограничения скорости, то тэг maxspeed поставлен правильно. Его надо бы ставить на дорогу, но здесь дорогу пока не нарисовали.

Danidin9 · 2011-03-12T21:23:11.000Z

Да, там именно так, как сказал Surly.
Кстати, за этими воротами находится навес для транспорта - крыша на бетонных столбах. Может кто-нибудь посоветует, как отмечать такие сооружения поизящнее? Пока обозначил просто как covered=yes.

andriano · 2011-03-13T07:21:31.000Z

fserges:

На затравку несколько ошибок из пробного прогона валидатора:

xybot прибил “amenity=” http://www.openstreetmap.org/browse/node/1153440818/history http://www.openstreetmap.org/browse/node/1156696653/history и получилась точка с name и без каких-либо ещё тегов.

И чем то, что стало после бота, хуже чем то, что было до него?
На карте мааса объектов, не имеющих никаких тегов кроме name. Это, конечно, ошибка, но не бота.

Кинотеатр, он же - заброшенная деревня - http://www.openstreetmap.org/browse/way/62365485

locality - это ни разу не заброшенная деревня, это - ненаселенная местность, имеющая собственное название. Например, урочище.

Здание = дорога - http://www.openstreetmap.org/browse/way/86601892
Дорога=озеро - http://www.openstreetmap.org/browse/way/60503929

Здание либо озеро может быть окружено дорогой. Хотя в случае с озером это, конечно, маловероятно.

Линия электропередач, она же дорога - http://www.openstreetmap.org/browse/way/80765386

А вот линия электропередачи, идущая вдоль дороги - обычное дело.

Промзона, имеющая адрес, она же лес - http://www.openstreetmap.org/browse/way/54117446

Вообще-то здесь весьма своеобразная промзона - радиопередающий цех. Зачастую это территория, на которой стоят антенны, а сама территория обычно от леса не очищается.

motorcar=Северная ТЭЦ - http://www.openstreetmap.org/browse/way/33227541

А это, вероятно, результат “подсказок” при наборе + опечатка - пользователь нажал “m” вместо “n”.

PS. Но, вообще-то проблема неоднозначной интерпретации данных существует. Особенно при конвертации - когда требуется отнести объект к одному из заранее предопределенных типов. Я лично эту задачу решаю так:

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

Не уверен, что я делаю правильно. Может, будут какие предложения по обработке данного рода конфликтных ситуаций?

fserges · 2011-03-13T09:15:36.000Z

Я не ставил целю провести подробный анализ странных данных. Поэтому придраться к моим словам при желании легко. Именно поэтому я вообще не собираюсь выкладывать сколько-нибудь сырые данные для всеобщего обозрения, ибо объём критики скорее всего вообще лишит интереса к OSM.

andriano:

И чем то, что стало после бота, хуже чем то, что было до него?
На карте мааса объектов, не имеющих никаких тегов кроме name. Это, конечно, ошибка, но не бота.

Грубо говоря это не ошибка бота. Он просто порождает из ошибочных данных пустые именованные объекты.

Кинотеатр, он же - заброшенная деревня - http://www.openstreetmap.org/browse/way/62365485
locality - это ни разу не заброшенная деревня, это - ненаселенная местность, имеющая собственное название. Например, урочище.

Хорошо, кинотеатр, он же - урочище

Здание = дорога - http://www.openstreetmap.org/browse/way/86601892
Дорога=озеро - http://www.openstreetmap.org/browse/way/60503929

Здание либо озеро может быть окружено дорогой. Хотя в случае с озером это, конечно, маловероятно.

Оба варианта возможны теоретически, но практически так никто рисовать бы не стал или такая практика была бы очень странной. Дорога проходящая по стене здания возможна, но тогда должен быть level=1 или level=-1. Скорее всего дорога рядом.

А вот линия электропередачи, идущая вдоль дороги - обычное дело.

Вдоль дороги - да. Но зачем накладывать друг на друга два разных объекта. Как навигатор или рендер должны это отображать? Как электифицированная дорога или провода по которым можно ходить?

Вообще-то здесь весьма своеобразная промзона - радиопередающий цех. Зачастую это территория, на которой стоят антенны, а сама территория обычно от леса не очищается.

Меня тоже этот объект заинтересовал. Его нет на подробных картах!! Там просто лес. Military? Но вот с описанием landuse=industrial всё же не бьётся - “Используйте тег landuse=industrial чтобы обозначить область, использующуюся в промышленных целях, например заводы, фабрики или склады”.

Резюме: три ипостаси - данные, правила и рендер должны сливаться в экстазе. То есть данные соответствовать правилам, правила не создавать проблем данным, рендер отображать данные и следовать правилам. Если находится спорный случай то нужно либо избегать противоречивых данных либо изменять правила. Если кто-то не по делу использует теги, может менять описания тегов?

PS. Но, вообще-то проблема неоднозначной интерпретации данных существует. Особенно при конвертации - когда требуется отнести объект к одному из заранее предопределенных типов. Я лично эту задачу решаю так:

Просматриваются все теги объекта и отчаются распознанные key.

Отмеченные значения key рассматриваются в порядке приоритета. Приоритет задается заранее волевым решением.

Если для данного key удается однозначно идентифицировать value, эта комбинация и считается типом объекта, на чем анализ заканчивается.

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

Если объект так и не удалось отнести ни к одному предопределенному типу, он попадает в список ошибок.

Не уверен, что я делаю правильно. Может, будут какие предложения по обработке данного рода конфликтных ситуаций?

По мне это нормальная логика. Как программист в области корпоративных решений могу сказать, что понять что имел в виду пользователь когда принимал странное решение невозможно не спросив автора данных. Поэтому какая-либо автоматическая обработка ошибок не более чем попытка выжать максимум из говна.

Dmitry_Terentiev · 2011-03-13T09:28:32.000Z

andriano, все правильно?
http://www.openstreetmap.org/browse/way/96497728/history

Sergey_Astakhov · 2011-03-13T10:47:17.000Z

fserges:

Вообще-то здесь весьма своеобразная промзона - радиопередающий цех. Зачастую это территория, на которой стоят антенны, а сама территория обычно от леса не очищается.

Меня тоже этот объект заинтересовал. Его нет на подробных картах!! Там просто лес. Military? Но вот с описанием landuse=industrial всё же не бьётся - “Используйте тег landuse=industrial чтобы обозначить область, использующуюся в промышленных целях, например заводы, фабрики или склады”.

Там вот такие штуки в этом лесу стоят: http://www.panoramio.com/photo/20175011
Адрес и название взяты из rgis. На military как-то не тянет, поэтому industrial.

andriano · 2011-03-13T12:49:07.000Z

fserges:

Я не ставил целю провести подробный анализ странных данных. Поэтому придраться к моим словам при желании легко. Именно поэтому я вообще не собираюсь выкладывать сколько-нибудь сырые данные для всеобщего обозрения, ибо объём критики скорее всего вообще лишит интереса к OSM.

Вряд ли любой ответ на свое сообщение следует рассматривать как критику в свой адрес.
Но если какие-то мои слова могут быть истолкованы так, приношу свои изменения, я этого не хотел.

А вот линия электропередачи, идущая вдоль дороги - обычное дело.

Вдоль дороги - да. Но зачем накладывать друг на друга два разных объекта. Как навигатор или рендер должны это отображать? Как электифицированная дорога или провода по которым можно ходить?

Если одна точка входит в два разных объекта (например, объекты - дороги, а точка - перекресток), это никого не шокирует?
Так почему вызывает удивление, когда одна линия представляет два различных объекта? В конце концов, если, скажем, граница проходит по дороге, забору или реке, неужели обязательно должно быть два (несколько) наборов точек и линий?
Т.е. ни противоречия здравому смыслу, ни противоречия существующей идеологии OSM я здесь не вижу.
Другое дело, что есть некоторое неудобство (несовершенство), которое не позволяет уверенно разграничить случаи двух (трех и более) геометрически совпадающих объектов и ошибки.
Но это неудобство/несовершеноство вызвано существующей структурой данных OSM, в которой изначально непонятно, что является объектом, а что - нет.
Сейчас объектом может быть (а может и не быть) точка, путь или отношение. В моем представлении объекты должны иметь явняе описания, а все прочие сущности, как то точки, пути и отношения не должны быть самостоятельными объектами, а должны быть лишь строительными кирпичиками, из которых сооружаются объекты. Например, объект (POI), состоящий из единственной точки.
Но коль скоро сакая сущность как объект структурой данных OSM не предусморен, мы и не можем сказать, представляет собой ломаная один объект, два (три и более), а, может, вообще не является самостоятельным объектом и имеет смысл лишь как часть отношения.

Да, навигационная программа должна обрабатывать это, безусловно, как дорогу. А как это должен обрабатывать рендер - его внутреннее дело. В идеале, при запросе ТОЛЬКО дорог он должен показать эту линию как дорогу, а при запросе ТОЛЬКО ЛЭП - как ЛЭП. (не забываем, что основное отличие электронной карты от бумажной - именно в возможности задать для отображения только нужные слои)

Резюме: три ипостаси - данные, правила и рендер должны сливаться в экстазе. То есть данные соответствовать правилам, правила не создавать проблем данным, рендер отображать данные и следовать правилам. Если находится спорный случай то нужно либо избегать противоречивых данных либо изменять правила. Если кто-то не по делу использует теги, может менять описания тегов?

Дополню: данные должны соответствовоать не только правилам, но и объективной реальности.
В остальном - полностью согласен.
Но в целом есть исторические традиции, которые не позволяют оперативно (а то и вовсе) менять правила вообще и структуру данных в частности.

andriano · 2011-03-13T12:58:22.000Z

Dmitry Terentiev:

andriano, все правильно?
http://www.openstreetmap.org/browse/way/96497728/history

Не знаю.
Это была довольно массовая правка по преобразованию highway=Явное_название в highway=road + name=Явное_название. Естественно, там, где возможно, вместо неопределенного road я пытался подставить что-либо более подходящее. И в данном случае: площадь, по которой можно проехать, предназначенная для бизнеса и отведенная под шиномонтаж - IMHO наименее противоречивая комбинация, которую можно было осуществить, исходя из имевшихся тегов.

fserges · 2011-03-13T13:37:20.000Z

Sergey Astakhov:

fserges:

Вообще-то здесь весьма своеобразная промзона - радиопередающий цех. Зачастую это территория, на которой стоят антенны, а сама территория обычно от леса не очищается.

Там вот такие штуки в этом лесу стоят: http://www.panoramio.com/photo/20175011
Адрес и название взяты из rgis. На military как-то не тянет, поэтому industrial.

Скажем так, теоретически такое сочетание тегов представить можно, но практичность вызывает сомнения. Я не буду утверждать что указанное сочетание тегов чему-то противоречит, но это какое-то странное сочетание тегов. Давайте глянем подробнее:

Откроем вики: natural=wood - Лес естественного происхождения (деревья). … Внимание. При обозначении лесных массивов, рекомендуется следующий подход: Если это реально дремучий лес со старыми деревьями, где никто не удаляет старые растения, а новые прорастают сами, просто поставьте тег natural=wood.
Открываем вики: Используйте тег landuse=industrial чтобы обозначить область, использующуюся в промышленных целях, например заводы, фабрики или склады.

Т.е. одним полигоном выделено два крайне разных объекта землепользования. Как можно этот объект воспринимать - дикий лес, в части которого расположен промышленный объект или промышленный объект полностью заросший лесом?

Логичное решение проблемы - понять где находится реальная граница объекта industrial а где - natural. Глядя на картинку кажется что есть некоторый лесной массив, на котором размещено несколько объектов промышленного назначения. Ведь если глянуть на карту то видно, что промзону пересекает две пешеходные тропинки и нигде нет заборов, ограждения. Поэтому рисуется большой полигон natural=wood а часть непосредственно относящаяся к объекту покрывается landuse=industrial.

P.S. Прошу рассматривать это рассуждение как общее, каждый конкретный объект уникален и может оказаться исключением из правил.

Kuprienko_Viktor · 2011-03-13T14:10:28.000Z

fserges:

…- радиопередающий цех. Зачастую это территория, на которой стоят антенны, а сама территория обычно от леса не очищается.

Правильнее - “антенное поле”. От растительности очищается обязательно, ибо пожароопасно. Так-же при необходимости ремонта антенное полотно приходится опускать на землю. Опускать на кустарник и деревья - немыслимо. Вердикт - либо это недействующее антенное поле, либо его начальник редкостный раз(гиль)дяй. Подобные антенные поля как-правило имеются возле аэропортов. Ант. поля поскромнее - на оси ИВПП на расст. 2 и 5 км от торцов - ближний и дальний приводные радиомаяки. Пример http://www.openstreetmap.org/?lat=67.49367&lon=33.48414&zoom=16&layers=M

andriano · 2011-03-13T17:04:08.000Z

fserges:

…
Т.е. одним полигоном выделено два крайне разных объекта землепользования. Как можно этот объект воспринимать - дикий лес, в части которого расположен промышленный объект или промышленный объект полностью заросший лесом?

Отнюдь.
Как раз землепользование здесь только одно, что и указано соответствующим тегом.
В целом - заросший лесом участок, используемый в промышленных целях (без вырубки леса).

Kuprienko_Viktor:

Правильнее - “антенное поле”. От растительности очищается обязательно, ибо пожароопасно. Так-же при необходимости ремонта антенное полотно приходится опускать на землю. Опускать на кустарник и деревья - немыслимо. Вердикт - либо это недействующее антенное поле, либо его начальник редкостный раз(гиль)дяй. Подобные антенные поля как-правило имеются возле аэропортов. Ант. поля поскромнее - на оси ИВПП на расст. 2 и 5 км от торцов - ближний и дальний приводные радиомаяки. Пример http://www.openstreetmap.org/?lat=67.49367&lon=33.48414&zoom=16&layers=M

Насчет терминологии - возможно (хотя, уверенности нет - мир намного разнообразнее, чем может показаться на первый взгляд).
Могу утверждать лишь то, что видел собственными глазами. И это имеет следующие отличия:

От леса не очищается. Возможно, в какой-то окрестности антенн что-то и расчищено (из-за забора не видно), но в целом лес присутствует, притом (опять же, из-за забора) он производт впечатление не слишком пострадавшего от рук человека.
К авиации данный объект никакого отношения не имеет. Имеет отношение к МО, но точно не ВВС.

Кстати, на приведенном выше фото лес, опять же, присутствует. Вероятно, мы просто говорим о разных по природе объектах, общим для которых является лишь наличие антенн.

fserges · 2011-03-18T14:25:26.000Z

Поэтому я и взялся за проект только по СПб и ЛО - легко съездить и убедиться на месте что и как К сожалению, я уже на чемоданах и есть дела по-важнее, но как вернусь - подниму вопрос снова

Кстати, рядом с территорией “Радиопередающего цеха” начинается строительство нового ЖК “Софийский” на 10 тыс. жителей, так что всё равно скоро участок придётся перерисовывать http://www.restate.ru/material/120987.html

fserges · 2011-04-04T09:07:42.000Z

Уф, загрузил я себе файл rus.osm. Когда делал это в первый раз то был шокирован тем что это заняло более суток. Скорость была мягко говоря не фонтан. Оказалось что проблема решаема. Отключение антивируса привело к увеличению скорости на порядок

Для истории темпы роста БД:

2.01.2011 (из stat.latlon.org)

Количество узлов: 27 019 791
Количество линий: 2 233 760
Количество отношений: 40 637

31.03.2011 (из rus.osm)

Количество узлов: 36 551 705
Количество линий: 3 250 984
Количество отношений: 55 753

Прирост 20-30% за 3 месяца - весьма неплохо