Объектно-ориентированный осм

Communities Россия (Russia)
1

Измышлизмы на тему «Если бы я делал систему тегирования для осм сейчас».

Представьте себе, что вам впервые понадобилось обозначить ДЮСШОР (Детско-Юношеская Спортивная Школа Олимпийского Резерва).
Что вы сделаете? Наверное, пойдёте читать вики или спросите в форуме / чятике.

А давайте представим себе, как это может выглядеть в ОООСМе.

  1. Делаем класс «Школа», задаём ему человекочитаемое описание (в каких случаях применять), свойства (с указанием тегов, которые следует использовать).
  2. Делаем класс «Спортивное учреждение», задаем, указываем.
  3. «Детское учреждение», по аналогии.

Теперь — хотим ДЮСШОР? Делаем производный класс «ДЮСШОР», от классов «Школа», «Спортивное учреждение», «Детское учреждение».
Класс принимает свойства родителей и их варианты значений.

Здесь пункты 1-3 можно проделать однажды перед запуском такого осма. Этакий “osm core”.
Новые классы вносятся через интерфейс внесения новых классов (уже простыми пользователями), и по сути являются автоматическими пропозалами с постановкой на голосование через некий раздел на сайте OSM.

Например, обозначая тот же ДЮСШОР, открываем окошко со свободным полем ввода и начинаем набирать Школ, видим предложенные варианты, тыкаем мышкой в слово «Школа». Сразу видим популярные сопутствующие классы (не предков!), например, «Государственное учреждение». Тыкаем. Пыщь-пыщь — получилось неплохое описание объекта.

Пришла мысль: «А объект-то довольно типовой, не внести ли его в osm core?» Раз, два — готово! А самое приятное, что объект поймут и старые интерпретаторы (конвертеры), не знающие о ДЮСШОР, но зато прекрасно знающие, что производные класса «Школа» — надо конвертировать в гарминотип «Школа».

Массовые замены и реструктуризации оформляются не менее автоматизированно. Например, кто-то решил, что добавить класс «Искусственный объект» в предки классу «Здание» чертовски хорошая идея. Пожалуйста — пропозал оформляется за пару минут.

Лично я не вижу никаких проблем со внедрением этой системы параллельно существующей. Ведь в OSM всё ограничено лишь ФГМ простором воображения и здравого смысла участников!
Прошу высказывать идеи и мысли на тему.

2

Производных очень много, и далеко не все признаки родителя могут быть у потомка. Как то дорога (highway) имеет член “количество полос для движения”, от этого класса будет наследоваться тропа (а это именно так и произойдёт, даже если вы не хотите, но юзеры так и сделают), но она такого члена иметь не может в силу своей неприспособленности для движения ТС, тогда придётся лезть в родителя, и дополнительно объяснять, что “число полос” - есть “число полос для движения именно ТС”, тогда в “тропе” это будет =0, но тогда конвертеры (условно скажем, что это они занимаются “применением данных ОСМ на практике”) скажут “что это за дорога, которая совсем не дорога?” И опять упрёмся в тягомотину уточнений, костылей и прочих дел, которые вместо “мапить для души” превращают ОСМ “ты сюда не ходи - вот тебе JOSM - сиди ешь кактусы, но делай только так и под присмотром программы”.
Ну не говоря про то, что полосы для движения ещё как-то могут начать описывать, да так, что их придётся вынести в отдельный класс.
ИМХО, идея имеет право на жизнь при наличии адекватных модераторов, которые оперативно меняют “базовые классы”, но ни как не через пропозалы, котрые по году ходят туда-сюда и ни к чему не приходят. А народ, вновь пришедший, как мапил под рендер, так и будет это делать. И highway=primary на здании поликлиники будет до тех пор, пока он будет рисоваться красным в мапнике на главной.

3

Если нет проблем, то отлично, давай урл API, потрогаем.

4

Давайте без трололо, ок? Если бы было апи, я бы дал урл. Мне казалось очевидным, что здесь изложена идея.

5

А вообще ты описываешь схему Википедии. Там любая категория (то есть тэг по сути) может входить в любую другую. Надо делать удобный ГУЙ для навигации и редактирования такой паутины тэгов.

6

(поправка: “для навигации по такой паутине”)

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

Чтобы что-то конкретное сделать, можно попрообовать в JSON написать текстом дерево тэгов и запостить сюда.

На Питоне я бы сделал так:

tags = {
    ('school', 'дюсшыр'): set([('amenity', 'school'), ('leisure', 'sports_centre')]),
    ('leisure', 'хоккейная коробка'): set([('leisure', 'pitch'), ('sports', 'ice_hockey'), ('sports', 'ice_skating')])
}

По-моему, надо поискать приложения на js, где такие схемы можно делать.

7

На самом деле, все эти тропинки и полосы — лишь вопрос детализации онтологии.

8

А на чем это должно быть написано?

9

