Comments (9)
I'm not as familiar with the nuances of the different use-cases here, would appreciate feedback from others with more experience mapping these!
from planetiler.
The principles I'd like to preserve in the current semantics of the YAML configurations are:
- An OSM element is selected if it complies with the
include_when
andexclude_when
definitions. When applied to relations of any kind, it means that only the tags of the relation are taken into account. - The geometry is created by descending from the selected element down to the nodes level. In the case of linestring geometries of relations, the geometry is obtained by descending trough other super-/relations and ways down to the relevant nodes.
- The tags are taken from the selected element
from planetiler.
Conceptually this makes sense. I'm wondering if we need additional flexibility to access and/or filter the ways that get included in the final shape by:
- tags on the ways
- role labels on the relation member elements
- tags on the relations contained in a super-relation (or superrelation member roles)
And also if there needs to be any built-in way to decide between a relation and superrelation, or if profiles can determine that entirely from the tags on them (for example see appalachian trail
from planetiler.
To accomplish that, in a general way, we could add the ability to refer to relation member role and tags.
For example, extracting only some of the segments of a route
include_when:
- network: ncn
geometry: linestring
include_members_when:
- highway:
- cycleway
- path
or for extracting country labels
include_when:
- admin_level: 2
geometry: point
include_members_when:
- @role: label
Note: this is not necessarily the best syntax.
When such member-based valued are used as attributes, using some new syntax, the geometry would split the relation into separate MultiLineString features according to the different values.
As for relation members that are relations themselves, I'm inclined to treat them as transparent, and flatten any nested relations. That would make the ways and node members of any relation seem as if they are members of any predecessor super-relation.
from planetiler.
OK got it, then if a profile wanted to limit the relation type they would just put an extra type
filter on include_when?
include_when:
- admin_level: 2
- type: boundary
I also wonder if we should make profiles opt-into this behavior? I'm trying to think if doing this by default would cause any issues if you're not expecting it?
from planetiler.
Also, we'd want to implement this capability in the java layer then have the yaml layer add an easier-to use API for it. I think it would make sense to build this as an extension to multipolygon handling, which currently does this:
pass1
- nodes: store the lat/lon of each node into
nodeLocationDb
disk-backed lookup table - relations: store a set
waysInMultipolygon
that contains way IDs that are a member of a multipolygon relation
pass2
- ways: if a way is in
waysInMultipolygon
then store its geometry inmultipolygonWayGeometries
, a disk-backed map from way ID to node IDs - relations: for multipolygon relations, get the list of node IDs for each way they contain from
multipolygonWayGeometries
then lookup the node locations innodeLocationDb
and reassemble the ways into a multipolygon
We want pass 2 relation processing to also be able to fetch node ids and locations for all of the ways it contains. The lookups should also be lazy so they only happen if profile decides the relation is relevant based on its tags.
For super relations we'd also need to be able to descend from the parent relation down to its children, which complicates things... For completeness we'd probably also want to expose super relation membership when processing ways.
from planetiler.
It we excluded super-relations, I think this could work by expanding waysInMultipolygon
to be waysInRelation
and either include all way IDs that exist inside a relation, or multipolygons + some filter provided by the profile. Then pass2 relation processing would have access to the geometries of each way it contains. For nodes contained in relations, we already have nodeLocationDb
that can be used to look up their location. This just gives access to node and way geometries when processing a relation, but not their tags.
To include superrelations, we need to be able to descend to all children like this and get their geometries. I think this means we'd need to store an extra map of relation -> node/way/relation children
since we can't depend on just having the relation info accessible because we're already processing it in pass 2 anymore. We could also limit the extra data we store to only relations contained in a superrelation if we did a third pass over relations, for example:
- relation pass 1: store set of relations that are a child of another relation
- relation pass 2: store relation info for every super-relation, and child relation
- relation pass 3 (after we finish reading OSM file): process all super-relations and their children stored during pass 2
I could try prototyping how much storage it would be for either of those options.
from planetiler.
For reference the current OSM planet pbf has:
- 12,042,918 relations
- 169,478 of them are superrelations
- they contain 18,781,152 nodes, 115,643,258 ways, and 863,384 relations
- there are 28,683 unique member roles
from planetiler.
Thank you for examining this need.
Iām not very experienced with planetiler, so Iām trying only to give what I want to achieve, with no consideration how the schema would look like.
I want to build a map of the Parisian subway.
There are super-routes for each line: https://www.openstreetmap.org/relation/3328695#map=17/48.86859/2.31292&layers=T
I need the colour tag for the rendering from the super-route, but I also need tags from the way (e.g. bridge).
So more than how to select the features, I would need some way to merge tags between the relation and the ways (and possibly also the role)
from planetiler.
Related Issues (20)
- [FEATURE] Min polygon area for including center point
- [FEATURE] Expose OSM entity metadata in the process feature context HOT 2
- [FEATURE] Lua profile followups
- [BUG] US admin level 4 boundary lines appear incomplete HOT 3
- Tilejson attributes missing attributes added or removed during post-processing
- [BUG] tiles missing >= zoom 7 HOT 13
- [FEATURE] Log planet version being used HOT 2
- [BUG] Charging stations won't be exported HOT 4
- [FEATURE] Add arbitrary extra metadata using the Profile interface
- [BUG] GeoPackageReader with EPSG:3067 results in swapped lat & lng
- [BUG] IOException/GOAWAY happening in parseResults()
- [FEATURE] Speed-up Planetiler by skipping OSM reads when generating only layers which do not need OSM data HOT 2
- Derive progress % from logs
- [FEATURE] Clarify documentation on CLI function arguments HOT 2
- Use google/cel-java ?
- [FEATURE] Please clarify what triggers "match_key" in YAML configurations
- [FEATURE] Expose OSM feature type HOT 1
- [FEATURE] Line-to-point geometry transformations
- [BUG] Live demo tiles returning 403 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from planetiler.