Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UK] Use database for co-ordinate transformation. #299

Merged
merged 3 commits into from
May 9, 2017

Conversation

dracos
Copy link
Member

@dracos dracos commented May 8, 2017

If the application is running on a server with GDAL 1.9 (and maybe 1.8),
its OSGB co-ordinate transformation can be up to a few metres out. As we
use the transformation by the database when saving new coordinates, also
use it when fetching so we can match and display accurate information.

@mhl
Copy link
Contributor

mhl commented May 9, 2017

Looks good to me - just a couple of things:

  • Do you have a link to a bug report describing the problem where GDAL 1.9 is returning wrong results? It would be helpful to include this in the commit message if so. (e.g. I think GDS are using GDAL 1.10, and that might help them to assess if this affect them.)
  • I'd probably add a test which adds a Postcode for somewhere in Great Britain, runs it through as_uk_grid and checks the eastings / northings output is as expected. (And the same for a postcode in Northern Ireland.)

If the application is running on a server with GDAL 1.9 (and maybe 1.8),
its OSGB co-ordinate transformation can be up to a few metres out. As we
use the transformation by the database when saving new coordinates, also
use it when fetching so we can match and display accurate information.

https://trac.osgeo.org/gdal/ticket/4597 is the GDAL ticket that explains
that it is fixed in GDAL 1.10.
@dracos
Copy link
Member Author

dracos commented May 9, 2017

I've added a link to the GDAL trac ticket and tests (the GB one I've validated against other data, the NI one doesn't agree but as GDAL + postgres match I'm going to go with that anyway). I've then fixed some other test thing (order mattered and tests failed on firefly) and a co-ord display issue.

dracos added 2 commits May 9, 2017 15:59
A couple of tests were e.g. altering mapit.models.countries and not
setting it back, and another two would only pass if COUNTRY was set
to 'GB'. Set those to skip, and restore original settings.
No idea why the latitude in the wmflabs link was being limited to
1 decimal place previously!
@dracos dracos merged commit 130a8d8 into master May 9, 2017
@dracos dracos removed the Reviewing label May 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants