Санкт-Петербург и область

Sergey Astakhov · 2010-11-13 10:14:48

ZCC wrote:

Задание addr:city для node/way объекта с целью последующего извлечения этой информации через API - это рисование под API?
Задание addr:city для node/way объекта противоречит принципам OSM?
Задание addr:city для node/way объекта противоречит хорошим практикам?

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

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

Last edited by Sergey Astakhov (2010-11-13 10:15:33)

lupin-de-mid · 2010-11-13 10:35:02

ZCC wrote:

KonTur wrote:
а зачем плодить лишние теги?
Они не лишние. Как я уже выше сказал, их очень просто и удобно использовать для выяснения принадлежности объекта к более крупному объекту, не обращаясь к описанию этого более крупного объекта.
Как индексы в БД - тоже своего рода избыточная (можно обойтись без них), но полезная (поиск ускоряется) информация.

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

ZCC · 2010-11-13 17:18:50

ZCC wrote:

Sergey Astakhov wrote:
А как же теги на way-ях/relation-ах? Зададут здание мультиполигоном и повесят на него тег больницы - вам его через API найти будет очень проблематично.
Да, c мультиполигонами проблема.

Я, пожалуй, погорячился, что это проблема. Ведь я легко найду relation с соотв. amenity, а какой у него будет тип - мультиполигон или еще что-нибудь - без разницы. Лишь бы были элементы адреса.

Last edited by ZCC (2010-11-13 17:19:24)

liosha · 2010-11-13 17:23:03

Адрес должен быть на building, а не на amenity

ZCC · 2010-11-13 17:26:40

lupin-de-mid wrote:

ZCC wrote:
KonTur wrote:
а зачем плодить лишние теги?
Они не лишние. Как я уже выше сказал, их очень просто и удобно использовать для выяснения принадлежности объекта к более крупному объекту, не обращаясь к описанию этого более крупного объекта.
Как индексы в БД - тоже своего рода избыточная (можно обойтись без них), но полезная (поиск ускоряется) информация.
Только индексы прозрачны при исползьзовании, в отличии от:)

В отличие от чего? Непосредственное использование addr:city для объекта вполне прозрачно в отличие от необходимости выяснять отношения с окружающими объектами.

lupin-de-mid wrote:

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

Можно, наверное, но я не сталкивался с практикой использования этих объектов для адресации. На Гражданку дедушке

ZCC · 2010-11-13 17:35:41

liosha wrote:

Адрес должен быть на building, а не на amenity

Sergey Astakhov сказал: "Зададут здание мультиполигоном и повесят на него тег больницы". Я это понимаю так - relation типа мультиполигон, имеющий теги building и amenity. Это неправильно?

liosha · 2010-11-13 17:50:26

Нет, конечно. Amenity совершенно не обязано быть зданием: это может быть точка внутри здания или территория с кучей зданий.

ZCC · 2010-11-13 17:54:31

Sergey Astakhov wrote:

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

Спору нет - без механизмов синхронизации реплик дублирование является плохой практикой (не считая, наверное, случаев резервного/архивного копирования и еще чего-нибудь подобного). А если такие механизмы есть, то наоборот, это хорошая практика, как правило дающая повышение надежности и производительности (RAID, например)

Sergey Astakhov wrote:

Спросите тех, кто не так давно улицы в Питере переименовывал, насколько им это было легко и удобно и сколько ошибок в адресных данных при этом наплодилось...

Ну так мы же вчера еще обсудили возможность использования соотв. бота. Это и есть механизм синхронизации реплик.

ZCC · 2010-11-13 18:26:59

liosha wrote:

Нет, конечно. Amenity совершенно не обязано быть зданием: это может быть точка внутри здания или территория с кучей зданий.

