Hello all
Quick report on recent work: I started to port
"org.apache.sis.parameter" as a side effect of WKT 2 work (for
dependency reasons), then ported more parameters as a side effect of
"Feature" work (because of similarity in implementation details), and
finally ported the rest of that package since I was on that way. I have
a special case for matrix parameters to port and I'm done.
"org.apache.sis.parameter" is about map projection parameters and is
derived from ISO 19111. While map projections are the main target of
this package, it can also be used for other kind of processes.
One difficulty about map projections is the wide variety of parameter
names for very close things. For example the following names can be seen
as "synonymous" (strictly speaking, many are conceptually different. But
they will perform the same computation in the referencing engine:
subtracting a value to the longitudes):
* OGC: central_meridian
* OGC: longitude_of_center
* EPSG: Longitude of origin
* EPSG: Longitude of false origin
* EPSG: Longitude of natural origin
* EPSG: Spherical longitude of origin
* EPSG: Longitude of projection centre
* ESRI: Central_Meridian
* ESRI: Longitude_Of_Center
* ESRI: Longitude_Of_Origin
* NETCDF: longitude_of_projection_origin
* NETCDF: longitude_of_central_meridian
* GEOTIFF: NatOriginLong
* GEOTIFF: FalseOriginLong
* GEOTIFF: ProjCenterLong
* GEOTIFF: CenterLong
* GEOTIFF: StraightVertPoleLong
* PROJ4: lon_0
So, map projection parameters must have a "primary name" (we select EPSG
name for that purpose) and an arbitrary amount of aliases [1]. They also
have numerical identifiers (not shown in above list). For each name,
alias and identifier, we have a codespace (OGC, EPSG, ESRI, NetCDF,
GeoTIFF, Proj4, etc.) We must be able to handle the fact that some names
became deprecated for historical reasons but still in use [2].
Parameters have cardinality constraints (i.e. be mandatory or optional)
may be constrained to a range of values and may have unit of
measurement. Parameters have Well Known Text (WKT) representation, and
may be (un)marshalled to XML according the GML standard (GML for
parameters to be implemented later).
All the above properties make parameters tedious to declare.
Consequently a ParameterBuilder [3] has been added in the hope to make
the task easier for developers (this is new compared to Geotk).
The parameter .toString() representations format the most important
information (not all) in a tabular format [4], for easier inspection by
developers.
If peoples agree, I would posdone Feature and Shapefile to SIS 0.5 so we
can start preparing the 0.4 RC hopefully Friday. However SIS 0.4 would
be in the strange situation of having support for map projection
parameters, but not yet the map projection themselves...
Martin
[1]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/referencing/AbstractIdentifiedObject.html#getName%28%29
[2]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/util/Deprecable.html
[3]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/parameter/ParameterBuilder.html
[4]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/parameter/ParameterFormat.ContentLevel.html#DETAILED
