Надо ли рисовать точку place внутри города с границей?

Zkir · 2011-07-06T16:44:10.000Z

fserges, еще раз повторю, это ни разу не проблема схемы. Ничего не мешает нагородить три вея с shop=convinience вокруг одного и того же объекта плюс точку внутри.

//Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск?
Это весьма интересный вопрос. Скорее всего Кировск обводили до тех пор, пока граница не заработала. У меня сейчас обрабатывается только один вариант - от Dinamik. (http://www.openstreetmap.org/browse/way/116121865) Я пока не готов ответить почему (интернет дохлый).

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

Zkir · 2011-07-06T16:51:15.000Z

Ну вот, кажется нашел.
отношение 1430461 не обрабатывается никак:

; ERROR: Multipolygon’s RelID=1430461 part WayID=103783335 is not closed
; ERROR: Multipolygon’s RelID=1430461 part WayID=103783370 is not closed

Вей 103783370 тоже не обрабатывается никак:
; ERROR: Area WayID=103783370 is not closed at (59.905018,30.9999802)

Как всегда виновата не схема, а чьи-то кривые ручки

dr_mx · 2011-07-06T17:14:01.000Z

Только звери не могут понять что я не революцию затеял.

gps-Max · 2011-07-06T19:26:45.000Z

fserges:

Если для навигатора то точка должна быть на дороге.

~~Не рисуем для навигатора!11~~ На центральной площади оптимально, обычно она так или иначе есть.

akks · 2013-02-13T08:53:55.000Z

Ну так как у нас, osm2mp по прежнему использует addr:… исключительно с полигона?
(Мне некогда было в перловых библиотеках копаться)

liosha · 2013-02-13T09:46:03.000Z

akks:

Ну так как у нас, osm2mp по прежнему использует addr:… исключительно с полигона?

Да, разумеется

esaulenka · 2013-02-13T10:12:17.000Z

liosha:

Да, разумеется

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

Тогда встречный вопрос: кому нужна точка? И какие тэги там нужны, кроме place и name?

Zkir · 2013-02-13T10:16:05.000Z

Тогда встречный вопрос: кому нужна точка?

Тем, кто рисует город точкой с надписью. Собственно, это все пользователи конверсии в польский формат.

И какие тэги там нужны, кроме place и name?

population, в основном

chnav · 2013-02-13T10:25:08.000Z

wowik:

VikDD:

chnav:

А что если полигоны place постепенно заменить на relation type=admin_boundary в случае если административные границы известны, либо type=place если нарисованы на глазок ? Соответственно атрибуты будут браться из точечного admin_centre, и не будет дублирования информации.

Тогда не на точку, а на отношение надо вешать все теги.

Вот кол, вот мочало…
Точку нп любой новичок нарисует и поправит.
Всё просто и наглядно.
Проще редактировать, проще использовать.

В принципе это не единственный случай, когда один объект может быть как точкой (удобной для внесения данных), так и полигоном. Если boundary не очень подходит по политическим мотивам, можно изобрести универсальное отношение.

Например имеется существующая точка place, locality и пр. Продвинутый пользователь может нарисовать контур, можно без тегов, и создать отношение
type=outline|contour
members:
point|centre|label=[node]
outer=[way]

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

Baz310 · 2013-02-13T11:08:54.000Z

akks:

Так как оно, теги-то по прежнему только с place кушает? (код osm2mp же чуть ли не каждый день исправляется, т.е. жив)) )
Ответ в тему http://forum.openstreetmap.org/viewtopic.php?id=12892 , пжалста

Судя из моих наблюдений, конвертер osm2mp “кушает” теги как с полигона, так и с точки. По отображению н.п. в поиске навигатора, на картах с http://navitel.osm.rambler.ru, мы имеем 3 варианта:

если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. корректно отображается в поиске, с указанием соответствующей информации
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще или частично, н.п. задваивается в поиске
если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.1

Далее, я не знаю, какой конвертер используют конвертированные из ОСМ карты с проекта http://www.megamaps.org/, но там картина следующая

если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. не отображается в поиске
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще, н.п. корректно отображается в поиске, с указанием соответствующей информации
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют частично, н.п. задваивается в поиске
если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.2

akks · 2013-02-13T11:49:54.000Z

Спасибо за систематизацию. Вот же ~~#@$@$~~ безобразие…

