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

Discussion: Make clipGeometry parameter explicit on all endpoints? #250

Open
SlowMo24 opened this issue Nov 18, 2021 · 3 comments
Open

Discussion: Make clipGeometry parameter explicit on all endpoints? #250

SlowMo24 opened this issue Nov 18, 2021 · 3 comments
Labels
brainstorming Idea for a potential new feature or adaption that still needs further discussion comments welcome Indicates that the creator of this issue/PR is open for early review comments
Milestone

Comments

@SlowMo24
Copy link
Contributor

This is a follow up of #245 , see #245 (comment).

The question arose if clipGeometry could be renamed to clipResult and added to all endpoints. Currently this is done, setting clipGeometry=True for any endpoint where it cannot be specified. E.g. the contributions endpoint will only return contributions within the given area of interest. Making it explicit would enable the user to get all contributions to the intersecting geometries.

@SlowMo24 SlowMo24 added brainstorming Idea for a potential new feature or adaption that still needs further discussion comments welcome Indicates that the creator of this issue/PR is open for early review comments labels Nov 18, 2021
@bonaparten
Copy link
Contributor

I also am for having it added to all endpoints. I think this is a coherent and expected behavior.
I am not sure regarding the name since it is the geometry that is clipped. Why would you like to have it renamed?

@bonaparten bonaparten added this to the 2.0 milestone Nov 18, 2021
@SlowMo24
Copy link
Contributor Author

For the user it may seem strange that you clip the geometry for a contributions or aggregation endpoint. The idea was that we have a result that is what the filter returns and then some clipping and post-processing that will create the return value. In that case its the result that is clipped, no matter its type. But clipGeometry may be just as reasonable, if it is well documented!

@bonaparten
Copy link
Contributor

I get the point, but I do not totally agree with that point, since in our case "clip" means to cut the geometry (no clipped result without clipped geometry). I understand "result" as what is given back at the end, when the clipping process already happened.
Definitely, it should be better documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming Idea for a potential new feature or adaption that still needs further discussion comments welcome Indicates that the creator of this issue/PR is open for early review comments
Projects
None yet
Development

No branches or pull requests

2 participants