Это понятно, но это другой случай, не тот, о котором говорил Sergey Astakhov. Что не так в моем толковании ЕГО слов?
Если же говорить об указанных тобой вариантах, то, да, примитивный API здесь не поможет. Потому я и рассуждаю о возможности копирования адресной информации из здания в точку внутри этого здания или в "территорию с кучей зданий". Если это будет происходить автоматически, то полное решение задачи можно осуществить и при помощи примитивного API, сняв бремя поиска этого нетривиального решения с пользователя и переложив его на робота.

liosha · 2010-11-13 18:31:04

А вот не надо её копировать со зданий на всё подряд. Адресуются у нас здания

ZCC · 2010-11-13 18:46:54

one_half_3544 wrote:

ZCC wrote:
Задание addr:city для node/way объекта противоречит хорошим практикам?
Противоречит здравому смыслу и принципам создания баз данных.

Снабдить описание объекта полной адресной информацией с целью повышения простоты и эффективности получения этой информации противоречит здравому смыслу? Здравый ли он в таком случае?

one_half_3544 wrote:

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

Ну и что - это же произойдет автоматически.

one_half_3544 wrote:

Название должно быть в одном месте прописано, во всех остальных местах должны быть ссылки.

Ну и где же эти ссылки на город находятся в описании зданий?

ZCC · 2010-11-13 19:00:03

liosha wrote:

А вот не надо её копировать со зданий на всё подряд. Адресуются у нас здания

Но ведь точка внутри здания имеет адрес. Более того, о возможности адресации точки говорит http://wiki.openstreetmap.org/wiki/Address
Да, и я не говорил о копировании "на всё подряд".

one_half_3544 · 2010-11-13 19:08:17

ZCC wrote:

one_half_3544 wrote:
ZCC wrote:
Задание addr:city для node/way объекта противоречит хорошим практикам?
Противоречит здравому смыслу и принципам создания баз данных.
Снабдить описание объекта полной адресной информацией с целью повышения простоты и эффективности получения этой информации противоречит здравому смыслу?

Таким способом (дублированием информации) - противоречит.

ZCC wrote:

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

За счёт чего, интересно? Сама база не обеспечивает какого-либо контроля за соответствием значений тегов разных объектов.

ZCC wrote:

one_half_3544 wrote:
Название должно быть в одном месте прописано, во всех остальных местах должны быть ссылки.
Ну и где же эти ссылки на город находятся в описании зданий?

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

Такая схема обеспечивает целостность данных (изменение имени отношения улицы приводит к тому, что все запросы к домам на этой улице (через parent relation) дадут верное имя) и отсутствие дублирования данных.

ZCC · 2010-11-13 20:10:55

one_half_3544 wrote:

ZCC wrote:
one_half_3544 wrote:
Противоречит здравому смыслу и принципам создания баз данных.
Снабдить описание объекта полной адресной информацией с целью повышения простоты и эффективности получения этой информации противоречит здравому смыслу?
Таким способом (дублированием информации) - противоречит.

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

one_half_3544 wrote:

ZCC wrote:
one_half_3544 wrote:
Например если город переименуют, то придётся все объекты внутри него обновлять.
Ну и что - это же произойдет автоматически.
За счёт чего, интересно? Сама база не обеспечивает какого-либо контроля за соответствием значений тегов разных объектов.

За счет внешних средств. См. выше - я упоминал робот.

one_half_3544 wrote:

ZCC wrote:
one_half_3544 wrote:
Название должно быть в одном месте прописано, во всех остальных местах должны быть ссылки.
Ну и где же эти ссылки на город находятся в описании зданий?
Эти ссылки должны быть в отношениях. Здания должны быть связаны с улицей, по которой они адресуются, отношением.
Улицы связаны с городом,в котором они находятся, географически - вхождением в полигон границы.
Такая схема обеспечивает целостность данных (изменение имени отношения улицы приводит к тому, что все запросы к домам на этой улице (через parent relation) дадут верное имя) и отсутствие дублирования данных.

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

Целостность и отсутствие дублирования - это, конечно, хорошо. Но до тех пор, пока не мешает просто и быстро делать простые вещи.

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

