Skip to content
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

Ability to mark artificial segments to facilitate visualization & reconstruction of tiled geometry #22

Open
jerstlouis opened this issue Nov 17, 2021 · 1 comment
Labels
future work A proposal or requirement that will or may be addressed in a future work item

Comments

@jerstlouis
Copy link
Member

jerstlouis commented Nov 17, 2021

In relation to the clip-box query parameter investigated in the November 2021 code sprint alongside geometry simplification, it would be useful to be able to mark artificial segments introduced by clipping.
This avoids the need to request an extra boundary in order to keep the information about whether a particular segment is artificial.
It is also more difficult for applications wishing to reconstruct the geometry to use extra boundaries rather than explicitly marked artificial line segments, rather than the visualization use case where rendering to a smaller canvas will simply drop the oustide boundaries.

This was first proposed in Testbed 13 for GML, and an eventual solution for GeoJSON. We also implemented an approach to marking artificial segments in MapML for Testbed 15.

Our server currently optionally implements this as a property for GeoJSON output, e.g. the following sample generated by our server

         "line::hidden" : [
            { "polygon" : 1, "contour" : 0, "segments" : [ { "from" : 344, "to" : 345 } ] }
         ],

means that the edge from the 345th to 346th coordinates pair for the first contour of the second polygon is artificial.

JSON F&G could potentially define an extension with a dedicated property outside of GeoJSON properties to encode this information, in one way or another.

@cportele
Copy link
Member

cportele commented Mar 7, 2022

Meeting 2022-03-07: Discuss this in conjunction with #7.

@cportele cportele added the future work A proposal or requirement that will or may be addressed in a future work item label Jan 8, 2024
@cportele cportele moved this to Waiting for Features API SWG in JSON-FG Part 1 Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future work A proposal or requirement that will or may be addressed in a future work item
Projects
Status: Waiting for Features API SWG
Development

No branches or pull requests

2 participants