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

andriano · 2010-12-29 16:41:05

AMDmi3 wrote:

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

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

Сооружайте пропозал с houseno:номердома в role, принимайте, и может дело сдвинется, наконец, с мёртвой точки. А то что есть, трогать нет никакого смысла.

Если то, что есть может быть распознано, трогать действительно не следует.
А если то, что не только нестандартно, но еще и непродуманно, и, как следствие, находится в виде непригодном для обработки, - это нужно менять. Без вариантов. Пусть даже способом нестандартным, но распознаваемым. Кстати, "hno:%number" по крайней мере распознаваем. А все остальное нужно либо исправлять, либо сносить.

andriano · 2010-12-29 16:47:39

osmisto wrote:

"Вменяемый" это как? По-моему, очень субъективная оценка. А у программистов она всё строже и строже с каждым годом опыта. Вон как они смотрят на свои(!) старые программки и всё рвутся их переписать: "Кто же так делает? Это же каша, не разобраться. не поддерживаемо. не расширяемо. где модульность? где объекты? ..."

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

AMDmi3 · 2010-12-29 17:09:44

andriano wrote:

Кстати, "hno:%number" по крайней мере распознаваем. А все остальное нужно либо исправлять, либо сносить.

Чтобы исправлять надо сначала нужно принять отношение с hno:%number, добавить его поддержку хотя бы куда-нибудь, а потом разом поменять на него всё, включая карлсруэ. А насчет сносить я согласен, потому что активно добавляется и правится карлсруэ, а в горстке отношений наблюдается всё больший bitrot, поэтом правильнее будет посносить их чтобы не мешались, а нормальные отношения построить потом из карлсруэ, но мне почему-то кажется что найдётся много недовольных.

Zkir · 2010-12-29 17:13:27

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

AMDmi3 · 2010-12-29 17:38:47

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

andriano · 2010-12-29 17:50:15

AMDmi3 wrote:

Чтобы исправлять надо сначала нужно принять отношение с hno:%number, добавить его поддержку хотя бы куда-нибудь, а потом разом поменять на него всё, включая карлсруэ.

Не суть важно, что останется в итоге, главное - чтобы в базе были данные, которые ВОЗМОЖНО использовать. Либо конвертить к другому стандарту, когда его примут. Пока же "role=123а" - это мусор, который невозможно прочитать. В отличие от, скажем, "role=hno:123а", который можно и прочитать, и обработать, и конвертировать, буде такая необходимость объявится.
По поводу поддержи: вот я сейчас перед тем, как решить, что следует поддерживать, а что - нет, подвожу статистику по частоте использования различных конструкций в реальных данных.
И, кстати, обратил внимание на "role=123а" именно потому, что еще несколько месяцев назад такого безобразия не было. И тут вопрос простой: либо править РУЧКАМИ, либо сносить, т.к. такая форма записи для автоматизированной правки непригодна.
Поэтому лучше поправить прямо сейчас, чтобы мусор типа "role=123а" не накапливался (повторяю - исправлять это можно только ручками).

AMDmi3 · 2010-12-29 18:20:44

Да всё оно правится автоматизированно. Только править не во что и незачем. А вот снести чтобы глаза не мозолило было бы неплохо.

luch86 · 2010-12-29 20:08:45

AMDmi3 wrote:

А насчет сносить я согласен, потому что активно добавляется и правится карлсруэ, а в горстке отношений наблюдается всё больший bitrot, поэтом правильнее будет посносить их чтобы не мешались, а нормальные отношения построить потом из карлсруэ

Кому и чем мешают существующие адресные отношения (любых типов), и чем они ненормальные? И предложите другой способ дать в вики (или в другом месте) одну ссылку на всю улицу с домами. Или просто визуально выделить все дома, относящиеся к улице. Это то, для чего как минимум уже сейчас можно использовать адресные отношения. А уж если всего лишь доработать поисковые системы, то и вовсе можно будет начать отказываться от addr:street.
К тому же, снося существующие отношения, вы резко снижаете шанс на их принятие в будущем. Они станут восприниматься как провалившийся эксперимент. И легче принимать то, к чему уже привыкли. А если потом ботом создать отношения сразу для всех улиц, многие участники будут просто не готовы сразу работать с этими отношениями.

