And now some days later, the pull request passes tests and is ready for
review:
- https://github.com/geotools/geotools/pull/1834
I have continued to update the proposal
<https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363> with
notes about any api changes (especially bulk search and replace).
--
Jody Garnett
On 26 March 2018 at 22:04, Jody Garnett <[email protected]> wrote:
> The proposal page (https://github.com/geotools/
> geotools/wiki/Migrate-Units-to-JSR-363) has been updated over the course
> of the sprint.
>
> The PR (https://github.com/geotools/geotools/pull/1834) is not quite
> ready yet :(
>
> Cesar and myself traded of migration tasks over the course of the week:
>
> We found the land scape of implementations to be complicated by two things:
>
> 1) There component has both a standard implementation and a reference
> implementation . The reference implementation was done in floats as a toy,
> and of course put into production for mobile.
>
> 2) Each jar has both a normal implementation, and a java8 implementation -
> I presume in response to jigsaw
>
> Currently I am stuck on a gap in JSR 363:
>
> * Measure<V,Q extends Quantity>, we make use of DecimalMeasure and
> VectorMeasure in the gt-coverage module.
>
> There is some discussion here: https://github.com/
> unitsofmeasurement/unit-ri/issues/61
>
> A way forward to to add to our org.geotools.util, or org.geotools.measure
> class to define similar constructs. However I am not sure how valuable
> these abstractions are.
> --
> Jody Garnett
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
