Работа для бота (требуется помощь ботоводов)

wildMan · 2010-12-30 16:10:30

ikz wrote:

Статистика говорит, что type=building использовалось 317 раз. Подозреваю, что все 317 в Беларуси.

...@wildman:/home/pub/osm/dumps$ bzcat belarus.current.osm.bz2 | grep -c 'k="type" v="building"'
0

подозреваю что это таки ваши любители 3Д домиков

AMDmi3 · 2010-12-30 16:15:40

luch86 wrote:

associatedStreet и street отличаются, по сути, только названием. Какое из них удачнее — вполне очевидно.
collection=street — то же самое. Только этот collection предназначен также для рек/ручьёв, но для них уже есть отдельный тип waterway, а для железных дорог вообще есть утверждённое решение (route=railway). Поэтому collection, думаю, можно считать устаревшим.
address — он по улицам вроде не противоречит другим вариантам, а дополняет их адресными отношениями более высокого уровня (а это уже другая тема).

Ещё address есть и ещё что-то. Можно долго рассуждать что там от чего отличается - более удобными существующие отношения не станут и помойка никуда не денется.

luch86 wrote:

Писать же в роль номер дома смысла не вижу, проще использовать тег. Кстати, addr:housenumber в таком случае можно будет заменить на более стандартный ref, который и в редакторе отношений отображается.

А зря. В ref ничего стандартного нет, пишут туда что попало, к адресу он никакого отношения не имеет и с несколькими адресами работет никак. А вот номер дома в role решит кучу проблем типа необходимости заводить N+1 отношений на дом с N адресами, либо невозмоджности указать такой адрес вообще (с addr:housenumber), а также обеспечит какие-никакие наглядность и удобство редактирования даже с существующими инструментами.

luch86 wrote:

Что-то мешает их обновлять? Наверно только то, что многие не хотят этого делать.

Их обновлять мешает только их абсолютная ненужность.

luch86 wrote:

Где тут мусор? Мусор, если уж на то пошло — это addr:country и addr:region на каждом доме. Предусмотрено схемой Карлсруэ. Оно не обязательно, но некоторые участники воспринимают «не обязательно» как «желательно», и реально зачем-то ставят addr:country=RU на каждом доме... Вот что сносить надо!

По мне так addr:country полезнее отношений будет. Потому что хотя бы ни чему не противоречит и соответствует действительности.

luch86 wrote:

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

От полутора людей, "активно работающих" каждый со своим любимым типом отношения только в своём районе толку в них не прибавляется.

andriano · 2010-12-30 20:19:41

ikz wrote:

luch86 wrote:
Писать же в роль номер дома смысла не вижу, проще использовать тег.
Есть нн-ое кол-во домиков с тремя адресами. Комплекс+две улицы.
Как, и каким образом записать три разных номера в один тег? В какой тег? И где он должен находится?
А если все остальные домики имеют по два адреса? Комплекс+улица?
Для меня единственный способ прописать все адреса без огромного кол-ва вспомогательных отношений - номер в роли дома...

Проблема как раз в том, что запись в role "голого" номера дома без префикса исключает автоматизированную обработку такого отношения, т.е. превращает его по сути дела в мусор, который раздувает размер базы, но который невозможно использовать.
В этом случае отношения НАМНОГО лучше просто потому, что они однозначно описывают ситуацию.
И, кстати, здесь была предложена разумная альтернатива: role=<префиrc>:<номер дома>.
Она позволяет отказаться от "лишних" отношений и в то же время однозначна и допускает автоматизированную обработку.

Sergey Astakhov · 2010-12-30 22:24:22

andriano wrote:

Проблема как раз в том, что запись в role "голого" номера дома без префикса исключает автоматизированную обработку такого отношения

Не исключает. Просто для данного типа отношений не будет возможности расширять состав типов членов. Будет возможен только фиксированный, заранее известный, список. Ну и этот вариант ставит крест на некоторых типах обработки, но это ещё не конец света. Лучше, конечно, теги на саму связь, но это уже расширение модели OSM.

AMDmi3 · 2010-12-30 23:44:07

Согласен с Sergey Astakhov. На самом деле имеет смысл выпотрошить текущие отношения и посмотреть что используется кроме собственно house и street. Если ничего или почти ничего, можно будет обойтись и без hno:, и это будет хорошо, так как его как пить дать будут забывать ставить.

Alexandr Zeinalov · 2010-12-31 12:26:14

