Как обозначать вузы, школы, заводы и прочие подобные?

Miroff · 2010-12-20T13:24:50.000Z

Fenuks:

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

Кроме того, корпуса и объекты имеют имена, которые тоже надо указывать, например «Главный корпус МГ Какого-то У», «Факультет Чего-нибудь МГ Какого-то У», «Столовая МГ Какого-то У», «Н-ский Филиал МГ Какого-то У» и так далее. В одном корпусе могут сидеть несколько факультетов на разных этажах или в разных частях зданий. Я не знаю, насколько это всё разграничивается на картах, в простонародии их называют «Корпус такого-то факультета». В общем, я не совсем уверен, какие названия в какие тэги писать. Особенно с «Главным корпусом», делать name=«МГ Какой-то У», ref=«Главный корпус» или наоборот?

Если здание называется “Лабораторный корпус”, следует писать name=Лабораторный корпус. Если здание никак не называется, то совершенно не важно кто в нем сидит, name должен быть пустым. ref вообще не в кассу.

Стандартного способа обозначить факультеты и филиалы нет. Хотите? Пишите пропозал, вроде немецкого Healthcare. Он будет примерно такой-же по сложности.

Fenuks:

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

Опять же стандартного способа нет. Есть пропозал Site (128 341 использование). Не знаю насколько он поддерживаются, но выглядит вполне популярным.

Fenuks:

Логичным решением основной проблемы мне кажется использование отношений (если я правильно понял, что они такое), в которые объединять все принадлежащие заведению объекты, включая корпуса (в том числе те, что находятся за огороженной территорией в пределах одного населённого пунка), общежития, территории, заборы. И каким-то образом обозначать филиалы, возможно в том же отношении, но я не уверен, что это не вызовет каких-либо проблем при поиске.
Вопрос, что за отношение для этого использовать? Мультиполигон вроде не для этого.

Совершенно верно, мультиполигон не для этого.

Принадлежность здания ВУЗу можно определить по по тому, на чьей территории оно находится. Поэтому для школ, ВУЗов, заводов нужно обозначать территорию. В конце концов, OSM это пространственная БД.

Fenuks · 2010-12-21T09:29:42.000Z

Miroff:

Если здание называется “Лабораторный корпус”, следует писать name=Лабораторный корпус. Если здание никак не называется, то совершенно не важно кто в нем сидит, name должен быть пустым. ref вообще не в кассу.

И получится 2 десятка «Лабораторных корпусов» по всему городу. Тогда уж «Лабораторный корпус НГПУ».

Miroff:

Стандартного способа обозначить факультеты и филиалы нет. Хотите? Пишите пропозал, вроде немецкого Healthcare. Он будет примерно такой-же по сложности.

Ну так я это и делаю. Пытаюсь.

Miroff:

Опять же стандартного способа нет. Есть пропозал Site (128 341 использование). Не знаю насколько он поддерживаются, но выглядит вполне популярным.

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

Miroff:

Совершенно верно, мультиполигон не для этого.

Принадлежность здания ВУЗу можно определить по по тому, на чьей территории оно находится. Поэтому для школ, ВУЗов, заводов нужно обозначать территорию. В конце концов, OSM это пространственная БД.

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

fserges · 2010-12-24T08:55:22.000Z

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

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

Обвести все корпуса и дать amenity=university и name=* логично, но как система узнает адрес ВУЗа? Ведь там несколько корпусов.
Каждому зданию проставить amenity=university и name=факультет *. Но тогда схема будет очень пестрить названиями, да и только от них ноль, т.к. по факту в нескольких зданиях расположены помещения разных факультетов, а не одно здание = один факультет.

Как бы Вы нарисовали? Под что мы рисуем?

Surly · 2010-12-24T19:07:39.000Z

fserges:

Обвести все корпуса и дать amenity=university и name=* логично, но как система узнает адрес ВУЗа? Ведь там несколько корпусов.

Делать так. Несмотря на то, что у каждого корпуса свой адрес, должен быть еще один основной адрес ВУЗа — что-то вроде юридического адреса. Вот его и поставить для всего amenity.

fserges:

Каждому зданию проставить amenity=university и name=факультет *

Так, но без amenity. Только building=yes, адресную информацию, название факультета, если оно есть.

fserges:

по факту в нескольких зданиях расположены помещения разных факультетов, а не одно здание = один факультет.

Тогда для каждого из таких зданий выбрать одно из следующего:

в name ставить название не факультета, а корпуса:«Главный учебный корпус», «Хоз. корпус №2» и т. п.
выбрать основной факультет (например, крупнейший по площади), в имя вписать его.
если разные факультеты находятся в разных крыльях одного здания, попытаться расставить точки с подписями на них — примерно так же, как мы поступаем с place=suburb, place=locality.
ничего не писать в name
а как обычно называют это здание «в народе»? Как-то же их различают — так и подписать.

fserges:

Под что мы рисуем?

Под истину и логику.

Fenuks · 2010-12-26T09:59:29.000Z

fserges:

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

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

Обвести все корпуса и дать amenity=university и name=* логично, но как система узнает адрес ВУЗа? Ведь там несколько корпусов.

Каждому зданию проставить amenity=university и name=факультет *. Но тогда схема будет очень пестрить названиями, да и только от них ноль, т.к. по факту в нескольких зданиях расположены помещения разных факультетов, а не одно здание = один факультет.

Как бы Вы нарисовали? Под что мы рисуем?

Ни к чему так и не пришли пока что. Тут рядом велось активное обсуждение о том, как рисовать здания сложной формы, вроде даже пришли к следующему:
Здания, которые имеют название/адрес рисуются как building=yes, name=, addr:=.
Если здание составное, то есть имеет пристройки другой этажности/формы, но по прежнему общий адрес, то оно тоже рисуется единым полигоном building=yes, name=, addr:= по контуру. А затем строения отличной этажности, компановки, переходы и прочее рисуются поверх как building:part=yes. В общем, как я понял из обсуждения «Трёхмерные здания», building=yes это юридический объект, нечто имеющее адрес. А собственно строения его составляющие это уже building:part=yes. Способа связать их пока нет, хотя тут то не будет расхождений с положением, все building:part в пределах многоугольника building принадлежат ему.
Amenity=university это конкретно территория университета, а не здания его составляющие, так что этот тэг ставится только на территорию. Здания уже обозначаются как name=, amenity на них не должно быть, иначе будет шибко много университетов. Столовые я обозначаю как amenity=cafe.

Если по нескольку факультетов в одном здании, то как Surely сказал, лучше ставить точку с name=факультет *.

По поводу юр. адерса вуза как раз мой основной вопрос. Варианта вижу два — ставить на главный корпус, обычно там находится ректорат, либо ваять отношение, как я говорил раньше. Лично мне больше нравится отношение, ведь связь корпусов вуза, как правильно заметил ZCC, не является информацией о физическом объекте. Причём таких отношений в пропозалах целая куча, включая уже используемый type=operator, который тоже подходит под данную задачу. Но andriano предостерегает от объединения в отношения разрозненных объектов, хотя тот же type=operator у нас объединяет заправки по всей области.

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

ZCC · 2010-12-26T11:33:46.000Z

Fenuks:

Например, построили новую общагу через улицу, не тянуть же на неё территорию вуза.

А почему нет? Если эта общага на территории вуза, то надо обозначить и территорию вуза и саму общагу как строение на этой территории. Территория вуза может состоять из нескольких кусков - например, http://www.openstreetmap.org/browse/relation/1330123

Fenuks · 2010-12-26T11:44:25.000Z

ZCC:

Fenuks:

Например, построили новую общагу через улицу, не тянуть же на неё территорию вуза.

А почему нет? Если эта общага на территории вуза, то надо обозначить и территорию вуза и саму общагу как строение на этой территории. Территория вуза может состоять из нескольких кусков - например, http://www.openstreetmap.org/browse/relation/1330123

Даже если территория ограничена зданием общежития? Тогда здание общежития будет amenity=university, а этого как раз хотелось бы избежать. Можно делать обводку, но тогда будет два одинаковых многоугольника с разными тегами.
А если делать не мультиполигон тогда и придём как раз к отношениям, которые будут содержать мемберы в разных частях города. Собственно, к чему я и склонюсь, ибо достаточно универсальное решение.

ZCC · 2010-12-26T13:28:16.000Z

Fenuks:

Даже если территория ограничена зданием общежития?

Да. У нас же два объекта - земельный участок и строение. Ну и что, что и их проекции совпадают. Отобразить в OSM можно оба.

Fenuks:

Тогда здание общежития будет amenity=university, а этого как раз хотелось бы избежать. Можно делать обводку, но тогда будет два одинаковых многоугольника с разными тегами.

Можно не обводку, а один way включить в два отношения - building и amenity.

Fenuks:

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

Всякий мультиполигон является отношением. Я же как раз и привел такой пример - с двумя несоединенными outer-членами такого отношения.

Fenuks · 2010-12-26T14:10:28.000Z

ZCC:

Fenuks:

Даже если территория ограничена зданием общежития?