AMDmi3 · 2010-12-29 21:54:58

luch86 wrote:

Кому и чем мешают существующие адресные отношения (любых типов), и чем они ненормальные?

Тем и ненормальные, что "любых типов". Их там штуки 4 + огромное количество химер, при этом нормального нет. Это всё никем не поддерживается и не обновляется. Актуальные данные - в addr:*, а то, что в отношениях как минимум их дублирует, как максимум - устарело.

luch86 wrote:

И предложите другой способ дать в вики (или в другом месте) одну ссылку на всю улицу с домами. Или просто визуально выделить все дома, относящиеся к улице.

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

luch86 wrote:

Это то, для чего как минимум уже сейчас можно использовать адресные отношения. А уж если всего лишь доработать поисковые системы, то и вовсе можно будет начать отказываться от addr:street.

Уже сказано сто раз что именно нужно чтобы отказаться от addr:street, однако ж что-то никто не шевелится, при этом еще и за существующую помойку держится.

luch86 wrote:

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

Они такое и есть.

luch86 wrote:

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

Пока есть карлсруэ никто не будет готов работать с отношениями.

luch86 · 2010-12-29 23:04:01

AMDmi3 wrote:

Тем и ненормальные, что "любых типов". Их там штуки 4 + огромное количество химер, при этом нормального нет.

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

Для домов все эти отношения предусматривают 2 роли — house и address. Какая из них лучше — можно решить голосованием.

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

AMDmi3 wrote:

Это всё никем не поддерживается и не обновляется. Актуальные данные - в addr:*, а то, что в отношениях как минимум их дублирует, как максимум - устарело.

Что-то мешает их обновлять? Наверно только то, что многие не хотят этого делать. Одни панически боятся отношений (даже мультиполигонов), другим очень нравится схема Карлсруэ (с дублированием всей информации на всех домах), третим нравится сложная белорусская адресация.
А можно было б договориться и принять отношение street как самую простую замену существующей схеме. Тем более что сама схема Карсруэ допускает использование отношений. Как associatedStreet, так и street.

AMDmi3 wrote:

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

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

AMDmi3 wrote:

Уже сказано сто раз что именно нужно чтобы отказаться от addr:street, однако ж что-то никто не шевелится, при этом еще и за существующую помойку держится.

Тут риторический вопрос, почему пропозал больше года заброшен, и никто не стремится его поднять. А «помойка» легко исправляется, если будет принято единое решение.

AMDmi3 wrote:

Пока есть карлсруэ никто не будет готов работать с отношениями.

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

liosha · 2010-12-30 06:19:29

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

ikz · 2010-12-30 07:14:26

luch86 wrote:

Писать же в роль номер дома смысла не вижу, проще использовать тег.

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

Для меня единственный способ прописать все адреса без огромного кол-ва вспомогательных отношений - номер в роли дома...

Alexandr Zeinalov · 2010-12-30 07:21:42

ikz wrote:

Для меня единственный способ прописать все адреса без огромного кол-ва вспомогательных отношений - номер в роли дома...

Ну сколько можно говорить - это не единственный способ...

ikz · 2010-12-30 07:38:00

Alexandr Zeinalov wrote:

Ну сколько можно говорить - это не единственный способ...

Ну коли так, прошу привести пример, как можно на одном строении прописать три адреса без применения вспомогательных отношений.
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87

wildMan · 2010-12-30 10:11:26

ikz wrote:

Alexandr Zeinalov wrote:
Ну сколько можно говорить - это не единственный способ...
Ну коли так, прошу привести пример, как можно на одном строении прописать три адреса без применения вспомогательных отношений.
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87

поставить три точки на которых оставить только addr:*
на контуре снести все адресные данные, оставив только building=*

ikz · 2010-12-30 10:21:10

wildMan wrote:

ikz wrote:
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87
поставить три точки на которых оставить только addr:*
на контуре снести все адресные данные, оставив только building=*

В таком случае эти адреса не попадут на любые пои в этом здании. При прорисовке подъездов (как говорит liosha они сконвертируются в EntryPoint) они тоже останутся без адресов.
Следующий.

AlRight · 2010-12-30 10:26:00

ikz wrote:

wildMan wrote:
ikz wrote:
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87
поставить три точки на которых оставить только addr:*
на контуре снести все адресные данные, оставив только building=*
В таком случае эти адреса не попадут на любые пои в этом здании. При прорисовке подъездов (как говорит liosha они сконвертируются в EntryPoint) они тоже останутся без адресов.
Следующий.

Смею предположить, что проблема "мультиадресности" - это проблема (большинства) конечного софта и (или) конвертеров для него. А не ОСМ.
Вариантов реализации в ОСМ - множество. А применения этому нет (мне известен только ДубльГИС, не нуждающийся в ОСМ)

Last edited by AlRight (2010-12-30 10:34:24)

ikz · 2010-12-30 10:36:30

AlRight wrote:

ikz wrote:
В таком случае эти адреса не попадут на любые пои в этом здании. При прорисовке подъездов (как говорит liosha они сконвертируются в EntryPoint) они тоже останутся без адресов.
Следующий.
Смею предположить, что это проблема конечного софта и (или) конвертеров для него. А не ОСМ

Гм. А смысла рассматривать отдельно ОСМ, отдельно конвертеры нет никакого....
Конвертеры (и конечный софт через них) - часть ОСМ, без него не существующая...
Так что это как раз проблема ОСМ: представление данных в таком виде, чтобы конечный софт мог эту информацию использовать по максимуму. Перенос адресной информации с полигона на точки усложняет использование данных - софту придется дополнительно искать внутри полигона (возможные) точки с адресной информацией.

fserges · 2010-12-30 10:53:03

Меня этот вопрос тоже волнует ... В центре Санкт-Петербурга много зданий имеют 2-3 и даже 4 адреса. В кадастре идёт один номер, но на табличках на домах проставлены несколько. Хочется действительно быть уверенным, что проставленная адресная информация будет понята внешними программами а не только лежать мёртвым грузом в БД OSM.

ikz · 2010-12-30 11:02:25

fserges wrote:

Меня этот вопрос тоже волнует ... В центре Санкт-Петербурга много зданий имеют 2-3 и даже 4 адреса. В кадастре идёт один номер, но на табличках на домах проставлены несколько. Хочется действительно быть уверенным, что проставленная адресная информация будет понята внешними программами а не только лежать мёртвым грузом в БД OSM.

Пока только один реально работающий способ.
addr:housenumber=*+(addr:street=*|relation street:name=*|relation associatedStreet:name=*)
Естественно о двух-трех-четырех адресах говорить не приходится.
С другой стороны, как я понимаю, формат mp тоже не поддерживает несколько адресов на полигоне.

wildMan · 2010-12-30 12:26:53

ikz wrote:

wildMan wrote:
ikz wrote:
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87
поставить три точки на которых оставить только addr:*
на контуре снести все адресные данные, оставив только building=*
В таком случае эти адреса не попадут на любые пои в этом здании. При прорисовке подъездов (как говорит liosha они сконвертируются в EntryPoint) они тоже останутся без адресов.
Следующий.

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

но для хоть сколько нибудь серьёзного использования, имхо, наиболее вменяемый вариант:
- по точке с addr:* на каждый адрес (без building. только с addr)
- релейшен type=building в который с ролью building входит контур (или несколько для сложных случаев), с ролями address включены точки из пункта 1, с пустыми ролями - все ПОИ и т.д.

это легко суппортится конвертерами (в случае *.mp: при нахождении релейшена - продублировать все объекты кроме building и address и копиям проставить по уникальному адресу) и без излишней сложности для заполнения ручками

Last edited by wildMan (2010-12-30 12:27:25)

ikz · 2010-12-30 14:52:59

wildMan wrote:

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

Уж не надо своих собеседников считать такого уровня... Хоть пои и ентрансы не упоминаются, но, обычно, их присутствие подразумевается...

но для хоть сколько нибудь серьёзного использования, имхо, наиболее вменяемый вариант:
- по точке с addr:* на каждый адрес (без building. только с addr)
- релейшен type=building в который с ролью building входит контур (или несколько для сложных случаев), с ролями address включены точки из пункта 1, с пустыми ролями - все ПОИ и т.д.
это легко суппортится конвертерами (в случае *.mp: при нахождении релейшена - продублировать все объекты кроме building и address и копиям проставить по уникальному адресу) и без излишней сложности для заполнения ручками

