Hi, Martin, You're correct about the different approach that was taken with Proj4. One of my greatest issues with it is that the datum transformation feels like it was more tacked on than designed as a part of a complete system.
After reading the alternatives, I agree that #3 is the best option. It seems to flow better, as well as providing less burden on users by reducing the number of imports to use it. Joe Sent from my iPad > On Oct 16, 2013, at 4:48 AM, Martin Desruisseaux > <[email protected]> wrote: > > Hello Adam > > Le 16/10/13 05:17, Adam Estrada a écrit : >> I like #3 as well. It's simple and makes sense. I would like to hear from >> Joe White on this as he has an intimate knowledge of Proj4 and how it's >> implemented in GDAL. Joe, what would you would have wanted to see in >> previous projects? > > On my side, I have a somewhat superficial knowledge of Proj.4. Last time I > looked at the API (when I wrote the Proj.4 - GeoAPI JNI bindings), I didn't > noticed pre-defined constants. I noticed two ways to create a CRS in Proj.4: > > * Either by specifying the CRS definition as a String in the Proj.4 > syntax. In Apache SIS, that would be conceptually equivalent to > using a CRSFactory [1]. > * Either by specifying the EPSG code, in which case Proj.4 looks for > the definition String in a file. In Apache SIS, that would be > conceptually equivalent to using a CRSAuthorityFactory [2]. For > making this task easier, a convenience static method would be > provided [3]. > > > A difference between Proj.4 and Apache SIS is that the Proj.4 project > exported some tables from the EPSG database to a plain text file, while > Apache SIS would connect directly to a local copy of the full EPSG database > using JDBC. Advantage of the full database is that we get more information > (accuracy estimation, aliases, area of validity, transformation paths, etc.). > Inconvenient is that we are more a risk that something goes wrong while using > JDBC (e.g. corrupted database). Thus the idea to select a small subset of CRS > to declare as constants not only for convenience, but also for providing the > guarantee that a minimal definition of those CRS will always be available no > matter what happen with the local copy of the EPSG database. I think that > there is less incentive for that approach in Proj.4... > > > Martin > > > [1] > http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/crs/CRSFactory.html > [2] > http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/crs/CRSAuthorityFactory.html > [3] > https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/referencing/CRS.html#forCode%28java.lang.String%29 >
