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

Geometry validation methods #14

Open
rafaqz opened this issue May 30, 2023 · 2 comments
Open

Geometry validation methods #14

rafaqz opened this issue May 30, 2023 · 2 comments
Labels
juliacon To be implemented for JuliaCon

Comments

@rafaqz
Copy link
Member

rafaqz commented May 30, 2023

We need some functions like Rs sf_make_valid to validate geometry correctness. R is just using GEOS for this.

Currently we are in a wild-west situation where anything reads, writes and plots and will just randomly fail when it hits methods where validity matters.

@skygering
Copy link
Collaborator

I am just copying over a comment from code I am cleaning up that connects to this:

What to do for corner cases (nan point, etc)?

@asinghvi17
Copy link
Member

asinghvi17 commented Mar 2, 2024

I imagine this working on several levels, and one would ascend the tree from the bottom up, from point to feature collection.

If empty geometries are deemed valid, ok - if not, then we could flag invalid and remove them.

  • A point is valid if it has no NaN or Inf values. Certain CRS may also require the point to be within a specified range - this can be something we use a custom correction for. We may also want to wrap points around the antimeridian.

  • A linestring is valid if it is either empty, or has 2 or more coordinates. If closed, a linestring must not be self-intersecting. Previous requirements for all points constituting the linestring also apply.
    Linestrings are a special case IMO because they are the first level of abstraction - we don't want to decompose to points and then go back to searching the linestring again because it's pointless.

  • A linear ring is a subset of linestrings which must be:

    • closed,
    • length > 3,
    • Non-collinear (cannot overlap itself over an interval of two or more consecutive points)
    • non-intersecting (optional),
    • made of valid points
  • A polygon must have an exterior, and optionally an interior.

    • Winding rules as specified,
      • Geographic winding via the left-hand rule (preferably with the ability to indicate)
    • holes must be inside the polygon,
    • no ring may self-intersect (but they can touch at single points)
    • no ring may intersect another (but they can touch at single points)
  • A multipolygon must:

    • not have intersecting polygons
    • have its interior polygons sorted in terms of area
    • satisfy all polygon requirements
  • Geometry collections must:

    • Satisfy all requirements for subsidiary geometries

For all geometries, antimeridian cutting is a viable method. The only issue is passing per-point attributes through for plotting - which will probably require a reimplementation in GeoMakie.

Alternatively, we could have internal functions here which return a list of the indices of altered/added vertices (perhaps when called with a Val) that GeoMakie can use to interpolate (or we can build that utility into GeometryOps which would be pretty cool). This feature is also what the barycentric API is building towards.

Feature collections - I guess validity checks are just all(isvalid.(fc.geometry))? Probably feature

https://learn.microsoft.com/en-us/sql/relational-databases/spatial/linestring?view=sql-server-ver16 is a nice link I thought

@asinghvi17 asinghvi17 added the juliacon To be implemented for JuliaCon label Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
juliacon To be implemented for JuliaCon
Projects
None yet
Development

No branches or pull requests

3 participants