AMDmi3 wrote:

так как его как пить дать будут забывать ставить.

И это ещё одна причина даже не пытаться использовать такой кривой способ.

andriano · 2011-01-01 09:35:18

Sergey Astakhov wrote:

andriano wrote:
Проблема как раз в том, что запись в role "голого" номера дома без префикса исключает автоматизированную обработку такого отношения
Не исключает. Просто для данного типа отношений не будет возможности расширять состав типов членов. Будет возможен только фиксированный, заранее известный, список.

Ты сам себе противоречишь.
Либо возможность расширения списка членов есть, тогда предложенный формат - номер дома без префикса - не подходит, т.к. противоречит этому принципу.
Либо возможности расширения членов нет, но тогда и самого подобного члена в списке не заявлено, следовательно, он недопустим.
С какой стороны ни посмотри, такого вида role быть не должно.

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

andriano · 2011-01-01 09:41:45

AMDmi3 wrote:

Согласен с Sergey Astakhov. На самом деле имеет смысл выпотрошить текущие отношения и посмотреть что используется кроме собственно house и street. Если ничего или почти ничего, можно будет обойтись и без hno:, и это будет хорошо, так как его как пить дать будут забывать ставить.

Я против.
О внутреннем противоречии я уже написал выше.
В конце концов, если кто-то что-то будет забывать ставить (либо допускать любые другие ошибки) то это уже должно обрабатываться рендером или другой программой, использующей данные:
- либо такие случаи игнорируются,
- либо делаются попытки восстановления информации.
При этом возможность восстановления информации не безгранична. Если все номера будут без hno:, 2-5% не сможет быть восстановлено. Если же подавляющее число номеров будет по стандарту и лишь процентов 5 без hno:, то невосстановимыми окажется в 20 раз меньше адресов и т.о. потери будут реально меньше.

А тот факт, что в базу будут неизбежно вносить ошибки говорит как раз в пользу того, что нужно умышленно создавать избыточность для борьбы с этими ошибками. Т.е. ЗА введение hno:.

ikz · 2011-01-01 09:53:05

andriano, ну посмотри внимательно на отношение street. Там всего три возможных роли. street, house/address и associated. Все, что не эти четыре слова - будет считаться номером дома. Какие тут могут быть проблемы? Это во первых.
Во вторых, о расширении. Ничего не мешает внедрить другие роли в отношение. Просто чуть-чуть увеличится список зарезервированных слов.
Ну а в третьих, номера домов в адресах обычно содержат буквенно-цифровые комбинации не пересекающиеся со словами английского языка, что дает практически безграничные возможности для расширения отношения.

Т.е. нет никаких препятствий для использования role в качестве номера дома, кроме лености проектировщика/программиста.

liosha · 2011-01-01 10:15:10

ikz wrote:

Т.е. нет никаких препятствий для использования role в качестве номера дома, кроме лености проектировщика/программиста.

Препятствие есть одно: это неправильно
Точно так же, как неправильно, например, дому поставить тег "д10 к1"=yes

То есть технически это возможно, конечно, но нарушайт всю логическую структуру.
И поэтому не вариант

andriano · 2011-01-01 12:12:40

ikz wrote:

andriano, ну посмотри внимательно на отношение street. Там всего три возможных роли. street, house/address и associated. Все, что не эти четыре слова - будет считаться номером дома. Какие тут могут быть проблемы? Это во первых.

Проблема первая: по указанной Вами ссылке предусмотрено именно 4 зарезервированных слова и НЕ ПРЕДУСМОТРЕНО никаких номеров.

Во вторых, о расширении. Ничего не мешает внедрить другие роли в отношение. Просто чуть-чуть увеличится список зарезервированных слов.

То есть я пишу программу, которая обрабатывает эти 4 слова, а все остальное считает номером дома.
Потом кто-то (кстати, не обязательно согласуя это с другими - ведь номера дома в role сейчас проставляют безо всякого согласоваания, почему кому-то в дальнейшем не поступить так же безалаберно?) добавил что-то другое, и моя программа стала работать неправильно.

Есть один общий принцип: если мы имеем дело с РАСШИРЯЕМЫМ форматом, совершенно необходимо уметь отличать те свойства, которые программе известны, от тех, которые - нет. И в этом смысле правило "все, что не подходит к предопределенным 4-м типам, является пятым" категорически неприменимо. Такое допустимо использовать лишь в форматах, которые заведомо не подразумевают никакого расширения.

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

