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: [email protected] [[email protected]] on behalf of Andrea Aime
[[email protected]]
Sent: Saturday, 1 June 2013 8:10 PM
To: Brett Walker; Simone Giannecchini
Cc: [email protected]
Subject: Re: [Geotools-devel] Broken Build on Windows (Again)
On Sat, Jun 1, 2013 at 3:03 AM, Brett Walker
<[email protected]<mailto:[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<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
