Reconstruct a single way based on multiple ways that share a common tag

[BenOnTrack]

I'm trying to build a single way object and store it in a tile (to be able to query it later on).
This way should be built based on a collection of others connected ways that share a common tag. In the following example, all ways have the name "Karamatura Track"

• https://www.openstreetmap.org/way/849160224
• https://www.openstreetmap.org/way/849160225
• ...(and so on)

The objective is to collect the hiking trail "Karamatura Track" in a single unique way, that could then :

• be queried
• be styled (while others similar ways would remain intact)
• ...

Is there any way with tilemaker to answer such requirement, as in keeping a buffer of each ways encountered and then working with them in a second step ?

As of now I'm using osmium with 2 handlers, one that records all ways of interest (in this case, highway=path, and name!=nil), and then a second handler that, based on each name collected, collects all others ways (such as steps, bridge, track, ...) and reconstruct each way - but it would be much more efficient if I could handle such kind of request directly when processing my .pbf and building all my other tiles

Also if it makes "more sense" to understand what I'm trying to achieve, just see it as if i was trying to create "missing" OSM relation

[systemed]

You should be able to do that by writing an object to a layer with just that name attribute, no others, then using tilemaker’s combine_below setting which automatically merges linestrings with the same attributes within the same layer.

[BenOnTrack]

Hi, thanks a lot, it looks like it might have worked. The layer looks good. It's hard to tell since as of now the only way I can query an object is with queryRenderedFeatures from mapLibre, which "splits" the rendered object in multiple ones. I've been struggling with that for a while and I understood that there wasn't any way to query the entire object with maplibre library (limited to the viewport - but it's another topic), and I've never been able to find other library to troubleshoot mbtiles.

[systemed]

You can use vt2geojson to debug individual vector tiles - then load the geojson into QGIS or geojson.io or whatever.

[BenOnTrack]

• thanks for the workaround - i like the idea of combining ways together but knowing that it limits the object to a single attribue might be too much of a limitation for my purpose. It's great to know that it works though!
• tilemaker generates mbtiles, and it seems that vt2geojson only works with mvt - I've been looking around and I'm not sure to understand how to go from one format to the other but anyway it's another discussion i'll open on stack.

thanks again

[systemed]

I might be misunderstanding but I can’t see what you want to do that is permissible by the vector tile format and that is different to what tilemaker can do.

A “single way object” (which in a vector role is basically a multilinestring) can only have a single set of tags (attributes) - you can’t have a single object that nonetheless has different attributes for each section.

But that aside, the method I described isn’t restricted to one single attribute - tilemaker merges features in the same layer with identical attributes.

An mbtiles file is a container of mvt tiles. You use an mbtiles server to serve out the individual mvts. So you might run a server on the mbtiles you’ve generated and then point vt2geojson to that, e.g. vt2geojson http://localhost/mytileset/9/75/245.mvt

[BenOnTrack]

You're totally right - I've just skipped part of what I was intending to do, and for instance i'd like to add an ID to each of those combined ways - which, unless i'm wrong, will not be possible to do with this workaround, since the combination occurs in a higher layer of the process. I'm still convince that the ways I'm trying to reconstruct should be directly combined as relation in OSM, but since that's not the case I don't have any other choices.

I was wondering if creating a layer with objects that already exist in other layers (for instance with your workaround, all the objects are already in my "highway" layer) could save some size compared to adding another specific mbtiles built with osmium ? If i build 2 layers based on the same objects, would that take twice the size or it's not that simple ?

I've managed to run vt2geojson! thanks again for your precious help.

[systemed]

Creating a layer with "duplicate" objects is absolutely a legit thing to do. I do that for cycle.travel's (mobile) vector map - the route highlights are a separate layer to the roads/paths themselves. Vector tile storage is quite space-efficient so it probably won't bloat your tile size noticeably.

[BenOnTrack]

Now that I understand how to build tiles that gather my ways, i'd like to find a way to query them. Thanks to your support, I found out that @vt2geojson or @mapbox/mbtiles was probably what I was actually looking for, since it can retrieve a tile at a specific z/x/y.
But some of my ways extend over multiple tiles, at some specific level. My idea is, knowing the latitude/longitude of the start (or end, or centroid) of my way (that would define my "starting tile"), I would probably need to randomly query tiles around that starting tile and identify in each of those tiles if any has the object (= layer + id) that i'm looking for. Where I'm slightly confused, is that it looks like there is not a tile for each x/y at a z level (which, thinking about it, could make sense to ... save size?).

For instance, I know that my way exists in the tile
const z = 14
const x = 16157
const y = 10005

my idea was to query the tile
const z = 14
const x = 16156
const y = 10005

to look for my way, and so on until I re-build the entire way to be able to export it, or post-process it.
Does that make sense ?

[systemed]

Yes - I do something fairly similar for the search feature in cycle.travel’s iOS app. Alternatively you could of course store the bounding boxes of the routes somewhere else if you know them ahead of time!

[BenOnTrack]

With the tilemaker solution you've provided above (combine_below), would there be an easy way to also compute the bbox (or any other property, such as creating an ID for the combined object) and save it as a properties within the mbtiles ?

I'm looking for a way to generate object that have in common:

• the same name
• an ID (computed) -> could be saved for each object with the name?
• a bbox (computed) -> ?

Or should I post-process the mbtiles first ?

Also what I'm struggling with my current solution (using osmium) is that if 2 objects have the same name,but are not related (imagine 2 hikes having the same name but being in different region) they would end up being combined in the same object.
Thinking about it, I guess that tilemaker would end up doing the same with the combine_below ? Unless it only checks for objects that are concurrent ?

[systemed]

combine_below basically looks for "same layer, same geometry type, same z-order, same attributes" within the same output tile. If all of those are true, then it'll merge the objects. The logic for this is in CheckNextObjectAndMerge in tile_worker.cpp. If you don't want them to be merged, then you'll need to set a distinct attribute.

In the example you gave, I wonder whether making the Karamatura Track into a route relation in OSM would be the way forward.

[BenOnTrack]

Thanks for the feedback - I'll see if I can tweak the function to make it work otherwise I'll stick to Osmium and will continue working on a workaround - i may have found a way with line_merge from shapely

When you say "...within the same output tile" -> then that could work, unless there are 2 non-concurrent linestring in the same tile.

Your comment makes total sense, and I've actually opened an OSM topic on this situation, but that's not going to solve my issue for now since we're talking about hundreds of "path" that are in the same situation (at least for New Zealand).