Re: [Geotools-devel] Broken Build on Windows (Again)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Sat, Jun 1, 2013 at 3:03 AM, Brett Walker <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 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

-------------------------------------------------------

Re: [Geotools-devel] Broken Build on Windows (Again)

Toolkit for working with and mapping geospatial data

Re: [Geotools-devel] Broken Build on Windows (Again)