Реки и пруды

mguzelevich · 2010-12-17T08:21:11.000Z

Scaurr0ck:

Еще такой вопрос возник, если граница административного деления проходит по реке, можно ли соединять их точки (границы и реки). Или надо отделять?

сделать релейшен границы в который включить отрезок реки - пример г. Гродно - http://www.openstreetmap.org/browse/relation/130921

Sergey_Astakhov · 2010-12-17T08:23:31.000Z

Hind:

Э… В OSM пересекающиеся на одном уровне физические объекты должны иметь общие точки, нет?

Не обязательно. Я хочу понять, какой в этом практический смысл?

Sergey_Astakhov · 2010-12-17T08:25:54.000Z

Scaurr0ck:

Еще такой вопрос возник, если граница административного деления проходит по реке, можно ли соединять их точки (границы и реки). Или надо отделять?

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

AlRight · 2010-12-17T08:30:34.000Z

Sergey Astakhov:

Hind:

Э… В OSM пересекающиеся на одном уровне физические объекты должны иметь общие точки, нет?

Не обязательно. Я хочу понять, какой в этом практический смысл?

Река впадает в пруд. И вытекает из него. Оставаясь, при этом, рекой.
Если речь о применимости для какой-то пользы, кроме рендеринга - то, например, для определения, в специализированном под нужды “водной” навигации, устройстве - можно ли приплыть в этот пруд по этой реке.
Как-то так, имхо

Vort · 2010-12-17T08:45:17.000Z

Fortress:

Линия реки (waterway=river) должна проходить сквозь пруд + должна иметь общие точки с полигоном пруда на “входе” и “выходе”. Это нужно для речной навигации.

хороший ответ, спасибо
вопрос какие теги вешать - waterway=riverbank или natural=water ?
я полагаю что riverbank, так как пруд это всё же часть речки

ещё есть сходный вопрос про максимальную длину и сегменты
но я так понял общего решения пока ещё не придумали

Fortress · 2010-12-17T08:49:34.000Z

если вся остальная часть реки имеет riverbank то конечно лучше эргономично вписать в это дело и пруд.

Hind · 2010-12-17T08:53:29.000Z

Sergey Astakhov:

Hind:

Э… В OSM пересекающиеся на одном уровне физические объекты должны иметь общие точки, нет?

Не обязательно. Я хочу понять, какой в этом практический смысл?

Что-то я не могу вспомнить примеры, где это необязательно.

Ilis · 2010-12-17T08:55:29.000Z

Поскольку река и пруд это разные вещи, и обозначать их надо по разному. Берег реки – riverbank, пруд (искусственный водоём) – landuse=reservoir, озеро (естественный водоём) natural=water.

Sergey_Astakhov · 2010-12-17T09:23:00.000Z

Hind:

Sergey Astakhov:

Hind:

Э… В OSM пересекающиеся на одном уровне физические объекты должны иметь общие точки, нет?

Не обязательно. Я хочу понять, какой в этом практический смысл?

Что-то я не могу вспомнить примеры, где это необязательно.

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

Hind · 2010-12-17T09:28:47.000Z

Жилой район, границы парков - не физические объекты. Границы лесов тоже - деревья-то стоят отдельные.
Граница газона тоже скорее нет, чем да.

Что значит, какой практический смысл? Именно для того, чтобы отличать пересекающиеся объекты от непересекающихся. Вы думаете, просто так josm validator обращает внимание пользователя на пересекающиеся линии без общих точек?

Sergey_Astakhov · 2010-12-17T09:33:37.000Z

Hind:

Жилой район, границы парков - не физические объекты. Границы лесов тоже - деревья-то стоят отдельные.
Граница газона тоже скорее нет, чем да.

Граница озера, проходящая по устью впадающей реки - тоже не есть физический объект.

Hind:

Что значит, какой практический смысл? Именно для того, чтобы отличать пересекающиеся объекты от непересекающихся.

Для чего это нужно для объектов разных сущностей?

Hind:

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

У josm validator много разных false positives. Он и на коды кладра ругается, это же не повод их всех удалить?

Diomas · 2010-12-17T10:45:14.000Z

Hind:

Sergey Astakhov:

Hind:

Э… В OSM пересекающиеся на одном уровне физические объекты должны иметь общие точки, нет?

Не обязательно. Я хочу понять, какой в этом практический смысл?

Что-то я не могу вспомнить примеры, где это необязательно.

А разве дорога, идущая через полигон natural=wood, должна иметь с ним общие точки?

Fortress · 2010-12-17T10:46:21.000Z

Sergey Astakhov:

Hind:

Что значит, какой практический смысл? Именно для того, чтобы отличать пересекающиеся объекты от непересекающихся.

Для чего это нужно для объектов разных сущностей?

Пример: дорога, проходящая через границу двух стран/регионов/городов. При обрезке по границе линии, выходящие за пределы границы отбрасываются (в том числе и тот кусок, который находится внутри вырезаемой площади). Справедливо для osmosis без completeWays. Если бы дорога имела общую точку с границей и была бы в этой точке разбита на 2 вея, проблем бы не было никаких. С completeWays тоже не красиво (торчат лохмотья). Так что лично я за создание общих точек, если это никому не мешает.

Sergey_Astakhov · 2010-12-17T10:56:23.000Z

Fortress:

Sergey Astakhov:

Hind:

Что значит, какой практический смысл? Именно для того, чтобы отличать пересекающиеся объекты от непересекающихся.

Для чего это нужно для объектов разных сущностей?

Пример: дорога, проходящая через границу двух стран/регионов/городов. При обрезке по границе линии, выходящие за пределы границы отбрасываются (в том числе и тот кусок, который находится внутри вырезаемой площади). Справедливо для osmosis без completeWays. Если бы дорога имела общую точку с границей и была бы в этой точке разбита на 2 вея, проблем бы не было никаких. С completeWays тоже не красиво (торчат лохмотья). Так что лично я за создание общих точек, если это никому не мешает.

Этот пример понятен и проблем не вызывает. Как минимум потому что юридически дороги по разные стороны этих границ суть разные объекты.
Я всё к тому, что нет в OSM универсального правила создания общих точек во всех местах пересечений каких бы то нибыло объектов - всё зависит от того какие именно это объекты.

dedNikifor · 2010-12-17T13:31:21.000Z

Diomas:

Hind:

Sergey Astakhov:

Не обязательно. Я хочу понять, какой в этом практический смысл?

Что-то я не могу вспомнить примеры, где это необязательно.

А разве дорога, идущая через полигон natural=wood, должна иметь с ним общие точки?

ни в коем случае

LLlypuk82 · 2017-04-14T21:55:26.000Z

Хочу узнать мысли участников на предмет ~~введения~~ восстановления (одобрения) и применения ~~новой~~ роли для членов отношения type=waterway.
А именно — ~~water_area~~ waterbody, для полигонов и мультиполигонов, обозначающих акваторию рек. Нето получается (как это часто бывает): сказали «а», но сказать «б» не получилось. Если уж собирать реку, то делать это «от и до». Сейчас самая «маленькая» деталь более-менее заметной (и тем паче — крупной) реки выпадает из «конструктора».
P. S. Эти отношения вообще нужны кому-нибудь (и если «да» — как используются и кем?)
P. P. S. Сам вижу полезность (в т. ч.) для корректной отрисовки рек, которые периодически впадают, а потом вытекают из озёр (это в суперсветлойперспективе, когда перейдём сугубо на отношения, без кусков-отрезков с дублированием тегов).
»Для предметного рассмотрения«
UPD Внёс корректировку в связи с обнаружением отвергнутой (под предлогом «редкого использования» и «спорности») уже имевшейся и применявшейся соответствующей роли.

pfg21 · 2017-04-15T21:33:20.000Z

я - за расширение отношения type=waterway и включение членов полигон реки.
под waterbody понимаются замкнутые линии или отношения с natural=water + water=river ?? может сразу outer/inner ??

LLlypuk82 · 2017-04-15T23:20:52.000Z

LLlypuk82:

для полигонов и мультиполигонов, обозначающих акваторию рек.

И линии, и отношения. Включается то, что описывает геометрию водной поверхности. Фактически не требуется расширение как таковое. Достаточно активной практики применения того, что уже есть. Ну и попутно убрать из вики ерунду с «непринятостью» данного подхода. Хоть бы один аргумент был толковый. А то «не принимаем, потому что редко используется, а редко используется, потому что не принято».

Vort · 2017-04-16T13:53:26.000Z

С вики:
“Some arguments against that roles again: Impossible to maintain You will never get complete waterways with it’s waterbodys. Hard to work with: as soon as you add riverbanks to relations you can no longer download them. e.g The Amazonas has a neat small relation (without waterbodies), but if you add riverbanks it will become useless. Redundant: As soon as you have the centerline of the river, a computer can collect all waterareas that are intersected by the centerline. Destroying applications: Wikipedia shows the rivers in the map using the relations (WIWOSM). It just causes troubles if you add stuff that is not part of the river … or not necessary to describe it.”

от себя ещё добавлю:

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

ну и после включения waterbody может захотеться ещё какие-то объекты на реке включить
в итоге релейшен с чётко очерченными функциями превратится в плохоподдерживаемого (maintain в тексте выше) монстра

LLlypuk82 · 2017-04-16T18:36:33.000Z

Vort, вы к четырём совершенно надуманным доводам прибавили ещё два.
Кому «трудно» работать или «невозможно» обслуживать — не делают этого (это ведь не трудно — не делать ничего?). Также, как мало кто занимается созданием маршрутов ОТ, например, или тегированием под 3-D рендеринг, или indoor. Кстати, упомянутое обслуживание становится проще, потому что появляется возможность одним движением мыши загрузить полный набор данных по отдельной реке.
О какой избыточности речь? В отношение включается (на мой взгляд — совершенно естественным, логичным образом) то, из чего состоит водный объект «река».
«Падение/уничтожение» приложений — откуда сведения о таких последствиях и при чём тут wikipedia? Все известные мне приложения замечательно справляются с отображением полигонов и мультиполигонов воды, а включение их в другое отношение никаким образом повлиять на это не может.
Водохранилище или озеро — самостоятельные объекты (другие сущности, со своими названиями обычно), сопряжённые с рекой. На мой взгляд их включать не стоит.
В местах впадения очерчиваем траекторию течения основной реки (в кот. впадает другая). Примерно как на нестандартном перекрёстке рируют разметку полос для движения. Нет в этом никакой проблемы, зачем их выдумывать и притягивать за уши?