Added Proj4Config and Proj4Importer objects.

[SamMousa]

Added a Proj4Config object. The goal of this object is to parse a proj4 definition and represent it as a PHP object. It should fail hard if the definition is incorrect. Currently it will only fail if there is an unknown key, it does not yet check if the values have the correct types.

Added a Proj4Importer object. The goal of this object is to run the "original" proj4 binary and extract values for datums, ellipsoids, projections and units. It saves these in json files.

The Proj4Config object should use these data files to validate certain values.

[SamMousa]

The "test" script:

• Regenerates the json data files
• Instantiates all definitions in test/data/definitions.json to see if common definitions are parsed correctly. At some point that json file should be a PHPUnit data provider.
• Checks all projections and searches for an implementation class, it lists the total number vs implemented number of projections.

[judgej]

Quick question: are the Proj4 parameters always just an unordered list, or does the ordering ever have any meaning? Or maybe the order only has meaning in certain contexts, such as when converting one format to another on the command line as a single command?

[SamMousa]

No idea. I'm operating under the assumption that it's a unordered list of
key value pairs
On Mar 29, 2016 1:54 PM, "Jason Judge" notifications@github.com wrote:

Quick question: are the Proj4 parameters always just an unordered list, or
does the ordering ever have any meaning? Or maybe the order only has
meaning in certain contexts, such as when converting one format to another
on the command line as a single command?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#8 (comment)

[judgej]

I think most libraries use of Proj4 defines separate source and destination Proj4 strings, like this so we should be okay.

I guess what needs to be parsed is the strings here: http://spatialreference.org/ for example this zone 56 spacial reference

+proj=utm +zone=56 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs

A UTM projection, southern hemisphere, WGS84 ellipsoid and WGS84 datum, and in zone 56. This kind of thing has puzzled me a little about how these things are defined. For me, the +south and +zone are part of what defines the point - they provide context to the point. Without that context, there are lots of points with the same x/y (or north/east) coordinates. So how do they link? How do you ensure a point is locked to this zone etc? Does this whole reference need to be an immutable property of that point? I think so, but I don't see how the original proj4php ever enforced that - I either misunderstand it, or proj4php was perhaps just not providing the protection the data needed?

[SamMousa]

Yes, I'm parsing exactly those.

[judgej]

So a parsed (or otherwise) reference, would that always need to injected into a Point to give that point context?

[SamMousa]

No never, the parsing just exposes the configuration and it (currently) can get from that configuration:

1. An ellipsoid.
2. A datum.
3. A projection.

These are just the objects you already implemented.
Your points should be related to your objects (I think in this case to your Projection class).

This is just to do the translation from proj4 string to judgej/Proj4 native object.

[judgej]

Also, if the geographic reference were supplied in a different format - an array, JSON or WKT format - is there an easy route in for those.

Sorry for all the questions - there is still much I don't understand about how these libraries will be used by other people.

[SamMousa]

@judgej I have added you in skype in case you want to discuss these questions; I have many questions about how all this projection stuff works; maybe we can complement each other!

[judgej]

Cool - can't do that today, as I have a pile of tasks as tall as the ceiling to catch up on, but over the coming week certainly. I don't have Skype running all the time as it eats too many of my laptop's resources, but can fire it up when needed - just email me first.

I have a hand-drawn diagram showing how the conversion paths work from any projection to any other projection, and the steps that it needs to go through, that I'm sure will be a big help. I'll get that scanned in tonight (my phone died this weekend, so can't take a quick snap of it).