Would OSGB conversions be appropriate?

[judgej]

Would OSGB to UTM conversions be appropriate to this library, or is it out of scope?
OSGB is a grid system used in the UK and developed by Ordnance Survey (OS). A conversion of OS data to UTM, and back again, would be very useful.

See http://en.wikipedia.org/wiki/Ordnance_Survey_National_Grid

Just testing the water to see if national grid systems is something you want to support. I've had to do conversions on data like this in the past, and will have some code from years ago, tucked away somewhere (I needed to convert postcode locations from OSGB formats). I expect there would be others from other regions and nations, once that gate is open.

[toin0u]

Hi @judgej I think it's very appropriate to this lib :)
It's a kind of toolbox so do not hesiate to submit PRs :)

[judgej]

Thanks - I'll see what I can dig out of my toolbox and have a play with it over the next few weeks.

[toin0u]

Sounds good :) Looking forward to this 🎆

[judgej]

Working on a class to hold an OSGB location, with conversions in and out in any of a number of different coordinates (e.g. location SE0123034300 == SE 01230 34300 == SE 0123 3430 == S 40123 43430 == 040123,043430) Each may represent different sized areas, but they all pinpoint the same bottom-left corner of those areas.

Once that is done, I'll look at the conversion to and from WGS84 (including ellipsoid conversion).

I looked at other libraries that handled OSGB coordinates, and they all mixed too many concepts together at once (formatting, parsing, ellipsoid conversion, coordinate system conversion etc.) which made them difficult to pull apart. Hopefully what I'm writing will be easier to follow and easier to test, albeit written more verbosely (but that's my style).

[toin0u]

Hi Jason,

It sounds good :) Maybe you can make a WIP PR :) So we can disscuss about it during the process. What do you think ?

[judgej]

I've not got anything to push to this repo yet, but am putting the OSGB handling together here:

https://github.com/academe/osgb-tools

Once I have tests etc. and am happy it copes with anything that can be thrown at it, then we can think about how it would integrate. What it does now, is take any OSGB reference format and normalise it to the OSGB grid (stored as metres East and North of square 'V', somewhere out in the Atlantic). This can then be pulled out again in any other OSGB reference format. But most importantly, once normalised, it can be converted to and from other datums.

It should be noted that the OSGB references point to a square, and the format of the reference tells us how big that square is (from 1m to 1000km). The "point" of any square is the bottom left corner (South West) and it is that point which would be used in the datum conversion.

The code I'm working on will accept a whole range of these formats because OSGB data generally comes in those various formats - e.g. free postcode lists to 100m, paid-for postcodes to 10m or even 1m).

[toin0u]

Hi @judgej, awesome work ! Ping me when you need review or something :)

[judgej]

Okay, I'm thinking about how integration will work.

I have a "Square" class that models an OSGB square, from 500km down to 1m. It allows various OSGB references to be passed in and pulled out, as well as numeric Easting/Northing values, that are used in conversions. The Square is the closest equivalent to your Point class. The OSGB Square uses only the Airy ellipsoid.

I also have a Convert class that converts the OSGB Square to and from Long/Lat values (in the OSGB datum and Airy ellipsoid). I started adding code to convert that ellipsoid to more useful ones, but notice that your library can do all that already. An OSGB reference is called a Square in my library because it represents an area and not a single point like a Lat/Long poing. When pulling a "point" out of a Square for conversion, you have the choice of using the SW corner of the square area of the centre of the square, depending on your application (there seems to be no one convention).

So, integration. Any thoughts on how this would work? Some options are:

1. My library is standalone, has yours as a dependency. That gives it access to your conversion classes.
2. My class is standalone and does not attempt to do any ellipsoid conversions. People wishing to do this must also include your library to provide those functions.
3. My library is a dependent of yours, and your library provides wrapper interfaces to make it a more integrated experience to use.
4. The code gets incorporated into your library. I would see Square sitting alongside Point in Coordinate. I don't think my code is stable enough (still refactoring, still no tests) to do that yet, but no reason why it can't be when/if you are happy to do so.
5. I make my library all singing and all dancing, and waste an inordinate amount of time duplicating work that you have already done.

There are pros and cons will all these. I am kind of leaning towards (1) for now, unless the ellipsoid conversions can be split out to a separate package. What do you think?

Got a better name than "Square"? I don't like it, but it kind of describes exactly what it is.

[toin0u]

Thanks for you message :)

I think the best is to do 4. because it gives meaning. But it's up to you :) The Square is fine for me because as you said, it describes precisely what it is.