one_half_3544 · 2010-11-13 21:57:29

ZCC wrote:

one_half_3544 wrote:
ZCC wrote:
Снабдить описание объекта полной адресной информацией с целью повышения простоты и эффективности получения этой информации противоречит здравому смыслу?
Таким способом (дублированием информации) - противоречит.
Нет, не соглашусь. Это м.б. противоречит научному подходу к проектированию БД (нормализация и пр.), но никак не здравому смыслу.

Ну ok, если учесть, что commons sense happens to be not so common after all , то да, соглашусь. Такая база будет не нормализована.

ZCC wrote:

one_half_3544 wrote:
ZCC wrote:
Ну и что - это же произойдет автоматически.
За счёт чего, интересно? Сама база не обеспечивает какого-либо контроля за соответствием значений тегов разных объектов.
За счет внешних средств. См. выше - я упоминал робот.

Что будет с данными в промежутке между правкой с переименовыванием города и запуском робота? Что будет, если у робота интернет отключат или его вообще забудут запустить? Ненадёжная схема. Такие вещи должны выполняться на сервере, в том же changeset'е, обеспечивая атомарность операции.

ZCC wrote:

one_half_3544 wrote:
ZCC wrote:
Ну и где же эти ссылки на город находятся в описании зданий?
Эти ссылки должны быть в отношениях. Здания должны быть связаны с улицей, по которой они адресуются, отношением.
Улицы связаны с городом,в котором они находятся, географически - вхождением в полигон границы.
Такая схема обеспечивает целостность данных (изменение имени отношения улицы приводит к тому, что все запросы к домам на этой улице (через parent relation) дадут верное имя) и отсутствие дублирования данных.
При таком подходе, глядя только на здание, я не смогу определить на какой улице оно находится. Понадобится искать отношение, в которое это здание входит, для выяснения названия улицы. Т.е. для выяснения элементарной вещи придется делать дополнительные телодвижения. По-моему, это уже чересчур, не здраво.

Ещё один запрос к базе - это много? Get relations for element.

ZCC wrote:

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

Да, именно так. Продолжая аналогию - на домах мы убираем названия улиц, но вешаем номер (координаты или что-то ещё) перекрёстка, на котором висит название улицы; прохожие, когда им надо узнать название улицы, бегут к этому конкретному перекрёстку. Только в osm 'бежать' быстрее.

ZCC wrote:

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

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

fserges · 2010-11-14 11:55:38

zverik wrote:

fserges wrote:
Есть ли кто-нибудь из Питерских кто бы мог дать краткий курс начинающего маппера с указанием как правильных тактик так и типичных ошибок. Можно на обеде выбраться в какое-нибудь кафе с WiFi, я могу подскочить в какой-нибудь бизнес-центр или пригласить к себе в офис (м. Балтийская). С меня кофе, пирожки и прочие ништяки
Я готов провести такое занятие, но нужна будет комната для хотя бы десятка человек и с wi-fi, желательно бесплатным. Мне как-то сложновато найти такую Библиотеку, может, кто знает?

Ну если будет 10-15 человек то я могу попробовать договориться с директором. У нас периодически устраиваются IT-ные мероприятия и конференц-зал для таких дел есть, нужно только директора заинтересовать Есть интернет и места, кофе, пироги можно где-нибудь заказать, проектор и т.п. Но как показал опыт собрать большую кучу людей не имея в агенде животрепещущей темы очень сложно. Одни в один день не могут, другие в другой. Кому-то удобнее вечером, кому-то утром. А перед самым началом мероприятия у кого-то вдруг внезапно рожает тёща или кому-то срочно нужно ехать чтобы получать Нобелевскую премию По опыту после двухнедельного планирования и обсуждения приходит 10-15%.

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

Last edited by fserges (2010-11-14 12:35:16)

yaleks · 2010-11-14 12:16:24