dimonster · 2013-02-13T12:52:57.000Z

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

IMHO, проще “как есть”. Точка и полигон с одинаковыми тегами. Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).

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

если теги addr:district, addr:region и т.п.,

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

liosha · 2013-02-13T12:54:47.000Z

dimonster:

Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).

Никакого

wowik · 2013-02-13T13:13:03.000Z

dimonster:

то не вижу смысла в addr:**** на полигоне и точке населённых пунктов

А вы выгляните за рамки мапанья под лёшин конвертер.
Или на секундочку представьте, что отношение границы нечаянно поломали. Сразу область останется без НП?

Baz310 · 2013-02-13T13:58:39.000Z

dimonster:

Впрочем, поскольку лёшин конвертер уже умеет автоматически привязывать населённые пункты к областям и районам просто по факту нахождения в границах области / района, то не вижу смысла в addr:**** на полигоне и точке населённых пунктов. Лишь бы границы были правильно обозначены.

Из практики. Возьмем сконвертированную вчера карту Челябинской области с проекта osm.rambler.ru. Границы районов там обозначены, а н.п., которые не имеют тегов addr, болтаются как … в проруби, имея только привязку к области. Опять же, неоднократно сталкивался с тем, что, в той же области, имеется несколько одноименных н.п. До добавления тега addr:district они, зачастую, видны, в поиске, как один н.п., а если не один, то встает проблема выбора нужного

dimonster:

ну логично же, что если и точка, и полигон обозначают один и тот же населённый пункт, то addr:**** у них должны совпадать.

Это в идеале, а на практике я встречал не совпадающие значения addr:district= и place=. Да и в привязке по территориальному принципу не все правильно. Например, Бижеляк (http://www.openstreetmap.org/?lat=55.594997&lon=60.728809&zoom=18&layers=M) поиск , на openstreets.org, выдает принадлежность поселка к Аргаяшскому району, а на самом деле он относится к Озерскому городскому округу, о чем есть соответствующее упоминание в уставе округа

dimonster · 2013-02-13T14:19:08.000Z

А вы выгляните за рамки мапанья под лёшин конвертер.

Ну, выглянул. Вот, к примеру, конвертер для navit требует теги is_in, которые вроде уже нигде не используются. И что? Мне теперь везде is_in вместо addr:region, addr:district писать? Да ещё и на двух языках…

представьте, что отношение границы нечаянно поломали.

Поломали - надо чинить. А не “представьте, что поломали, представьте, что удалили…”. Представьте, что у вас резинка в трусах завтра лопнет - подвяжитесь заранее шнурком

Возьмем сконвертированную вчера карту

А это уже косяки конвертера. Скорее всего, там старая версия конвертера. Возьмите другую карту. Вон, у меня (http://www.dimonster.w.pw/) населённые пункты чётко раскиданы по районам.

Это в идеале, а на практике я встречал не совпадающие значения addr:district= и place=.

Да мало ли что может встретиться в карте, которую может править любой кому не лень. Не совпадает, не соответствует - ошибка. Исправляй.
Вон по Украине после старого импорта есть куча посёлков, где есть теги place и name на точке, а на полигоне ничего нет, кроме boundary.

поиск выдает принадлежность поселка к Аргаяшскому району, а на самом деле он относится к Озерскому городскому округу,

А что, границами это никак не обозначить?

Baz310 · 2013-02-13T15:06:48.000Z

dimonster:

А что, границами это никак не обозначить?

отвечу цитатой из Вашего комментария к http://www.openstreetmap.org/browse/changeset/14946261

Порисовал лес, но не осилил.

dkiselev · 2013-02-13T15:10:19.000Z

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

andriano · 2013-02-13T17:44:52.000Z

dimonster:

представьте, что отношение границы нечаянно поломали.

Поломали - надо чинить. А не “представьте, что поломали, представьте, что удалили…”. Представьте, что у вас резинка в трусах завтра лопнет - подвяжитесь заранее шнурком

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

andriano · 2013-02-13T17:48:41.000Z

dkiselev:

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

На все 100% поддерживаю.
Постоянно оказывается, что часть границ поломана, часть отсутствует, а часть - проходит не там, где должна проходить.

Кстати, пока работал валидатор по КЛАДР. ОКТМО, ОКАТО, можно было видеть, что пока в OSM присутствует менее половины нужных границ.