Create a Proj4 configuration object

[SamMousa]

This object should be able to parse a valid Proj4 string and hold its settings.

Some of the valid arguments are listed here:
https://trac.osgeo.org/proj/wiki/GenParms

Values should be validated and transformed to their native types.

[judgej]

This was PR #8

[judgej]

Now, taking this one step further, this Proj4 configuration parser is just an instance of a more general geographic reference configuration. The data comes from a Proj4 command-line string in this class now, but could also come from a variety of other sources, including a WKT string, or parsed WKT objects, JSON, or from the ESPG numeric ID (which can be looked up online like this or like this, or even just an array or built up with [immutable] setters.

How would that look?

[SamMousa]

Well in my opinion we should move away from array notations.
My configuration object has public properties (maybe those should be betters).

But if you want to reliable get your parameters from multiple source types than an interface is the way to go, but that interface should not have a getParams() function, it should have a getA() function, or even better a descriptive function name like getEllipsoidRadius() or whatever relevant parameters exist.

[judgej]

Major axis, minor axis, flattening, reciprocal flattening, etc. The terms a, b, r, rf, f etc are well-known to GIS people, so if using the full names instead, then they do need to be absolutely the correct names. Proj4 parameters will be a, b, f etc. so there will be a mapping in there somewhere, perhaps in both directions if we wanted the Proj4 parameter string to go in both directions (for testing and documentation, if nothing else).

Those are just the parameters for an ellipsoid. The others also have long names, but are also referred to by very common abbreviations - lat0, h, long0 etc. I think you are right that parameters and methods need a good, correct and logical name, but we also don't want to hit new users with a massive learning curve that is makes everything very different from what they are used to.

It's why I have tried to use alias for may of the parameters - so you can use l, lng, long, longitude - all equivalent and familiar to people with different datasets from different sources and systems. I guess we pick one (the long one) for the methods, and can implement the aliases as magic methods if we choose to keep that approach.

[SamMousa]

As long as the short names are clearly defined I don't mind getLon0(), for me as "just" a developer they are not clear though, but that's not a big problem.

Agree on your point, we can create mappings relatively easy; we could even do that via a different interface & trait. Then any implementor that implements the "basic" interface can implement the "extended" interface by adding it to the implements clause and adding the trait to the use clause.

[SamMousa]

Even if we want 2 directions I'm not sure that the interface for configuration objects is the place.
Rather it would make sense to have a Proj4Writer::createString(ConfigurationInterface) that can create a configuration string from any configuration object.