You can send a work in progress pull request so we can discuss it. Anyway thanks a lot for your effort 👍

[judgej]

I'm using option 1 for now, just while I experiment. We can review that later.
Quick question: I'm sure I saw a way to convert between ellipsoids in the League geo tool library, but I can no longer find it. I either imagined it, or am just not looking in the right place.
For example, the OSGB National Grid Refernce to OSGB Lat/Long conversion will generate Lat/Long coordinates in the Airy ellipsoid. However, Airy is only of use in the UK, while WGS84 is used more widely around the world (it is used for GPS coordinates, which makes it pretty global). So to convert Airy->WGS84 and back again, is needed. Do you have methods for doing that? Or did I imagine it on the route to becoming barking mad?

[toin0u]

Ok, I'm fine with the option 1 :)

There is no methods for converting ellipsoid. But it shouldn't be too difficult to do it as all the information about ellipsoid is present in https://github.com/thephpleague/geotools/blob/master/src/League/Geotools/Coordinate/Ellipsoid.php.

[judgej]

I'm collecting together data for datums at the moment. A datum (in this context) includes both the ellipsoid and the origin (the centre of the Earth). There are a few dozen ellipsoids in common use that most of the common datums use. However, each datum tends to define a different origin. This means that we can convert ellipsoids without a problem (ellipsoid A -> Cartesian (xyz) coordinates -> ellipsoid B), but if we ignore the origin, then the resulting point can be anything up to 200m out.

There are lists of offsets that allow us to shift the centre of he Earth easily while in Cartesian space. It is these lists that I am collecting together, so that datums can be converted more accurately. We are still talking about an accuracy of a metre or two, but it is better than being out by a quarter of a mile.

The centre of the Earth - the origin - is considered to be defined by WGS84, so that defines a centre of (0,0,0). The other datums are offset in 3D from that.

What I am having problems finding, is a clear and unambiguous list of codes for the datums, so they can easily be selected. I don't want to just make something up, as that will isolate the data too much from other systems. There seems to be three-letter codes defined by ARINC (the aviation industry), and a numeric ID defined by EPSG (oil industry). We could probably use both, but the ARINC codes are easier to understand but not so complete (probably fine for general use though https://github.com/academe/osgb-tools/blob/master/data/arinc-424-datum-codes.csv). The EPSG codes are very comprehensive, and really good for oil surveying (http://www.epsg.org/), but maybe overkill for a library that is likely to be used just for converting some common coordinates to Google maps/OpenMaps.

Anyway - that's where I am - tumbling down a rabbit warren. But still having fun. No PRs yet, as I'm still exploring the scope, but I've collected a few more common ellipsoids together that may be worth including. I've indexed them by a standard two-digit code (not sure the source of this code, but it is used a lot) and also referenced to the codes you use where relevant. There are thousands more ellipsoids used by some industries, some of which change each year due to plate tectonics, and I'm sure will be changing due to melting poles and hydro-electric dams changing the centre of mass of the planet. I don't think we want go there though - it would be an application that is well outside PHP's normal realm.

[judgej]

The two-letter codes for the ellipsoids are defined by ISO/IEC 18026. This standard is behind a paywall, but there is enough of the codes spread around the 'net to bring them together here. My intention is to link the datums to their ellipsoids using this code, but there is no reason why the ellipsoids cannot also be referenced directly using any other alias, so WGS84 == WE, and CLARKE_1866 == CC.

[toin0u]

What to say ? Your work is amazing :) I'm really looking forward to your PR !

[coreation]

Hi @toin0u, really nice work with your geotools library, however I have a question about conversions of coordinates between different reference systems. Since @judgej was working on one for the UK reference system, I thought my comment here would be a good place to start.

So I'm using proj4php since 4 years ago, only using some small conversions between Lambert '73 (or EPSG:31370) or others. However I don't see any possibility of doing this using geotools (is that correct?).

If this is so, I can take the code from proj4php, which is LGPL licensed, and change it to match your library structure. Pretty sure that coordinate conversions fit in this package, definitly since it's a league package :). Hope to hear from you soon!

[toin0u]

Hi @coreation, thank you for your kind words :) You're right - it's not possible so you're very welcome to make a PR. I will really appreciate it :)

[coreation]

Great! I think I'll put the code in 1 converter class that inherits from your Convert-interface. Creating a point then convert that point into a something else seems like a big change, as it currently doesn't accept any other coordinate system if I'm reading it quickly ;).

So I'll start doing that, see where I end up, I'll mention you in my commits before I make a PR ;)

[toin0u]

You read correctly ;) Feel free to ping me anytime! I'm very busy atm but I'll do my best :)

