You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collecting issues that require deviating from the standard OpenMapTiles schema, or where the Planetiler implementation doesn't match the OMT spec.
PR #134 is a candidate implementation of a custom Planetiler profile on the new tilegen pipeline (replaces #133). It covers railways from zoom 6, via ferratas, extended path tags and hiking routes.
Need a custom profile (not in standard OMT schema)
Planetiler has two ways of adding custom information to the tiles: yaml config or java class.
Yaml gives less control and seems like it is intended for defining fully new layers not altering existing onces, as a result my attempts of adding sac_scale to paths that have it resulted in duplicated lines in the layer.
So I've tried to write a custom java class with a couple of goals in mind:
Adding a new "feature" to the map should not require custom logic for every feature.
Configuration should be somewhat straight forward if possible.
Expanding on a features information should not create a duplicate of said feature (example: adding sac_scale to a path should not cause a line on the map to still have the original value, this should help keep the tile sizes down).
Planetiler uses the term feature for any point, line, polygon it is processing.
what I've ended up with is a set of:
filters: used to check if incoming feature matches required conditions.
tag_maps: used to define the feature that should end up in the tiles that are being generated.
extractors: two constructs that bring filters and tag_maps together to actually process the incoming features into tile features.
I've designed this in an attempt to find a way to get tags for outdoor into the mbtiles, whilst keeping the openmaptiles spec in mind.
To prevent the double processing of features it doesn't allow planetiler to process a feature that it has processed it self.
The main issue with no custom logic should be required happens when trying to process hiking routes. as a result of the route_x_ref, route_x_name etc. that are present in the transportation_name layer. to solve this I've added a lambda processor that can be added to the config of mapping relations onto a layer.
A previous iteration was posted in #31 but this is a significant rewrite, a few of the open issues that could be fixed with this were also tagged over there.
The main downside I see in this system is that right now it doesn't allow for overwriting the bypass of the default processing.
Overall this system should be flexible enough to fix multiple open issues regarding information missing from the map and deviating from the openmaptiles spec in general.
I could make further changes to it if you are interested in using this for deviating from openmaptiles.
Any configs defined up top are just there for testing / as examples of how to use it.
One of the things that should possibly be added is a way to set zoom levels of features.
The main issue issue with solving these issues is determining which tags to include.
I've reworked my previously linked code to be more flexible.
It can now actually add new tags to the base Planetiler profile and it supports for setting the zoom levels of features and individual tags within a feature.
I've just shipped a major refactor of the whole project. The tilegen pipeline is rebuilt from scratch and there's now a clean integration point for a custom Planetiler profile in tilegen/tilegen_lib/planetiler.py. Production still uses the standard OpenMapTiles profile for now.
Updated the issue body with all related requests, grouped by whether they actually need a custom profile or might be gaps in Planetiler's OMT implementation.
Thanks for the trust! I have no idea about planetiler though, and some unread emails which may help me understanding how to fix things in the spec. I have a list of shortcomings, where the tiles are not aligned with the yaml files, if you are interrested. The OMT folks have been positive to fixing, but it seems not to actually fix things themselves.
The problem with straits is that only one form of the tag is included - point. Straits can be points, linestrings or areas (including relations). Place=ocean are points, and there are exactly 5 of them, according to the osm wiki.
Look into planetiler, it's an amazing tool. Ask your favourite agenic harness like pi.dev to make a git clone and explore the codebase, it can tell you what it can and cannot do. I mean this whole thread is about fixing things in OMT without requiring the upstream project to agree with our decisions.
If the goal is to get a similar setup to the lake centerlines, where you get a (curved) line that has the localized names for oceans, this is not provided by OSM.
I believe the lake centerlines are a custom dataset used by planetiler, doing the same for oceans should be possible once the custom profiles are in.
@anderslundx: What exactly was the issue with the strait?
I seem to remember it being pressent in the mbtiles as polygon but not as a line?
There was a fix that would add those lines in PR #133
I know what I can see comparing my own map with carto and OMT maps on osm.org, and from looking at the osm wiki and using overpass turbo.
In my own map (using ofm tiles) I can find straits tagged as points in the osm data. Not straits mapped as areas (like Als Sund) or linestrings (like Svendborg Sund). Carto displays both, though the area ones are converted to a (center-) point, where a string would be much better.
I can see #133 was closed a few hours ago - I will see the changes when the map tiles are updated.
The problem apperas (to me) to be related to objects tagged differently (point/string/area) in the osm data, som objects does not end in the tiles. This probably affects other objects than straits as well.
Another issue is with where the data for the OMT subclass field is taken from, an example is wetlands. Most wetland areas in OMT tiles have subclass wetland, bc the correct data is not collected, so no way to spearate various types of wetands, although a list of subclasses are mentioned in the yaml files (landcover, water layers, maybe also water_name).
Activity
NoPlanNomad commentedon May 31, 2026
Planetiler has two ways of adding custom information to the tiles: yaml config or java class.
Yaml gives less control and seems like it is intended for defining fully new layers not altering existing onces, as a result my attempts of adding sac_scale to paths that have it resulted in duplicated lines in the layer.
So I've tried to write a custom java class with a couple of goals in mind:
Planetiler uses the term feature for any point, line, polygon it is processing.
what I've ended up with is a set of:
I've designed this in an attempt to find a way to get tags for outdoor into the mbtiles, whilst keeping the openmaptiles spec in mind.
To prevent the double processing of features it doesn't allow planetiler to process a feature that it has processed it self.
The main issue with no custom logic should be required happens when trying to process hiking routes. as a result of the route_x_ref, route_x_name etc. that are present in the transportation_name layer. to solve this I've added a lambda processor that can be added to the config of mapping relations onto a layer.
A previous iteration was posted in #31 but this is a significant rewrite, a few of the open issues that could be fixed with this were also tagged over there.
The main downside I see in this system is that right now it doesn't allow for overwriting the bypass of the default processing.
Overall this system should be flexible enough to fix multiple open issues regarding information missing from the map and deviating from the openmaptiles spec in general.
I could make further changes to it if you are interested in using this for deviating from openmaptiles.
Any configs defined up top are just there for testing / as examples of how to use it.
One of the things that should possibly be added is a way to set zoom levels of features.
repository with the custom profile
NoPlanNomad commentedon Jun 4, 2026
The following issues also seem to relate.
#31 #77 #103 #115 #116 #117
The main issue issue with solving these issues is determining which tags to include.
I've reworked my previously linked code to be more flexible.
It can now actually add new tags to the base Planetiler profile and it supports for setting the zoom levels of features and individual tags within a feature.
hyperknot commentedon Sep 4, 2026
I've just shipped a major refactor of the whole project. The tilegen pipeline is rebuilt from scratch and there's now a clean integration point for a custom Planetiler profile in
tilegen/tilegen_lib/planetiler.py. Production still uses the standard OpenMapTiles profile for now.Updated the issue body with all related requests, grouped by whether they actually need a custom profile or might be gaps in Planetiler's OMT implementation.
hyperknot commentedon Sep 4, 2026
Outdoor-related data/tag requests from the discussion in #31:
sac_scale,trail_visibility,surface,tracktypeon paths/trailsvia_ferrata_scaleandhighway=via_ferratatype=route,route=hiking) with network hierarchy (iwn/nwn/rwn/lwn), name, ref, colour, osmc:symboltourism=alpine_hut,tourism=wilderness_hut,amenity=shelterin POI layerhighway=trailheadas POI@ravenfeld and @NoPlanNomad have working custom profile code in #31 that covers most of these. PR #133 is a separate attempt at the same thing.
anderslundx commentedon Sep 5, 2026
Regarding ocean names (#116):
Ocean names are not in the tile data. They are mentioned in the water_name layer here: https://github.com/openmaptiles/openmaptiles/blob/master/layers/water_name/water_name.yaml
I use a plugin that shows all data in the tiles at current level, and I can find no sign of ocean names.
I would have to create an account with maptiler to be able to check if they are in the OMT tile data.
I have two style layers that are relevant, one covering linestrings and one for points, limited to a few classes:
Other water bodies of type point and class sea, bay or strait are visible in my map.
Thanks for caring!
anderslundx commentedon Sep 5, 2026
Regarding straits tagged as polygons and linestrings (#115)
It's not in the data, so a problem with the schema. An error, because these are in the water_name.yaml file, same with ocean names.
hyperknot commentedon Sep 5, 2026
@anderslundx you seem to understand a lot about this topic. Which of these do you think is fixable easily by a custom planetiler profile?
I mean we'll be adding a custom profile/OMT mod soon, but its not clear what your "custom plugin" does. #115 can be done by profile?
anderslundx commentedon Sep 5, 2026
Thanks for the trust! I have no idea about planetiler though, and some unread emails which may help me understanding how to fix things in the spec. I have a list of shortcomings, where the tiles are not aligned with the yaml files, if you are interrested. The OMT folks have been positive to fixing, but it seems not to actually fix things themselves.
The problem with straits is that only one form of the tag is included - point. Straits can be points, linestrings or areas (including relations). Place=ocean are points, and there are exactly 5 of them, according to the osm wiki.
hyperknot commentedon Sep 5, 2026
Look into planetiler, it's an amazing tool. Ask your favourite agenic harness like pi.dev to make a git clone and explore the codebase, it can tell you what it can and cannot do. I mean this whole thread is about fixing things in OMT without requiring the upstream project to agree with our decisions.
NoPlanNomad commentedon Sep 5, 2026
Regarding the oceans.
If the goal is to get a similar setup to the lake centerlines, where you get a (curved) line that has the localized names for oceans, this is not provided by OSM.
I believe the lake centerlines are a custom dataset used by planetiler, doing the same for oceans should be possible once the custom profiles are in.
@anderslundx: What exactly was the issue with the strait?
I seem to remember it being pressent in the mbtiles as polygon but not as a line?
There was a fix that would add those lines in PR #133
anderslundx commentedon Sep 5, 2026
I know what I can see comparing my own map with carto and OMT maps on osm.org, and from looking at the osm wiki and using overpass turbo.
In my own map (using ofm tiles) I can find straits tagged as points in the osm data. Not straits mapped as areas (like Als Sund) or linestrings (like Svendborg Sund). Carto displays both, though the area ones are converted to a (center-) point, where a string would be much better.
I can see #133 was closed a few hours ago - I will see the changes when the map tiles are updated.
The problem apperas (to me) to be related to objects tagged differently (point/string/area) in the osm data, som objects does not end in the tiles. This probably affects other objects than straits as well.
Another issue is with where the data for the OMT subclass field is taken from, an example is wetlands. Most wetland areas in OMT tiles have subclass wetland, bc the correct data is not collected, so no way to spearate various types of wetands, although a list of subclasses are mentioned in the yaml files (landcover, water layers, maybe also water_name).
hyperknot commentedon Sep 5, 2026
@anderslundx can you post screenshot of all examples you are referring to? Both good and bad?
anderslundx commentedon Sep 5, 2026
Als Sund, which is an area

Svendborg Sund, which is a linestring
Siø Sund, which is a point
hyperknot commentedon Sep 5, 2026
Thanks, this is great reference, when we'll get there to have these fixed properly.
anderslundx commentedon Sep 5, 2026
What I see/look for is the name, from water_name, either point or linestring, ofc.