convert geoJSON polygons to WKT

[corviday]

The SCIP backend provides data on regions in geoJSON form, but the PCEX backend requires area parameters to be in WKT, so the functions that query the PCEX backend in pcex-backend.js convert geoJSON to WKT before querying.

A bug was caused by the lack of a code to convert geoJSON Polygons to WKT Polygons . This meant that sometimes the PCEX backend was queried with a blank WKT string instead of an actual area, and returned the mean for the entire spatial extent of the file instead of the area of interest. This also meant changing areas to a different area sometimes didn't update the graph, if both of them were buggy.

resolves #45 resolves #38

[corviday]

This lays bare a new problem, previously hidden behind the bug: some regions have too many points for the PCEX backend, such as the Fraser watershed. Thinking about a solution. Options are to have the backend simplify regions (downside: overlaps where we don't want them) or to have the front end just tell you you can't graph an entire basin.

You probably can graph most basins, though! The Fraser is the biggest one by far, and also - unfortunately - the only one we have data for.

[corviday]

Demo here.

To see the new functionality:

1. Select the "Fraser" basin under the map
2. select a watershed or conservation unit.
3. If your watershed or conservation unit is outside the bounds of the visible data on the map, select a different one
4. Go to one of the graph tabs (Yearly / Monthly / Daily Indicators) and select a variable and - if needed - a climatology from the menus at the top.
5. Data should appear on the graph
6. Select a different watershed or conservation unit
7. If your watershed or conservation unit is outside the bounds of visible data on the map, select a different one
8. The data on the graph should change! (This is the fancy new part)
9. Select some other basin
10. The graph should show row of zeroes (This is also new)

[eyvorchuk]

I selected the "Fraser" basin, the "Adams River" watershed, and yearly "apf_flow", and when I select the "Coast 4", "Columbia River", "Mackenzie River", or "Skeena River" basins afterward, the graphs show data instead of zeroes. The other basins give me zeroes.

[QSparks]

I had a similar experience with non-zero data for the above basins and "Southwest Coast"

[corviday]

Hmm, thanks. Tha's not supposed ot happen, I'll look into that!

[corviday]

Aargh, that's due to data errors, I think. The watersheds right next to the Fraser, like Adams, overlap it enough that they contain a cell or two of the Fraser data. That's definitely an issue, but it belongs in a separate PR.

Could you try the tests again with basins that don't touch Fraser:

Haida Gwai North Coast Nass Mackenzie Stewart Stikine Taku Tatsheshini Yukon

[QSparks]

Using: Basin: Fraser Variable: POT19freq-year Watershed: Big Bar Creek I went through each of the requested watersheds and the graph showed zeros for all of them but the Mackenzie River.

[rod-glover]

My trials reproduce all the effects noted above.

[rod-glover]

Aside: This comment should undoubtedly be put elsewhere, but it might conceivably be useful here. There's a JS spatial package called jsts that's full of useful (geo)spatial tools. It's very mature and highly developed, and I have a small amount of experience using it.

JSTS is an ECMAScript library of spatial predicates and functions for processing geometry conforming to the Simple Features Specification for SQL published by the Open Geospatial Consortium. JSTS is also a port of the well established Java library JTS.

The primary goal of the project is to provide web mapping applications with a complete library for processing and analyzing simple geometries but JSTS can also be used as a free standing geometry library.

JSTS was made using automatic translation of the original JTS Java source via AST to AST transformation preserving the JTS API, except for the I/O related classes which has been selectively and manually ported with support for WKT, GeoJSON and OpenLayers 3+.

That last bit may be of use here (or not), in particular the WKT processing, which as they note has a different API than the Java original code.