Current state of JSR-363 migration

[Martin Desruisseaux <ma...@geomatys.com>]

Hello all

The implementation of JSR-363 (Unit of Measurement API, the JSR-275
successor) is still under way on the JDK8 and JDK7 branches, but will
hopefully be finished soon. A reference implementation exists outside
Apache, but providing our own implementation in Apache SIS allow us to:

  * Associate EPSG code with units.
  * Support GML (un)marshalling for Sensor Web (not yet implemented).
  * Make unit parsing and formatting compatible with geospatial data
    formats (e.g. NetCDF has its own syntax).
  * Provide pre-defined constants for units that would not be of special
    interest outside the geospatial domain (e.g. "US survey foot",
    "grad", etc.).
  * Design the system in a way that facilitate integration with the
    coordinate operations implemented by sis-referencing module.

The implementation takes in account the fact that most unit conversion
factors are defined in base 10 (e.g. one inch is exactly 2.54 cm by
definition) or as ratios (e.g. one US survey foot is defined as exactly
1200/3937 metres). Those numbers have no exact representation in IEEE
754 'double' type.

The tests are temporarily disabled until JSR-363 implementation is
completed. After completion and verification that all tests pass, the
proposal is to deploy a GeoAPI 3.0.1 release candidate on a temporary
Maven repository and use it for trunk. After we verified that all tests
pass on trunk with that release candidate, I would submit GeoAPI 3.0.1
for a formal release at OGC.

Is there any comment about this approach or things that should be done
differently?

    Martin

Re: Current state of JSR-363 migration

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Dave

Le 26/10/16 � 18:47, David Neufeld - NOAA Affiliate a �crit :
> Do you see the JSR-363 implementation supporting units within ISO as well?

Yes, the intend is to provide all the base and derived units published
by BIPM (I think it is equivalent to ISO/IEC 80000-1:2009), with the
addition of some other units for the spatio-temporal dimensions.
Pre-defined constants for some fundamental units are still missing in
org.apache.sis.measure.Units, but I plan to add them.

    Regards,

        Martin

Re: Current state of JSR-363 migration

[David Neufeld - NOAA Affiliate <da...@noaa.gov>]

Martin,

Do you see the JSR-363 implementation supporting units within ISO as well?

Thanks,
Dave


On Tue, Oct 25, 2016 at 3:57 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:

> Hello all
>
> The implementation of JSR-363 (Unit of Measurement API, the JSR-275
> successor) is still under way on the JDK8 and JDK7 branches, but will
> hopefully be finished soon. A reference implementation exists outside
> Apache, but providing our own implementation in Apache SIS allow us to:
>
>   * Associate EPSG code with units.
>   * Support GML (un)marshalling for Sensor Web (not yet implemented).
>   * Make unit parsing and formatting compatible with geospatial data
>     formats (e.g. NetCDF has its own syntax).
>   * Provide pre-defined constants for units that would not be of special
>     interest outside the geospatial domain (e.g. "US survey foot",
>     "grad", etc.).
>   * Design the system in a way that facilitate integration with the
>     coordinate operations implemented by sis-referencing module.
>
> The implementation takes in account the fact that most unit conversion
> factors are defined in base 10 (e.g. one inch is exactly 2.54 cm by
> definition) or as ratios (e.g. one US survey foot is defined as exactly
> 1200/3937 metres). Those numbers have no exact representation in IEEE
> 754 'double' type.
>
> The tests are temporarily disabled until JSR-363 implementation is
> completed. After completion and verification that all tests pass, the
> proposal is to deploy a GeoAPI 3.0.1 release candidate on a temporary
> Maven repository and use it for trunk. After we verified that all tests
> pass on trunk with that release candidate, I would submit GeoAPI 3.0.1
> for a formal release at OGC.
>
> Is there any comment about this approach or things that should be done
> differently?
>
>     Martin
>
>
>


-- 
David Neufeld
Senior Associate Scientist
CIRES
Software Engineering Support Branch
Data Stewardship Division
NOAA National Centers for Environmental Information (NCEI)
Ph. 303-497-6507

Note:
The opinions expressed in this email are those of the author. They do not
necessarily reflect the official views or policies of the University of
Colorado, NOAA, Department of Commerce, or the US Government.