functions return data in EPSG:3005 (4326 is expected)

[sebdalgarno]

e.g. https://features.hillcrestgeo.ca/fwa/functions/postgisftw.fwa_watershedhex/items.html?blue_line_key=356308001&downstream_route_measure=10000&limit=10

are coordinates in correct CRS?

[smnorris]

It does seem to be a CRS issue, but the function has not been changed. Other functions seem to have the same issue, and all seems to be fine when working directly with the db. First thought is this could maybe be related to upgrading pg_featurserv to support CQL on May 4. Did you use the service successfully between then and last week?

[sebdalgarno]

unfortunately I'm not sure whether these functions worked as expected between May 4th and last week

[smnorris]

ok, no worries. I'm currently upgrading the db to pg14 - once that is done I'll look more closely into the functions

[smnorris]

I've filed an issue upstream. The function code has not changed, testing locally with pgfs 1.3 gives the same result, and testing locally with pgfs v1.2 works fine. Unless I've missed a required config setting or function change with 1.3 it appears to be a bug.

https://github.com/CrunchyData/pg_featureserv/issues/114

Let me know if you need this sooner rather than later and I can revert back to 1.2

[sebdalgarno]

Thanks Simon. This appears to affect all of the functions in the API. Until resolved, the following fwapgr functions will not work:

• fwa_locate_along()
• fwa_locate_along_interval()
• fwa_watershed_at_measure()
• fwa_watershed_hex()
• fwa_watershed_stream()
• fwa_index_point()

Note the tests are currently passing in fwapgr since we are not actually testing that the locations make sense (i.e., in the event of incorrect CRS)

@joethorley can you weigh in here?

[joethorley]

if we look at the coordinates of the returned locations is it obvious what CRS is being used?

[smnorris]

CRS is specified in the response: https://features.hillcrestgeo.ca/fwa/functions/postgisftw.fwa_watershedhex/items.json?blue_line_key=356308001&downstream_route_measure=10000&limit=10

[joethorley]

@sebdalgarno are we able to reproject conditional on the CRS to have code that is robust to the projection provided?

[smnorris]

I think this would be a temp workaround - it looks like the design says if we don't specify the CRS in the request, we should be getting EPSG:4326 in the responses. https://github.com/CrunchyData/pg_featureserv/issues/6 Martin also wonders if the UI can always request WGS84, which does not appear to be happening.

[smnorris]

This doesn't seem to make any difference: https://features.hillcrestgeo.ca/fwa/functions/postgisftw.fwa_watershedhex/items.json?blue_line_key=356308001&downstream_route_measure=10000&limit=10&crs=4326

[smnorris]

I've tweaked most of the above listed functions to specifically return WGS84.

https://features.hillcrestgeo.ca/fwa/functions/postgisftw.fwa_locatealonginterval/items.html?blue_line_key=359572348&start_measure=1597489&interval_length=700&end_measure=1706733&limit=1000

I didn't touch WatershedAtMeasure - if the rest of these work fine I can do that one too.

[smnorris]

pgfs issue is fixed. I've installed the latest and reverted the db functions back to as they were. All seems to work fine: https://features.hillcrestgeo.ca/fwa/functions/postgisftw.fwa_locatealonginterval/items.html?blue_line_key=359572348&start_measure=1597510&interval_length=700&end_measure=1706733&limit=1000

[sebdalgarno]

thanks @smnorris tests are now passing and all looks like back to functioning normally