Implement a Boundary Box Selector

[Zeitsperre]

For some basic processes (such as Flyingpigeon - Subset 0.1), a feature that would be really useful to implement is a bounding box selection tool. This functionality will be especially useful for more generalist users but can save specialists a lot of time if they need a data from a general region. Ideally the max and minimum lon/lat values would serve as form entries in the process below:

gis.stackexchange has more than a few examples of how the GeoServer API works for reading/providing subsetted bounding box coordinates (for WCS requests, for WMS and WFS requests, etc.). Andrea AIme is a core GeoServer dev so he might have answers in his history that can help.

[huard]

Agreed this would be useful. I'm wondering if we can approach the problem from another angle however. A bounding box is just a special case of a polygon, so if a process already has a WFS input parameter for a polygon, why not use the frontend to generate on the fly a GML file that encodes the bounding box?

[Zeitsperre]

That would also be a nice feature.

[Renaud009]

Is there any more processes that actually attend bbox as input and how do they attend it?

• Flyingpidgeon subset_bbox (Subset 0.1) actually attend 4 inputs of type float named lon0, lon1, lat0 and lat1. Same for flying averager_bbox (Averager 0.1).
• There's also BoundingBox Data whos a primitive WPS datatype, does any known process actually use this datatype as input?
• There's also the more common case of generic polygons as suggested by @huard , any process that attend a WFS input (geoserver/typename/featureid) could want a simple bbox what would be drawn by user and then automatically uploaded as shapefile on geoserver by frontend (eventually just like any other private polygon).

Do we want to cover those 3 scenarios or any other?

[huard]

Renaud, I'm not aware of processes actually using the BoundingBox object primitive.

Note that we're not strongly attached to existing processes (subset_bbox). I'm not sure they'll get a lot of usage in the real world outside of testing.

Something that we might want to add to the discussion is the possibility of computing zonal average (https://en.wikipedia.org/wiki/Zonal_and_meridional).

[Renaud009]

Not sure a bbox selector is the right tool for such a selection.

[Renaud009]

When drawing/defining a new polygon, user could pick a drawing tool between those 5 or any other:

• BBox selector
• Circle selector, if needed
• Simple regular convexe polygons selector (triangle, square, etc.), if needed with the possibilty of pivoting it
• Complex polygon selector (n edges, concavity, etc.)
• Zonal and meridional selector (a line or two point should be enough to determine latitudinal or longitudinal circle.

[Zeitsperre]

@Renaud009 Would it be difficult to leverage/implement some of the tools that are used in a platform like http://geojson.io? Many of the tools shown there could be particularly useful beyond BBox selectors (e.g. Multipoint layers for multi-pixel data extractions)

@huard I can see a particular usefulness of the more primitive CDO bindings in Malleefowl for more technical users (e.g. CCCS and ECCC analysts). Much of the data requests I've been performing lately have been bbox subsets. Being able to quickly identify and subset an area based on geocoordinates could reduce bandwidth and CPU cycles. I'm not sure what you mean.

[Renaud009]

Implementation of a one-shot bbox is actually very simple and have already been developped in my branch. I actually also added to possibilty of selecting multiple regions at once with an ephemere bbox. If you want to be able to edit the selection (ex. by selecting edges) afterward is another beast tho, like in this example based on ol2 http://harrywood.co.uk/maps/examples/openlayers/bbox-selector.html

Simple point(s) marker(s) is already in my todo list and should be trivial too, that would be usefull for the point information panel and should already have been impletemed a while ago.

[huard]

@Zeitsperre Point taken.

@Renaud009 How do you suggest we handle the WPS - frontend communication? That is, how does the WPS process tell the interface: I can accept a general WFS, or I'm restricted to a BBox ?

[Renaud009]

@huard Well maybe processes should start using primitive type "Bounding Box" for such a restriction. There's no way we can express such a restriction at the moment.

ATM we intend to develop, as you suggested, that drawing regions will result in automatically uploading a geopackage on geoserver in the user's private workspace. By selecting such region, just like in the regular workflow (general WFS), you'll be able to fill core processes with custom regions (scenario #3).

Filling primitive BBox datatype should also be trivial w/o having to upload anything, we probably intend to support it even if there's no actual process using it at the moment (scenario #2).

We don't intend to fill wps inputs based on field ids anymore (scenario #1)

[huard]

I've created a simple process in emu (wps_poly_centroid.py) that takes as input a ComplexInput with a application/gml+xml mimetype. You can use it to test the interface. There is also wps_bbox.py process with a BBox Input.