You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it's cool that the crate itself doesn't have many dependencies, we would potentially need to implement a lot of algorithms on our own if we stuck to only depending on geo-types. Also, this crate here is used:
as a debugging crate in many use cases anyways
used in conjunction with geo in many use cases anyways
Because of this, I think it's not a big issue if we depend on geo directly (with default features turned off!). I'm planning on implementing PolyLabel in geo which would be one of the cool algorithms we could utilize here then.
The text was updated successfully, but these errors were encountered:
Is there any reason you can't pull in PolyLabel? I think the only dependency it doesn't share with geo is libc, and I can easily feature-gate that since it's only for FFI. I've wondered about integrating into geo before and decided that it was somewhat too specialised, so we wouldn't accept duplicate functionality.
While it's cool that the crate itself doesn't have many dependencies, we would potentially need to implement a lot of algorithms on our own if we stuck to only depending on
geo-types
. Also, this crate here is used:geo
in many use cases anywaysBecause of this, I think it's not a big issue if we depend on
geo
directly (with default features turned off!). I'm planning on implementing PolyLabel ingeo
which would be one of the cool algorithms we could utilize here then.The text was updated successfully, but these errors were encountered: