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

BBox search and download #96

Open
JordanPinder opened this issue Jan 30, 2020 · 6 comments
Open

BBox search and download #96

JordanPinder opened this issue Jan 30, 2020 · 6 comments

Comments

@JordanPinder
Copy link

Back again!

Just a couple others I missed off - the ability to search for layers and download data by a user-defined bounding box.

I imagine downloading data might be similar to using WFS intersect filter that was discussed in the hierarchical filtering issue, but obviously would need to have a consistent "geom" column and also consider resource constraints; for example, whether it's faster to return all polygons that intersect with the bbox or only those explicitly found within it.

As for searching for layers, I guess this might be similar to Graeme's suggestion using WMS intersect calls?

@andyb-esdm
Copy link
Collaborator

@JordanPinder @HelenwoodsJNCC
I've got bounding box downloads working in principle. You can click on an icon on the layer, draw a bounding box and get a shapefile download for the features that intersect it. This is done by setting the output format on a WFS request to shape-zip and adding an intersects filter as was trialled in the highlight features issue.
However, I've just read (and experienced) that layer groups don't support WFS requests - you have to specify a layer within the group. Maybe we knew that from before?
So I think for layer groups you want to have download support, we'll need to add a configuration column, which is the downloadable layer from the group e.g. 'eusm2016_msfd_full'. The mapper could then conditionally display a bounding box download button next to layers that have this populated.
We may also want to restrict how much data can be downloaded this way. This could be done by specifying a maximum area for the bounding box?
Finally, some of these features cover a very large area so the extent of the download can be surprising.

image

image

@andyb-esdm
Copy link
Collaborator

@HelenwoodsJNCC @JordanPinder
Shall we go ahead and make the database configuration change for bbox downloads (a column for the downloadable layer in the group)? Then we can deploy to the esdm test server and you can see what you think.

@JordanPinder
Copy link
Author

@andyb-esdm apologies for the delay.

I'm happy with adding a configuration column, makes it nice and simple from our end.

As the datasets are quite large I think some form of restriction would be needed. The maximum area to download seems appropriate, also some GeoServer restriction could be useful as well?

With regards to the features downloaded, this is a quirk I've also come across using WFS with extracting data (mainly the EMODnet data). This isn't an issue from my perspective but it might depend on what the EMODnet secretariat ask for in the future, currently they haven't specified but just something for us to bear in mind.

@andyb-esdm
Copy link
Collaborator

@JordanPinder No problem!

I think this can 'self-configure'. That is, if the downloadLayer column is populated then show a button on the active layers that allows the user to download by bounding box. Else no button (or download). This way we can implement the functionality for both EMODnet and MPA mappers but it will only be available if you decide to populate that column for specific layers.

Agree it's difficult to decide on limits to the downloads and this might be dataset specific. But If we keep it to the test site for now, you'll have something more tangible to test.

SimonAnnetts added a commit that referenced this issue Aug 11, 2020
#96
Add new field to database Layer table
Update the controller to deliver this as JSON
Update the Razor pages for Layer to include this new field
@JordanPinder
Copy link
Author

@andyb-esdm I agree with that approach, seems like the simplest to implement it.

For data limits I think we can go with your suggestion for restriction download to a max area for the time being and try that on test site if that's OK?

Also just a logistic question, do you know if this work is being covered by last years support contract?

@andyb-esdm
Copy link
Collaborator

@JordanPinder okay - i'll set the limit to something 'arbitrary' that we can tweak. I'll let you know when it's on the test site.
Yes, this is currently covered by last year's contract.

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

No branches or pull requests

5 participants