Add server side function wkt("polygon") to allow subsetting by WKT polygon

[BobSimons]

Add new server side function like: &wkt("a string with the WKT polygon") ERDDAP could handle this by converting the polygon into lat and lon constraints, getting that data subset, then properly subsetting to the polygon, then return the results to the user. Thanks to Matthew Biddle.

[BobSimons]

Rather than just add a wkt(polygon feature, it may be much better to add support for the features of the new
OGC EDR API . That could be relatively easy given that ERDDAP is already set up to do all the background work (getting data from data sources).

[7yl4r]

That API seems to provide a good framework for single-url requests that includes WKT. The details specified in the API look very nice to me but I will be happy to get data for a given WKT regardless of the implementation.

[7yl4r]

The need for this functionality keeps coming up in my communities. Utilities are being developed to provide this functionality client-side by combining results from several ERDDAP calls.

What can I do to help move this forward? I am setting up an ERDDAP dev environment now in case I can help contribute some code.

[BobSimons]

I'm just one guy and I'm maxed out. If you want to speed this up:
a) You can add a server-side function to do it. (It won't be easy because it would be the first server-side function for griddap. There is analogous code for server-side functions in tabledap. Maybe the first step is to add this function to tabledap.) Sorry, for now, I can't offer much help. I'm maxed out.
b) You can add it by adding support for (some of) the EDR API to ERDDAP.
c) You may be able to fund (a) or (b). We have another programmer capable of this, but currently by contract only. Talk to Roy.Mendelssohn@noaa.gov about funding issues.

[BobSimons]

@7yl4r, a background question:
I understand the desire for being able to specify a polygon and having the data server just return the data which is within the polygon. I've seen (silly) demos (recently) where the user clicked on 6 points to crudely outline the US. But that was an absurdly simplistic outline of the U.S (and he excluded the San Francisco peninsula and the Monterey Peninsula!).

So in practice, I don't see how this works well. If for example, the region desired is a U.S. state, the polygon needed to specify it with any accuracy has 100's or 1000's of points. Are you anticipating that users will click on a map to define these points, or cut and paste the WKT for these polygons?

And if the polygon is >500 points, the WKT for the polygon will probably be >5000 characters, which exceeds the default limit in Tomcat for incoming URLs.

How do you plan to get around these issues to make this system useful in practice, not just in theory?

Here's a possible, but limited solution: in addition to allowing WKT, ERDDAP could support predefined names for which
ERDDAP already has the accurate and precise WKT. That would solve the problem for the supported regions (e.g., countries of the world, and US states), but not the problem of, e.g., some watershed somewhere.

Your thoughts?

[pzaborowski]

Hi, afaik the scenario that makes sense is retrieving coverage of the given polygon that is diagonal to the box like Adriatic sea or vessel route corridor. The user does not draw polygon manually then.
Ad URL limit options I can see are POST instead of GET and URL of the polygon in parameter rather than inline and additional external query assuming it's allowed.