search

judgej / Proj4

Experiments in a Proj4 reboot
MIT License
3 stars 0 forks source link

Create a Proj4 configuration object #7

Open SamMousa opened 8 years ago

SamMousa commented 8 years ago

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 commented 8 years ago

This was PR #8

judgej commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.