Wow Daniel you move quick!
For everyone else here the PR https://github.com/geotools/geotools/pull/2916
is moving along pretty quick. There will be some changed imports but I hope
that most of this ends up being self contained for downstream applications.
One thing that I would like to bring to the email list is changes of this
nature:
- import static tec.uom.se.unit.Units.METRE;
+ import static tech.units.indriya.unit.Units.METRE;
Which are a bother!
How do folks feel about adding to org.geotools.measure.Units:
static Unit<Distance> METRE = tech.units.indriya.unit.Units.METRE;
This way downstream apps could depend on geotools to reference all the
units we use (via static import org.geotools.measure.Units.*) and be a bit
more stable if we ever have to change units libraries again.
--
Jody Garnett
On Wed, 29 Apr 2020 at 16:45, Jody Garnett <jody.garn...@gmail.com> wrote:
> Now is a great time to make the change! We have just released a new major
> release so master is available for breaking changes.
> Experience last time shows that some coordination is needed, but I am
> happy to help with that.
>
> Additional comments inline:
>
> On Wed, 29 Apr 2020 at 14:50, Daniel Cruver <ddcru...@gmail.com> wrote:
>
>> 1.) It doesn't seem to be "auto correcting" to degrees in all cases. See
>> *org.geotools.measure.UnitsTest#testUnitsMatch2*
>>
>
> We found a key difference between these implementation, and our previous
> jscience units library, was how fuzzy the matching was when trying to
> determine if a provided constant was close enough of a match to one
> provided by unit conversions. I think we found the comparison was done
> using float, even when the conversion was a double, making for a very
> subtle series of "regressions".
>
> I found it very helpful when doing this work last time to have two copies
> of the code open and step through with a debugger and see where they
> diverge.
>
> 2.) Doesn't yet handle *NetCDF *Units completely has problems with *DU *
>> unit.
>> *org.geotools.coverage.io.netcdf.NetCDFUnitParserTest.SimpleTests#testDU*
>>
>
>> 3.) *ImageMosaicReaderTests#testGranuleFileViewSidecars and
>> #testGIFSupportFiles*
>> INFO] Running org.geotools.gce.imagemosaic.ImageMosaicReaderTest
>> [/mnt/c/Users/daniel.cruver/Build/Libraries/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/rbgFileView/global_mosaic_0.prj,
>> /mnt/c/Users/daniel.cruver/Build/Libraries/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/rbgFileView/global_mosaic_0.pgw,
>> /mnt/c/Users/daniel.cruver/Build/Libraries/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/rbgFileView/global_mosaic_0.PGW,
>> /mnt/c/Users/daniel.cruver/Build/Libraries/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/rbgFileView/global_mosaic_0.PRJ]
>> [ERROR] Tests run: 91, Failures: 3, Errors: 0, Skipped: 0, Time elapsed:
>> 29.848 s <<< FAILURE! - in
>> org.geotools.gce.imagemosaic.ImageMosaicReaderTest
>> [ERROR]
>> testGranuleFileViewSidecars(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
>> Time elapsed: 0.515 s <<< FAILURE!
>> java.lang.AssertionError:
>>
>> Expected: iterable over [equalToIgnoringCase("global_mosaic_0.prj"),
>> equalToIgnoringCase("global_mosaic_0.pgw")] in any order
>> but: Not matched: "global_mosaic_0.PGW"
>> at
>> org.geotools.gce.imagemosaic.ImageMosaicReaderTest.testGranuleFileViewSidecars(ImageMosaicReaderTest.java:5584)
>>
>> [ERROR]
>> testOverviewSupportFiles(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
>> Time elapsed: 0.248 s <<< FAILURE!
>> java.lang.AssertionError: expected:<2> but was:<4>
>> at
>> org.geotools.gce.imagemosaic.ImageMosaicReaderTest.testOverviewSupportFiles(ImageMosaicReaderTest.java:4898)
>>
>> [ERROR]
>> testGIFSupportFiles(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
>> Time elapsed: 0.026 s <<< FAILURE!
>> java.lang.AssertionError: expected:<6> but was:<12>
>> at
>> org.geotools.gce.imagemosaic.ImageMosaicReaderTest.testGIFSupportFiles(ImageMosaicReaderTest.java:4854)
>>
>> There are more failures but my local test build keeps on failing on
>> database connections.
>>
>
> That sounds odd, are you running with an "online test"? They are all
> usually off by default ... what test is failing?
>
>>
>> Thanks,
>> Dan
>>
>>
>>
>> On Fri, Mar 13, 2020 at 5:38 PM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> I would love to see this work go ahead! Anything we can do to support
>>> you?
>>>
>>> As for plans this is an open community please make a proposal - and then
>>> you are part of the planning :)
>>>
>>> On Fri, Mar 13, 2020 at 11:03 AM Daniel Cruver <ddcru...@gmail.com>
>>> wrote:
>>>
>>>> In GeoTools 20.x, the units library was updated from JSR 271 to JSR 363
>>>> Units (Units 1.0). Which was a great improvement because I was
>>>> encountering classpath issues before I upgrade my projects to using a newer
>>>> version of GeoTools. I am using JSR 385 in my project but adding GeoTools
>>>> still causes additional ServiceProvider to be available that are
>>>> incompatible and cause the process to close if I access them. This can be
>>>> avoided but another problem is that including GeoTools on my projects also
>>>> adds incompatible unit and systems to the classpath and causes confusion.
>>>>
>>>> JSR 363:
>>>> systems.uom:systems-common-java8:0.7.2
>>>>
>>>> JSR 385:
>>>> systems:uom:systems-common:2.0.0
>>>> tech.units:indriya:2.x
>>>>
>>>> Basically if the packages start with "tec.uom" are from the older
>>>> libraries but they now exist in "javax.measure" and "tech.units".
>>>>
>>>> I have done most of the grunt work to rename the packages but the
>>>> custom GeoTools UnitFormats and SexagesimalConverter require more work.
>>>>
>>>> Good new I think some of the workarounds that had to be done in
>>>> GeoTools related to
>>>> https://github.com/unitsofmeasurement/uom-se/issues/201 are no longer
>>>> necessary in the unitofmeasure libraries and reference implementation of
>>>> JSR 385.
>>>> _______________________________________________
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>> --
>>> --
>>> Jody Garnett
>>>
>>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
