My +1 for option #1 if you are still deciding, Martin. Cheers, Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Tuesday, October 15, 2013 1:10 PM To: Apache SIS <[email protected]> Subject: Would like advice on enumeration name for frequently used geodetic objects >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/referen >cing/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 >
