Zoom to failing for features with westings. Strange behaviour for features at 180° Long, or at -90° lat

[CMKMS-LINZ]

Bug Description

Westings: When searching for any feature with a westing coordinate (eg, Raoul Island, which has a reference point at -177.922006 -29.271703 and polygon geometry fully over the 180° line), the zoom-too fails, instead sending the User to 0° 0° (lat long).

It always appears to snap to 0,0 (lat long) unaffected by the projection system the project is in.

180° For features with coordinates at exactly 180° longitude, the zoom too instead zooms out to show both 180° and -180° (eg, Chatham Rise has a reference point at 180.000000 -43.500000, selecting this feature causes the window to zoom out to show 180.000000 -43.500000 and -180.000000 -43.500000 at the top and bottom of the map window respectively.

-90 S, but may be 0° E/W causing the issue The behaviour is possibly identical for features at 0,-90 but is less clear - the zoom too will snap to show the relevant reference point at the top of the map window, with what is presumably interpreted as -0,-90 at the bottom.

Eastings The zoom to for features with eastings works perfectly, including the new functionality to zoom to features with only a reference point.

Steps to Reproduce

For the westing issue: Select any feature with a reference point with a westing, eg Chatham Island, Raoul Island, King Edward VII Land

For the 180° issue, use Chatham Rise

For the pole issue, use South Pole or Polheim

Desktop

• Environment: [Windows 10]
• Relevant Software Versions: [e.g. Gazetteer Plugin 2.0.0-UAT, QGIS 3.14]

Screenshots

Result if a westing is searched, using the built in coordinate query tool:

Chatham Rise result (will probably always result in a nice centered view of the South Pole):

[SPlanzer]

@CMKMS-LINZ I have connected QGIS2 with the current plugin (v1.8.2) to the production database and this appears to be the same behavior.

Can you confirm this?

[CMKMS-LINZ]

@SPlanzer You may have affected the production database credentials or configuration?

As I've been booted and can't reconnect.

[SPlanzer]

I have also been booted. I have just been running search queries via the plugin to compare behaviors with the new version as well as compare dev and prd databases.

This problem is all the more worse I a do no longer (at least i believe I once did) have ssh access to this server.

I will contact service desk

[CMKMS-LINZ]

Right, back on the question, production behaviour ( 1.8.2 plugin on QGIS 2.6.1) isn't the same:

• Where a name has just a Refpt, it does not zoom too (this is something requested as a fix for the migration), so I can't compare behaviour

• For features with line or point geometry with westings, if 1); spatially or text searched for, then 2): selected it 3): throws up a python error and doesn't move the window (to the correct feature, or to lat long 0,0), eg Searching for Nairn River (a river on Chatham Island):

An error has occured while executing Python code:

Traceback (most recent call last): File "C:/Users/cstephens/.qgis2/python/plugins\NZGBplugin\Layers.py", line 343, in showNameId self.zoomToFeature() File "C:/Users/cstephens/.qgis2/python/plugins\NZGBplugin\Layers.py", line 416, in zoomToFeature mapview = self._transform.transformBoundingBox( geom.boundingBox(), QgsCoordinateTransform.ReverseTransform ) QgsCsException: inverse transform of (179769313486231550856124328384506240234343437157459335924404872448581845754556114388470639943126220321960804027157371570809852884964511743044087662767600909594331927728237078876188760579532563768698654064825262115771015791463983014857704008123419459386245141723703148097529108423358883457665451722744025579520.000000, 179769313486231550856124328384506240234343437157459335924404872448581845754556114388470639943126220321960804027157371570809852884964511743044087662767600909594331927728237078876188760579532563768698654064825262115771015791463983014857704008123419459386245141723703148097529108423358883457665451722744025579520.000000) PROJ.4: +proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs Error: latitude or longitude exceeded limits

Python version: 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]

QGIS version: 2.6.1-Brighton Brighton, e2a51df

