Thoughts on algorithms for trait-based geometries #1247
kylebarron
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A continuation of previous trait-based geometry discussions #838, #1021, #1019.
Just putting some words down on the page because @urschrei nerdsniped me! On discord we were talking about coordinate representations for geo and geo-types and @urschrei asked what the blockers were on trait-based geometries. I responded that I thought figuring out the best way to implement algorithms on top of geometries was hard.
I started to play around with a bit of scratch traits, got something to compile, and figured I should jot down some notes in case it resonates with anyone else.
The main idea is having algorithm traits per geometry type that rely on that type's geometry trait definition. Then a blanket implementation over every geometry type that implements that trait.
to keep a top-level
Area
trait as well, we could haveThe main downside of this might be the proliferation of public traits? Is there a way to get around
AreaPoint
,AreaLineString
, etc? The blanket implementation overGeometryTrait
would also mean that it's impossible to implementGeometryTrait
on, say, ageo::Point
, because then there would be two trait options? The other option would opt in to implementingGeometryTrait
on structs likegeo::Point
, so that people could keep usingArea
for all geometry types like they are now.Who knows, this might fall apart on more complex traits like
Intersection
that require two geometries? Idk, thoughts?Beta Was this translation helpful? Give feedback.
All reactions