Реки и пруды

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

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

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

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

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

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

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

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

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

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

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

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

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

С вики:
“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 в тексте выше) монстра

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

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

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

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

Да

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

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

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

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

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

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

И правильно делают.
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank

  1. Если река рисуется полигоном, то линию реки желательно отрисовать как можно ближе к тальвегу (если его возможно определить, например, при низкой воде), либо - для судоходных рек - по фарватеру.
  2. Должна быть сохранена топология реки, аналогично дорожной сети.

Т. е. топология подгоняется под гипотетическую маршрутизацию. По аналогии, когда площадной тротуар или дорога дублируются линейными.
А существует такая маршрутизация? (по рекам).
P. S. Ещё забыл: когда река меняет название (т. е. впадает одна, а вытекает — другая), то какова будет топология?

Если знаете примерное положение русел - меняете а местах впадения / слияния. Если не знаете - на глазок “best as possible”.

Русла рек можно определять по

  • старым картам, у которых возраст > 70 лет
  • снимкам Corona, которые в public domain (для молодых водохранилищ, заполненых не ранее 60-х г.)