Давайте исходить из того, что адреса (или названия - почему нет?) домов могут включать любые алфавитно-цифровые символы. Это требование прямо вытекает из отсутствия единой всемирной системы нумерации домов.

Т.е. нет никаких препятствий для использования role в качестве номера дома, кроме лености проектировщика/программиста.

Если кто-то их не видит (или в упор не желает замечать, что они есть), это не значит, что их нет.

Я сейчас ввел у себя правило, по которому <одна или несколько цифр>[<буква|корп.|Корп.|кор.|Кор.|к.|К.>[<одна или несколько цифр>]] трактуется как номер дома. Но, увы, не все номера подходят под этот шаблон, например, в базе присутствует 30-30а. Ну и больше всего меня смущает ненадежность такого решения.

Кстати, в условиях, когда данные в базу вносит множество разных людей с различным уровнем подготовки, нельзя не учитывать и требование защиты от ошибок.
Например, в предлагаемом варианте "role=sstreet" должно быть трактовано как номер дома, что, естественно, неправильно.
Обрабатывающая программа должна иметь возможность отличать валидные данные от ошибочных или нераспознанных по формальным признакам.

Zkir · 2011-01-01 14:25:34

Andriano дело говорит. В правильной схеме заранее известно, что некоторое поле - номер дома.

Last edited by Zkir (2011-01-01 14:25:57)

dimuzz · 2011-01-20 07:21:37

...а тем временем xybot уже взялся за дело:
http://www.openstreetmap.org/browse/changeset/7024797

Hind · 2011-01-20 09:15:44

Всё правильно сделал. Во всяком случае, я пишу именно "221Б с1 к2" :3

AlRight · 2011-01-20 09:48:54

Hind wrote:

Всё правильно сделал. Во всяком случае, я пишу именно "221Б с1 к2" :3

хм .. сомнительно. Если посмотреть историю:

http://www.openstreetmap.org/browse/way … 29/history
было до бота

addr:housenumber = 12/12к1
addr:housenumber2 = 12/12к1
addr:street = Новомарьинская улица
addr:street2 = Мячковский бульвар

Из одной из более старых версий

addr:housenumber = 12; 12к1
addr:street = Новомарьинская ул.; Мячковский бул.

можно с большой "степенью верности" быть уверенным, что до дроби перед правкой был адрес по одной улице, после дроби - по другой
После бота стало

addr:housenumber = 12/12 к1
addr:housenumber2 = 12/12к1
addr:postcode = 109652
addr:street = Новомарьинская улица
addr:street2 = Мячковский бульвар

Т.е., во первых, в "дополнительном" адресном теге не внесены сообразные изменения, во вторых написание стало неоднозначно читаться. Ведь, смотрите - в адресе другого дома:
http://www.openstreetmap.org/browse/way … 32/history
было до бота

addr:housenumber = 26/1С2
addr:street = Софийская набережная

после бота стало

addr:housenumber = 26/1 с2
addr:street = Софийская набережная

появился пробел перед "с2" и выполнено "С"->"с"

Бот не учитывает наличие "угловых" и т.п. адресов.
Вредная правка, имхо.

Last edited by AlRight (2011-01-20 09:51:47)

Alexandr Zeinalov · 2011-01-20 09:49:21

Мне интересно: xybot сам догадался это сделать или его кто-то из "наших" попросил?

dkiselev · 2011-01-20 09:58:36

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

Hind · 2011-01-20 10:23:31

Вообще-то это бот тупой, а не схема, к которой, кстати, пришли голосованием.

TarzanASG · 2011-01-20 15:32:44

Конечно, из наших. Я подумал, что раз никто не против изменений, то не важно кто их сделает и поскольку меня тут на форуме замучили требованиями сделать то, что я сделать не могу, я и обратился к Xylome. И он глупостями не занимался. Я сразу показал стандарт и Xylome всё сделал по стандарту. Вот пакеты правок:
http://www.openstreetmap.org/browse/changeset/7024797
http://www.openstreetmap.org/browse/changeset/7027691
http://www.openstreetmap.org/browse/changeset/7028257
http://www.openstreetmap.org/browse/changeset/7029630

http://www.openstreetmap.org/browse/changeset/7022960
http://www.openstreetmap.org/browse/changeset/7021015

Кстати, если есть какие-то замечания, то давайте их сначала оговорим на http://wiki.openstreetmap.org/wiki/RU:Key:addr

Last edited by TarzanASG (2011-01-20 15:42:32)

