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

Specifying target all the time in polygon methods is painful #66

Open
asinghvi17 opened this issue Mar 4, 2024 · 3 comments
Open

Specifying target all the time in polygon methods is painful #66

asinghvi17 opened this issue Mar 4, 2024 · 3 comments
Labels
juliacon To be implemented for JuliaCon

Comments

@asinghvi17
Copy link
Member

Can we have it default to the greater of the two types given?

@asinghvi17 asinghvi17 added the juliacon To be implemented for JuliaCon label Mar 4, 2024
@skygering
Copy link
Collaborator

I don't think so. Because if you give two Polygons, in LibGEOS it can return anything from a Point to a LineString to a Polygon. I think default behavior should probably mimic LibGEOS, which was my plan in the long term (but a list instead of a GeometryCollection). However, we could change that to do what you have suggested. It is more applicable for my use case. But then if people want LibGEOS behavior they have to specify that they want a Union{Point, Line, LineString, Polygon} which seems more annoying to me.

@asinghvi17
Copy link
Member Author

Ah, I see what you're saying. I guess I wanted unspecified target to give the algorithm freedom to return anything, so the user doesn't have to specify at all.

@skygering
Copy link
Collaborator

Ah yes. I agree with that. That is the long-term plan. So the default target would beUnion{GI.Point, GI.Line, GI.LineString, GI.Polygon} it is just that doesn't work right now, so I didn't want to give people a false understanding of what is possible with the current code.

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

2 participants