addr:region и республики

freeExec · 2012-12-14 19:39:24

Ну обрабатывать это всё надо в любом случае, иначе сервис будет убогим, если он оперирует только нодами. И опять за запрос обычно задаётся bbox-ом и что придет в результате не важно, одна точка или много точек полигона.

AMDmi3 · 2012-12-14 20:24:31

freeExec wrote:

Ну обрабатывать это всё надо в любом случае, иначе сервис будет убогим, если он оперирует только нодами.

Нет, не надо. Много где полигоны нафиг не сдались.

freeExec wrote:

И опять за запрос обычно задаётся bbox-ом и что придет в результате не важно, одна точка или много точек полигона.

Ага, bbox на всю Россию.

andriano · 2012-12-15 07:50:25

freeExec wrote:

Тьфу, описался, разница между нодой в веем ?

В way нет координат. Есть только id узлов.
Т.е. добыть координаты для way существенно более ресурсоемко. Ориентировочно - на порядок.
При обработке значительных площадей это может играть существенную роль. (успеваем обработать за 3 часа или не успеваем за сутки)

AMDmi3 wrote:

Вея нет. Граница может быть веем, мультиполигоном, а может и вообще не быть. Всё это нужно по-разному обрабатывать, при том что обычно всё равно нужна точка.

Кстати - да.
По статистике у нас менее половины населенных пунктов имеют полигональную границу.

Last edited by andriano (2012-12-15 07:52:46)

andriano · 2012-12-15 07:59:22

freeExec wrote:

Ну обрабатывать это всё надо в любом случае, иначе сервис будет убогим, если он оперирует только нодами. И опять за запрос обычно задаётся bbox-ом и что придет в результате не важно, одна точка или много точек полигона.

Отчего же сразу - убогим.
Все определяется потребностями.
С точки зрения дорожного графа одна точка в центре крупной транспортной развязки намного лучше массива точек, средняя координата которых находится где-то в районе геометрического центра н/п.
Кроме того, мы ведь получаем из bbox'а не все подряд, а лишь то, что запросили. Точек типа place будет на несколько порядков меньше, чем нетегированных точек. И у нас либо существенно меньшая вероятность нарваться на таймаут, либо возможность получить данные за гораздо меньшее число запросов.

freeExec · 2012-12-15 08:10:41

andriano wrote:

добыть координаты для way существенно более ресурсоемко. Ориентировочно - на порядок.

Где же тут на порядок, в первый проход получаем все точки, во-второй вей-ид куда входят эти точки.
Но это ладно, я больше не понимаю, почему вы все ссылаетесь на трудность обработки. Если программа нормальная, а не фигня на которую и не стоит равняться, то она должна уметь обрабатывать и мультиполигоны и всё прочее. А если она это всё умеет, то к чему эти выкрутасы - мы будем обрабатывать только точку.

freeExec · 2012-12-15 08:16:55

andriano wrote:

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

1. твой дорожный граф тоже работает только с точками и линии ему чужды ?
2. тут утверждали что полигона НП без полигональных границ. Так вот, точечные центры в транспортной развязки вообще единицы.
3. еще раз, мои суждения про дублировании информации ни точке и полигоне, а не сам факт, что точка не нужна.

andriano · 2012-12-15 12:47:29

freeExec wrote:

andriano wrote:
добыть координаты для way существенно более ресурсоемко. Ориентировочно - на порядок.
Где же тут на порядок, в первый проход получаем все точки, во-второй вей-ид куда входят эти точки.
Но это ладно, я больше не понимаю, почему вы все ссылаетесь на трудность обработки. Если программа нормальная, а не фигня на которую и не стоит равняться, то она должна уметь обрабатывать и мультиполигоны и всё прочее. А если она это всё умеет, то к чему эти выкрутасы - мы будем обрабатывать только точку.