Python path: ['C:/Users/cstephens/.qgis2/python/plugins\NZGBplugin', 'C:/OSGeo4W/apps/qgis/./python/plugins\processing', 'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/cstephens/.qgis2/python', u'C:/Users/cstephens/.qgis2/python/plugins', 'C:/OSGeo4W/apps/qgis/./python/plugins', 'C:\OSGeo4W\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\nose-1.3.3-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\tornado-4.0.1-py2.7-win-amd64.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\backports.ssl_match_hostname-3.4.0.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\certifi-14.05.14-py2.7.egg', 'C:\OSGeo4W\bin\python27.zip', 'C:\OSGeo4W\apps\Python27\DLLs', 'C:\OSGeo4W\apps\Python27\lib', 'C:\OSGeo4W\apps\Python27\lib\plat-win', 'C:\OSGeo4W\apps\Python27\lib\lib-tk', 'C:\OSGeo4W\bin', 'C:\OSGeo4W\apps\Python27', 'C:\OSGeo4W\apps\Python27\lib\site-packages', 'C:\OSGeo4W\apps\Python27\lib\site-packages\PIL', 'C:\OSGeo4W\apps\Python27\lib\site-packages\jinja2-2.7.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\markupsafe-0.23-py2.7-win-amd64.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\python_dateutil-2.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\pytz-2012j-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\win32', 'C:\OSGeo4W\apps\Python27\lib\site-packages\win32\lib', 'C:\OSGeo4W\apps\Python27\lib\site-packages\Pythonwin', 'C:\OSGeo4W\apps\Python27\lib\site-packages\Shapely-1.2.18-py2.7-win-amd64.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\six-1.3.0-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode', 'C:\OSGeo4W\apps\Python27\lib\site-packages\xlrd-0.9.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\xlwt-0.7.5-py2.7.egg', 'C:\OSGeo4W\apps\qgis\python\plugins\fTools\tools']

For the examples of Chatham Rise at exactly 180° or the South Pole, as they just have reference points, plugin 1.8.2 doesn't do anything when selected other than open the panel (since there's no zoom to).

[CMKMS-LINZ]

This bug therefore, is probably the existing defective behaviour just expressing itself in a new and exciting way in Python3/QGIS 3.

[billgeo]

What is the impact of this on the team Chris? How often does it occur and what is the workaround for it?

[CMKMS-LINZ]

It occurs every time for any feature with westings. In production, you'd dismiss any python errors, then right click the feature in the layer tree and go 'Zoom to Layer' to get where you wanted to go.

The impact is that the existing plugin is defective for features with westings, of which there are currently 1121, and UAT v.2.0.0 has magnified the defect by snapping to 0, 0 rather than doing nothing (per production) or working

Eg if you were working on the Chatham Islands in production, while looking at the islands in the spatial window you would search a feature, open it, dismiss any errors (if it had lines or polygons), and keep working. In UAT v.2.0.0, it would snap zoom you away to 0,0 every time you opened a feature

Examples with features at exactly 180° don't exist in production.

[billgeo]

In UAT v.2.0.0, it would snap zoom you away to 0,0 every time you opened a feature

And can you do the same workaround after this happens (right click the feature in the layer tree)?

[CMKMS-LINZ]

Yes, but I couldn't say being chucked to 0,0 every time a name was opened would be a useful outcome.

[billgeo]

Agreed. Just trying to understand the severity of it.

[SPlanzer]

For more context

This is related to the way the gazetteer.gaz_featureextents(integer, double precision); calculates the extent surrounding a point when that extent crosses the dateline.

Below is the results of such extent calculations. Here we can see Lavaud Valley which is not near the dateline and its calculated extent (in red) for "zoom to purposes". On the other hand the Chatham Rise feature is near the dateline and its calculated extent incorrectly extends 180 degrees. This finds 0,0 in the middle.

[SPlanzer]

Not in scope for initial QGIS2>3 release.

[strk]

@SPlanzer or @CMKMS-LINZ could you write instructions to reproduce this in the test environment (ie: starting with make docker-qgis-start) ?

[strk]

I tried this test:

INPUT: ST_Transform('SRID=4326;POINT(180 0)'::geometry, 4167)

FUNCTION: gazetteer.gaz_featureExtents($input, 1)

OUTPUT: BOX(179.99999 -1e-05,180.00001 1e-05)

Is this the problem ?

If so, PR #231 would fix the above by returning, as output:

BOX(179.99999 -1e-05,180 1e-05)

Would that work ? I don't know how to test it completely

[billgeo]

Thanks @strk.

could you write instructions to reproduce this in the test environment (ie: starting with make docker-qgis-start) ?

I think we would need test data for @CMKMS-LINZ to do this, which I think we don't have in the test environment that we built? Not sure how @SPlanzer was testing issues like this. Maybe he can provide some guidance on that?

[SPlanzer]

could you write instructions to reproduce this in the test environment (ie: starting with make docker-qgis-start)

That is problematic.

This behaviour can be investigated in DaaS. But in terms of the docker test environment, specific test data needs to be added (data that crosses 180).

The python integration tests use the plugin functionality to create new data prior to a test but it seems we need a method for loading/creating test data without running these also.

Some data is loaded in the the DB container via the execution of the sql scripts. This could be expanded for creating the relevant test data.

Be aware the DB integrity checks will require certain system codes are in --> https://github.com/linz/gazetteer/blob/master/src/sql/gazetteer_sysdata.sql prior to inserting new data

[billgeo]

Thanks @SPlanzer. So that considerably increases the work to resolve this properly. I think we can leave this on the backlog for now until we have proper test data and other things needed to work on the database code.