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