На самом деле тут всплывает классическая дилемма ООП is-a vs has-a, т.е. “наследование” vs “включение”. Опыт показывает, что наследование часто используется неправильно, вместо использования включения. В итоге получаются кривые иерархии с избыточными связями и неприменимыми свойствами, когда свойство базового класса неожиданно становится неприменимым к наследнику. Стоит ли тянуть это в OSM - не уверен. В опытных руках это мощное средство, но его слишком легко применять некорректно, что может быть губительно для коллективного проекта.

10

Наследование используют вместо аггрегации просто потому что так большинству понятнее. Тянуть стоит но что значит тянуть в осм? Рядышком сложим :slight_smile:

Этож продолжение темы про TOSM, правильно я понимаю?

11

Черновичек


<?xml version="1.0" encoding="UTF-8"?>

<document>
	<name>trololo</name>
	<version>0.1</version>
	<description>Черновик документа бла бла бла</description>
	
	<elements>
		<!-- id можно и циыерками заменить, но осмысленный - тоже хорошо -->
		<element id="water_polygon">
		
			<description>Водное пространство</description>
			
			<note>Бла бла бла</note>
			
			<!-- позднее тут можно будет добавить более хитрые ограничения применимости тега -->
			<applyed-to>
				<osm-closed-way/>
				<osm-relation type="multipolygon"/>
			</applyed-to>
						
			<mandatory-kv id="mkv1" key="natural" value="water"/>
			
			<tag id="mt1" mandatory="true" tag-key="some-key" description="Характеристика воды с селектом">
				<tag-value value="Значение селекта 1" description="Значение селекта обозначающее бла бла бла 1"/>
				<tag-value value="Значение селекта 2" description="Значение селекта обозначающее бла бла бла 2"/>
			</tag>

			<tag id="mt2" mandatory="true" tag-key="name" description="Название объекта" multilingual="yes" multilingual-pattern="key:XX" />
			
			<!-- Тоесть обязательно проставить да или нет -->
			<tag id="mt3" mandatory="true" tag-key="some-bool-attr" description="какой-нибудь булевый атрибут" >
				<tag-value-yes-no />		
			</tag>
			
			<tag id="ot1" mandatory="false" tag-key="some-bool-attr2" description="какой-нибудь булевый атрибут 2" >
				<tag-value-yes-no />		
			</tag>
			
		</element>
		
		<element id="river_polygon">
			
			<!-- С наследованием правда есть вопрос, стоит ли наследовать ограничения применимости. 
			     Пример написан в расчете что они наследуюся -->
			
			<element-parent id="water_polygon" >
				<exclude-tag id="mt2" />
				<substitude-tag id="mt1" value="Значение селекта 1"/>
			</element-parent>
			
			<element-parent id="something_else" />
		
			<description>Полигональная речка</description>
			
			<note>Бла бла бла про речки</note>
			
			<mandatory-kv id="mkv1" key="water" value="river"/>
			
			<tag mandatory="false" tag-key="watershed" description="речной бассейн" multilingual="yes" multilingual-pattern="key:XX" />	
			<tag mandatory="false" tag-key="gvr:code" description="код учета бла бла" />
			
			<tag mandatory="false" tag-key="tidial" description="Пересыхает ли речка" >
				<tag-value-yes-no />
			</tag>
		</element>
		
	</elements>
</document>
12

Это не продолжение про TOSM, это вариация на тему) TOSM это справочник как никак, а тут по сути стандарт тегирования заложенный программно, жаль что реалии мне кажутся похожими на слова SergeyA

13

Какую проблему это решает? На кого нацелено это решение? Кто будет этим пользоваться? В чём это конкретно выльется (новый совершенный мапник, удобство редакттирования)?

14

Какую проблему решают структуризация и формализация данных? Машиночитаемость.

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

Пользоваться будут, соответственно, поставщики и пользователи данных. Да, говоря о ФМГ, я имел в виду то, о чём вы сейчас подумали.

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

15

Такая идея на freebase.com, например.
Можно создавать типы и на их основе записи.
Интересно там всё, но реализация кривовата.

Кстати, для OSM можно было бы использовать их же типы.
Вообще, для описания этого есть всякие RDF, OWL и прочее.

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

16

Да, кстати, давно кошусь в сторону точки доступа SPARQL для осма.

17

Выльется в необходимость паттернов типа фабрика :3

18

Ну так и сделайте супер-мега формат файлов, который строиться из базы ОСМ, что бы рендеры работали не с осмом, а с этим файлом. Как по мне так и изменение API ОСМа и т.п. для этого не нужно;).
А прописывание всяких наслед. классов запутает ещё больше, чем текущая схема тэгов.

19

Вы явно не читали первое сообщение.

20

Согласен с Sergey Astakhov; боюсь, что с данной схемой принцип Барбары Лисков не сработает, а когда он не срабатывает - получаем гарантированный ужос. Я в своей программистской практике категорически избегаю наследования каких-либо данных и состояний. Но я не претендую на объективность по отношению к данному случаю.