Martin,

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?

Adam


On Tue, Oct 15, 2013 at 4:10 PM, Martin Desruisseaux <
[email protected]> wrote:

> Hello all
>
> In the "org.apache.sis.referencing" package (link below), there is now 3
> enumerations for frequently used geodetic objects - mostly datum for now,
> Coordinate Reference Systems (CRS) will come later. However I'm unhappy
> about the enumeration names. Below is the purpose of those enumerations,
> followed by the problem and possible solutions.
>
> Reference: classes listed in the "Enum summary" tab of
> https://builds.apache.org/job/**sis-jdk7/site/apidocs/org/**
> apache/sis/referencing/**package-summary.html<https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/referencing/package-summary.html>
>
>
> The purpose
> -------------------------
> Our most definitive way to get geodetic objects is to query the EPSG
> database (to be ported later), which contain thousands of object
> definitions (CRS, ellipsoids, etc). However some geodetic objects are used
> so frequently that it is worth to provide convenience constants for them.
> Some very frequently used geodetic objects are: the Greenwich prime
> meridian, the WGS 84 ellipsoid, the WGS 84 datum, etc.
>
> In Geotk, each implementation classes (DefaultPrimeMeridian,
> DefaultEllipsoid, etc.) provided "public static final" constants for
> frequently used objects. However experience has shown some problems with
> this approach (to detail those problems would be an other topic). For
> Apache SIS, I'm trying to rather provide frequently used geodetic objects
> in separated enumerations. The intend is:
>
>  * To provide meaningful names for frequently used objects (e.g. some
>    peoples may find easier to remember "WGS84" instead than "EPSG:4326").
>  * To make easy to get those objects (e.g. no need to write try ...
>    catch block for FactoryException).
>  * To guarantee that those objects will always be available in any
>    Apache SIS installation. For example it seems reasonable to
>    stipulate that the Greenwich prime meridian and the WGS84 datum
>    shall always be available even in the absence of EPSG database, or
>    even if the user corrupted his local EPSG database. If the geodetic
>    object can not be created from the EPSG database, then Apache SIS
>    would fallback on hard-coded definitions (not as exhaustive as EPSG,
>    but enough for getting things to work).
>
>
>
> The problem
> -------------------------
> The 3 enumerations in are currently named "GeodeticObjects",
> "VerticalObjects" and "TemporalObjects". A Google search suggests that the
> words "geodetic objects" are typically used for ellipsoid, datum, CRS and
> the like. So the "GeodeticObjects" name may be okay. However "vertical
> objects" and "temporal objects" are not typically used in context of
> referencing by coordinates. So I feel that "VerticalObjects" and
> "TemporalObjects" are bad enumeration names.
>
>
> Possible solutions
> -------------------------
> 1) "VerticalReferencing" and "TemporalReferencing" - but I found no usage
> of those words on Google.
>
> 2) "VerticalGeodeticObjects" and "TemporalGeodeticObjects", but I'm not
> sure that the expression "vertical geodetic objects" make sense. Again I
> found no hit on Google.
>
> 3) "GeodeticObjects.Vertical" and "GeodeticObjects.Temporal" (i.e. as
> inner enums of the GeodeticObjects enum). Like option 2 but avoid the
> feeling that we are trying to make a "vertical geodetic objects" sentence.
> As a side effect, developers get enumerations for all dimensions
> (horizontal, vertical and temporal) with a single import statement.
>
> 4) Any other proposal?
>
>
> At this time I have a preference for option 3 but my feeling may change.
> Does anyone have proposal or comments?
>
>     Martin
>
>

Reply via email to