On Sat, Jun 1, 2013 at 3:03 AM, Brett Walker <[email protected]>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 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
-------------------------------------------------------
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
