Теги: стандартизация и исправление ошибок.

Осталось только привести твоё определение “качества”, а то недосказанность получается…

Хотелось бы еще иметь формальный алгоритм, позволяющий отличить первое от второго. :wink:

Интересно, и как же этот справочный материал может быть использован ботом для пакетной правки “явных ошибок”?
Собственно, тот XML, который я разместил в первом посте, получен автоматом именно из Map Features, но если приглядеться повнимательнее, там нужна довольно существенная правка руками.
Не говоря уже о том, что, например, даже такой набивший оскомину тег “landuse=military” там попросту не отражен.

Если это уже давно делается, откуда тогда опечатки?
Кстати, в каких из приведенных ниже случаев опечатки, а в каких нет? (hint: в 615 строке в теге содержатся “лишние” символы, которые при просмотре в режиме utf8 на экране не отображаются - такие случаи тоже бывают)

  78       1 "name:krl"
  82       1 "game:patrizer2:bier"
  83       1 "game:patrizer2:eisenerz"
  84       1 "game:patrizer2:felle"
 102       1 "old_name:pl"
 129       1 "island"
 161       1 "AND_nodes"
 230       1 "inat_name"
 239       1 "oldname"
 378       1 "source:highway"
 387       1 "name_engl"
 399       2 "ont_name"
 402       1 "name_3"
 411       1 "abbr_name"
 426       1 "ent_name"
 429       1 "private"
 434       1 "name_old:ru"
 440       1 "boat"
 451       1 "currency"
 452       1 "postcode"
 480       1 "books"
 481       1 "polulation"
 533       1 "school"
 566       1 "x-point-id"
 567       1 "open_hours"
 576       1 "dogs"
 585       1 "poi"
 606       1 "_сladr:code"
 610       1 "closed"
 612       1 "game"
 615       1 "сladr:note"
 625       1 "zip"
 639       1 "tel"
 642       1 "female"
 643       1 "male"
 650       1 "
name"
 692       1 "Лесоарк"
 693       1 "№"
 710       1 "name_"
 715       1 "cladr:namt"
 717       1 "restruktion"
 719       1 "дом 59"
 729       1 "отделение милиции Хабаровск-2"

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

Опечатки - можно просто считать разность между тегами из map features и тегами на карте, если разность меньше 2 - скорее всего это опечатка. Кирилические тэги - скорее всего опечатка. Таковые можно наверное и автоматом править.

Редкие теги, которые встречаются 1-2 раза на карте - тут уж скорее писать автору.

А повышать качество коллективного продукта надо двумя путями:

  1. Толковое описание в вики. С примерами и туториалами.
  2. Стимуляция - расставь релейшены так то - получишь роутинг в таких то навигаторах. Расставь теги так-то получишь нормальное отображение в рендере.

В общем я за пряники а не за кнуты :slight_smile:

Слишком оптимистичное заявление.
Во-первых, я не упомянул, но оанализ касался ТОЛЬКО nodes, при этом ways и relations попросту не учитывались.
Но самое главное, military - это в данном случае key, огда как нормальное применение этого атрибута должно быть val. (а val я и не пытался обрабатывать по понятным причинам)
Другими словами, те 52 вхождения military - это только явные ошибки.

Ну, когда КАЖДОМУ новичку нужно один раз объяснить. А потом оказывается, что и не один… надобность в автомате, который бы проверял корректность ввода, мне кажется, достаточно насущна.
Ведь все “нестандартные” теги - это просто информационный мусор, т.к. любой перекодировщик (а без перекодирования использовать данные OSM ни в одной конкретной программе невозможно) все равно это выкинет.

andriano, military в качестве ключа вполне допустимо: http://wiki.openstreetmap.org/wiki/Key:military

И не надо считать чужие теги мусором.
Any tags you like - один из принципов OSM
Хотя против правки очевидных вещей, типа engl_name на name:en или tel на phone вряд ли кто-то будет возражать.

Почему ошибки? http://wiki.openstreetmap.org/wiki/RU:Key:military

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

Чайник куда идет первым делом?
В полтлач. А там пресеты скудные. Без лазанья в вики ничего не разметишь толком. Упомнить как что называется и с чем сочетается невозможно, да и долго ручками-то вбивать. Правда я уже привык. Но это дело двух-трех месяцев.
А за это время ерунды нагородил-то: ого-го!.

на самом деле “правильные” презеты в джосме на практике оказываются офигенно НЕинформативными без чтения вики.

поэтому, лучше юзать потлач+вики, чем джосм+чей-то_не всегда верный_перевод_тегов

Да, это я погорячился.
Но т.к. для анализа был взят только key, причем только для node, говорить о незначительности military в общем объеме данных преждевременно.

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

Ну и какой вывод? Вряд ли кто сможет сказать, что вот этот непонятный тег точно никому не нужен потому что “не распознается ни одним конвертером”. Хотя бы потому что есть конвертеры и не выложеные в общий доступ, но однако используемые.

Есть явные ошибки/очепятки (типа "
name" и “cladr:namt”) - их, наверное, можно и автоматом править. Но их обычно очень мало, так что смысла в автомате немного.
Есть явные теги по незнанию (типа school, “Лесоарк”, “дом 59” и “отделение милиции Хабаровск-2”) - тут надо подсказать автору как правильно делать.

А есть прочие теги, неподходящие под первые два пункта (типа тех же game) - вот их трогать точно не стоит. Максимум - списаться с автором чтобы узнать для чего они нужны.

а Вы уверены, что Вам известны все существующие конвертеры и все поддерживаемые ими теги?

Решительно против. Наверняка никто не обрабатывает surface, часы работы магазинов, типы бензинов на заправках, таких тегов полно… Это мусор? Это база, гео-база, и никто не заставляет тебя использовать “чужие” теги. Сколько тегов поддерживает ТВОЙ конвертер? Или у тебя нет своего конвертера?
А вот сейчас два человека на слуху – пишут показывалки ОСМа, вдруг у них будут задействованы эти теги? Мусор, говоришь…

Это тупиковый путь для общения на форуме :slight_smile:
Я вот думаю иначе. Что мне , утереться теперь? :slight_smile: мне вот нравится много разных тегов, ДА большинство из них не показывается. Сделай, что бы показывались! Скажем спасибо.

В конце концов никто не запрещает вытягивать данные через xapi, запрашивая их по конкретным тегам (по мап_фичесам, к примеру), что бы даже не “мараться” этим лишним “мусором”.

:slight_smile:

Ну, раз начался переход на личности, значит, обсуждение зашло в тупик. :frowning:
Какая разница, что МНЕ известно и что - нет?
Или кто-то всерьез собирается наделить МЕНЯ правом решать, какие теги нужны, а какие недостойны находиться в OSM?

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

По порядку:

  1. Выше уже было отмечено, что помимо общедоступных конвертеров существует немало (наверняка гораздо больше) других - для личного или ограниченного использования. И вполне вероятно, что они обрабатывают теги, игнорируемые открытыми конвертерами. Вопрос в другом: вряд ли имеет смысл делать обработку тега, который встречается в единственном экземпляре (или в количестве 3-7 штук). Разве что для отладки. Другими словами, часть тегов НИКОГДА не будут обработаны. Хотя, с другой стороны, даже некоторые, возможно, полезные теги не обрабатываются именно по причине их малого количества.
  2. Данная тема связана как раз с тем, что я пытаюсь прояснить для себя вопрос: “Сколько тегов должен обрабатывать мой конвертер?” Пока брал данные после osm2mp, такого вопроса не возникало. Но оказалось, что кое-чего мне лично не хватает. Прежде, чем писать конвертер, нужно прояснить для себя задачу. Началось это прояснение с набора статистики.
  3. Любопытная ситуация: пока никто ничего конкретного не упомянул, но уже появились “эти теги”, которые кто-то нехороший намерен удалить из базы.

Я что, пошел уже удалять “ненужеые” теги? Или попытался выяснить к ним отношение на форуме? Зачем же приписывать мне склонность к вандализму?

Я подумаю.
Точнее, уже думаю.
Но пока именно обилие тегов, многие из которых встречаются от одного до нескольких раз, мешает мне завершить процесс обдумывания.

У меня есть пунктик - на производительности и ресурсоемкости. Так что тянуть целиком РФ (и, кстати, не только) средствами API с применением фильтров на стороне сервера мне кажется слишком наглым с моей стороны.

это наше больное место, ты же не обижаешься, правда? :slight_smile:

форкни конвертер, он же открытый…

на самом деле, ты затеял доброе дело, только подал загадочно)) видишь же, обострение у нас) все нервные)

