-
-
Notifications
You must be signed in to change notification settings - Fork 155
[FEATURE] Add relation_members geometry type for processing OSM relation members #1427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…members Add a new `geometry: relation_members` option to YAML custom maps that allows processing individual members of OSM relations as separate features. Instead of emitting one feature per relation, this emits one feature per qualifying member, using each member's geometry and tags. Key features: - Select relations using existing include_when/exclude_when filters - Emit one feature per qualifying member (way/node) - Filter members by type, role, and tags (with inline script support) - Add member-level attributes from member tags - Support inline script expressions for member filtering and attributes New configuration fields: - member_types: Filter members by OSM element type (node, way, relation) - member_roles: Filter members by their role in the relation - member_include_when: Filter members by their tags (structured or inline script) - member_exclude_when: Exclude members by their tags (structured or inline script) - member_attributes: Add attributes from member tags (with inline script support) Implementation follows the multipolygon processing pattern: - Phase 1: Identify relations matching relation_members features - Phase 2: Store member geometries/tags, then process relations to emit member features Includes comprehensive validation: - Member fields can only be used with relation_members geometry - member_types values must be valid OSM element types - Clear error messages for invalid configurations Resolves onthegomap#1426
Full logs: https://github.com/onthegomap/planetiler/actions/runs/20689654879 |
This commit fixes the build failure where test compilation couldn't find VectorTileProto classes, and improves the relation_members feature implementation with better test coverage and code quality improvements - Added new tests for code and functional coverage - Fix test compilation failure for VectorTileProto classes by adding build-helper-maven-plugin to include generated protobuf sources in test compilation classpath - Allow relations to be processed as both multipolygon and relation_members by changing conditional logic in OsmReader from else-if to independent if statements - Refactor relation_members processing loop to reduce continue statements (SonarQube java:S135 compliance) - Fix MemberContext.tags() to return mutable copy instead of parent tags - Add comprehensive integration tests for relation_members (772 lines, 11 tests) covering railway routes, boundary relations, member filtering, duplicate handling, polygon conversion, missing geometry, inline scripts, and dual processing scenarios - Refactor validation test lambdas to satisfy SonarQube java:S5778 rule - Remove temporary documentation files (COMMIT_MESSAGE.txt, PR_DESCRIPTION.md) - Clean up comments and improve code documentation
9302b53 to
486a5a6
Compare
486a5a6 to
6b2ab52
Compare
CommanderStorm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(not a maintainer)
🤔 Reealy stupid question:
Is the following possible with this PR, or is this another issue?
planetiler/planetiler-custommap/src/main/resources/samples/shortbread.spec.yml
Lines 1087 to 1123 in 6eb3ab5
| - name: 'country boundary' | |
| input: | |
| source: osm | |
| geometry: line | |
| # TODO from relation | |
| tags: | |
| boundary: administrative | |
| admin_level: '2' | |
| maritime: yes | |
| output: | |
| layer: boundaries | |
| geometry: line | |
| min_zoom: 0 | |
| min_size: 0 | |
| tags: | |
| maritime: true | |
| admin_level: 2 | |
| disputed: false | |
| - name: 'country coastline' | |
| input: | |
| source: osm | |
| geometry: line | |
| # TODO from relation | |
| tags: | |
| boundary: administrative | |
| admin_level: '2' | |
| natural: coastline | |
| output: | |
| layer: boundaries | |
| geometry: line | |
| min_zoom: 0 | |
| min_size: 0 | |
| tags: | |
| maritime: true | |
| admin_level: 2 | |
| disputed: false |
Currently, the US-Canada and russia-ukraine border are relations, so cannot be incuded via the custommap previously (?).
In general, could you add this to the custommap' Readme (aka the docs for this feature)
ec9d7ba to
f989290
Compare
- Add comprehensive documentation for relation_members geometry type in README - Document member_types, member_roles, member_include_when, member_exclude_when, and member_attributes fields - Add Relation Members section with examples and usage patterns - Document Member Context variables for inline script expressions - Update JSON schema to include relation_members in geometry enum - Add all member-related fields to feature definition in schema - Include descriptions noting member fields are only valid with relation_members geometry
f989290 to
e187082
Compare
This PR would allow the boundary segments to be taken from the members of boundary relations, while taking attributes such as If I understand it correctly, this PR could address this TODO in the planetiler/planetiler-custommap/src/main/resources/samples/shortbread.yml Lines 372 to 373 in 6eb3ab5
This PR does not address the other
It would be a valuable to be able issue a single geometry for each member and be able to aggregate information for tags of the parent relations. Note that shortbread.spec.yml is a test for shortbread.yml were each name represents an example where the given input should produce the given output. This PR does not affect the schema testing mechanism. The quoted comment should probably be placed in the schema itself. |
|



Add a new
geometry: relation_membersoption to YAML custom maps that allows processing individual members of OSM relations as separate features. Instead of emitting one feature per relation, this emits one feature per qualifying member, using each member's geometry and tags.Key features:
New configuration fields:
Implementation follows the multipolygon processing pattern:
Includes comprehensive validation:
Resolves #1426