Katerina wrote:

Приветствую всех!
Я рисую Гатчину по снимкам, купленным у СканЭкса. Могу выложить куда-нибудь кусочек снимка, чтобы желающие могли убедиться в отсутствии "водяных знаков".
По поводу сдвижки относительно Yahoo - на мой взгляд, у СканЭкса привязка точнее (они прилагают файлы привязки к купленным снимкам). И с треками их привязка совпала.
Рисовала я сначала в GPSMapEdit, теперь по частям конвертирую в osm и с помощью JOSM заливаю. Но работать мне (во всяком случае пока) удобнее в Merkaartor, поэтому правлю там. Стараюсь не трогать нарисованное ранее другими участниками.
Если что-то не так, поправляйте и подсказывайте, пожалуйста!

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

ZCC · 2010-11-14 20:58:22

one_half_3544 wrote:

ZCC wrote:
one_half_3544 wrote:
За счёт чего, интересно? Сама база не обеспечивает какого-либо контроля за соответствием значений тегов разных объектов.
За счет внешних средств. См. выше - я упоминал робот.
Что будет с данными в промежутке между правкой с переименовыванием города и запуском робота?,

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

one_half_3544 wrote:

Что будет, если у робота интернет отключат или его вообще забудут запустить?

Очевидно, синхронизация не произойдет.

one_half_3544 wrote:

Ненадёжная схема.

С точностью до ненадежности сервера БД, Интернета, клиента и пр. элементов системы. А если у БД Интернет отключат? Робота можно легко клонировать, распределить клонов в пространстве Интернет, а также распределить работу между ними (а ля *@home). Так, наверное, будет надежнее.

one_half_3544 wrote:

Такие вещи должны выполняться на сервере, в том же changeset'е, обеспечивая атомарность операции.

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

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

Короче, возникает еще один способ получения информации. Это же хорошо, когда есть выбор. Хочу актуальность 100% - вычисляю нужное значение через соотв. отношения или географически. Не хочу вычислять - беру сразу, но с актуальностью 99.(9)%. "Каждый выбирает по себе..."

one_half_3544 wrote:

ZCC wrote:
one_half_3544 wrote:
Эти ссылки должны быть в отношениях. Здания должны быть связаны с улицей, по которой они адресуются, отношением.
Улицы связаны с городом,в котором они находятся, географически - вхождением в полигон границы.
Такая схема обеспечивает целостность данных (изменение имени отношения улицы приводит к тому, что все запросы к домам на этой улице (через parent relation) дадут верное имя) и отсутствие дублирования данных.
При таком подходе, глядя только на здание, я не смогу определить на какой улице оно находится. Понадобится искать отношение, в которое это здание входит, для выяснения названия улицы. Т.е. для выяснения элементарной вещи придется делать дополнительные телодвижения. По-моему, это уже чересчур, не здраво.
Ещё один запрос к базе - это много? Get relations for element.

Ну, если быть последовательным, то да 2 - это много. В целых 2 раза больше, чем один.

one_half_3544 wrote:

ZCC wrote:
Это все равно что в реальности пройтись вдоль по улице и убрать название улицы с табличек на домах, оставив там только номера. Так, кстати делают в США. Но там название улицы пишут хотя бы на каждом перекрестке. А мы не будет заниматься дублированием - напишем где-то в одном месте. А то вдруг название улицы сменят - поменяем только одну табличку - сэкономим. А приезжие не помня себя будут бегать по улице в поисках этой таблички или терзать прохожих, чтобы определить на какой улице они находятся.
Да, именно так. Продолжая аналогию - на домах мы убираем названия улиц, но вешаем номер (координаты или что-то ещё) перекрёстка, на котором висит название улицы;

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

one_half_3544 wrote:

прохожие, когда им надо узнать название улицы, бегут к этому конкретному перекрёстку. Только в osm 'бежать' быстрее.

Только это и спасает, что бежать быстрее...