Да. У нас же два объекта - земельный участок и строение. Ну и что, что и их проекции совпадают. Отобразить в OSM можно оба.

Fenuks:

Тогда здание общежития будет amenity=university, а этого как раз хотелось бы избежать. Можно делать обводку, но тогда будет два одинаковых многоугольника с разными тегами.

Можно не обводку, а один way включить в два отношения - building и amenity.

Fenuks:

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

Всякий мультиполигон является отношением. Я же как раз и привел такой пример - с двумя несоединенными outer-членами такого отношения.

Не нравится мне дублирование и опять же sfs — все члены мультиполигона должны иметь одинаковые тэги, а так получится здание и территория в одном мультиполигоне.
Кроме того, мультиполгон не для того, у него много ограничений.
Вот я щас вижу три пропозала, которые подойдут для решения этой задачи — site, operator и campus (который не особо то пропозал).

ZCC · 2010-12-26T16:36:13.000Z

Fenuks:

Не нравится мне дублирование

Нет там никакого дублирования.

Fenuks:

и опять же sfs — все члены мультиполигона должны иметь одинаковые тэги,

Откуда такое ограничение?

Fenuks:

Кроме того, мультиполгон не для того, у него много ограничений.

Что значит “не для того”? Если территория из нескольких несвязанных частей - как раз для того.

ZCC · 2010-12-27T07:30:11.000Z

Surly:

fserges:

Обвести все корпуса и дать amenity=university и name=* логично, но как система узнает адрес ВУЗа? Ведь там несколько корпусов.

Делать так. Несмотря на то, что у каждого корпуса свой адрес, должен быть еще один основной адрес ВУЗа — что-то вроде юридического адреса. Вот его и поставить для всего amenity.

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

Fenuks · 2010-12-30T14:56:07.000Z

ZCC:

Fenuks:

и опять же sfs — все члены мультиполигона должны иметь одинаковые тэги,

Откуда такое ограничение?

Fenuks:

Кроме того, мультиполгон не для того, у него много ограничений.

Что значит “не для того”? Если территория из нескольких несвязанных частей - как раз для того.

http://wiki.openstreetmap.org/wiki/RU:Relation:multipolygon#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.87.D0.B0.D0.BD.D0.B8.D1.8F, последний пункт. Вроде как для большая часть рендеров согласно sfs работает, значит приводит мультиполигоны к простому виду. В соседней теме обсуждали, вроде как, но щас не по глазам.
А про адрес земельного участка это верно замечено, зачастую есть, но вроде там номер в реестре с адресом типа дом-улица не очень связанный.

ZCC · 2010-12-30T16:42:29.000Z

Fenuks:

ZCC:

Fenuks:

и опять же sfs — все члены мультиполигона должны иметь одинаковые тэги,

Откуда такое ограничение?

http://wiki.openstreetmap.org/wiki/RU:Relation:multipolygon#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.87.D0.B0.D0.BD.D0.B8.D1.8F, последний пункт. Вроде как для большая часть рендеров согласно sfs работает, значит приводит мультиполигоны к простому виду.

Понял о чем речь. Так тот way, который входит и в отношение типа мультиполигон для building, и в отношение типа мультиполигон для amenity вообще не имеет тэгов. Так что это условие выполняется.
Говоря об адресе земельного участка я имел в виду не номер в реестре, а обычный почтовый адрес типа улица+дом.

Fenuks · 2011-01-05T06:03:32.000Z

ZCC:

Fenuks:

ZCC:

Откуда такое ограничение?

http://wiki.openstreetmap.org/wiki/RU:Relation:multipolygon#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.87.D0.B0.D0.BD.D0.B8.D1.8F, последний пункт. Вроде как для большая часть рендеров согласно sfs работает, значит приводит мультиполигоны к простому виду.

Понял о чем речь. Так тот way, который входит и в отношение типа мультиполигон для building, и в отношение типа мультиполигон для amenity вообще не имеет тэгов. Так что это условие выполняется.
Говоря об адресе земельного участка я имел в виду не номер в реестре, а обычный почтовый адрес типа улица+дом.

Правильно ли я понимаю, вы предлагаете ставить пустой вей и включать его в 2 отношения building просто чтобы обозначить его как здание и mutipolygon для присоединения к территории? Имхо лишнее. А если вей не пустой — не соблюдается sfs. Да и пустой вей будет смотреться весьма странно.

