Add a water layer

[dschep]

With the layers currently available, you could almost make a map, except that you wouldn't have any water bodies!

[jake-low]

Definitely open to adding a water layer. Some questions for you (and anyone else who's interested in such a layer):

• Should it contain water areas only, or also waterway lines? How about water-related POIs like locks, dams, waterfalls, boat launches, etc?
• What columns should be included?
• What are the use cases for this layer? Cartography is one you already mentioned, but Layercake's main purpose is to allow you to easily export specific types of OSM data for analysis (e.g. hydrography), or to use in applications like search or geocoding. Identifying the use cases for water features would probably help us decide which features and tags to include.

[dschep]

• I would expect areas and lines. Hadn't though of the others
• name, "type", intermittent.. 🤔
• I didn't realize what the main purpose was. That def would be reason to include waterway lines!

[jake-low]

To clarify, I think both water areas and waterway lines should be available through Layercake; the question is whether they should live together in a single water layer or separately (in say waterbodies and waterways layers). And which additional feature types should be included in those files.

The current highways layer includes everything in OpenStreetMap with a highway=* tag. This includes roadways but also point features like turning circles, streetlamps, and trailheads, and area features like rest stops. This seems to work pretty well, and gives data consumers more flexibility than it would if we applied some filter criteria at build time (they can filter themselves however they want when downloading the data). So similarly, I could see an argument for a waterways layer to include everything tagged waterway=* which includes water flowlines but also waterfalls, dams, locks, etc.

For water areas, which are tagged differently in OSM (natural=water), the question is whether they should have their own layer or whether they should be included in the same layer as waterways.

Also, I presume that most data consumers who want lakes also want oceans, which are modeled implicitly in OSM (by enclosing them in natural=coastline ways). Layercake would need to reassemble these into polygons using e.g. https://osmcode.org/osmcoastline/ and then emit the ocean as a polygon (or more likely, slice it up into a grid, since a single enormous polygon would be painful to work with).

[dschep]

I'm inclined to say one big layer similar to highways containing both roads and road points.

and good point re: coastlines !

[ratmice]

I've been working towards making some maps for kayaking, because many federal maps don't contain POI's like boat ramps outside of the federal area. These are georeferenced pdf output.

One example:
https://www.fs.usda.gov/sites/nfs/files/legacy-media/siuslaw/Trail%20Map%20%20Siltcoos%20Area%20Trails.pdf
If you look at that area in osmus https://opentrailmap.us/#map=14/43.87758/-124.13959
You'll see that there is a boat ramp within the maps bounds not pictured because it is on county land just outside the federal land.

I'm not sure about including water related POI's, I do need boat related POIs like boat launches/slipways, but there are also other non boat specific POIs that I would need (restrooms, camp sites, drinking water). Such that I think leaving these POIs/amenities to their own layer might be better. I guess the concern is if I'm dealing with non-water POIs across multiple layers,
there is potential that we'd now have deal with multiple duplicate instances of the same POI.

I wonder if it would be better to just leave coastlines out, and leave them to their own layer too, i'm not sure how big and detailed the coastline data is or if it's big enough to matter (not currently far enough along to use it).

Currently I've been using a osm.pbf to geoparquet conversion, but since we're generating maps for such small areas
We currently only use small portions of the osm data we download. So if we could refer to geoparquet files, and only download the areas overlapping the relevant bbox. That would probably make it sustainable enough that we could just generate our georeferenced pdfs from within the CI and git.