Skip to content

Conversation

rafaqz
Copy link
Member

@rafaqz rafaqz commented Jan 1, 2024

Closes #190

@rafaqz rafaqz force-pushed the gi_tuple_points branch 3 times, most recently from ee9e84e to 519051a Compare January 1, 2024 21:58
Copy link
Member

@evetion evetion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With a merge from master this should be cleaner. I'm fine with this change, but only if we update our constructors to also take Vector of Tuples, so we can reverse.

nit: Please spellcheck your comments ;)

@rafaqz
Copy link
Member Author

rafaqz commented Jan 7, 2024

Doing this for MultiPoint and coordSeq methods is a huge task that I cant include in this PR. This package needs a rewrite of the internals with the aim of reducing the constant small allocations with some ArchGDAL like closures for safety instead of clones. But who knows when that can happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Swap to returning Tuples instead of LibGEOS.Point for anything GeoInterface related
2 participants