Мне вот лично иногда не хватает inclines, (мной же и проставленных).
Теги, встречающиеся разово, конечно не надо никак изображать. Нельзя угодить всем. Да и смысла нет. Если ты сделаешь все теги из мап_фичесов, это УЖЕ будет нечто! Вот, покрытием дорог у нас никто не занимается, хотя оно интересно за городом. Хотя бы через доп.свойства посмотреть (прямо на дороге наверно можно и не рисовать).

схема должна быть жёсткой. Другое дело, что пополняемой. Нельзя, уважаемый andriano, объять необъятное! Конвертер должен обрабатывать конечное число тегов, разумное. Не думаю, что мы, даже совместно, придумаем тут нечто новое.
Но и зажимать сообщество рисовать только известные теги, или их малое подмножество – тоже не дело. Да это и не нужно – каждый понимает, что программа при всём желании пользователя физически не сможет УДОБНО(!) отобразить ВСЕ теги, даже из списка мапфичесов.
Я понял, почему ты поднял этот вопрос – тебе навеяло вот этой фразой: “не рисуйте под рендерер!” :slight_smile: и ты решил всем нам помочь (себе в первую очередь) преодолеть это биение линейкой по рукам, и дать свободу творчества осмерам, реализации их тайных желаний)) – видеть на карте ВСЕ нарисованные фичи.
Это невозможно!))
У тебя будет yet another конвертер/навигационная программа, возможно более гибкая и тому подобное… Я не говорю “ты не сможешь”, нет, но моё мнение, что все программы уже написаны, все интерфейсы уже выдуманы.

Пиктограмма это стилизованная картинка (неожиданная смена темы)) для изображения сообщения или указания в условиях помех – в цейтноте, в плохой видимости, слышимости, стрессовом состоянии, и т.д. (ну и языковой барьер).
Так вот, программа-навигатор – это тоже самое. Чем больше мы впихиваем информации в экран, тем менее читаемой в условиях помех она оказывается.

Здесь есть минимум 3 препятствия:

  1. Интерпретируемый язык.
  2. Целевой формат (MP) точно так же непригоден для визуализатора, как и OSM. Т.е. снова требуется конвертер.
  3. Это уже мой личный недостаток - как только начинаю разбираться в каком-либо проекте, обнаруживаю в нем кучу несуразностей, после чего появляется желание переписать все с нуля.

Минуточку!
Давай четко разделим понятия: “обрабатывать конвертером” и “отображать визуализатором”.
Визуализатор, естественно, никак не может показать то, что пропущено конвертером, а вот конвертер вполне может (и должен!) обрабатывать то, что не будет показывать визуализатор.
Примеры:

  • данные по организации движения - используются для прокладки маршрута, но не рисуются на карте,
  • иерархическая структура объектов - используется для поиска, но сама структура не рисуется.
    И в принципе, мне кажется, к программе, в число функций которой входит построение картоподобного изображения на экране, нельзя относиться как к карте: у нее может быть масса других функций недоступных бумажной карте, как раз тех, ради которых эту программу и стоит писать. И все эти функции, как правило, требуют определенного гобъема данных, которые непосредственно не отображаются на экране.
    Но даже без дополнительных функций (типа поиска, маршрутизации и т.п.) у меня сейчас, например, при щелчке мышью по объекту выводится “простыня” с его свойствами. Я думаю, будет не очень здорово выглядеть, если просто вываливать на экран фрагмент XML-кода, соответствующий данному объекту. А это единственное, что можно сделать без его обработки. Зато есть гарантия, что пользователю будет доступно ВСЕ, что есть в OSM. :slight_smile:
    А чтобы привести выдачу к “человеческому” виду, конвертер должен это все как-то обрабатывать. При этом отчасти обработка может понадобиться именно чтобы не выводить лишнего - мне трудно представить ситуацию, при которой нужно выводить имя объекта на ВСЕХ языках. Значит, эти теги должны ВСЕ обрабатываться, а выводиться только международное название и название, соответствующее установленной на компьютере пользователя локали.
    Что же касается покрытия дорог, то почему бы не предусмореть режим отображения (да, в этом случае именно отображения), при котором вместо статуса дороги показывалось качество ее покрытия. На выбор пользователя - либо одно, либо другое.

