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

ZCC · 2010-12-19T09:51:39.000Z

andriano:

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

А как же вот это - http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Two_disjunct_outer_rings ? Если таким образом оформлять amenity=university, состоящий из нескольких отдельных территорий? Неужели будут сложности с отрисовкой?

Fenuks · 2010-12-19T13:29:10.000Z

ZCC:

Организовать - позволяет. Но с какой целью?

Чтобы была какая-то связь и можно было что-то вроде «Показать другие филиалы» 2гиса создать. Или это логичнее делать как-то отдельно? Согласен, это можно сделать и при помощи тега operator, например. Но при этом, если у факультета и у вуза в целом есть, например, веб-сайт, то на каждом придётся писать оба? Метаданные, как никак.

ZCC:

Какой адрес, если площадок несколько - в разных частях города? Юридический адрес организации?

Юридический адрес вуза, куда можно обратиться и тебя переправят ниже по инстанциям, если нужно. Центральный офис организации.

ZCC:

Меня смущает то, что эта “информация вообще” не является в явном виде информацией о пространственном объекте. Если дальше развивать такой подход, то в OSM можно будет хранить исчерпывающую информацию о детальной структуре вуза, структуре управления, студентах, учебных планах, расписаниях занятий и т.д…

Она является информацией о связях пространственных объектов плюс в ней же объединение общей информации для этих объектов, чтобы не тыкать дубликаты в каждый объект. Просто моё имхо, что такая информация полезна в ГИС. Естественно, что до абсурда её доводить не стоит, структура вуза, управления и данные о студентах уже слабо соотносятся с понятием «связи между пространственными объектами». Опять же, тега operator должно бы и хватить, потом просто по этому тегу сортировать сторонней программой, но тогда возможности ОСМ сводятся к возможностям плоской бумажной карты, опять же на мой взгляд.

ZCC:

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

Ну всмысле да, это и имел в виду.

ZCC:

Fenuks:

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

Так ведь эту информацию можно и без кампуса найти - по территории, зданию и точечным объектам.

Визуально по отрендеренной карте. А в базе? Сверять по координатам точек? Или я чего-то не понимаю, я честно не претендую на то, что разбираюсь в ОСМ, я просто стараюсь помогать в меру своих сил.

ZCC:

Fenuks:

Во-вторых, достаточно прозрачный и простой способ тегирования подобных объектов.

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

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

ZCC:

Fenuks:

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

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

Ну щас все делают как получится без особой системы и однозначности. А целостность сама по себе из неоткуда не возникнет, её в любом случае надо внедрять и культивировать. Вчера шерстил Академгородок, очень много точек поставленных друг на друга, дороги пересекающие реки непонятно как. Кто захочет сломать — сломает, кто захочет сделать правильно — разберётся и сделает правильно. Я вообще не понимаю упрощения в ущерб возможностям. Моментальная выгода сейчас в обмен на долговременные сложности потом?

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

ZCC · 2010-12-19T19:11:29.000Z

Fenuks:

Чтобы была какая-то связь и можно было что-то вроде «Показать другие филиалы» 2гиса создать. Или это логичнее делать как-то отдельно?

Цель - понятна. Сделать, по-моему, лучше отдельно - ИС уровня вуза, использующая данные OSM.

Fenuks:

Согласен, это можно сделать и при помощи тега operator, например. Но при этом, если у факультета и у вуза в целом есть, например, веб-сайт, то на каждом придётся писать оба?

Вот этого не понял. Если вуз и факультет представлены каждый своим пространственным объектом, то на каждом свой сайт.

Fenuks:

ZCC:

Fenuks:

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

Так ведь эту информацию можно и без кампуса найти - по территории, зданию и точечным объектам.

Визуально по отрендеренной карте. А в базе? Сверять по координатам точек?

Да. Это же ГИС. Но такой подход, видимо, годится для вузов имеющих свою территорию. Если несколько подразделений вуза на разных арендованных площадках - тогда без отношений или operator не обойтись. Тогда использование отношения типа campus - универсальный способ.

Fenuks:

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

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

Fenuks:

Ну щас все делают как получится без особой системы и однозначности.

Ну так ведь что-то небесполезное получается.

Fenuks:

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

Так ведь нет в OSM механизмов, гарантирующих целостность…

Fenuks:

Кто захочет сломать — сломает, кто захочет сделать правильно — разберётся и сделает правильно.

А потом придет следующий ломальщик и опять сломает

Fenuks:

Я вообще не понимаю упрощения в ущерб возможностям. Моментальная выгода сейчас в обмен на долговременные сложности потом?

Да, прагматический подход. Решение проблем по мере их возникновения.

Fenuks:

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

Использование отношения - вполне нормальная идея. Других выразительных возможностей для этого в OSM пока, наверное, нет. Но я бы не стал надеяться, что все вузы в стране будут нарисованы одинаково. Не нравится - потому, наверное, что существующих выразительных возможностей и так достаточно во многих случаях. Вот если бы вместе с предложением появился инструмент с ф-циональностью “что-то вроде «Показать другие филиалы» 2гиса”, тогда бы, я думаю, понравилось

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 все-таки говорил о метаданных, а не о метаинформации. Так о них только ленивый не говорит… И что значит, “надо догонять”?