Программа должна уметь делать только то, что от нее требуется.
Если от нее не требуется работать с мультиполигонами, она этого уметь совершенно не должна.
Скажу более: ни одна программа в принципе не может уметь ВСЕГО. И разработчику (разумеется, если он хочет создать полезную программу в обозримые сроки) обязательно нужно решить, какие функции реализовывать, а от каких - отказываться.

andriano · 2012-12-15 12:54:04

freeExec wrote:

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

Из всего множества данных он выбирает линии с тегом highway и точки с тегом place.
Больше ему не нужно.
По крайней мере, пока.
Но, поверьте, это в масштабах local.osm и так довольно много.

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

Можно то же самое, только по-русски?

3. еще раз, мои суждения про дублировании информации ни точке и полигоне, а не сам факт, что точка не нужна.

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

Last edited by andriano (2012-12-15 12:55:39)

CupIvan · 2012-12-15 13:29:58

andriano wrote:

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

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

andriano · 2012-12-15 13:53:25

CupIvan wrote:

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

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

fserges · 2012-12-15 13:54:50

^^ Не забывайте про валидаторы. Они помогают проверить данные даже без избыточности в ОСМ.

andriano · 2012-12-15 14:00:14

fserges wrote:

^^ Не забывайте про валидаторы. Они помогают проверить данные даже без избыточности в ОСМ.

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

А при отсутствии избыточности ошибку в принципе невозможно детектировать. Вообще никакими средствами.

Строго говоря, при наличии полигональной границы любые теги на точке-центре избыточны. Даже place и name.

Last edited by andriano (2012-12-15 14:02:52)

CupIvan · 2012-12-15 14:30:15

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

AMDmi3 · 2012-12-15 14:30:59

freeExec wrote:

Где же тут на порядок, в первый проход получаем все точки, во-второй вей-ид куда входят эти точки.
Но это ладно, я больше не понимаю, почему вы все ссылаетесь на трудность обработки. Если программа нормальная, а не фигня на которую и не стоит равняться, то она должна уметь обрабатывать и мультиполигоны и всё прочее. А если она это всё умеет, то к чему эти выкрутасы - мы будем обрабатывать только точку.

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

AMDmi3 · 2012-12-15 14:32:53

CupIvan wrote:

валидаторы обычно сравнивают какое-то эталонное значение с тем что есть в базе, если там есть несколько значений, то да - покажет расхождение; саму избыточность то они не используют

В addresses.amdmi3.ru нет никаких эталонных значений, есличо.

CupIvan · 2012-12-15 14:36:44

AMDmi3 wrote:

В addresses.amdmi3.ru нет никаких эталонных значений, есличо.

офф: а у вас как-то использует я избыточность? вроде просто проверяются теги конкретного объекта, нет?

AMDmi3 · 2012-12-15 14:43:12

CupIvan wrote:

офф: а у вас как-то использует я избыточность? вроде просто проверяются теги конкретного объекта, нет?

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

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

Last edited by AMDmi3 (2012-12-15 18:00:40)

Sergey Astakhov · 2012-12-15 20:09:10

AMDmi3 wrote:

Для начала напиши "нормальную" программу которая по планете вытащит все НП не используя точек, за приемлемое время.

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

Обычно бывает нужно как то, так и другое, но с разными целями. Для рендеринга и поиска удобнее все комбинации name иметь именно на точках - так как именно они обычно рисуются или индексируются. А вот данные, используемые при проверки вхождения в полигон НП удобнее иметь именно на полигоне. Очевидно, что эти подмножества тегов будут пересекаться. Дублировать данные просто так никому не хочется, поэтому закономерно возникает вопрос: что проще алгоритмически - вытащить данные из точек НП при обработке полигона или вытащить данные с полигона при обработке точек НП?

Last edited by Sergey Astakhov (2012-12-15 20:10:28)

AMDmi3 · 2012-12-16 00:43:41

Sergey Astakhov wrote:

что проще алгоритмически - вытащить данные из точек НП при обработке полигона или вытащить данные с полигона при обработке точек НП?

Понятное дело, что первое.

andriano · 2012-12-16 09:21:21

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

IamCrazy · 2012-12-16 15:56:04

Ох, как понаобсуждали-то!
Ладно, я понял, просто добавляю полигоны, если их нет и меняю на точке addr:region на правильный.
Если кому будет нужно, тот сам продублирует теги с точки на полигон.

wowik · 2013-10-31 09:11:21

Изначальная тема замылилась и заглохла.
Напомню.

В addr:street пишем ровно так, как в name у соответствующей улицы.
В addr:district пишем ровно так, как в name у соответствующего района.

А вот в addr:region пишут вовсе не так, как в name у соответствующего региона.
С одной стороны, статусную часть иметь хорошо. Можно адрес на конверт строить не привлекая дополнительной информации. Это я понимаю и даже, в определенной мере, поддерживаю.
Но возникает два вопроса:
- почему же статусная часть строго сзади? Это бот втыкал? Так надо поправить. "республика Татарстан" правильнее, чем "Татарстан республика".
- чтобы найти этот регион по имени надо эту статусную часть найти и отрезать. Как-то это криво для символьной ссылки в базе данных.

Предлагаю таки писать в addr:region пишут ровно не так, как в name у соответствующего региона.
Тогда надо выбрать одно из решений:
1) писать везде о статусной частью
2) не писать статусную часть и республик

Внимание опрос: Куда плыть?

Last edited by wowik (2013-10-31 09:50:30)

wowik · 2013-10-31 09:50:45

Масштабы бедствия:
Список НП "Татарстан республика" => http://wowik.000space.com/places/ru-ta/

Кстати, топикстартер так Башкирию-то и не поправил http://wowik.000space.com/places/ru-ba/

IamCrazy · 2013-10-31 12:39:40

wowik wrote:

Кстати, топикстартер так Башкирию-то и не поправил http://wowik.000space.com/places/ru-ba/

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

wowik · 2013-10-31 13:06:30

Хорошо, тогда сносим "республика".
Для пробы у Башкортостана и Татарстана.

Announcement

#26 2012-12-14 19:39:24

Re: addr:region и республики

#27 2012-12-14 20:24:31

Re: addr:region и республики

#28 2012-12-15 07:50:25

Re: addr:region и республики

#29 2012-12-15 07:59:22

Re: addr:region и республики

#30 2012-12-15 08:10:41

Re: addr:region и республики

#31 2012-12-15 08:16:55

Re: addr:region и республики

#32 2012-12-15 12:47:29

Re: addr:region и республики

#33 2012-12-15 12:54:04

Re: addr:region и республики

#34 2012-12-15 13:29:58

Re: addr:region и республики

#35 2012-12-15 13:53:25

Re: addr:region и республики

#36 2012-12-15 13:54:50

Re: addr:region и республики

#37 2012-12-15 14:00:14

Re: addr:region и республики

#38 2012-12-15 14:30:15

Re: addr:region и республики

#39 2012-12-15 14:30:59

Re: addr:region и республики

#40 2012-12-15 14:32:53

Re: addr:region и республики

#41 2012-12-15 14:36:44

Re: addr:region и республики

#42 2012-12-15 14:43:12

Re: addr:region и республики

#43 2012-12-15 20:09:10

Re: addr:region и республики

#44 2012-12-16 00:43:41

Re: addr:region и республики

#45 2012-12-16 09:21:21

Re: addr:region и республики

#46 2012-12-16 15:56:04

Re: addr:region и республики

#47 2013-10-31 09:11:21

Re: addr:region и республики

#48 2013-10-31 09:50:45

Re: addr:region и республики

#49 2013-10-31 12:39:40

Re: addr:region и республики

#50 2013-10-31 13:06:30

Re: addr:region и республики

Board footer