В общем, по прежнему не вижу причин городить сущности. Судя по пропозалам, наиболее логичным будет использование отношения type=operator, причём оно может использоваться для объединения любых объектов принадлежащих одному предприятию/фирме и при этом физических данных касаться не будет.
Кто-то ещё предлагал делать отношение с каким-то центральным нодом. Не совсем понял, что за зверь, вроде как отношение само по себе тэгов не содержит, его содержит точка или полигон, входящая(ий) в отношение и помеченный специальным образом. Это тоже вполне вписывается, в качестве такого нода надо просто использовать центральный офис/ректорат и так далее.

ZCC · 2011-01-05T09:54:27.000Z

Fenuks:

Правильно ли я понимаю, вы предлагаете ставить пустой вей и включать его в 2 отношения building просто чтобы обозначить его как здание и mutipolygon для присоединения к территории?

Да, именно так.

Fenuks:

Имхо лишнее. А если вей не пустой — не соблюдается sfs. Да и пустой вей будет смотреться весьма странно.

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

Fenuks:

В общем, по прежнему не вижу причин городить сущности. Судя по пропозалам, наиболее логичным будет использование отношения type=operator, причём оно может использоваться для объединения любых объектов принадлежащих одному предприятию/фирме и при этом физических данных касаться не будет.

А это не “горожение сущностей”? amenity и building - этих двух пространственных сущностей, по-моему, вполне достаточно. А вот непространственные сущности - это уже от лукавого.

Fenuks:

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

И уж тем более вот это.

Fenuks · 2011-01-05T15:11:11.000Z

ZCC:

Fenuks:

Имхо лишнее. А если вей не пустой — не соблюдается sfs. Да и пустой вей будет смотреться весьма странно.

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

Fenuks:

В общем, по прежнему не вижу причин городить сущности. Судя по пропозалам, наиболее логичным будет использование отношения type=operator, причём оно может использоваться для объединения любых объектов принадлежащих одному предприятию/фирме и при этом физических данных касаться не будет.

А это не “горожение сущностей”? amenity и building - этих двух пространственных сущностей, по-моему, вполне достаточно. А вот непространственные сущности - это уже от лукавого.

Два совпадающих вея мне тоже не нравятся, их редактировать ужасно неудобно, ибо фиг попадёшь в один под другим.

Ограничение пространственными сущностями это как-то мелко для подобного проекта, имхо. Зачем нужна электронная карта, которая предоставляет возможностей не больше, чем бумажная? W3C уже сказали «да» метаинформации, надо догонять.

ZCC · 2011-01-05T16:46:15.000Z

Fenuks:

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

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

Fenuks:

W3C уже сказали «да» метаинформации, надо догонять.

Наверное, W3C все-таки говорил о метаданных, а не о метаинформации. Так о них только ленивый не говорит… И что значит, “надо догонять”?

Fenuks · 2011-01-06T05:13:43.000Z

ZCC:

Fenuks:

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

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

Fenuks:

W3C уже сказали «да» метаинформации, надо догонять.

Наверное, W3C все-таки говорил о метаданных, а не о метаинформации. Так о них только ленивый не говорит… И что значит, “надо догонять”?

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

ZCC · 2011-01-07T07:56:21.000Z

Fenuks:

По тому, что там эти возможности можно реализовать, в отличие от бумажной.

Нереализуемые возможности - это не возможности.

Fenuks:

По-моему, электронные карты могут всё, что могут бумажные (в том числе их можно распечатать)

В этом случае они превращаются в бумажные и теряют свойства электронных.

Fenuks:

и ещё больше.

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

Fenuks:

И в чём разница между метаданными и метаинформацией?

Видимо та же, что и между данными и информацией - не все данные и не всегда являются информацией.

Fenuks:

тут то мы имеет возможность сделать.

Лишь бы монструозный уродец не получился…

Fenuks · 2011-01-08T16:57:33.000Z

ZCC:

Fenuks:

По тому, что там эти возможности можно реализовать, в отличие от бумажной.

Нереализуемые возможности - это не возможности.

Fenuks:

По-моему, электронные карты могут всё, что могут бумажные (в том числе их можно распечатать)

В этом случае они превращаются в бумажные и теряют свойства электронных.

Fenuks:

и ещё больше.

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

Fenuks:

И в чём разница между метаданными и метаинформацией?

Видимо та же, что и между данными и информацией - не все данные и не всегда являются информацией.

Fenuks:

тут то мы имеет возможность сделать.

Лишь бы монструозный уродец не получился…

Этак у нас получился театр двух актёров…
В общем, я тебя понял, твоё мнение — нафиг не нужны эти объединения, карта для материальных сущностей.
Тогда надо думать тэги для обозначения учебных корпусов, по аналогии с Proposed Building.