Нет такого отношения. http://wiki.openstreetmap.org/wiki/Relation:building
И я очень сомневаюсь, что кто-то сделает поддержку такого отношения.

wildMan · 2010-12-30 15:03:35

ikz wrote:

Уж не надо своих собеседников считать такого уровня... Хоть пои и ентрансы не упоминаются, но, обычно, их присутствие подразумевается...

...@wildman:/home/pub/osm/dumps$ bzcat belarus.current.osm.bz2 | grep -c 'k="building"'
124997
...@wildman:/home/pub/osm/dumps$ bzcat belarus.current.osm.bz2 | grep -c 'entrance'
224

при таком результате слова «обычно подразумевается» имхо неуместны

ikz wrote:

Нет такого отношения. http://wiki.openstreetmap.org/wiki/Relation:building

можете посмотреть на статистику по тегам. и отфильтровать каких ещё отношений нет в вики. не говоря уж о тегах

ikz wrote:

И я очень сомневаюсь, что кто-то сделает поддержку такого отношения.

я сделал. и использую. никаких трудностей. на 2 часа кодинга.

dkiselev · 2010-12-30 15:23:19

ikz wrote:

Alexandr Zeinalov wrote:
Ну сколько можно говорить - это не единственный способ...
Ну коли так, прошу привести пример, как можно на одном строении прописать три адреса без применения вспомогательных отношений.
Новый город, 7/06; пр. Дружбы народов, 6; пр. Московский, 87

Ну либо 3 точки, (то что адреса не попадут на пои - скорее вопррос к алгоритму расставления адресов на пои)
либо, как вариант http://wiki.openstreetmap.org/wiki/AddrN: (я правда его так и не дописал, т.к. счел что с точками проще и удобнее)

Last edited by dkiselev (2010-12-30 15:23:51)

ikz · 2010-12-30 15:23:39

wildMan wrote:

ikz wrote:
Уж не надо своих собеседников считать такого уровня... Хоть пои и ентрансы не упоминаются, но, обычно, их присутствие подразумевается...
...@wildman:/home/pub/osm/dumps$ bzcat belarus.current.osm.bz2 | grep -c 'k="building"'
124997
...@wildman:/home/pub/osm/dumps$ bzcat belarus.current.osm.bz2 | grep -c 'entrance'
224
при таком результате слова «обычно подразумевается» имхо неуместны

Ну у меня тоже только 4982 vs 719. Но я сам недавно стал расставлять подъезды... И их с каждым днем больше и больше.
Так что "подразумевается".

P.S. А что же не подсчитал кол-во пои внутри строений?

Update:

можете посмотреть на статистику по тегам. и отфильтровать каких ещё отношений нет в вики. не говоря уж о тегах

Статистика говорит, что type=building использовалось 317 раз. Подозреваю, что все 317 в Беларуси.
Я тоже могу придумать релейшены и теги. И использовать, и гордится этим. Кстати и придумывал, и даже использовал... Но... Пока я один их использую, им цена в минус одну копейку. Т.е. нафиг не надо.

Last edited by ikz (2010-12-30 15:33:00)

Announcement

#226 2010-12-29 16:41:05

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

#227 2010-12-29 16:47:39

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

#228 2010-12-29 17:09:44

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

#229 2010-12-29 17:13:27

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

#230 2010-12-29 17:38:47

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

#231 2010-12-29 17:50:15

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

#232 2010-12-29 18:20:44

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

#233 2010-12-29 20:08:45

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

#234 2010-12-29 21:54:58

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

#235 2010-12-29 23:04:01

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

#236 2010-12-30 06:19:29

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

#237 2010-12-30 07:14:26

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

#238 2010-12-30 07:21:42

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

#239 2010-12-30 07:38:00

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

#240 2010-12-30 10:11:26

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

#241 2010-12-30 10:21:10

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

#242 2010-12-30 10:26:00

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

#243 2010-12-30 10:36:30

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

#244 2010-12-30 10:53:03

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

#245 2010-12-30 11:02:25

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

#246 2010-12-30 12:26:53

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

#247 2010-12-30 14:52:59

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

#248 2010-12-30 15:03:35

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

#249 2010-12-30 15:23:19

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

#250 2010-12-30 15:23:39

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

Board footer