[judgej]

Hi @coreation I did start trying to convert proj4 to PHP, and have got some way. That was to convert the OSGB datum to the single datum that geotools uses. IMO that it is the right way to go - to use a separate coordinate conversion library rather than to try to build it into geotools (and of course, duplicating effort and ending up with less flexible tools. Some people are using some parts of that library now, but it still needs more care and attention to finish it off:

https://github.com/academe/proj4php

The basic idea of the library is to be able to pass it some coordinates, tell it what projection and datum it uses, then ask the library to return those some coordinates in any other projection and datum you like.

There may be something you can use in that library, or better still, help to finish it off. It is on my TODO list, but priorities are a constantly shifting thing.

[coreation]

Hi @judgej I was thinking about whether or not this would be fitting to use it here. When I took a look at the Convert Interface I was thinking the same thing: "This maybe better off in a separate library".

I see that it's a 5.3 port (or it was when you started) I'd like for this to be 5.4 at minimum, I'll fork your project and take it for a spin. @toin0u keep you posted on this, you can choose then whether or not to pull it into geotools.

[judgej]

Yeah, go for it. It was 5.3 because that is where thephpleague libraries were at the time. 5.4 is definitely a good minimum now. 5.5 has some nice features, but it does take time for hosters to catch up.

Let me know if there is anything I can do to help, or anything that needs explaining.

[coreation]

Well, (and I've should've seen this coming), there's a port from a project that I was iniitally using, but seemed to lack modern coding ;). This project is called proj4php and initially started by someone in Mexico iirc. This has now been put on github.

[judgej]

Just for a bit of background on the proj4 conversion, I'm basically taking the JavaScript library and converting it almost line-for-line. Ultimately there may be a better way to organise it and to structure the code, but what it actually does is so mathematically complex, I didn't want to have to delve too deeply into the inner workings to rewrite it, because that could be a year-long full-time project on its own.

[coreation]

Oh yea, completely agreeing on that ;) That's why I wanted to check what's out there first. I'm not 100% sure, but I think the proj4php port is almost equal to yours, but just more completed in terms of supported coordinate references. The math behind it to actually perform all of the translations is indeed too much for "just a project on the side".

[judgej]

https://github.com/muka/proj4php/tree/master/src/proj4php - go for it :-) A bit of namespacing, autoloading and PSR-*, and it could be a nice composer library.

[coreation]

Indeed!

[judgej]

One thing the JS libraries don't do, but which PHP is probably more suited to, is to drive some of the functionality from data rather than have all those files with a single line of code in. I did try to pull all the data into CSV files, so that perhaps this data can be read and used to initialise the library. There may be some useful snippets in there:

https://github.com/academe/proj4php/tree/master/data

[coreation]

Great, thanks for the reference. Currently I'm also working with a new Shp library, I'm converting shape libraries into geojson which needs 1/ a shape reader 2/ geo conversion ;). So I'll look into it as my work progresses.

[judgej]

Sorry this has been left hanging for so long. I'm getting back to it now :-)

The OSGB conversion involves a datum shift to WGS84 as well as a projection translation, and that is the complicated bit. I didn't want to put the functionality for that into my OSGB package, because it is a problem that has been solved many times before and it makes sense not duplicating that effort. The Proj.4 project, written in C and which has been going strong since the early 1980s, does datum shifts and a bunch of projection conversions very well. That has been ported to JavaScrript, and that JavaScript library has been ported to PHP.

Now, I have got involved in that latter project to help bring it up to PHP5.4 standards and support composer. That is partly done, but it needs more to be done to shake off a bunch of JavaScript baggage that its conversion has carried with it. Not wanting to do a BC break on its current (large number of) users, I'm experimenting with a reboot of it here. Where that will go - back into Proj4php (which I hope) or whether it will be too far out of scope to do that, I don't know - that's the fun of experimentation.

But the end result is that this will be a separate library to handle datum shifts and projections to and from WGS84, which neither geotools nor its willdurand/geocoder dependency handle (quite rightly, though geocoder does do some ellipsoid stuff). So watch both those spaces if you need to use OSGB UK mapping coordinates with this library, or (hopefully) any other type of coordinate system or projection. I'll make sure there are adapters to help all these things plug together.

Oh, and feedback and suggestions welcomed - I'm dumping all my ideas and thoughts into that package, and any shoves in the right direction if the ideas are way out, will be useful.

[toin0u]

I'll make sure there are adapters to help all these things plug together.

Great work :) I think it's the best alternative 👍

[coreation]

Thanks for the update!