Implement validity checks for each geometry type about geo HOT 8 OPEN

I agree about optional validity. I really like the idea of validity checks being easily chainable, so you could e.g. carry out a series of "cheap" geo operations, only checking validity before a potentially expensive one, and bailing out with an Err if need be.
Also, if I understand the current state of this part of Rust's type system correctly, it's not possible to conveniently express validity using trait bounds, but that doesn't need to hold us back – a subset of operations that are guaranteed to produce valid geometries (logic errors and floating-point issues notwithstanding) is something worth exploring IMHO, but we've got plenty of more fundamental stuff to do.

from geo.

Relevant: #56

from geo.

Something I'm working on appears to require valid geometries, so I'm interested in this. I'd be half tempted to implement what I want as a starting point sometime.

from geo.

i have a WIP PR for ensuring valid linestrings: https://github.com/georust/rust-geo/pull/155/files?w=1 if you have any feedback, let me know

from geo.

Looks like it solves one case, but there are many ways for a linestring to be invalid, and I hit an odd one (a linestring of 2 identical points!).

However that link from PostGIS splits things 2 ways. Simple, and Valid. In it, there are no invalid linestrings (so long as there's >=2 points). So maybe It's worth adding simplicity check? Or call do a simple & valid check but call that "validity" (my preferred option)?

from geo.

for what it's worth, i'm in favor of making validity opt-out. if i have a LineString instance, i'd rather not have to check everytime i work with it if it's valid or not. if we can guarantee validity with low overhead (see my branch), i don't see the downside (besides being a little less ergonomic)

yeah, i knew about the 'no duplicate points' simplicity rule for linestrings, but wasn't sure the best way to address it. logically, it's a pretty straightforward check, but i'm not sure how best to implement it since it could affect performance. for example, if we kept a Vec for LineString, concatenating two large LineStrings could be pretty expensive since we'd have to check the intersection of two Vecs. another option is to use a BTreeSet (an ordered set) which would allow us to use set operations, but i haven't thought too hard about it.

from geo.

I also haven't thought about it too much. I think validity should be opt-out too. Sometimes you don't care, or more importantly, you can assume (or know) that the thing is valid, in which case there shouldn't be a performance hit.

from geo.

Just opened a new pull request adding a LineString validity constructor: #168

If any of you have some time, would love to get some 👀 and opinions

from geo.