Hind · 2011-01-20 15:51:06

Уже написали - отделил букву С от номера дома как строение, не обрабатывает addr:housenumber2...n

TarzanASG · 2011-01-20 15:54:41

А строение согласно стандарту и должно отделяться, так что всё правильно.

А зачем вообще нужен addr:housenumber2? Это где-нибудь документировано?

liosha · 2011-01-20 15:56:01

TarzanASG wrote:

А строение согласно стандарту и должно отделяться, так что всё правильно

Имеется в виду дом номер типа 21С.

gps-Max · 2011-01-20 16:15:19

TarzanASG wrote:

и поскольку меня тут на форуме замучили требованиями сделать то, что я сделать не могу, я и обратился к Xylome. И он глупостями не занимался.

Одним махом вы назвали глупцами многих хороших людей, пытавшихся вам помочь. Напрасно.

AlRight · 2011-01-20 16:18:58

TarzanASG wrote:

Я сразу показал стандарт и Xylome всё сделал по стандарту.
...
Кстати, если есть какие-то замечания, то давайте их сначала оговорим на http://wiki.openstreetmap.org/wiki/RU:Key:addr

Вы уверены, что это _стандарт_? У него номер есть какой-нибудь, он зарегистрирован в гос. реестре (хз что еще должно быть у документа, именуемого "СТАНДАРТ").
Это, вроде бы, "соглашение". Не более того. Не находите?
Причём, всего лишь переводная страница.
Не факт, что схема, названная вами "стандартом" охватывает все возможные случаи.
В который раз уже вы что-то предпринимаете, что потом выглядит или странно, или смешно или приносит вред. Попробуйте сначала обсуждать, а потом делать.

Last edited by AlRight (2011-01-20 16:27:13)

TarzanASG · 2011-01-20 16:21:35

gps-Max, не придумывайте того, чего нет. Я никого глупцами не называл.

AlRight, пожалуйста, не придирайтесь к словам.

Announcement

#251 2010-12-30 16:10:30

Re: Работа для бота (требуется помощь ботоводов)

#252 2010-12-30 16:15:40

Re: Работа для бота (требуется помощь ботоводов)

#253 2010-12-30 20:19:41

Re: Работа для бота (требуется помощь ботоводов)

#254 2010-12-30 22:24:22

Re: Работа для бота (требуется помощь ботоводов)

#255 2010-12-30 23:44:07

Re: Работа для бота (требуется помощь ботоводов)

#256 2010-12-31 12:26:14

Re: Работа для бота (требуется помощь ботоводов)

#257 2011-01-01 09:35:18

Re: Работа для бота (требуется помощь ботоводов)

#258 2011-01-01 09:41:45

Re: Работа для бота (требуется помощь ботоводов)

#259 2011-01-01 09:53:05

Re: Работа для бота (требуется помощь ботоводов)

#260 2011-01-01 10:15:10

Re: Работа для бота (требуется помощь ботоводов)

#261 2011-01-01 12:12:40

Re: Работа для бота (требуется помощь ботоводов)

#262 2011-01-01 14:25:34

Re: Работа для бота (требуется помощь ботоводов)

#263 2011-01-20 07:21:37

Re: Работа для бота (требуется помощь ботоводов)

#264 2011-01-20 09:15:44

Re: Работа для бота (требуется помощь ботоводов)

#265 2011-01-20 09:48:54

Re: Работа для бота (требуется помощь ботоводов)

#266 2011-01-20 09:49:21

Re: Работа для бота (требуется помощь ботоводов)

#267 2011-01-20 09:58:36

Re: Работа для бота (требуется помощь ботоводов)

#268 2011-01-20 10:23:31

Re: Работа для бота (требуется помощь ботоводов)

#269 2011-01-20 15:32:44

Re: Работа для бота (требуется помощь ботоводов)

#270 2011-01-20 15:51:06

Re: Работа для бота (требуется помощь ботоводов)

#271 2011-01-20 15:54:41

Re: Работа для бота (требуется помощь ботоводов)

#272 2011-01-20 15:56:01

Re: Работа для бота (требуется помощь ботоводов)

#273 2011-01-20 16:15:19

Re: Работа для бота (требуется помощь ботоводов)

#274 2011-01-20 16:18:58

Re: Работа для бота (требуется помощь ботоводов)

#275 2011-01-20 16:21:35

Re: Работа для бота (требуется помощь ботоводов)

Board footer