ZCC · 2010-11-14 21:24:53

liosha wrote:

А вот не надо её копировать со зданий на всё подряд. Адресуются у нас здания

"У нас" - это где? Насколько плохо я понимаю OSM - это модель реального мира. А в реальном мире адресуются не только здания. А модель д.б. адекватна моделируемому объекту в каком-то смысле. Разве не так?

Zkir · 2010-11-14 21:42:17

Адрес - это атрибут здания. То что находится внутри адресовано уже одним этим фактом. Так что модель вполне адекватна

Last edited by Zkir (2010-11-14 21:43:00)

ZCC · 2010-11-14 21:48:54

Zkir wrote:

Адрес - это атрибут здания. То что находится внутри адресовано уже одним этим фактом. Так что модель вполне адекватна

В отношении зданий - да, адекватна. А как быть с не зданиями, имеющими адреса? Например, с земельными участками.

Diomas · 2010-11-14 23:01:58

Я ставил адрес на ворота. Т.к. на воротах написан адрес, а что внутри за стеной - неизвестно (заводская территория)

copov · 2010-11-15 03:09:36

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

Last edited by copov (2010-11-15 03:10:47)

ZCC · 2010-11-15 07:34:49

Diomas wrote:

Я ставил адрес на ворота. Т.к. на воротах написан адрес, а что внутри за стеной - неизвестно (заводская территория)

А ворота, наверняка представлены точкой, а не полигоном типа building. И это, по-моему, является адекватным отражением факта реального мира.

copov wrote:

Адреса можно ставить на любые полигоны.

Абсолютно согласен. Но вот liosha, вопреки мнению коллективного разума, выраженного в http://wiki.openstreetmap.org/wiki/Address, отвергает возможность адресации точек и ограничивает множество полигонов типом building. Очень хочется понять - почему.

copov · 2010-11-15 08:13:13

Хотя правды ради, обычно в этих случаях адрес ставят на административный корпус

Announcement

#751 2010-11-13 10:14:48

Re: Санкт-Петербург и область

#752 2010-11-13 10:35:02

Re: Санкт-Петербург и область

#753 2010-11-13 17:18:50

Re: Санкт-Петербург и область

#754 2010-11-13 17:23:03

Re: Санкт-Петербург и область

#755 2010-11-13 17:26:40

Re: Санкт-Петербург и область

#756 2010-11-13 17:35:41

Re: Санкт-Петербург и область

#757 2010-11-13 17:50:26

Re: Санкт-Петербург и область

#758 2010-11-13 17:54:31

Re: Санкт-Петербург и область

#759 2010-11-13 18:26:59

Re: Санкт-Петербург и область

#760 2010-11-13 18:31:04

Re: Санкт-Петербург и область

#761 2010-11-13 18:46:54

Re: Санкт-Петербург и область

#762 2010-11-13 19:00:03

Re: Санкт-Петербург и область

#763 2010-11-13 19:08:17

Re: Санкт-Петербург и область

#764 2010-11-13 20:10:55

Re: Санкт-Петербург и область

#765 2010-11-13 21:57:29

Re: Санкт-Петербург и область

#766 2010-11-14 11:55:38

Re: Санкт-Петербург и область

#767 2010-11-14 12:16:24

Re: Санкт-Петербург и область

#768 2010-11-14 20:58:22

Re: Санкт-Петербург и область

#769 2010-11-14 21:24:53

Re: Санкт-Петербург и область

#770 2010-11-14 21:42:17

Re: Санкт-Петербург и область

#771 2010-11-14 21:48:54

Re: Санкт-Петербург и область

#772 2010-11-14 23:01:58

Re: Санкт-Петербург и область

#773 2010-11-15 03:09:36

Re: Санкт-Петербург и область

#774 2010-11-15 07:34:49

Re: Санкт-Петербург и область

#775 2010-11-15 08:13:13

Re: Санкт-Петербург и область

Board footer