From: Brett W. <bre...@ge...> - 2013-06-01 11:41:59
|
Hi Andrea, Thanks for the trouble I have put you through. I develop on Windows -not supported :( I develop using JDK7 - not supported :( I'm not putting down Geotools. It means that I have more of a difficult time to build my own version of Geotools. I'm glad to help, contribute and provide support where needed. I have seen your patch, updated my repo and I am running a build. It has passed the troublesome module. I known that with latter versions of JUnit the execution order of test can be controlled; one option is random. It is just a thought to make the build more robust. It would detect these type of issue more often. Brett ________________________________ From: and...@gm... [and...@gm...] on behalf of Andrea Aime [and...@ge...] Sent: Saturday, 1 June 2013 8:10 PM To: Brett Walker; Simone Giannecchini Cc: geo...@li... Subject: Re: [Geotools-devel] Broken Build on Windows (Again) On Sat, Jun 1, 2013 at 3:03 AM, Brett Walker <bre...@ge...<mailto:bre...@ge...>> wrote: Hi Devs, I develop on Windows and have come across another issue that may be broken ONLY on windows. Not Windows specific, the unofficial GeoSolutions Windows build server is blue now, so there is likely something extra on your system, besides it being Windows: http://office.geo-solutions.it/jenkins/job/GeoTools%20-%2010.x/ There may be other causes, like cross test contamination via static variables (which often shows up as a result of different test order, which in turn stems from listing files in a different order depending on the file system and other accidents), locale or timezone dependent tests, and the like (just to make examples, not saying this is your case). Issuing mvn clean install the build fails in the GeoTIFF grid coverage exchange module on the test org.geotools.gce.geotiff.GeoTiffReaderTest#prjOverrideTesting1 on line 87 After exploring the code, the assertion fails because the two CRSs have datums with different names crs: PROJCS["unnamed", GEOGCS["GCS Name = GRS 1980(IUGG, 1980)", DATUM["Datum = unknown", SPHEROID["Ellipsoid = GRS80", 6378137.0, 298.257222101]], PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH]], PROJECTION["Transverse_Mercator"], PARAMETER["central_meridian", 21.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["scale_factor", 0.9999], PARAMETER["false_easting", 7500000.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0], AXIS["Easting", EAST], AXIS["Northing", NORTH]] crs_: PROJCS["KosovaRef01", GEOGCS["GCS_GRS_1980", DATUM["D_ETRS_89", SPHEROID["GRS_1980", 6378137.0, 298.257222101]], PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295], AXIS["Longitude", EAST], AXIS["Latitude", NORTH]], PROJECTION["Transverse_Mercator"], PARAMETER["central_meridian", 21.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["scale_factor", 0.9999], PARAMETER["false_easting", 7500000.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0], AXIS["x", EAST], AXIS["y", NORTH]] >From reading the comment in org.geotools.referencing.datum.AbstractDatum#equals (line 276) this seems entirely appropriate. I have two suspicions as to location of the failed test; the first is the test is itself is bad (this would be the easy solution), and the second is the GeoTiffReader or PrjFileReader is suspect on Windows. The question I ask is where should I be looking to resolve the issue I have? I may be of target with my analysis above. Is this a known problem on Windows, or is there a satisfactory 'fix' to apply for building on windows. Not aware of any, I believe this is the first time this issue gets reported. Looking at the tif file, it has internally the crs with the un-named datum: aaime@Hydra:~/devel/git-gt$ gdalinfo /home/aaime/devel/git-gt/modules/plugin/geotiff/src/test/resources/org/geotools/gce/geotiff/test-data/override/sample.tif Driver: GTiff/GeoTIFF Files: /home/aaime/devel/git-gt/modules/plugin/geotiff/src/test/resources/org/geotools/gce/geotiff/test-data/override/sample.tif Size is 100, 100 Coordinate System is: PROJCS["unnamed", GEOGCS["GRS 1980(IUGG, 1980)", DATUM["unknown", SPHEROID["GRS80",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",21], PARAMETER["scale_factor",0.9999], PARAMETER["false_easting",7500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (7472000.000000000000000,4776000.000000000000000) Pixel Size = (40.000000000000000,-40.000000000000000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 7472000.000, 4776000.000) ( 20d39'21.21"E, 43d 7'23.96"N) Lower Left ( 7472000.000, 4772000.000) ( 20d39'21.93"E, 43d 5'14.33"N) Upper Right ( 7476000.000, 4776000.000) ( 20d42'18.18"E, 43d 7'24.45"N) Lower Right ( 7476000.000, 4772000.000) ( 20d42'18.80"E, 43d 5'14.82"N) Center ( 7474000.000, 4774000.000) ( 20d40'50.03"E, 43d 6'19.40"N) Band 1 Block=100x27 Type=Byte, ColorInterp=Red NoData Value=255 Band 2 Block=100x27 Type=Byte, ColorInterp=Green NoData Value=255 Band 3 Block=100x27 Type=Byte, ColorInterp=Blue NoData Value=255 So it seems that on your machine the .prj override is not working... I see the override is controlled by GeoTiffReader.OVERRIDE_INNER_CRS, which prjOverrideTesting2 changes, imho in a careless manner: GeoTiffReader.OVERRIDE_INNER_CRS=false; ... System.setProperty(GeoTiffReader.OVERRIDE_CRS_SWITCH, "True"); That is, the switch is asymmetric and not guarantee to happen, and if by any chance prjOverrideTesting2 runs first, prjOverrideTesting1 will break as you see it. Are you by any chance building with JDK 7? GeoTools is officially supported only on JDK 6 (and it will be so until the minimum supported version is that one... basically with the resources we have the minimum supported version is also the only supported version), changing the VM has among other effects one of changing the test order. I know I sound like a broken record, yet a few months ago I also setup a OpenJDK 7 build server, made it build, but again I was the only one looking after it... so eventually I took it down (was running at home and chewing power for nothing...) Anyways, idle complaining does not do any good, but the patch I've just committed on trunk might fix this issue. Can you give it a spin? Cheers Andrea -- == GeoServer training in Milan, 6th & 7th June 2013! Visit http://geoserver.geo-solutions.it<http://geoserver.geo-solutions.it/> for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- |