Реки и пруды

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? Все известные мне приложения замечательно справляются с отображением полигонов и мультиполигонов воды, а включение их в другое отношение никаким образом повлиять на это не может.
Водохранилище или озеро — самостоятельные объекты (другие сущности, со своими названиями обычно), сопряжённые с рекой. На мой взгляд их включать не стоит.
В местах впадения очерчиваем траекторию течения основной реки (в кот. впадает другая). Примерно как на нестандартном перекрёстке рируют разметку полос для движения. Нет в этом никакой проблемы, зачем их выдумывать и притягивать за уши?

Vort · 2017-04-17T03:49:28.000Z

О какой избыточности речь? В отношение включается (на мой взгляд — совершенно естественным, логичным образом) то, из чего состоит водный объект «река».

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

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

И будет в водной поверхности реки (по данным релейшена) дырка?

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

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

LLlypuk82 · 2017-04-17T05:52:15.000Z

Vort:

дырка?

Да

Vort:

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

Ничего не зависает. Подтормаживает.
Так что делать в таких случаях предлагаете? Озеро удалить, чтобы не зависало?

Vort · 2017-04-17T06:45:21.000Z

LLlypuk82:

Так что делать в таких случаях предлагаете? Озеро удалить, чтобы не зависало?

Не создавать тяжелых объектов без надобности.
Или хотя бы изолировать их так, чтобы было возможно обойти стороной.

Пример с “озером” привёл потому, что оно бы автоматом начало грузиться, если бы его кто-то включил в отношение Нила.

Интересно, кстати, было бы посмотреть на водную поверхность Днепра, если из неё убрать водохранилища.

freeExec · 2017-04-17T07:01:44.000Z

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

LLlypuk82 · 2017-04-17T09:23:12.000Z

Vort:

если из неё убрать водохранилища.

А в чём противоречие? Вот и посмо́трите: на Днепр и на водохранилища — отдельно. В том прелесть отношения waterway, что можно работать именно с самой рекой (русло и акватория), не трогая лишнее. При этом не важно, сколько разрывов: всё необходимое на отношении висит, исключая кашу из отрезков с кучей разношёрстных тегов. Сейчас кто во что горазд: кто-то добавляет названия на полигоны (речные), русла рек трассируют сквозь озёра/водохранилища. Река сначала впадает в водоём, а потом — вытекает, причём, может изменить название при этом. Это два разных объекта гидрографии. Объединяет их формально — название, а физически — та запруда (естественная или искусственная), с которой они сопряжены.