А почему бы и не придумать?
Мне бы, например, показалось ОЧЕНЬ полезным наличие некоторого ПОПОЛНЯЕМОГО источника, который одновременно мог бы использоваться и в качестве справочника для картографа, и в качесте основы для программы -“теговалидатора” и для программы-конвертера. Собственно, размещенный здесь XML - как раз попытка создания первой итерации подобного источника (сейчас я его правлю ручками и по окончании собираюсь выложить следующую версию). Кстати, было бы желательно подключение его и к редактору - чтобы пользователь в основном не набирал теги вручную, а выбирал из списка.

Еще раз хочу обратить внимание на разницу между “обрабатывать” и “отображать”.
Кроме того, теги имеют две части: ключ и значение. Сейчас они как бы равнопроавны с точки зрения свободы выбора. А должны быть, на мой взгляд, совершенно неравноправны: употребление в ключе нестандартной комбинации должно рассматриваться как явление крайне нежелательное (именно поэтому я и привел в исходном посте лишь анализ по ключевой части), а значение - в некоторых случаях (как, например, с ключами name или description) просто обязано быть уникальным. Опять же, хотелось бы четко разделить ключи на 3 типа:

  1. С уникальными значениями.
  2. Допускающие как уникальные, так и предопределенные значения.
  3. Только с предопределенными значениями (как частный случай - единственное значение yes).

Я не разделяю эту точку зрения.

А разве я употребил слово “навигатор”?
Я пока еще вообще не решил, будет ли моя программа прокладывать маршрут или нет. Зато, например, она будет работать с базой КЛАДР. Это, кстати, отчасти ответ на вопрос - а все ли программы уже написаны. Я, например, не знаю ни одной, которая бы работала и с базой КЛАДР, и со спутниковыми снимками.

Richard Fairhurst с Вами бы не согласился:

Кхе… Меня всегда удивляют слова “обязаны”, “должны”… Кто, что и кому обязан в ОСМе? Надо мыслить реальными категориями. Если есть финансы - нанимайте команду картографов и они будут рисовать так, как Вам надо. Если нет финансов - ну тогда и выбора особого нету…

Ну конечно, никто никому ничем не обязал, каждый может лепить все что угодно:
http://www.openstreetmap.org/browse/way/40119721/history - линия электропередач, она же ручей
http://www.openstreetmap.org/browse/way/23768213/history - дом, он же дорога
http://www.openstreetmap.org/browse/way/40845859/ - математические выражения
http://www.openstreetmap.org/browse/way/9395279 - нормальный такой сервис. на 4 полосы.
Это так, навскидку по московскому региону.

Еще больная тема: обозначение дворовых проездов.
Вариант 1: highway=service + living_street=yes
Вариант 1а: вариация highway=service + livingstreet=yes - http://www.openstreetmap.org/browse/way/23242517
Вариант 2: просто service - http://www.openstreetmap.org/browse/way/47048088
Вариант 3: highway=service+maxspeed=20 http://www.openstreetmap.org/browse/way/43568579/history
Вариант 4: highway=living_street http://www.openstreetmap.org/browse/way/24491054
Вариант 5: highway=service + service=alley+living_street http://www.openstreetmap.org/browse/way/42205511
Вариант 6: highway=residential http://www.openstreetmap.org/browse/way/46037940

Уверяю, это далеко не конечный список вариантов обозначени одного и того же (дворового проезда), нарисованный вольными художниками “фо фан”.