Hi Amanda, Thank you for this additional piece of very useful tool :)
> WWM/ends excludes canals. It's ok but it includes pressurised waterways and these nodes are flagged as ends : https://www.openstreetmap.org/node/2255728449/ I'd like to include canals instead of removing pressurised waterways (which connect to upstream rivers and it could lead to other mistaken ends too). Isn't this an opportunity to check the appropriate usage of inlet/outlet values and man_made=outfall as well? https://wiki.openstreetmap.org/wiki/Key:inlet https://wiki.openstreetmap.org/wiki/Key:outlet https://wiki.openstreetmap.org/wiki/Tag:man_made%3Doutfall Best regards François Le lun. 29 janv. 2024 à 21:04, Amanda McCann <ama...@technomancy.org> a écrit : > I've added a new feature to [WaterwayMap.org: A map showing where > waterways end](https://waterwaymap.org/ends/), i.e. a map of the > ends-of-waterways 🙂. > > It shows nodes which are “the end” of a waterway, i.e. where the water > can't go anywhere else. Uniquely, it calculates the total upstream length > of waterway ways which end at a point. It uses the direction of OSM ways, > and how they are connected. This should make larger mistakes more visible. > Like the rest of WaterwayMap.org, data is updated daily, at the same time. > > It's normal for there to be ends, like when a river ends at a coastline. > This will rightly show up on WWM:Ends. When a river empties into a lake, > this will also show up, unless we've mapped a waterway through the lake. > There's [active discussion]( > https://community.openstreetmap.org/t/should-river-lines-be-mapped-through-lakes-estuaries-gulfs-and-other-large-water-bodies/104438) > on when & how to do that. > > # Merging & Splitting > > When 2+ waterways come together, the upstream value is added together. > When 2+ waterways split, the upstream value is split equally. This mostly > works well, e.g. when a river splits through a side channel, and then > rejoins. > > If you have a small stream going into a large river, and it's in the wrong > direction, then half the upstream value from the big river will go off to > the side stream. This is a mapping mistake, and this tool makes it easier > to find them. e.g. [way 962171457]( > https://www.openstreetmap.org/way/962171457/history) is mapped as flowing > *out* of the Nile, so it's taking 17,000 km of upstream away! [on > `wwm/ends`](https://waterwaymap.org/ends/#map=13.8/17.96527/33.98571). > This direction should probably be reversed. > > Conversely, [this way]( > https://www.openstreetmap.org/way/67963223#map=19/52.66517/-8.62906) is > taking half (930 km) of the Shannon [wwm/ends]( > https://waterwaymap.org/ends/#map=15.34/52.66393/-8.627153). I don't > think this should count as an “end”, but the mapping looks ok. WWM/ends > excludes canals. I'm unsure if it's possible to calculate the right value. > Perhaps more advanced tag calculations. What do yous think? > > I hope you enjoy this new map & we all improve OSM together. 🙂 > > # See also > > • a short description of [how it works]( > https://waterwaymap.org/ends/help/). > • [News about WaterwayMap.org]( > https://en.osm.town/@amapanda/tagged/WaterwayMapOrg) can be found on > Mastodon/Fediverse (incl. [Atom/RSS feed]( > https://en.osm.town/@amapanda/tagged/WaterwayMapOrg.rss)): > • This code is on Github: [`amandasaurus/waterwaymap.org`]( > https://github.com/amandasaurus/waterwaymap.org). [New issue reports]( > https://github.com/amandasaurus/waterwaymap.org/issues) are welcome. > • The programme which generates it is [`osm-lump-ways`]( > https://github.com/amandasaurus/osm-lump-ways) > > -- > Amanda > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
