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
