[Geotools-devel] [JIRA] (GEOT-5784) Intermittent failure of ImageWorkerTest.rescaleToBytesNoData

[Ben Caradoc-Davies (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5784  
 
 
  Intermittent failure of ImageWorkerTest.rescaleToBytesNoData   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 18-beta, 17.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 coverage  
 
 
Created: 
 16/Jul/17 4:16 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies  
 

  
 
 
 
 

 
 Seen on Jenkins CI (ares) and locally in Maven and Eclipse. Can be reproduced running just this method in Eclipse: Tests run: 54, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.125 sec <<< FAILURE! - in org.geotools.image.ImageWorkerTest
rescaleToBytesNoData(org.geotools.image.ImageWorkerTest)  Time elapsed: 0.044 sec  <<< FAILURE!
java.lang.AssertionError: expected:<255.0> but was:<254.0>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:743)
	at org.junit.Assert.assertEquals(Assert.java:494)
	at org.junit.Assert.assertEquals(Assert.java:592)
	at org.geotools.image.ImageWorkerTest.rescaleToBytesNoData(ImageWorkerTest.java:868)
  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
  

[Geotools-devel] [JIRA] (GEOT-5780) OGR GeoJSON layer name changes with GDAL 2.2 or later, breaking BridjOGRDataStoreTest

[Ben Caradoc-Davies (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5780  
 
 
  OGR GeoJSON layer name changes with GDAL 2.2 or later, breaking BridjOGRDataStoreTest   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 18-beta  
 
 
Assignee: 
 Ben Caradoc-Davies  
 
 
Components: 
 ogr  
 
 
Created: 
 13/Jul/17 3:55 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies  
 

  
 
 
 
 

 
 With GDAL 2.2 or later, the layer name of a GeoJSON datasource is set to the name member of the FeatureCollection, if it exists: http://www.gdal.org/drv_geojson.html Previous versions of GDAL set the layer name to OGRGeoJSON. This change breaks (for example) BridjOGRDataStoreTest.testAttributesWritingGeoJSON, which expects the old name OGRGeoJSON, not the new name junk set under GDAL 2.2: Tests run: 28, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.251 sec <<< FAILURE! - in org.geotools.data.ogr.bridj.BridjOGRDataStoreTest
testAttributesWritingGeoJSON(org.geotools.data.ogr.bridj.BridjOGRDataStoreTest)  Time elapsed: 0.01 sec  <<< ERROR!
java.io.IOException: Schema 'OGRGeoJSON' does not exist.
	at org.geotools.data.store.ContentDataStore.ensureEntry(ContentDataStore.java:620)
	at org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:393)
	at org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:360)
	at org.geotools.data.ogr.OGRDataStoreTest.testAttributesWritingGeoJSON(OGRDataStoreTest.java:407)
 Solution is for the test to use the layer name that is found, not hard-code the old one. Users should take note that OGR GeoJSON layer names may depend on the version of GDAL installed on their platforms.  
 

  
 

[Geotools-devel] [JIRA] (GEOT-5779) gt-javafx breaks build on server OpenJDK that lacks OpenJFX

[Ben Caradoc-Davies (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5779  
 
 
  gt-javafx breaks build on server OpenJDK that lacks OpenJFX   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 18-beta  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 unsupported  
 
 
Created: 
 13/Jul/17 12:55 AM  
 
 
Environment: 
 OpenJDK 8 on Debian sid amd64  
 
 
Priority: 
  Highest  
 
 
Reporter: 
 Ben Caradoc-Davies  
 

  
 
 
 
 

 
 JavaFX/OpenJFX is included in Oracle JDK 8 but not in OpenJDK 8 bundled for server deployments. Adding the javafx module to the full -Dall build breaks the build on OpenJDK wherever OpenJFX is not installed, including the new Jenkins on build.geoserver.org and GeoSolutions OpenJDK Jenkins. On Debian amd64 this requires 19 MB of downloads and 52 MB on disk. Because OpenJDK is a supported platform, I think that this new native dependency requires discussion. I will remove javafx from the full -Dall build until agreement is reached. gt-javafx can still be built with the -Pjavafx profile. I changed the name for consistency. On Debian or derivatives OpenJFX can be installed with: apt-get install openjfx  
 

  
 
 
  
 

 
 
 
  

[Geotools-devel] [JIRA] (GEOT-5246) Complex feature WFS client fails to parse nested features

[Ben Caradoc-Davies (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ben Caradoc-Davies created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5246 
 
 
 
  Complex feature WFS client fails to parse nested features  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14.0, 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 complex-feature-wfs-client-example.patch 
 
 
 

Components:
 

 wfs-ng 
 
 
 

Created:
 

 09/Oct/15 5:51 AM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Ben Caradoc-Davies 
 
 
 
 
 
 
 
 
 
 
The wfs-ng complex feature WFS client does not appear to parse some nested features. Tested against: http://geossdi.dmp.wa.gov.au/services/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=gsml:Borehole&maxfeatures=2 
Results sometimes depend on the responsiveness of the remote service. 
The failure is: 

 
Exception in thread "main" java.lang.IllegalStateException: Failed to build feature 'urn:cgi:xmlns:CGI:GeoSciML:2.0:BoreholeType'

[Geotools-devel] [JIRA] (GEOT-5197) SQL syntax error in gt-jdbc-postgis PostgisDataStoreOnlineTest

[Ben Caradoc-Davies (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ben Caradoc-Davies created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5197 
 
 
 
  SQL syntax error in gt-jdbc-postgis PostgisDataStoreOnlineTest  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 org.geotools.data.postgis.PostgisDataStoreOnlineTest.txt 
 
 
 

Components:
 

 jdbc-postgis plugin 
 
 
 

Created:
 

 24/Aug/15 11:01 PM 
 
 
 

Environment:
 
 
Jenkins on ares and local Maven against postgis 2.1 on postgres 9.4: 
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-15T06:29:23+13:00) Maven home: /home/ben/java/maven Java version: 1.7.0_79, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.0.0-2-amd64", arch: "amd64", family: "unix" 
 
 
 

Priority:
 
  Highest 
 
 
 

Reporter:
 
 Ben Caradoc-Davies 
 
 
 
 
 
 
 
   

[Geotools-devel] [jira] (GEOT-5014) SimplifyingFilterVisitor breaks MatchAction on multivalued binary comparison operators

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-5014



  SimplifyingFilterVisitor breaks MatchAction on multivalued binary comparison operators 










Issue Type:

  Bug




Affects Versions:


 13-beta, 13-RC1




Assignee:

 Ben Caradoc-Davies




Components:


 main




Created:


 06/Feb/15 6:20 PM




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










A change introduced to SimplifyingFilterVisitor for 

GEOT-4938
 ignores MatchAction when negating binary comparison operators, causing incorrect results on multivalued properties.


GEOT-4938
 Add support for range based simplification to SimplifyingFilterVisitor https://github.com/geotools/geotools/commit/9036a740fadb0a35b095a97616bb7f70ab2fd6f1
Failure is seen in GeoServer app-schema-test online data reference tests:
https://github.com/geoserver/geoserver/blob/master/src/extension/app-schema/app-schema-test/src/test/java/org/geoserver/test/onlineTest/DataReferenceWfsOnlineTest.java
The filter used is:


 

[Geotools-devel] [jira] (GEOT-5011) Invalid double-semicolon on import declarations

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-5011



  Invalid double-semicolon on import declarations 










Issue Type:

  Bug




Affects Versions:


 13-beta, 13-RC1




Assignee:

 Ben Caradoc-Davies




Components:


 coverage-multidim, imagemosaic plugin, render




Created:


 05/Feb/15 4:52 PM




Environment:


 Eclipse Luna SR1a (4.4.1)




Priority:

  Major




Reporter:

 Ben Caradoc-Davies










Import declarations ending in a double-semicolon are invalid and do not compile in Eclipse Luna SR1a (4.4.1) because Eclipse ecj follows the JLS. OpenJDK javac permits import declarations ending in a double-semicolon. Insert usual javac-vs-JLS finger pointing here.
See discussion: http://stackoverflow.com/questions/8125558/eclipse-double-semi-colon-on-an-import http://mail.openjdk.java.net/pipermail/compiler-dev/2013-August/006956.html









 

[Geotools-devel] [jira] (GEOT-5008) PostgisLobTest fails against PostgreSQL 9.4

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-5008



  PostgisLobTest fails against PostgreSQL 9.4 










Issue Type:

  Bug




Affects Versions:


 13-RC1




Assignee:

 Justin Deoliveira




Components:


 jdbc-postgis plugin




Created:


 02/Feb/15 1:33 PM




Environment:


 postgresql-9.4 9.4.0-1 amd64 on debian/sid




Priority:

  Major




Reporter:

 Ben Caradoc-Davies










PostgisLobTest still fails against a fresh PostgreSQL 9.4 test database because gt-jdbc-postgis uses postgresql-8.4-701.jdbc3.jar for tests, and although PostGISDialect faithfully writes bytea hex format for PostgreSQL 9.4, the PostgreSQL 8.4 JDBC driver cannot read bytea hex format and returns corrupted values.


Failed tests: 
  PostgisLobTest>OnlineTestCase.run:123->JDBCLobTest.testWrite:84 null
  PostgisLobTest>OnlineTestCase.run:123->JDBCLobTest.testRead:66 null
  PostgisLobTest>OnlineTestCase.run:123->JDBCLobTest.testWrite:84 null
  PostgisLobTest>OnlineTestCase.run:123->JDBCLobTest.testRead:66 null


  

[Geotools-devel] [jira] (GEOT-4861) Silent failure of almost all online jdbc tests against PostGIS 8

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4861



  Silent failure of almost all online jdbc tests against PostGIS 8 










Issue Type:

  Bug




Affects Versions:


 12-beta, 12-RC1




Assignee:


 Unassigned




Components:


 jdbc




Created:


 29/Jul/14 1:08 AM




Environment:


 PostGIS 8.4.17.




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies












GEOT-4713
 introduced support for citext data in postgis. The test fixture uses PostGIS 9 "create extension" which fails on PostGIS 8, silently disabling all remaining online tests for the module. And PostGISCitextTest is the third test to be run!
commit 0d3fbe332c62530090b3798b50b5c023d7f4fe68 Author: Greg Symons  AuthorDate: Tue Oct 1 17:31:27 2013 -0500 Commit: aaime  CommitDate: Tue Feb 25 12:45:41 2014 +0100
 

GEOT-4713

[Geotools-devel] [jira] (GEOT-4809) Build failure in gt-process-raster BandProcessTest.testROI

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4809



  Build failure in gt-process-raster BandProcessTest.testROI 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:


 Unassigned




Attachments:


 org.geotools.process.raster.BandProcessTest.txt




Components:


 process




Created:


 27/May/14 10:58 PM




Environment:


 Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-15T01:37:52+08:00)  Maven home: /home/car605/tmp/java/maven3  Java version: 1.7.0_55, vendor: Oracle Corporation  Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre  Default locale: en_GB, platform encoding: UTF-8  OS name: "linux", version: "3.14-1-amd64", arch: "amd64", family: "unix" 




Priority:

  Major




Reporter:

 Ben Caradoc-Davies










BandProcessTest.testROI fails in Maven and Eclipse, but only on one 

[Geotools-devel] [jira] (GEOT-4786) LabelShieldTest depends on local font configuration

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4786



  LabelShieldTest depends on local font configuration 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:

 Andrea Aime




Components:


 render




Created:


 27/Apr/14 10:44 PM




Environment:


 Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;  2013-02-19 21:51:28+0800)  Maven home: /home/car605/junk/java/maven3  Java version: 1.6.0_45, vendor: Sun Microsystems Inc.  Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre  Default locale: en_GB, platform encoding: UTF-8  OS name: "linux", version: "3.13-1-amd64", arch: "amd64", family: "unix" 




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










Looking at the rendered images suggests that this test is vulnerable to local font configuration. My failing configuration has:
$ fc-match serif LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"
 Original Message  Subject: [ExternalEmail] [Geotools-devel] LabelShieldTest also failing on Linux with Java 6 Date: Mon, 28 Apr 2014 10:09:40 +0800 From: Ben Caradoc-Davies To: geotools-d

[Geotools-devel] [jira] (GEOT-4751) Build failure in OracleVirtualTableTest

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4751



  Build failure in OracleVirtualTableTest 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:

 Andrea Aime




Attachments:


 org.geotools.data.oracle.OracleVirtualTableTest.txt




Components:


 jdbc-oracle plugin




Created:


 26/Mar/14 9:43 PM




Environment:


 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production  With the Partitioning, OLAP, Data Mining and Real Application Testing options   Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 21:51:28+0800)  Maven home: /home/car605/junk/java/maven3  Java version: 1.6.0_45, vendor: Sun Microsystems Inc.  Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre  Default locale: en_GB, platform encoding: UTF-8  OS name: "linux", version: "3.13-1-amd64", arch: "amd64", family: "unix" 




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies









  

[Geotools-devel] [jira] (GEOT-4733) Build failure in gt-ogr-bridj on Debian wheezy libgdal1

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4733



  Build failure in gt-ogr-bridj on Debian wheezy libgdal1 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:


 Unassigned




Components:


 ogr




Created:


 10/Mar/14 2:04 AM




Environment:


 Apache Maven 3.0.4 (r1232337; 2012-01-17 16:44:56+0800)  Maven home: /home/car605/jenkins/tools/Maven/apache-maven-3.0  Java version: 1.6.0_34, vendor: Sun Microsystems Inc.  Java home: /home/car605/jenkins/tools/JDK/sun-java-6/jre  Default locale: en_AU, platform encoding: UTF-8  OS name: "linux", version: "3.2.0-4-amd64", arch: "amd64", family: "unix"




Priority:

  Major




Reporter:

 Ben Caradoc-Davies










The build fails on Debian wheezy with libgdal1 1.9.0-3.1 amd64. It looks like gdal is working well enough to be detected but not enough for all unit tests to pass. This suggests that functionality might also be broken.
Failed tests:  BridjOGRDataStoreTest>TestCaseSupport.run:116->OGRDataStoreTest.testAttributesWritingCsv:427 expected:<20> but was:<21>
Tests in error:  BridjO

[Geotools-devel] [jira] (GEOT-4732) Build failure in gt-mbtiles MBTilesReaderTest in path with spaces caused by bad File-URL conversions

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4732



  Build failure in gt-mbtiles MBTilesReaderTest in path with spaces caused by bad File-URL conversions 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:

 Justin Deoliveira




Created:


 09/Mar/14 11:03 PM




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










testZoomlevel2(org.geotools.mbtiles.mosaic.MBTilesReaderTest) Time elapsed: 1.196 sec <<< ERROR! java.io.IOException: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (path to '/home/car605/geoserver/src%20with%20spaces/geotools/modules/unsupported/mbtiles/target/test-classes/org/geotools/mbtiles/mosaic/world_lakes.mbtiles': '/home/car605/geoserver/src%20with%20spaces' does not exist)












   

 Add Comment











 

  

[Geotools-devel] [jira] (GEOT-4731) Build failure in gt-render PartialsTest.testPartialLineLabelTrue

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4731



  Build failure in gt-render PartialsTest.testPartialLineLabelTrue 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:

 Andrea Aime




Components:


 render




Created:


 09/Mar/14 8:36 PM




Environment:


 Maven home: /home/car605/junk/java/maven3  Java version: 1.6.0_45, vendor: Sun Microsystems Inc.  Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre  Default locale: en_GB, platform encoding: UTF-8  OS name: "linux", version: "3.13-1-amd64", arch: "amd64", family: "unix" 




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










Fails locally and in Jenkins since GEOT-4729 change:
Failed tests:  PartialsTest.testPartialLineLabelTrue:178 expected:[r=0,g=0,b=0]> but was:[r=255,g=255,b=255]>
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geotools-master/769/consoleText







 

[Geotools-devel] [jira] (GEOT-4728) Intermittent build failure in gt-ogr-bridj BridjOGRDataStoreTest

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4728



  Intermittent build failure in gt-ogr-bridj BridjOGRDataStoreTest 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:


 Unassigned




Components:


 ogr




Created:


 06/Mar/14 9:49 PM




Environment:


 Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 21:51:28+0800)  Maven home: /home/car605/junk/java/maven3  Java version: 1.6.0_45, vendor: Sun Microsystems Inc.  Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre  Default locale: en_GB, platform encoding: UTF-8  OS name: "linux", version: "3.13-1-amd64", arch: "amd64", family: "unix" 




Priority:

  Major




Reporter:

 Ben Caradoc-Davies










Failed tests:  BridjOGRDataStoreTest>TestCaseSupport.run:116->OGRDataStoreTest.testGeometryFilters:735 expected:<4> but was:<2> BridjOGRDataStoreTest>TestCaseSupport.run:116->OGRDataStoreTest.testLoadAndVerify:145 Number of Features loaded expected:<49> but was:<2> BridjOGRDataStoreTest>TestCaseSupport.run:116->OGRDataStoreTest.testOptimizedCount:136 expected:<49> but was:<-1>

 

[Geotools-devel] [jira] (GEOT-4725) Build failure in gt-ogr-bridj BridjOGRDataStoreFactoryTest in path with spaces

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4725



  Build failure in gt-ogr-bridj BridjOGRDataStoreFactoryTest in path with spaces 










Issue Type:

  Bug




Affects Versions:


 12-beta




Assignee:


 Unassigned




Components:


 ogr




Created:


 05/Mar/14 2:08 AM




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










--- Original Message  Subject: Re: [Geotools-devel] Pushing ogr to supported status (on trunk at least) Date: Wed, 05 Mar 2014 16:03:31 +0800 From: Ben Caradoc-Davies To: Jody Garnett CC: jerickson, GeoTools Developers list
Fails locally in maven and Eclipse in a pthe with spaces.
Looks like a b0rked File/URL conversion; for example, just before  failure, ogrSourceName is: /home/car605/geoserver/src%20with%20spaces/geotools/modules/plugin/ogr/ogr-bridj/target/test-classes/org/geotools/data/ogr/bridj/test-data/shapes/statepop.shp
Note the incorrect %20 in the file path.
On 05/03/14 15:55, Ben Caradoc-Davies wrote: > It just passed on Boundless Jenkins (ares). Either a path-with-spaces > issues of ogr installation issue. > > I can confirm that it failed locally as well. > > On 05/03/14 15:53, Jody Garnett wrote: >> It built for me locally, but I assume it is avoiding running tests as I >> do not have OGR installed. >> >> Jody Garnett >

[Geotools-devel] [jira] (GEOT-4687) Build failure in gt-svg DrawTest caused by visibly different image

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4687



  Build failure in gt-svg DrawTest caused by visibly different image 










Issue Type:

  Bug




Affects Versions:


 11-RC1




Assignee:

 Andrea Aime




Components:


 svg plugin




Created:


 02/Feb/14 9:10 PM




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










PerceptualDiff detects a visibly different image after:


GEOT-4685
 SLDStyleFactory graphic rasterization does not honor the rendering hints field
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geotools-master/719/
Failed tests:  DrawTest.testImageFill:69->runFillTest:62 Images are visibly different, PerceptualDiff output is:  Field of view is 89.92 degrees Threshold pixels is 1000 pixels The Gamma is 2.20 The Display's luminance is 100.00 candela per meter squared Converting RGB to XYZ Constructing Laplacian Pyramids Performing test FAIL: Images are visibly different 1998 pixels are different








   

[Geotools-devel] [jira] (GEOT-4684) Build failure in geopkg GeoPackageReaderTest caused by bad File-URL conversions

[Ben Caradoc-Davies (JIRA)]

Title: Message Title










 

 Ben Caradoc-Davies created an issue











 






 GeoTools /  GEOT-4684



  Build failure in geopkg GeoPackageReaderTest caused by bad File-URL conversions 










Issue Type:

  Bug




Affects Versions:


 11-beta




Assignee:

 Niels Charlier




Components:


 geopkg




Created:


 30/Jan/14 8:15 PM




Environment:


 Path with spaces. Java 6. Jenkins and locally.




Priority:

  Critical




Reporter:

 Ben Caradoc-Davies










Building in a path with spaces fails; looks like bas File-URL conversion: https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geotools-master/717/


Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.013 sec <<< FAILURE! - in org.geotools.geopkg.mosaic.GeoPackageReaderTest
testZoomlevel2(org.geotools.geopkg.mosaic.GeoPackageReaderTest)  Time elapsed: 0.008 sec  <<< ERROR!
java.io.IOException: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (path to '/home/jenkins/workspace/geotools-master%20with%20spaces/modules/unsupported/geopkg/target/test-classes/org/geotools/geopkg/mo

[Geotools-devel] [jira] (GEOT-4664) Online build failure inOracleFeatureStoreExposePkTest.testModifyExposedPk caused by Integer/BigDecimal type mismatch

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4664


Online build failure inOracleFeatureStoreExposePkTest.testModifyExposedPk caused by Integer/BigDecimal type mismatch















Issue Type:


Bug



Affects Versions:


11-beta



Assignee:


Andrea Aime



Components:


jdbc-oracle plugin



Created:


12/Jan/14 9:25 PM



Description:


Online gt-jdbc-oracle build fails with:


OracleFeatureStoreExposePkTest>OnlineTestCase.run:123->JDBCFeatureStoreExposePkTest.testModifyExposedPk:71 expected:<0> but was:<0>



The underlying cause is at  org.geotools.jdbc.JDBCFeatureStoreExposePkTest.testModifyExposedPk:71:

assertEquals(0, feature.getAttribute(aname("id")));


which compares the Integer 0 with the BigDecimal 0, which fails as BigDecimal is not instanceof Integer.

This line was introduced by the following commit:

commit 328165b90b7f431ffa7645ee72de84cda3cf6d8a
Author: Andrea Aime 
Date:   Fri Dec 13 12:30:21 2013 +0100
[GEOT-4621] Error updating oracle layer through jdbc






Environment:


ojdbc14-10.2.0.3.0.jar and Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 



Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 21:51:28+0800)

Maven home: /home/car605/junk/java/maven3

Java version: 1.6.0_45, vendor: Sun Microsystems Inc.

Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre

Default locale: en_GB, platform encoding: UTF-8

OS name: "linux", version: "3.12-1-amd64", arch: "amd64", family: "unix"






Project:


GeoTools



Priority:


Major




Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4585) Build failure in PostgisUDTTest against PostgreSQL 9.3

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4585


Build failure in PostgisUDTTest against PostgreSQL 9.3















Issue Type:


Bug



Affects Versions:


11-beta



Assignee:


Justin Deoliveira



Components:


jdbc-postgis plugin



Created:


02/Oct/13 3:49 AM



Description:


It looks like there is a new timezone handling issue introduced between PostgreSQL 9.1 and 9.3.

org.geotools.data.postgis.PostgisUDTTest (the plain one, not the prepared statement test) fails against 9.3 with:

Failed tests: 
  PostgisUDTTest>OnlineTestCase.run:123->testRead:81 null expected:<2004-10-3[0 17]:30:00.0> but was:<2004-10-3[1 01]:30:00.0>



In PostgisUDTTestSetup the following non-timezone timestamp literal is used but then inserted into a with-timezone timestamptz column:

'2004-10-30 17:30'::timestamp



The PostgreSQL 9.3 failure occurs at this point.

assertEquals("2004-10-30 17:30:00.0", item.getAttribute(aname("ut12")).toString());



It looks like the timestamp literal is being parsed as 'GMT' (the database TimeZone) but encoded in the system timezone is Australia/Perth.

The workaround is to change the database TimeZone from 'GMT' to 'Australia/Perth' to match the system:

alter database test set TimeZone to 'Australia/Perth';



The test then passes. This should not be necessary.

I am not quite sure what the change is that causes this problem. There are a few time related changes:
http://www.postgresql.org/docs/9.2/static/release-9-2.html
http://www.postgresql.org/docs/9.3/static/release-9-3.html

Perhaps the casting from timestamp to timestamptz changed? Perhaps the literal could be changed to include a timestamp to make this test more robust?




Environment:


postgresql-9.3 9.3.0-2 amd64 on debian/sid,

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 21:51:28+0800)

Maven home: /home/car605/junk/java/maven3

Java version: 1.6.0_45, vendor: Sun Microsystems Inc.

Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre

Default locale: en_GB, platform encoding: UTF-8

OS name: "linux", version: "3.10-3-amd64", arch: "amd64", family: "unix"




Project:


GeoTools



Priority:


Major




Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4563) SrsSyntax ignored when encoding EngineeringCRS

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4563


SrsSyntax ignored when encoding EngineeringCRS















Issue Type:


Bug



Affects Versions:


11-beta



Assignee:


Justin Deoliveira



Components:


referencing, xsd-gml



Created:


10/Sep/13 4:21 AM



Description:


I have a 3D EngineeringCRS defined in GeoServer epsg.properties as:
71=LOCAL_CS["Mine coordinates",LOCAL_DATUM["Unknown",0],UNIT["m",1.0],AXIS["x",OTHER],AXIS["y",OTHER],AXIS["z",UP]]

(1) According to gt-referencing CRS.getAxisOrder, any CoordinateReferenceSystem that is not instanceof ProjectedCRS or instanceof GeographicCRS has AxisOrder.INAPPLICABLE.

(2) According to gt-xsd-gml2 GML2EncodingUtils.toURI, any CoordinateReferenceSystem with AxisOrder.INAPPLICABLE whall be encoded with SrsSyntax.OGC_HTTP_URL, regardless of the supplied option. There is a TODO questioning this behaviour.

(1)+(2) results in GeoServer SrsSyntax.OGC_HTTP_URL responses srsName="http://www.opengis.net/gml/srs/epsg.xml#71" even when another syntax such as SrsSyntax.OGC_URN or SrsSyntax.OGC_HTTP_URI is selected for WFS. This prevents GeoServer from providing WFS 1.1.0 or WFS 2.0.0 compliant service for this CRS.

The fix is to remove AxisOrder.INAPPLICABLE from the test in gt-xsd-gml2 GML2EncodingUtils.toURI. This is a backwards-incompatible change.




Project:


GeoTools



Priority:


Major




Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4512) Build failure in gt-jdbc-oracle OracleTypeNamesTest

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4512


Build failure in gt-jdbc-oracle OracleTypeNamesTest















Issue Type:


Bug



Affects Versions:


10-beta



Assignee:


Andrea Aime



Components:


jdbc-oracle plugin



Created:


17/Jul/13 4:27 AM



Description:


The tests also take twice as long as usual, suggesting a large performance degradation.

Tests in error: 
  OracleTypeNamesTest>OnlineTestCase.run:123->JDBCTypeNamesTest.testTypeNames:36 » NullPointer

Problematic commit (and a similar merge was performed on 9.x):

commit 309ef90b0ece06532bca0026061a08420a78cb37
Merge: 7e612b8 b465971
Author: Jody Garnett 
Date:   Wed Jul 17 01:35:40 2013 -0700

Merge pull request #227 from r0bb3n/10.x-GEOT-4486_synonyms

GEOT-4486 JDBCDataStore allow synonyms




Project:


GeoTools



Priority:


Major




Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4504) Build failure in gt-coverage-api CatalogSliceTest in path with spaces

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4504


Build failure in gt-coverage-api CatalogSliceTest in path with spaces















Issue Type:


Bug



Affects Versions:


10-beta



Assignee:


Simone Giannecchini



Components:


coverage



Created:


07/Jul/13 9:51 PM



Description:


Caused by bogus URL->File conversion. Test data is written to parallel directory where path with spaces becomes path%20with%20spaces and the test fails.

Running org.geotools.coverage.io.catalog.CatalogSliceTest
08-Jul-2013 10:33:01 org.geotools.data.h2.H2Dialect postCreateTable
WARNING: Column the_geom has no crs
08-Jul-2013 10:33:01 org.geotools.data.h2.H2Dialect postCreateTable
WARNING: Column the_geom has no crs
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.83 sec <<< FAILURE! - in org.geotools.coverage.io.catalog.CatalogSliceTest
basicConnectionTest(org.geotools.coverage.io.catalog.CatalogSliceTest)  Time elapsed: 0.144 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<20> but was:<0>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:277)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:195)
	at junit.framework.Assert.assertEquals(Assert.java:201)
	at org.geotools.coverage.io.catalog.CatalogSliceTest.basicConnectionTest(CatalogSliceTest.java:202)

Failed tests: 
  CatalogSliceTest.basicConnectionTest:202 expected:<20> but was:<0>




Environment:


Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 21:51:28+0800)

Maven home: /home/car605/junk/java/maven3

Java version: 1.6.0_45, vendor: Sun Microsystems Inc.

Java home: /home/car605/junk/java/jdk1.6.0_45.x64/jre

Default locale: en_GB, platform encoding: UTF-8

OS name: "linux", version: "3.9-1-amd64", arch: "amd64", family: "unix"






Project:


GeoTools



Priority:


Critical




Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4457) DecoratingSimpleFeatureCollection does not delegate accepts method

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 reopened  GEOT-4457


DecoratingSimpleFeatureCollection does not delegate accepts method
















Broke the build on both 9.x and master.





Change By:


Ben Caradoc-Davies
(01/May/13 9:12 PM)




Status:


Resolved
Reopened





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4390) Missing expression in Oracle with app-schema joining

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4390


Missing _expression_ in Oracle with app-schema joining















Issue Type:


Bug



Affects Versions:


8.6



Assignee:


Rini Angreani



Components:


app-schema plugin



Created:


11/Feb/13 8:45 PM



Description:


Report referred to "GeoServer 2.2" so I am guessing a recent 8.x. Not tested against master. Original thread here:
http://osgeo-org.1560.n6.nabble.com/WFS-Performance-Issues-in-GeoTools-with-App-schema-Module-td5032333.html

This report comes further on:


 Original Message 
Subject: Re: [Geotools-gt2-users] WFS Performance Issues in GeoTools with App-schema Module
Date: Fri, 8 Feb 2013 10:22:30 +0800
From: Mike Beaumont
To: geotools-gt2-us...@lists.sourceforge.net

I don't expect anyone to answer the following in this thread but for the
record, I set 
app-schema.joining = true
and the following SQL was generated which led to an Oracle Exception
*ORA-00936: missing _expression_*
due to some of the inner join clauses having empty brackets where the
specified join columns should go.
I'll have to dig deeper into the code and/or config. But it is interesting
that the requests work fine without joining (it's just that it's slow) but
not at all with joining=true.
Here's the SQL:
SELECT 
SG_GSML_LITHOLOGY.ID,
SG_GSML_LITHOLOGY.COMPOSITIONPART_ID,
SG_GSML_LITHOLOGY.LITHOLOGY,
SG_GSML_LITHOLOGY.LITHOLOGY_URI,
SG_GSML_LITHOLOGY.LITHOLOGY_URN,
SG_GSML_COMPOSITIONPART.ID FOREIGN_ID_0_0,
SG_GSML_GEOLOGICUNIT.GML_ID FOREIGN_ID_1_0,
SG_GSML_MAPPEDFEATURE_250K.GML_ID FOREIGN_ID_2_0 
FROM SG_GSML_LITHOLOGY 
INNER JOIN SG_GSML_COMPOSITIONPART ON ( SG_GSML_COMPOSITIONPART.ID =
SG_GSML_LITHOLOGY.COMPOSITIONPART_ID)  
INNER JOIN SG_GSML_COMPOSITIONPART SG_GSML_COMPOSITIONP_1 ON ( ) 
INNER JOIN SG_GSML_GEOLOGICUNIT ON ( SG_GSML_GEOLOGICUNIT.ID =
SG_GSML_COMPOSITIONP_1.GEOGRAPHICFEATURE_ID) 
INNER JOIN SG_GSML_GEOLOGICUNIT SG_GSML_GEOLOGICUNIT_1 ON ( )  
INNER JOIN SG_GSML_MAPPEDFEATURE_250K ON (
SG_GSML_MAPPEDFEATURE_250K.GEOGRAPHICFEATURE_ID = SG_GSML_GEOLOGICUNIT_1.ID) 
INNER JOIN ( 
SELECT DISTINCT GML_ID FROM SG_GSML_MAPPEDFEATURE_250K 
WHERE GML_ID = gsml.mappedfeature.geologicunit.250k-1005 )
temp_alias_used_for_filter 
ON ( SG_GSML_MAPPEDFEATURE_250K.GML_ID = TEMP_ALIAS_USED_FOR_FILTER.GML_ID )  
ORDER BY 
SG_GSML_MAPPEDFEATURE_250K.GML_ID ASC,
SG_GSML_GEOLOGICUNIT.GML_ID ASC, 
CASE WHEN SG_GSML_MAPPEDFEATURE_250K.GEOGRAPHICFEATURE_ID =
SG_GSML_GEOLOGICUNIT.ID THEN 0 ELSE 1 END ASC,
SG_GSML_COMPOSITIONPART.ID ASC, 
CASE WHEN SG_GSML_GEOLOGICUNIT.ID =
SG_GSML_COMPOSITIONPART.GEOGRAPHICFEATURE_ID THEN 0 ELSE 1 END ASC






Project:


GeoTools



Priority:


Major



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4354) Improving BandSelect selection of ColorModel

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 reopened  GEOT-4354


Improving BandSelect selection of ColorModel 
















Reverted in 7dfd0fd833a81d419676eae19a31be7c18dc2842 on master to fix the build.





Change By:


Ben Caradoc-Davies
(18/Dec/12 8:57 PM)




Status:


Resolved
Reopened





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4268) Build failure in gt-render LabelObstacleTest.testLineWithGraphicStroke with perceptualdiff

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4268


Build failure in gt-render LabelObstacleTest.testLineWithGraphicStroke with perceptualdiff















Issue Type:


Bug



Affects Versions:


9.0-M0



Assignee:


Justin Deoliveira



Components:


render



Created:


19/Sep/12 9:39 PM



Description:


Justin, since you made these changes the build is broken if perceptualdiff is enabled:

Summary

GEOT-4258 envelope returned by MemoryDataStore getBounds has no coordinate reference system set (details)
added testcases for GEOT-4258 (details)

Commit a4e2edf1151c619aa41e35b42f286e0838ca5393 by jdeolive

GEOT-4258 envelope returned by MemoryDataStore getBounds has no coordinate reference system set

The file was modified	modules/library/main/src/main/java/org/geotools/data/memory/MemoryDataStore.java
Commit 3370eb440ba9c7088ac8847767503285e9fc2ebe by jdeolive

added testcases for GEOT-4258

The file was modified	modules/library/main/src/test/java/org/geotools/data/memory/MemoryDataStoreBoundsTest.java


See:


https://cgsrv8.arrc.csiro.au/jenkins/job/geotools-master/org.geotools$gt-render/107/testReport/org.geotools.renderer.lite/LabelObstacleTest/testLineWithGraphicStroke/

Error Message

Images are visibly different, PerceptualDiff output is:  /home/jenkins/workspace/geotools-master with spaces/modules/library/render/src/test/resources/org/geotools/renderer/lite/test-data/obstacles/hatch.png: Not a TIFF or MDI file, bad magic number 20617 (0x5089). /home/jenkins/workspace/geotools-master with spaces/modules/library/render/target/actual.png: Not a TIFF or MDI file, bad magic number 20617 (0x5089). Field of view is 89.92 degrees Threshold pixels is 10 pixels The Gamma is 2.20 The Display's luminance is 100.00 candela per meter squared Converting RGB to XYZ Constructing Laplacian Pyramids Performing test FAIL: Images are visibly different 4464 pixels are different 

Stacktrace

java.lang.AssertionError: Images are visibly different, PerceptualDiff output is: 
/home/jenkins/workspace/geotools-master with spaces/modules/library/render/src/test/resources/org/geotools/renderer/lite/test-data/obstacles/hatch.png: Not a TIFF or MDI file, bad magic number 20617 (0x5089).
/home/jenkins/workspace/geotools-master with spaces/modules/library/render/target/actual.png: Not a TIFF or MDI file, bad magic number 20617 (0x5089).
Field of view is 89.92 degrees
Threshold pixels is 10 pixels
The Gamma is 2.20
The Display's luminance is 100.00 candela per meter squared
Converting RGB to XYZ
Constructing Laplacian Pyramids
Performing test
FAIL: Images are visibly different
4464 pixels are different

at org.geotools.image.test.ImageAssert.assertEquals(ImageAssert.java:119)
	at org.geotools.image.test.ImageAssert.assertEquals(ImageAssert.java:58)
	at org.geotools.renderer.lite.LabelObstacleTest.testLineWithGraphicStroke(LabelObstacleTest.java:234)




Environment:


Linux Java 6 64-bit.




Project:


GeoTools



Priority:


Critical



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j

[Geotools-devel] [jira] (GEOT-4262) imagemosaic tests write data outside working directory with spaces

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4262


imagemosaic tests write data outside working directory with spaces















Issue Type:


Bug



Affects Versions:


9.0-M0



Assignee:


Unassigned


Components:


imagemosaic plugin



Created:


18/Sep/12 2:00 AM



Description:


Looks like a bad File<->URL conversion.

When I build GeoTools in a path with spaces:

"src with spaces/geotools"

I find the following written outside the working directory:


$ find src%20with%20spaces/
src%20with%20spaces/
src%20with%20spaces/geotools
src%20with%20spaces/geotools/modules
src%20with%20spaces/geotools/modules/plugin
src%20with%20spaces/geotools/modules/plugin/imagemosaic
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/water%20temp3
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/water%20temp3/imagemosaic.data.db
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/water%20temp3/imagemosaic.trace.db
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/water%20temp3/imagemosaic.8.log.db
src%20with%20spaces/geotools/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/water%20temp3/imagemosaic.index.db






Project:


GeoTools



Priority:


Major



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4234) Intermittent build failure in wfs-ng MemoryDataStoreIntegrationTest testGetFeatureLockingExpire

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4234


Intermittent build failure in wfs-ng MemoryDataStoreIntegrationTest testGetFeatureLockingExpire















Issue Type:


Bug



Affects Versions:


9.0-M0



Assignee:


Gabriel Roldán



Components:


wfs plugin



Created:


20/Aug/12 8:36 PM



Description:


wfs-ng MemoryDataStoreIntegrationTest testGetFeatureLockingExpire fails intermittently.

Seen on OpenGeo Hudson, Jenkins, and locally.

Here is one:
http://hudson.opengeo.org/hudson/job/geotools-master/4498/console

Failed tests:   testGetFeatureLockingExpire(org.geotools.data.wfs.integration.MemoryDataStoreIntegrationTest): fid-3c6d8b2_13943566ad6_-7f74 not locked



Here is another:
https://cgsrv8.arrc.csiro.au/jenkins/view/geoserver-master/job/geotools-master/org.geotools$gt-wfs-ng/33/testReport/junit/org.geotools.data.wfs.integration/MemoryDataStoreIntegrationTest/testGetFeatureLockingExpire/

junit.framework.AssertionFailedError: fid--19568732_1392bb88785_-7f74 not locked
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at org.geotools.data.wfs.integration.AbstractDataStoreTest.testGetFeatureLockingExpire(AbstractDataStoreTest.java:1447)






Project:


GeoTools



Priority:


Critical



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4223) Build failure in wfs-ng WFSClientTest

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4223


Build failure in wfs-ng WFSClientTest















Issue Type:


Bug



Affects Versions:


9.0-M0



Assignee:


Gabriel Roldán



Attachments:


org.geotools.data.wfs.internal.WFSClientTest.txt



Components:


wfs plugin



Created:


08/Aug/12 3:23 AM



Description:



Results :

Failed tests:   testAutoDetermineStrategy(org.geotools.data.wfs.internal.WFSClientTest): expected: but was:

Tests run: 56, Failures: 1, Errors: 0, Skipped: 3



Surefire report attached.




Environment:


Apache Maven 3.0.4 (r1232337; 2012-01-17 16:44:56+0800)

Maven home: /home/car605/junk/java/maven3

Java version: 1.6.0_32, vendor: Sun Microsystems Inc.

Java home: /home/car605/junk/java/jdk1.6.0_32.x64/jre

Default locale: en_GB, platform encoding: UTF-8

OS name: "linux", version: "2.6.43.8-1.fc15.x86_64", arch: "amd64", family: "unix"






Project:


GeoTools



Priority:


Major



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4170) Support for URL query component in app-schema-resolver cache

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 reopened  GEOT-4170


Support for URL query component in app-schema-resolver cache
















 Original Message 

Subject: Re: [jira] (GEOT-4170) Support for URL query component in app-schema-resolver cache

Date: Wed, 18 Jul 2012 11:27:49 +0800

From: Ben Caradoc-Davies 

To: Brown, Adam (CESRE, Kensington) 



Perhaps an optional constructor argument, to make it immutable?



On 18/07/12 10:55, Brown, Adam (CESRE, Kensington) wrote:

> Mmm good question, I fixed this in isolation thinking that I would be calling those methods myself but it looks like EmfAppSchemaReader will actually be responsible for using the resolver. Perhaps I should make it an object-level setting instead?

>

> AppSchemaResolver.setKeepQuery(true)

>

> Cheers,

>

>

> Adam

>

>

> -Original Message-

> From: Caradoc-Davies, Ben (CESRE, Kensington)

> Sent: Wednesday, 18 July 2012 10:36 AM

> To: Brown, Adam (CESRE, Kensington)

> Subject: Fwd: [jira] (GEOT-4170) Support for URL query component in app-schema-resolver cache

>

> Adam, one thing occurred to me this morning: how do you actually *use* this new functionality? To you intend to patch other resolver methods as well? I don't see how the keepQuery flag can ever be set.

>

> Kind regards,

> Ben.

>







Change By:


Ben Caradoc-Davies
(17/Jul/12 11:02 PM)




Assignee:


Ben Caradoc-Davies
Adam Brown





Status:


Resolved
Reopened





Resolution:


Fixed



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4204) Intermittent JDBCJoinTest failures

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4204


Intermittent JDBCJoinTest failures















Issue Type:


Bug



Affects Versions:


9.0-M0



Assignee:


Andrea Aime



Components:


jdbc-oracle plugin, jdbc-postgis plugin



Created:


17/Jul/12 3:21 AM



Description:


I am seeing intermittent JDBCJoinTest failures in both gt-jdbc-postgis and gt-jdbc-oracle in Maven. I have also seen one for gt-jdbc-postgis failure in Eclipse.

3 of our last 18 Jenkins builds for GeoTools master have failed with seemingly random failures in JDBCJoinTest subclasses:
https://cgsrv8.arrc.csiro.au/jenkins/job/geotools-master/

Two are org.geotools.data.postgis.ps.PostgisJoinTest.testSimpleJoinWithSort:
https://cgsrv8.arrc.csiro.au/jenkins/job/geotools-master/39/
https://cgsrv8.arrc.csiro.au/jenkins/job/geotools-master/34/

One is org.geotools.data.oracle.OracleJoinTest.testSimpleJoinWithPostFilter:
https://cgsrv8.arrc.csiro.au/jenkins/job/geotools-master/24/

I have seen one in Eclipse in org.geotools.data.postgis.ps.PostgisJoinTest.testOuterJoin:

java.lang.RuntimeException: org.postgresql.util.PSQLException: This ResultSet is closed.
	at org.geotools.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:349)
	at org.geotools.jdbc.JDBCJoiningFeatureReader.next(JDBCJoiningFeatureReader.java:93)
	at org.geotools.jdbc.JDBCJoiningFeatureReader.next(JDBCJoiningFeatureReader.java:41)
	at org.geotools.data.store.ContentFeatureCollection$WrappingFeatureIterator.next(ContentFeatureCollection.java:218)
	at org.geotools.data.store.ContentFeatureCollection$WrappingFeatureIterator.next(ContentFeatureCollection.java:198)
	at org.geotools.jdbc.JDBCJoinTest.doTestOuterJoin(JDBCJoinTest.java:419)
	at org.geotools.jdbc.JDBCJoinTest.testOuterJoin(JDBCJoinTest.java:402)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at org.geotools.test.OnlineTestCase.run(OnlineTestCase.java:123)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.postgresql.util.PSQLException: This ResultSet is closed.
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.checkClosed(AbstractJdbc2ResultSet.java:2674)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.checkResultSet(AbstractJdbc2ResultSet.java:2693)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2528)
	at org.apache.commons.dbcp.DelegatingResultSet.getObject(DelegatingResultSet.java:325)
	at org.apache.commons.dbcp.DelegatingResultSet.getObject(DelegatingResultSet.java:325)
	at org.apache.commons.dbcp.DelegatingResultSet.getObject(DelegatingResultSet.java:325)
	at org.geotools.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:326)
	... 26 more






Environment:


Apache Maven 3.0.4 (r1232337; 2012-01-17 16:44:5

[Geotools-devel] [jira] (GEOT-4174) Build failure in gt-epsq-hsql caused by LongitudeFirstFactoryOverrideTest forceXY hint leak

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4174


Build failure in gt-epsq-hsql caused by LongitudeFirstFactoryOverrideTest forceXY hint leak















Issue Type:


Bug



Affects Versions:


8.0-RC2



Assignee:


Andrea Aime



Components:


referencing



Created:


13/Jun/12 12:19 AM



Description:


ThreadedHsqlEpsgFactoryTest (and others) fail if and only if LongitudeFirstFactoryOverrideTest runs first. ThreadedHsqlEpsgFactoryTest runs fine by itself with -Dtest=ThreadedHsqlEpsgFactoryTest.

LongitudeFirstFactoryOverrideTest has setUp:

System.setProperty("org.geotools.referencing.forceXY", "true");


and tearDown:

System.clearProperty("org.geotools.referencing.forceXY");


but something called in the tests is likely caching some static hint set on first invocation.

The full output:

---
 T E S T S
---
Running org.geotools.referencing.factory.epsg.LongitudeFirstFactoryOverrideTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.065 sec
Running org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest
Tests run: 12, Failures: 0, Errors: 12, Skipped: 0, Time elapsed: 0.061 sec <<< FAILURE!
Running org.geotools.referencing.factory.epsg.DefaultFactoryTest
Tests run: 14, Failures: 0, Errors: 14, Skipped: 0, Time elapsed: 0.146 sec <<< FAILURE!
Running org.geotools.referencing.factory.epsg.OperationFactoryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.132 sec
Running org.geotools.referencing.factory.OrderedAxisAuthorityFactoryTest
Tests run: 4, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec <<< FAILURE!
Running org.geotools.referencing.factory.URN_EPSG_Test
Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.087 sec <<< FAILURE!
Running org.geotools.referencing.CrsCreationDeadlockTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.geotools.referencing.CRSTest
Tests run: 27, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 0.326 sec <<< FAILURE!

Results :

Failed tests:   testFind(org.geotools.referencing.factory.OrderedAxisAuthorityFactoryTest)
  testAxisReordering(org.geotools.referencing.factory.OrderedAxisAuthorityFactoryTest)
  testLongitudeFirst(org.geotools.referencing.factory.OrderedAxisAuthorityFactoryTest): Expected a left-handed CS. expected:<-90.0> but was:<90.0>
  test4326(org.geotools.referencing.factory.URN_EPSG_Test): expected same: but was:
  testForcedAxisOrder(org.geotools.referencing.CRSTest): Should not be (long,lat) axis order.
  testHorizontalFromCompound(org.geotools.referencing.CRSTest): expected: but was:
  testSRSAxisOrder(org.geotools.referencing.CRSTest): null expected:<[urn:ogc:def:crs:EPSG:]:4326> but was:<[EPSG]:4326>

Tests in error: 
  testConnectionCorruption(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.geotools.referencing.factory.epsg.LongitudeFirstFactory cannot be cast to org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
  testConnectionCorruptionListAll(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.geotools.referencing.factory.epsg.LongitudeFirstFactory cannot be cast to org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
  testCreation(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.geotools.referencing.factory.epsg.LongitudeFirstFactory cannot be cast to org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
  testFunctionality(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.geotools.referencing.factory.epsg.LongitudeFirstFactory cannot be cast to org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
  testAuthorityCodes(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.geotools.referencing.factory.epsg.LongitudeFirstFactory cannot be cast to org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
  testFindWSG84(org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactoryTest): org.g

[Geotools-devel] [jira] (GEOT-4160) Support parsing srsName in OGC HTTP URI format

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies
 created  GEOT-4160


Support parsing srsName in OGC HTTP URI format















Issue Type:


Improvement



Affects Versions:


8.0-RC2



Assignee:


Andrea Aime



Components:


referencing



Created:


31/May/12 11:28 PM



Description:


Support parsing srsName represented with an OGC HTTP URI like:

http://www.opengis.net/def/crs/EPSG/0/4326

urn:ogc support in requests is provided by gt-referencing URN_AuthorityFactory. To support HTTP URIs we need an HTTP_URI_AuthorityFactory (not to be confused with HTTP_AuthorityFactory). We would also need SPI entries in:
modules/library/referencing/src/main/resources/META-INF/services/org.opengis.referencing.crs.CRSAuthorityFactory
modules/library/referencing/src/main/resources/META-INF/services/org.opengis.referencing.cs.CSAuthorityFactory

Support in WFS for HTTP URIs is before the WFS/FES SWG and will likely be included in WFS 2.1. See:
"Allow use of http URIs to identify CRS" (WFS/FES change request 11-152):
https://portal.opengeospatial.org/files/?artifact_id=46445

Whitepaper:
"OGC Identifiers – the case for http URIs" (OGC 10-124r1):
https://portal.opengeospatial.org/files/?artifact_id=39467

HTTP URIs are current OGC policy:
"In June 2010 OGC revised the naming policy to use http URIs to identify
persistent OGC resources instead of URNs."
http://www.opengeospatial.org/projects/groups/ogcnasc

Youse might also be interested in Simon's recent seminar on controlled
vocabularies (slides and audio):
https://wiki.csiro.au/display/ARRCSeminars/Delivering+controlled+vocabularies+on+the+web+-+persistent+identifiers+and+the+web+of+things

Simon explains why HTTP URIs are useful because they allow the
implementation of Tim Berners-Lee's Linked (Open) Data rules, and
describes some successful patterns for using them.




Project:


GeoTools



Priority:


Major



Reporter:


Ben Caradoc-Davies




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4115) Switch to W3C XLink

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4115:


 Summary: Switch to W3C XLink
 Key: GEOT-4115
 URL: https://jira.codehaus.org/browse/GEOT-4115
 Project: GeoTools
  Issue Type: Improvement
  Components: xsd-gml
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Critical


http://www.spatineo.com/2012/04/ogc-to-switch-to-wc3-xlink-in-july-2012/


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4114) Substitution group errors in FeatureTypeRegistry

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4114:


 Summary: Substitution group errors in FeatureTypeRegistry
 Key: GEOT-4114
 URL: https://jira.codehaus.org/browse/GEOT-4114
 Project: GeoTools
  Issue Type: Bug
  Components: app-schema plugin
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani


To see many of these messages, run the unit tests for gt-app-schema in Maven or 
Eclipse.

 Original Message 
Subject: Re: [Geotools-devel] App-Schema and not found warnings
Date: Fri, 20 Apr 2012 10:11:13 +0800
From: Ben Caradoc-Davies 
To: Brett Walker 
CC: geotools-devel@lists.sourceforge.net 

On 20/04/12 09:38, Brett Walker wrote:
> I've noticed that the app-schema extension on trunk now generates a myriad of 
> warnings like the one below.
> 19/04/2012 1:29:29 PM 
> org.geotools.data.complex.config.FeatureTypeRegistry
> WARNING: Unable to set substitution group, caused by: XSD type definition not 
> found in schemas: {http://www.opengis.net/gml}CoordinateSystemAxisBaseType

I think this might be a bona fide error. Substitution groups are 
collected to enable better support for polymorphic types, so users do 
not have to specify targetAttributeNode in many cases. This error might 
be caused by circular dependencies or type registration order problems 
in FeatureTypeRegistry.

[...]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4105) app-schema GML 3.2 gml:id xlink:href for repeated elements in wrong location

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4105:


 Summary: app-schema GML 3.2 gml:id xlink:href for repeated 
elements in wrong location
 Key: GEOT-4105
 URL: https://jira.codehaus.org/browse/GEOT-4105
 Project: GeoTools
  Issue Type: Bug
  Components: app-schema plugin, xsd-gml
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani


[Originally reported on CSIRO Jira on 30/Jun/11. See: 
https://jira.csiro.au/browse/SISS-1086 (login required)]


Original report from Alistair Ritchie:


When an element with the same gml:id is repeated in an XML document all 
subsequent instances must be replaced with an xlink:href on the property in 
question hash referencing the initial occurrence.

For example, where two MappedFeatures have the same specification values, they 
should appear as:


[MappedFeature stuff]


[Contact stuff]




then


[MappedFeature stuff]



Geoserver is wrongly encoding the second occurrence, resulting in schema 
invalid responses:


[MappedFeature stuff]





This has been observed in a number of contexts, not just gsml30:specification.


And later after much discussion and many delays:


 Original Message 
Subject: Re: Geoserver and gml:ids (ii)
Date: Tue, 7 Feb 2012 11:29:36 +0800
From: Alistair Ritchie
To: Caradoc-Davies, Ben (CESRE, Kensington)
CC: Angreani, Rini (CESRE, Kensington), Fraser, Ryan (CESRE, Kensington)

OK, thanks for the update.

This may well cause grumbles in in the GeoSciML community as it renders 
MappedFeature responses invalid/useless.

Important point - unlike ERML services, GeoSciML GeologicFeatures almost always 
have multiple associated MappedFeatures, so an ability to properly 'escape' 
repeated GeologicFeatures inline in a MappedFeature is crucial to getting a 
valid response.

As a result, app-schema still can't be considered production ready and I can't 
recommend that the Geoserver work I've done for the sample DB 'goes live' until 
this is resolved. As far as deployment for GeoSciML goes, I'd be calling this a 
blocker.

I understand, however, that your local needs are driven by EarthResourceML, not 
GeoSciML, so there are competing requirements.

You'll be able to test using the reference database and Geoserver 
configurations - these will be published within a week.

Cheers,
Alistair

"XML is like violence. If it doesn't solve the problem, use more." - Unknown



On 7 February 2012 16:03, Ben Caradoc-Davies wrote:
I spoke too soon. This issue has just been deprioritised and kicked out of the 
2012-02 iteration. I will pencil it in for 2012-03 in hope that we can have a 
look at it.

Kind regards,
Ben. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4104) Build failures with UnsatisfiedLinkError in imagio-ext-gdal in Maven 3 / 64-bit

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4104:


 Summary: Build failures with UnsatisfiedLinkError in 
imagio-ext-gdal in Maven 3 / 64-bit
 Key: GEOT-4104
 URL: https://jira.codehaus.org/browse/GEOT-4104
 Project: GeoTools
  Issue Type: Bug
  Components: imageio-ext-gdal plugin
Affects Versions: 8.0-RC1
 Environment: Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)
Maven home: /home/car605/junk/java/maven3
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: /home/car605/junk/java/jdk1.6.0_29.x64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "2.6.42.12-1.fc15.x86_64", arch: "amd64", family: 
"unix"

Reporter: Ben Caradoc-Davies
Priority: Blocker


Build of imagio-ext-gdal passes in Maven 2 / 32-bit but fails in Maven 3 / 
64-bit with UnsatisfiedLinkError:

{noformat}
Results :

Tests in error: 
  test(org.geotools.coverageio.gdal.envihdr.EnviHdrTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.envihdr.EnviHdrTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.rpftoc.RPFTOCTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.rpftoc.RPFTOCTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.aig.AIGTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.aig.AIGTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.idrisi.IDRISIImgTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.idrisi.IDRISIImgTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.nitf.NITFTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.nitf.NITFTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.dted.DTEDTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testService(org.geotools.coverageio.gdal.dted.DTEDTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.erdasimg.ErdasImgTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.erdasimg.ErdasImgTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  test(org.geotools.coverageio.gdal.ehdr.EsriHdrTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
  testIsAvailable(org.geotools.coverageio.gdal.ehdr.EsriHdrTest): 
org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J

Tests run: 26, Failures: 0, Errors: 16, Skipped: 0
{noformat}

In Eclipse (Indigo R2, Java 6 64-bit) the stack traces look like: 

{noformat}
java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.SWIGDriverUpcast(J)J
at org.gdal.gdal.gdalJNI.SWIGDriverUpcast(Native Method)
at org.gdal.gdal.Driver.(Driver.java:18)
at org.gdal.gdal.gdal.GetDriverByName(gdal.java:521)
at 
it.geosolutions.imageio.gdalframework.GDALUtilities.isDriverAvailable(GDALUtilities.java:355)
at 
it.geosolutions.imageio.gdalframework.GDALImageReaderSpi.isAvailable(GDALImageReaderSpi.java:257)
at 
org.geotools.coverageio.gdal.aig.AIGFormatFactory.isAvailable(AIGFormatFactory.java:61)
at 
org.geotools.coverageio.gdal.GDALTestCase.testingEnabled(GDALTestCase.java:105)
at org.geotools.coverageio.gdal.GDALTestCase.setUp(GDALTestCase.java:88)
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4103) Can't select last character with OCQL strSubstring()

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4103:


 Summary: Can't select last character with OCQL strSubstring()
 Key: GEOT-4103
 URL: https://jira.codehaus.org/browse/GEOT-4103
 Project: GeoTools
  Issue Type: Bug
  Components: main
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett
 Fix For: 2.7.5, 8.0-RC1


 Original Message 
Subject: Re: [Siss] Cant select last character with OCQL strSubstring(), bug?
Date: Fri, 13 Apr 2012 09:41:50 +0800
From: Ben Caradoc-Davies
To: Geoff Williams
CC: siss list

Geoff,

this is a bug in GeoTools gt-main StaticGeometry:
http://svn.osgeo.org/geotools/trunk/modules/library/main/src/main/java/org/geotools/filter/function/StaticGeometry.java

In StaticGeometry at line 551 is the following:

if (beg < 0 || end < 0 || beg >= s1.length() || end >= s1.length()) 
return null;

This is an off-by-one error as it is valid for end to be equal to be 
length of the string. The last clause should be "end > s1.length()".

Thanks for the bug report. I will submit a patch to the module maintainer.

Kind regards,



 Original Message 
Subject: [Siss] Cant select last character with OCQL strSubstring(), bug?
Date: Fri, 13 Apr 2012 09:25:55 +0800
From: Geoff Williams
To: siss list

Hi All,

I think I may have found a bug with strSubstring() when used in  tags.  
In nutshell, I'm unable to select the last character in a string.  EG a mapping 
file containing:

gml:description

strSubstring('ABCD',0,4)

  

Does not produce the gml:description element in the output (because the value 
coming back from strSubstring is null I assume).  I would have expected the 
output here to have contained:
ABCD

Which is analogous to the Java code:
"ABCD".substring(0,4);

Which returns "ABCD"


Whereas:

gml:description

strSubstring('ABCD',0,3)

  

Produces an output containing:
ABC

As expected.  


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4098) Feature builder for app-schema

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4098:


 Summary: Feature builder for app-schema
 Key: GEOT-4098
 URL: https://jira.codehaus.org/browse/GEOT-4098
 Project: GeoTools
  Issue Type: New Feature
  Components: app-schema plugin
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Adam Brown


[Pushed upstream from internal CSIRO Jira issue created 15/Mar/11. See: 
https://jira.csiro.au/browse/SISS-1019 (requires login)]

app-schema needs a builder like SimpleFeatureBuilder to aid the programmatic 
construction of complex features. This might be rather useful to someone 
working on a complex parser (hint, hint).

 Original Message 
Subject: FeatureBuilder?
Date: Sat, 12 Mar 2011 21:36:00 +0800
From: Jody Garnett 
To: Caradoc-Davies, Ben (CESRE, Kensington) 

Morning Ben:

I am going through the docs again this weekend; and wondering if your team got 
around to making a FeatureBuilder? I know we have a SimpleFeatureBuilder in 
place; but a helper class for app schema content would not be a bad idea?

-- 
Jody Garnett

 Original Message 
Subject: Re: FeatureBuilder?
Date: Mon, 14 Mar 2011 10:01:00 +0800
From: Ben Caradoc-Davies 
To: Jody Garnett

Sorry, no. It is hard to address issues such as polymorphism and feature
type nesting (feature chaining) in a feature builder. It would be great
if we had one, but I recall that there are some rather large hurdles.

Kind regards,
Ben. 


 Original Message 
Subject: Re: FeatureBuilder?
Date: Mon, 14 Mar 2011 10:12:49 +0800
From: Jody Garnett
To: Caradoc-Davies, Ben (CESRE, Kensington)

I don't really get that Ben.

If it is hard to address in a builder - how much harder is it to address
with direct use of a factory (with no builder around to help?)

For a FeatureBuildeR:
- polymorphism: this is a association that can have a choice of valid
(complex?) attributes? For a Feature builder the user is just going to
supply a value, nobody is saying they have to supply the correct one.
- feature type nesting: for a feature they are going to choose a single
feature type to fill in, the fact that feature type is defined in
relation to its super types is neither here nor there (and we have some
utility functions to produce a list of everything at the end of the day
which should help)

For a FeatureTypeBuilder:
- polymorphism: This should be easier to help out; when defining the
association you can supply one or more complex types that are valid
targets? (I assume that each complex type referenced would be created
independently before hand).
- feature type nesting: Same deal as above, create the super feature
type before hand and you can just refer to it when defining your sub type.

Although it does give me a good idea, an alternative to "build" which
would both build the current type, and fill in the current type as
"super" to allow definition of nested types quickly.

build.setName("Foo");
build.add("field", String.class );
build.super();
build.setName("Bar");
build.add("field2", String.class );

How are you writing test cases for app schema? Do you build the features
and types by hand using the factories?

-- 
Jody Garnett


 Original Message 
Subject: factory / builder fun
Date: Mon, 14 Mar 2011 11:13:05 +0800
From: Jody Garnett 
To: Caradoc-Davies, Ben (CESRE, Kensington)

Hi Ben

Reading my email and was worried it came across as harsh :-) Since I
plan to use the feature model I would like it to work; if you did have
any interest into what made it difficult it would be a good thing to learn.

I was really hoping your team would pick up that ball and throw the
feature model around and clean it up and make it easy to use. I
understand that appschema has been really tough. I have appreciated the
hard work Niels has put in recently.

On a related note we still have an issue with FeatureCollection to sort
out (with respect to publishing the descriptor of the members rather
than simply their type).

-- 
Jody Garnett



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4081) app-schema filtering by xlink:href is broken

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4081:


 Summary: app-schema filtering by xlink:href is broken
 Key: GEOT-4081
 URL: https://jira.codehaus.org/browse/GEOT-4081
 Project: GeoTools
  Issue Type: Bug
  Components: app-schema plugin
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani


[Pushed upstream from CSIRO Jira issue created 24/Oct/11. See 
https://jira.csiro.au/browse/SISS-1138 (login required)]

FeatureChainingWfsTest.testFilteringXlinkHref() doesn't test filtering 
attributes that were encoded as xlink:href anymore. Perhaps because the data in 
the properties file has changed.
I updated the test and it failed:

{noformat}
/**
 * Making sure attributes that are encoded as xlink:href can still be 
queried in filters.
 */
public void testFilteringXlinkHref() {
String xml = //
"" //
+ " " //
+ " " //
+ " " //
+ " 
gsml:specification/gsml:GeologicUnit/gml:name"
 //
+ " Yaugher Volcanic Group 2" //
+ " " //
+ " " //
+ "  " //
+ "";
validate(xml);
Document doc = postAsDOM("wfs", xml);
LOGGER.info("WFS filter GetFeature response:\n" + prettyString(doc));
assertEquals("wfs:FeatureCollection", 
doc.getDocumentElement().getNodeName());
// there should be 2:
// - mf2/gu.25678
// - mf3/gu.25678
assertXpathEvaluatesTo("2", "/wfs:FeatureCollection/@numberOfFeatures", 
doc);
assertXpathCount(2, "//gsml:MappedFeature", doc);
assertXpathEvaluatesTo("mf2", "//gsml:MappedFeature[1]/@gml:id", doc);
assertXpathEvaluatesTo("mf3", "//gsml:MappedFeature[2]/@gml:id", doc);
}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4080) Build failures in referencing caused by bad File/URL conversions

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4080:


 Summary: Build failures in referencing caused by bad File/URL 
conversions
 Key: GEOT-4080
 URL: https://jira.codehaus.org/browse/GEOT-4080
 Project: GeoTools
  Issue Type: Bug
  Components: referencing
Affects Versions: 8.0-RC1
 Environment: Maven 2 and 3, Oracle JDK 6 32 or 64-bit, under Linux, in 
a path with spaces.
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime
Priority: Blocker


GEOT-4063 patch causes build failures in a path with spaces because of bad 
File/URL conversions. Code likely does not conform to policy:
http://docs.geotools.org/latest/developer/conventions/code/url.html

{noformat}
Results :

Failed tests: 
  
testIsNTv2GridAvailable(org.geotools.referencing.factory.gridshift.NTv2GridShiftFactoryTest)

Tests in error: 
  
testTransform(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testGetSourceDimensions(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testGetTargetDimensions(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testGetParameterValues(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testNADCONTransform(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testInverse(org.geotools.referencing.operation.transform.NADCONTransformTest): 
File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testInverseTransform(org.geotools.referencing.operation.transform.NADCONTransformTest):
 File does not exist or is unreadable: 
/home/car605/geoserver/src%20with%20spaces/geotools-trunk/modules/library/referencing/target/test-classes/org/geotools/referencing/factory/gridshift/stpaul.las
  
testTransform(org.geotools.referencing.operation.transform.NTv2TransformTest): 
NTv2 Grid File not available.
  
testGetSourceDimensions(org.geotools.referencing.operation.transform.NTv2TransformTest):
 NTv2 Grid File not available.
  
testGetTargetDimensions(org.geotools.referencing.operation.transform.NTv2TransformTest):
 NTv2 Grid File not available.
  
testGetParameterValues(org.geotools.referencing.operation.transform.NTv2TransformTest):
 NTv2 Grid File not available.
  testInverse(org.geotools.referencing.operation.transform.NTv2TransformTest): 
NTv2 Grid File not available.
  
testInverseTransform(org.geotools.referencing.operation.transform.NTv2TransformTest):
 NTv2 Grid File not available.
  
testNTv2Transform(org.geotools.referencing.operation.transform.NTv2TransformTest):
 NTv2 Grid File not available.

Tests run: 241, Failures: 1, Errors: 14, Skipped: 5
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4074) App-schema needs to support feature chaining 1 element with multiple values

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4074:


 Summary: App-schema needs to support feature chaining 1 element 
with multiple values
 Key: GEOT-4074
 URL: https://jira.codehaus.org/browse/GEOT-4074
 Project: GeoTools
  Issue Type: Bug
  Components: app-schema plugin
Affects Versions: 8.0-RC1
Reporter: Pavel Golodoniuc
Assignee: Rini Angreani


[Pushed out from CSIRO Jira. See https://jira.csiro.au/browse/SISS-1268 (login 
required)]

Schema: http://www.cubewerx.com/schemas/gazetteer/1.0.0/gmlsf1/full/iso19112.xsd

What Pavel wants to achieve:


AFG


جُمْهُورِئ
 إِسْلامِئ 
أَفْغَانِسْتَان
official
true


دِ 
أَفْغَانِسْتَان
 إِسْلامِی 
جُمْهُورِيَت
official
true


...

The above is currently not supported.

By hacking the schema (to specify maxOccurs="unbounded" for 
alternativeGeographicIdentifiers), we can achieve:


AFG


جُمْهُورِئ
 إِسْلامِئ 
أَفْغَانِسْتَان
official
true




دِ 
أَفْغَانِسْتَان
 إِسْلامِی 
جُمْهُورِيَت
official
true

 
...

But it's not the desired output. I estimate 1 - 2 days work (with unit tests). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4047) OracleNGDataStoreFactoryTest fails because it does not use common fixture

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4047:


 Summary: OracleNGDataStoreFactoryTest fails because it does not 
use common fixture
 Key: GEOT-4047
 URL: https://jira.codehaus.org/browse/GEOT-4047
 Project: GeoTools
  Issue Type: Bug
  Components: jdbc-oracle plugin
Affects Versions: 8.0-RC1
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime


When ~/.geotools/oracle.properties is configured to allow other gt-jdbc-oracle 
online tests to pass, OracleNGDataStoreFactoryTest still fails because is uses 
its own fixture configuration properties file factory.properties. This file is 
read from src/test/resources. Attached patch removes redundant fixture 
configuration files and makes the test use the same file as the others.

(1) Does this test still test whatever it was meant to test?

(2) Is this test still required, or should it instead me remoned in its 
entirety?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4046) SQLException: Invalid column type in OracleFeatureSourceTest

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4046:


 Summary: SQLException: Invalid column type in 
OracleFeatureSourceTest
 Key: GEOT-4046
 URL: https://jira.codehaus.org/browse/GEOT-4046
 Project: GeoTools
  Issue Type: Bug
  Components: jdbc-oracle plugin
Affects Versions: 8.0-RC1
 Environment: Both Eclipse and Maven (Indigo R1):

Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)
Maven home: /home/car605/junk/java/maven3
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: /home/car605/junk/java/jdk1.6.0_29.x64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "2.6.42.3-2.fc15.x86_64", arch: "amd64", family: 
"unix"

Using:

driver = oracle.jdbc.driver.OracleDriver
url = jdbc:oracle:thin:@[...]

Connecting to:

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production

Running tests with -Doracle so using ojdbc14.jar.
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime


Both oneline tests OracleFeatureSourceTest and OracleFeatureSourceExposePkTest 
fail in testCaseInsensitiveFilter with:
java.sql.SQLException: Invalid column type
at the point where the case-sensitive PropertyIsEqualTo is used (the one that 
should return no properties). Instead of returning nothing, an exception is 
thrown:

{noformat}
---
Test set: org.geotools.data.oracle.OracleFeatureSourceTest
---
Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 59.421 sec <<< 
FAILURE!
testCaseInsensitiveFilter(org.geotools.data.oracle.OracleFeatureSourceTest)  
Time elapsed: 0.99 sec  <<< ERROR!
java.io.IOException
at 
org.geotools.jdbc.JDBCDataStore.getAggregateValue(JDBCDataStore.java:1325)
at org.geotools.jdbc.JDBCDataStore.getCount(JDBCDataStore.java:1255)
at 
org.geotools.jdbc.JDBCFeatureSource.getCountInternal(JDBCFeatureSource.java:432)
at 
org.geotools.data.store.ContentFeatureSource.getCount(ContentFeatureSource.java:451)
at 
org.geotools.jdbc.JDBCFeatureStore.getCountInternal(JDBCFeatureStore.java:183)
at 
org.geotools.data.store.ContentFeatureSource.getCount(ContentFeatureSource.java:451)
at 
org.geotools.jdbc.JDBCFeatureSourceTest.testCaseInsensitiveFilter(JDBCFeatureSourceTest.java:185)
[surefire/junit frames]
Caused by: java.sql.SQLException: Invalid column type
at 
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at 
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at 
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208)
at 
oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:9209)
at 
oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:8790)
at 
oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:9263)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
at 
org.geotools.jdbc.PreparedStatementSQLDialect.setValue(PreparedStatementSQLDialect.java:158)
at 
org.geotools.jdbc.JDBCDataStore.setPreparedFilterValues(JDBCDataStore.java:3172)
at 
org.geotools.jdbc.JDBCDataStore.setPreparedFilterValues(JDBCDataStore.java:3149)
at 
org.geotools.jdbc.JDBCDataStore.selectAggregateSQLPS(JDBCDataStore.java:3374)
at 
org.geotools.jdbc.JDBCDataStore.getAggregateValue(JDBCDataStore.java:1297)
... 32 more
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] (GEOT-4040) Support PostgreSQL 9 hex bytea output format to avoid massive data corruption

[Ben Caradoc-Davies (JIRA)]

Ben Caradoc-Davies created GEOT-4040:


 Summary: Support PostgreSQL 9 hex bytea output format to avoid 
massive data corruption
 Key: GEOT-4040
 URL: https://jira.codehaus.org/browse/GEOT-4040
 Project: GeoTools
  Issue Type: New Feature
  Components: jdbc-postgis plugin
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira


PostgreSQL 9 introduces a new default "hex" output format for bytea. This 
results in massive silent data corruption.

The workaround is:

alter database DATABASENAME set bytea_output = 'escape';

http://www.postgresql.org/docs/9.0/static/runtime-config-client.html#GUC-BYTEA-OUTPUT
http://www.postgresql.org/docs/9.0/static/datatype-binary.html
http://unicolet.blogspot.com.au/2012/01/grails-blobs-and-postgres-byteaoutput.html

See GEOT-3905:
{noformat}
Failed tests: 
  testRead(org.geotools.data.postgis.ps.PostgisLobTest): null
  testWrite(org.geotools.data.postgis.ps.PostgisLobTest): null
  testRead(org.geotools.data.postgis.PostgisLobTest): null
  testWrite(org.geotools.data.postgis.PostgisLobTest): null
{noformat}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3971) NumberRange compile failure in Eclipse Indigo

[Ben Caradoc-Davies (JIRA)]

NumberRange compile failure in Eclipse Indigo
-

 Key: GEOT-3971
 URL: https://jira.codehaus.org/browse/GEOT-3971
 Project: GeoTools
  Issue Type: Bug
  Components: metadata
Affects Versions: 8.0-RC1
 Environment: Eclipse Indigo SR1 (3.7.1) Linux x86_64 jdk1.6.0_29.x64
Reporter: Ben Caradoc-Davies


Four methods in NumberRange fail to compile in Eclipse Indigo SR1 (3.7.1) 
(eclipse-jee-indigo-SR1-linux-gtk-x86_64). They compile fine in javac in 
jdk1.6.0_29.x64 and in Eclipse Helios SR2 
(eclipse-jee-helios-SR2-linux-gtk-x86_64).

{noformat}
The method containsNC(Number&Comparable>) 
in the type Range>> is 
not applicable for the arguments (Comparable) NumberRange.java 
/gt-metadata/src/main/java/org/geotools/util line 477 Java Problem

The method containsNC(Number&Comparable>) 
in the type Range>> is 
not applicable for the arguments (Range) NumberRange.java 
/gt-metadata/src/main/java/org/geotools/util line 495 Java Problem

The method intersectsNC(Range>>) in the type Range>> is not applicable for the arguments 
(Range) NumberRange.java 
/gt-metadata/src/main/java/org/geotools/util line 512 Java Problem

The method unionNC(Range>>) in the type Range>> is not applicable for the arguments 
(Range) NumberRange.java 
/gt-metadata/src/main/java/org/geotools/util line 524 Java Problem
{noformat}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3943) Intermittent H2DataStoreFactoryTest.testTCP failure when another GeoTools is building on the same host

[Ben Caradoc-Davies (JIRA)]

Intermittent H2DataStoreFactoryTest.testTCP failure when another GeoTools is 
building on the same host
--

 Key: GEOT-3943
 URL: https://jira.codehaus.org/browse/GEOT-3943
 Project: GeoTools
  Issue Type: Bug
  Components: jdbc-h2 plugin
Affects Versions: 2.7.4, 8.0-M3
Reporter: Ben Caradoc-Davies
Priority: Critical


H2DataStoreFactoryTest.testTCP can fail if another GeoTools is building on the 
same host. This test assumes that it has exclusive use of localhost. It assumes 
that nothing else will be using the TCP ports it likes and it can test for 
their availability by connecting to them. These assumptions are incorrect. 
Because this test can fail on 2.7.x when trunk is building, I suspect that 
trunk will also be affected by the same problem. The two branches are 
inadvertently communicating via the network.

Tests that use network resources should be subclasses of OnlineTestCase.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3905) Online tests failing in gt-jdbc-postgis

[Ben Caradoc-Davies (JIRA)]

Online tests failing in gt-jdbc-postgis
---

 Key: GEOT-3905
 URL: https://jira.codehaus.org/browse/GEOT-3905
 Project: GeoTools
  Issue Type: Bug
  Components: jdbc-postgis plugin
Affects Versions: 8.0-M3
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Blocker


Testing trunk r38203:

Results :

Failed tests: 
  testRead(org.geotools.data.postgis.ps.PostgisLobTest): null
  testWrite(org.geotools.data.postgis.ps.PostgisLobTest): null
  testRead(org.geotools.data.postgis.PostgisLobTest): null
  testWrite(org.geotools.data.postgis.PostgisLobTest): null

Tests in error: 
  testAfterInterval(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testBeforeInterval(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testBegins(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testBegunBy(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testEnds(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testEndedBy(org.geotools.data.postgis.PostgisTemporalFilterTest)
  testDuring(org.geotools.data.postgis.PostgisTemporalFilterTest)

Tests run: 554, Failures: 4, Errors: 7, Skipped: 0

[INFO] 
[INFO] BUILD FAILURE
[INFO] 


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3853) Build failure in swing CRSStatusBarItemTest

[Ben Caradoc-Davies (JIRA)]

Build failure in swing CRSStatusBarItemTest
---

 Key: GEOT-3853
 URL: https://jira.codehaus.org/browse/GEOT-3853
 Project: GeoTools
  Issue Type: Bug
  Components: swing
Affects Versions: 8.0-M2
 Environment: Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)
Maven home: /home/car605/junk/java/maven3
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/car605/junk/java/jdk1.6.0_26.x64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "2.6.40.4-5.fc15.x86_64", arch: "amd64", family: 
"unix"

Alo seen on Maven 2 with a 32-bit Oracle Java 6.
Reporter: Ben Caradoc-Davies
Assignee: Michael Bedward
Priority: Blocker
 Attachments: org.geotools.swing.control.CRSStatusBarItemTest.txt

Results :

Tests in error: 
  
createItemWhenMapContentHasBeenSet(org.geotools.swing.control.CRSStatusBarItemTest)
  
canCreateItemBeforeMapContentIsSet(org.geotools.swing.control.CRSStatusBarItemTest):
 Could not initialize class org.geotools.swing.control.CRSStatusBarItem

Tests run: 72, Failures: 0, Errors: 2, Skipped: 0

See attached surefire report.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3824) Encoded GML 3.2 MultiSurface is schema-invalid because contained Polygon lacks gml:id

[Ben Caradoc-Davies (JIRA)]

Encoded GML 3.2 MultiSurface is schema-invalid because contained Polygon lacks 
gml:id
-

 Key: GEOT-3824
 URL: https://jira.codehaus.org/browse/GEOT-3824
 Project: GeoTools
  Issue Type: Bug
  Components: xsd-gml
Affects Versions: 2.7.3, 8.0-M2
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira


GML 3.2 geometries have a mandatory gml:id attribute. When MultiSurface is 
encoded, even if the top-level geometry has a gml:id, the encoded GML is 
schema-invalid because contained geometries go not have gml:id. This will 
likely affect all multi-geometries.

{noformat}


 


268926.0 4810180.0 268926.0 4829560.0 296474.0 4829560.0 296474.0 
4810180.0 268926.0 4810180.0





{noformat}
it 
app-schema can put a gml:id on the top-level feature (as in this case), but 
knows nothing about the structure of contained geometries.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3680) All ComplexType definitions in GML 3.2 subpackages are empty

[Ben Caradoc-Davies (JIRA)]

All ComplexType definitions in GML 3.2 subpackages are empty


 Key: GEOT-3680
 URL: https://jira.codehaus.org/browse/GEOT-3680
 Project: GeoTools
  Issue Type: Bug
  Components: xsd-gml
Affects Versions: 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Critical


Every ComplexType defined in the GML 3.2 G??Schema classes is defined with 
properties Collections.emptyList(), causing the definition 
to be empty. This prevents use of these types in app-schema.

Affected classes are:

GCOSchema
GMLSchema
GMXSchema
GSRSchema
GSSSchema
GTSSchema

Was true used to generate these?

Alistair Ritchie reports:

gsml:MappedFeature has a resolutionScale property (used to provide the map 
scale). The value is provided as a gmd:MD_RepresentativeFraction value.

The following attribute mapping:

{noformat}


gsml:resolutionScale/gmd:MD_RepresentativeFraction/gmd:denominator/gco:Integer
25

{noformat}

should (user error notwithstanding) provide the following (valid!) XML




25




but instead results in the exception:

{noformat}
29 Jun 13:32:41 ERROR [geoserver.ows] -
java.lang.RuntimeException: Error applying mapping with targetAttribute 
gsml30:resolutionScale/gmd:MD_RepresentativeFraction/gmd:denominator/gco:Integer
at 
org.geotools.data.complex.DataAccessMappingFeatureIterator.computeNext(DataAccessMappingFeatureIterator.java:818)
at 
org.geotools.data.complex.AbstractMappingFeatureIterator.next(AbstractMappingFeatureIterator.java:278)
at 
org.geotools.data.complex.AbstractMappingFeatureIterator.next(AbstractMappingFeatureIterator.java:64)
at org.geotools.xml.Encoder.encode(Encoder.java:677)
at org.geotools.xml.Encoder.encode(Encoder.java:566)
at 
org.geoserver.wfs.xml.GML32OutputFormat.encode(GML32OutputFormat.java:80)
at 
org.geoserver.wfs.xml.GML3OutputFormat.complexFeatureStreamIntercept(GML3OutputFormat.java:276)
at 
org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:240)
at 
org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:141)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:757)
at 
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:238)
[...]
Caused by: java.lang.IllegalArgumentException: gmd:denominator is not a valid 
location path for type 
http://www.isotc211.org/2005/gmd:MD_RepresentativeFraction_Type. 
gmd:denominator ns: http://www.isotc211.org/2005/gmd, 
MD_RepresentativeFraction_Type properties:
at org.geotools.data.complex.filter.XPath.set(XPath.java:685)
at org.geotools.data.complex.filter.XPath.set(XPath.java:563)
at 
org.geotools.data.complex.DataAccessMappingFeatureIterator.setAttributeValue(DataAccessMappingFeatureIterator.java:526)
at 
org.geotools.data.complex.DataAccessMappingFeatureIterator.computeNext(DataAccessMappingFeatureIterator.java:805)
... 73 more
{noformat}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3677) app-schema joining fails on writable feature types

[Ben Caradoc-Davies (JIRA)]

app-schema joining fails on writable feature types
--

 Key: GEOT-3677
 URL: https://jira.codehaus.org/browse/GEOT-3677
 Project: GeoTools
  Issue Type: Bug
  Components: app-schema plugin
Affects Versions: 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies


app-schema joining support fails on writable feature types because it expects 
JDBCFeatureSource not JDBCFeatureStore. It turns out that our test fixtures 
lack primary keys(?), and so JDBCFeatureSource.buildFeatureType marks them as 
read-only, and JDBCFeatureStore.createFeatureSource only returns a 
JDBCFeatureSource. In the real world, app-schema joining must expect and handle 
JDBCFeatureStore.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3650) docs pom packaging breaks Eclipse integration and causes Java non-compilation

[Ben Caradoc-Davies (JIRA)]

docs pom packaging breaks Eclipse integration and causes Java non-compilation
-

 Key: GEOT-3650
 URL: http://jira.codehaus.org/browse/GEOT-3650
 Project: GeoTools
  Issue Type: Bug
  Components: docs
Affects Versions: 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
 Fix For: 8.0-M1


On 15 May in r37194 "Speedup repeated doc builds", Andrea changed packaging for 
docs from jar to pom. This saves a little time in the build (in addition to the 
huge repeated-build speedup implemented by Andrea), but prevents mvn 
eclipse:eclipse from processing the module (it will not process projects with 
pom packaging). Furthermore, with pom packaging, the Java in docs is not 
compiled. This defeats the purpose of having Java in the module, and having 
declared dependencies in the project pom. Compiling the Java is important 
because it detects errors and gives docs developers the ability to test their 
examples in Eclipse.

"mvn -o clean install" takes about 47 seconds for jar versus about 43 seconds 
for pom packaging. On #geotools I asked Andrea if I could revert to jar 
packaging at the cost of an extra four seconds; Andrea did not support this 
change. But things are not quite this bad: most of the extra time is taken 
"Compiling 69 source files" and a little for building and installing the jars.

We can skip the java compilation by not using clean. Once an initial build has 
been made:
"mvn -o install" takes about 9.3 seconds for jar versus about 8.3 seconds for 
pom packaging.

We can skip the jar building by running the compile target instead:
"mvn -o compile" takes about 7.8 seconds for jar versus about 6.6 seconds for 
pom packaging.

So what I'm really asking for is an extra 1.2 seconds per "mvn -o compile" so 
we can get Eclipse integration (and Java compilation working again).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3635) Improve copyright header instructions

[Ben Caradoc-Davies (JIRA)]

Improve copyright header instructions
-

 Key: GEOT-3635
 URL: http://jira.codehaus.org/browse/GEOT-3635
 Project: GeoTools
  Issue Type: Sub-task
  Components: docs
Affects Versions: 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett


The copyright header example can be taken as instructions to use the specified 
date range. This should be clarified to change the range to ${year file 
created}-{year file last changed}.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3622) Typo in exception message: geometry_columns versus geography_columns

[Ben Caradoc-Davies (JIRA)]

Typo in exception message: geometry_columns versus geography_columns


 Key: GEOT-3622
 URL: http://jira.codehaus.org/browse/GEOT-3622
 Project: GeoTools
  Issue Type: Bug
  Components: data postgis
Affects Versions: 8.0-M0, 2.7.1, 2.7.2, 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Trivial


The first occurrence of geometry_columns here should be geography_columns 
(causes user confusion). Typo location is PostGISDialect:389.

{code}
2011-06-01 11:47:55,018 WARN [geotools.jdbc] - Failed to retrieve information 
about public.AHGFReservoir.the_geom from the geometry_columns table, checking 
geometry_columns instead
org.postgresql.util.PSQLException: ERROR: permission denied for relation 
geography_columns
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3621) Error using ST_Estimated_Extent on non-lowercase relation

[Ben Caradoc-Davies (JIRA)]

Error using ST_Estimated_Extent on non-lowercase relation
-

 Key: GEOT-3621
 URL: http://jira.codehaus.org/browse/GEOT-3621
 Project: GeoTools
  Issue Type: Bug
  Components: data postgis
Affects Versions: 8.0-M0, 2.7.1, 2.7.2, 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira


Seen in GeoServer trunk while publishing a table called AHGFReservoir.

{code}
2011-06-01 11:48:09,497 WARN [geotools.jdbc] - Failed to use 
ST_Estimated_Extent, falling back on envelope aggregation
org.postgresql.util.PSQLException: ERROR: relation "public.ahgfreservoir" does 
not exist
  Where: SQL statement "SELECT has_table_privilege((SELECT usesysid FROM 
pg_user WHERE usename = session_user), 'public.AHGFReservoir', 'select')"
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
{code}

Because the table identifier contains uppercase characters, it should be 
encoded as 'public."AHGFReservoir"' when passed to this function.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3603) More robust behaviour if geography_columns not readable

[Ben Caradoc-Davies (JIRA)]

More robust behaviour if geography_columns not readable
---

 Key: GEOT-3603
 URL: http://jira.codehaus.org/browse/GEOT-3603
 Project: GeoTools
  Issue Type: Improvement
  Components: data postgis
Affects Versions: 2.7.2, 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Minor


gt-jdbc-postgis should be able to determine the SRID of a geometry column even 
if geography_columns is not readable. Because the presence of geography_columns 
is a new feature in PostGIS 1.5, we can expect more users to be caught out as 
permissions settings in existing deployment procedures probably do not cater 
for it.

{code}
 Original Message 
Subject: [ExternalEmail] Re: [Geotools-gt2-users] Permission Denied Error on a 
PostGIS Query
Date: Tue, 24 May 2011 16:51:48 +0800
From: Ben Caradoc-Davies 
To: Gerson Galang 
CC: geotools-gt2-us...@lists.sourceforge.net


I think your request succeeded, but I suspect that, because of the error 
encountered while trying to determine the SRID, your geometries won't 
have a SRID until you grant at a minimum read access to 
geography_columns, and so spatial operations including reprojection will 
likely fail.

On 24/05/11 14:55, Gerson Galang wrote:
> Note that I still get "1" as the output in stdout even if the exception
> gets thrown in stderr.
{code}

{code}
 Original Message 
Subject: [ExternalEmail] Re: [Geotools-gt2-users] Permission Denied Error on a 
PostGIS Query
Date: Tue, 24 May 2011 16:22:30 +0800
From: Ben Caradoc-Davies 
To: Gerson Galang 
CC: geotools-gt2-us...@lists.sourceforge.net

alter view geography_columns owner to gis;

You can see views with \dv (no semicolon required as this is a postgres 
command and not SQL).


On 24/05/11 14:55, Gerson Galang wrote:
> Hi Guys,
>
> I ingested a couple of shape files into PostGIS and after running a
> query against it, an exception gets thrown even if the query returns a
> proper response.
>
> Here are the tables I have in my DB:
> geo=# \dt;
>List of relations
>Schema |   Name| Type  | Owner
> +---+---+---
>public | geometry_columns  | table | gis
>public | lga07aaust_region | table | gis
>public | spatial_ref_sys   | table | gis
>public | ssc06aaust_region | table | gis
>
> Here's the code snippet that I'm trying to execute:
>   String typeName = "ssc06aaust_region";
>   FeatureSource source = dataStore.getFeatureSource(typeName);
>
>   Filter filter = CQL
>   .toFilter("name_2006 = 'Melbourne'");
>   FeatureCollection  features =
> source
>   .getFeatures(filter);
>   System.out.println(features.size());
>
> And the exception that it throws back to the terminal:
> May 24, 2011 2:55:14 PM org.geotools.jdbc.JDBCFeatureSource buildFeatureType
> WARNING: Error occured determing srid for ssc06aaust_region.wkb_geometry
> org.postgresql.util.PSQLException: ERROR: permission denied for relation
> geography_columns
>   at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
>   at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795)
>   at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>   at
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479)
>   at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353)
>   at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:252)
>   at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
>   at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
>   at
> org.geotools.data.postgis.PostGISDialect.getGeometrySRID(PostGISDialect.java:386)
>   at
> org.geotools.jdbc.JDBCFeatureSource.buildFeatureType(JDBCFeatureSource.java:291)
>   at
> org.geotools.jdbc.JDBCDataStore.createFeatureSource(JDBCDataStore.java:767)
>   at
> org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:384)
>   at
> org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:349)
>   at
> org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:102)
>   at au.org.aurin.wfs.client.QueryLab.filterFeatures(QueryLab.java:116)
>   at au.org.aurin.wfs.client.QueryLab.connect(QueryLab.java:103)
>   at au.org.aurin.wfs.client.QueryLab.(QueryLab.java:67)
>   at au.org.aurin.wfs.client.QueryLab.main(QueryLab.java:54)
>
> Note that I still get "1" as the output in stdout even if the exception
> gets thrown in stderr.
>
> Any ideas?
>
> Thanks,
> Gerson
{code}

--

[Geotools-devel] [jira] Created: (GEOT-3595) app-schema-resolver schema downloading broken

[Ben Caradoc-Davies (JIRA)]

app-schema-resolver schema downloading broken
-

 Key: GEOT-3595
 URL: http://jira.codehaus.org/browse/GEOT-3595
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 8.0-M0, 2.7.1, 2.7.2, 8.0-M1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
Priority: Critical


app-schema-resolver schema downloading is broken by the changes introduced in 
GEOT-3411, and related hack-removal in AppSchemaResolver. The problem is that 
downloading works fine, but because Schemas.parse(String, ResourceSet) 
carefully now canonicalises file URLs, they no longer match the noncanonical 
file URL that might have been provided to the resolver and be stored in the 
reverse-lookup map. This prevents reverse-lookups, causing all relative 
references to fail.

Affects stable as well as trunk.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-3587) Use .rst extension for all sphinx source files

[Ben Caradoc-Davies (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOT-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ben Caradoc-Davies reopened GEOT-3587:
--


Michael,

your commit in r37204 has broken every page that includes or references another 
file by its old .txt name. This has broken the geotools-trunk-docs build:
http://hudson.opengeo.org/hudson/job/geotools-trunk-docs/817/console

Here is a quick find+grep (some false positives):
{code}
$ find . -name "*.rst" -exec grep -H '.txt' {} \;
./developer/guide/conventions/code/url.rst:file.txt
file:file.txt
./developer/guide/conventions/code/url.rst:C:\direct with a space\file.txt 
file://C:/directory%20with%20a%20space/file.txt
./developer/guide/conventions/code/url.rst:\\host.org\share\directory\file.txt 
file:/host.org/share/directory/file.txt
./developer/guide/conventions/profile.rst:At the end of the run you'll find a 
java.hprof.txt file that can be opened with HPJMeter.
./developer/guide/conventions/profile.rst:At the end of the run you'll find a 
java.hprof.txt file that can be opened with HPJMeter.
./developer/guide/procedures/check.rst:* Passes IP check documented in 
review.txt file, basically has correct headers
./developer/guide/building/maven/build.rst: 22/10/2006  09:11 AM
 3,705 README.txt
./developer/guide/building/maven/build.rst:   
C:\java\geotools\trunk\modules\library\metadata\target\surefire-reports>more 
*RangeSetTest.txt
./developer/guide/building/maven/build.rst:   
C:\java\geotools\trunk\modules\library\render\target\surefire-reports>more 
*GridCoverageRendererTest.txt
./developer/guide/docs/reference.rst:* module/index.txt
./developer/guide/docs/reference.rst:* module/faq.txt (frequently asked 
questions; included in overall geotools faq)
./developer/guide/docs/reference.rst:* module/foo.txt
./developer/guide/docs/reference.rst:* module/bar.txt
./developer/guide/docs/reference.rst:1. Create a faq.txt page similar to the 
example below::
./developer/guide/docs/reference.rst:2. Update the root faq.txt to include your 
new page::
./developer/guide/docs/reference.rst:.. include:: 
/unsupported/name/faq.txt
./developer/guide/docs/tutorial.rst:.. include:: 
./user/tutorial/raster/image.rst:.. include:: 
./user/tutorial/map/style.rst:.. include:: 
./user/tutorial/filter/query.rst:.. include:: 
./user/library/referencing/internal.rst:  (The DatumAliasesTable.txt file 
inside gt-referencing has an entry for "North American Datum 1927").
./user/library/referencing/crs.rst:To parse WKT please use the CRS.parseWKT( 
txt ) method::
./user/library/coverage/jdbc/prepare.rst:  In this situation you have to create 
a file listing all the tif files with absolute path names (Lets call it 
tilelist.txt ) 
./user/library/coverage/jdbc/prepare.rst:gdal_retile.py -levels 3  -ps 512 
512 -targetDir /tmp/test --optfile tilelist.txt
./user/library/coverage/jdbc/prepare.rst:gdal_retile.py -levels 3  -ps 512 
512 -csv index.csv -targetDir /tmp/test --optfile tilelist.txt
./user/library/coverage/jdbc/prepare.rst:gdal_retile.py -levels 3  -ps 512 
512 -tileIndex index.shp -tileIndexField LOCATION -targetDir /tmp/test 
--optfile tilelist.txt
./user/library/coverage/jdbc/prepare.rst:gdal_retile.py -levels 3  -ps 512 
512 -co "WORLDFILE=YES" -targetDir /tmp/test --optfile tilelist.txt
./user/library/internal/integration.rst:jar for a META-INF/services/\*.txt 
files. This works out of the box when all jars are loaded via the
./user/faq.rst:.. include:: /welcome/faq.txt
./user/faq.rst:.. include:: /library/opengis/faq.txt
./user/faq.rst:.. include:: /library/jts/faq.txt
./user/faq.rst:.. include:: /library/api/faq.txt
./user/faq.rst:.. include:: /library/metadata/faq.txt
./user/faq.rst:.. include:: /library/referencing/faq.txt
./user/faq.rst:.. include:: /library/coverage/faq.txt
./user/faq.rst:.. include:: /library/main/faq.txt
./user/faq.rst:.. include:: /library/jdbc/faq.txt
./user/faq.rst:.. include:: /library/cql/faq.txt
./user/faq.rst:.. include:: /library/xml/faq.txt
./user/faq.rst:.. include:: /library/render/faq.txt
./user/faq.rst:.. include:: /extension/brewer/faq.txt
./user/faq.rst:.. include:: /extension/wms/faq.txt
./user/faq.rst:.. include:: /unsupported/swing/faq.txt
{code}

> Use .rst extension for all sphinx source files
> --
>
> Key: GEOT-3587
> URL: http://jira.codehaus.org/browse/GEOT-3587
> Project: GeoTools
>  Issue Type: Task
>  Components: doc
>Reporter: Michael Bedward
>Assignee: Michael Bedward
> Fix For: 2.7.2, 8.0-M1
>
>
> Jody used .txt because it was favoured by the software he used to port the 
> docs from the wiki. Unless anyone objects we can now swap back to .rst to 
> make it easier for syntax-aware editors.

-- 
This message is automatically generated by JIRA.
-
I

[Geotools-devel] [jira] Created: (GEOT-3581) Support encoding of GML srsName in urn:ogc format

[Ben Caradoc-Davies (JIRA)]

Support encoding of GML srsName in urn:ogc format
-

 Key: GEOT-3581
 URL: http://jira.codehaus.org/browse/GEOT-3581
 Project: GeoTools
  Issue Type: New Feature
  Components: ext xml-xsd
Affects Versions: 8.0-M0
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira


Users would like to encode srsName in WFS responses as 
urn:ogc:def:crs:EPSG::4283 instead of urn:x-ogc:def:crs:EPSG:4283. I also have 
requests for http://www.opengis.net/def/crs/EPSG/0/4283, the latest format out 
of the OGC-NA.

This last came up in November:
http://osgeo-org.1803224.n2.nabble.com/srsName-urn-x-ogc-vs-urn-ogc-more-headaches-and-long-term-decisions-td6133528.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3546) PropertyAttributeReader fails to translate empty value to null

[Ben Caradoc-Davies (JIRA)]

PropertyAttributeReader fails to translate empty value to null
--

 Key: GEOT-3546
 URL: http://jira.codehaus.org/browse/GEOT-3546
 Project: GeoTools
  Issue Type: Bug
  Components: data property
Affects Versions: 8-M0
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett
Priority: Blocker


The PropertyAttributeReader change in r37013 breaks the GeoServer build in 
app-schema test because it no longer honours its former behaviour of reading an 
empty value as a null.

After the change, boolean isEmpty defined at line 280 is never read. The old if 
("".equals(stringValue)) is gone.

The behaviour change  causes GeoServer app-schema-test failures:

Failed tests: 
  testPolymorphism(org.geoserver.test.PolymorphismWfsTest)
  
testPropertyEncodingOrder_PlanarOrientation(org.geoserver.test.PropertyEncodingOrderTest)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3524) Support GML 3.2 AbstractGeometry in xsd-gml2 GMLEncodingUtils

[Ben Caradoc-Davies (JIRA)]

Support GML 3.2 AbstractGeometry in xsd-gml2 GMLEncodingUtils
-

 Key: GEOT-3524
 URL: http://jira.codehaus.org/browse/GEOT-3524
 Project: GeoTools
  Issue Type: Improvement
  Components: ext xml-xsd
Affects Versions: 8-M0
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
 Fix For: 8-M0
 Attachments: GMLEncodingUtils.patch

Justin, the attached (rather tiny) patch adds support for GML 3.2 
AbstractGeometry in xsd-gml2 GMLEncodingUtils. It is required to support 
app-schema encoding of abstract geometries, and is covered in GeoServer 
app-schema-test.. The main reason this is needed is that OGC changed _Geometry 
to AbstractGeometry  on going from 3.1 to 3.2, otherwise the existing code 
would just work. Without this patch, GeoSciML 3.0rc1 geometries are not encoded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3515) Build failure in imagemosaic CatalogBuilderTest on host with name problems

[Ben Caradoc-Davies (JIRA)]

Build failure in imagemosaic CatalogBuilderTest on host with name problems
--

 Key: GEOT-3515
 URL: http://jira.codehaus.org/browse/GEOT-3515
 Project: GeoTools
  Issue Type: Bug
  Components: gc imagemosaic
Reporter: Ben Caradoc-Davies
 Fix For: 8-M0


Same problem as reported in GEOT-3511 for coverage:

{code}
---
Test set: org.geotools.gce.imagemosaic.CatalogBuilderTest
---
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.489 sec <<< 
FAILURE!
buildCatalog(org.geotools.gce.imagemosaic.CatalogBuilderTest)  Time elapsed: 
1.348 sec  <<< ERROR!
java.lang.RuntimeException: wsrv2: wsrv2
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:567)
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:473)
at org.geotools.gce.imagemosaic.Utils.storeSampleImage(Utils.java:882)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.createSampleImage(CatalogBuilder.java:1421)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.indexingPostamble(CatalogBuilder.java:1379)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.access$1900(CatalogBuilder.java:109)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder$CatalogBuilderDirectoryWalker.handleEnd(CatalogBuilder.java:858)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:336)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder$CatalogBuilderDirectoryWalker.(CatalogBuilder.java:734)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.run(CatalogBuilder.java:963)
at 
org.geotools.gce.imagemosaic.CatalogBuilderTest.buildCatalog(CatalogBuilderTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at 
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at 
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at 
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at 
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at 
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at 
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at 
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at 
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)

buildCachingIndex(org.geotools.gce.imagemosaic.CatalogBuilderTest)  Time 
elapsed: 0.046 sec  <<< ERROR!
java.lang.RuntimeException: wsrv2: wsrv2
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:567)
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:473)
at org.geotools.gce.imagemosaic.Utils.storeSampleImage(Utils.java:882)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.createSampleImage(CatalogBuilder.java:1421)
at 
org.geotools.gce.imagemosaic.catalogbuilder.CatalogBuilder.indexingPostamble(CatalogBuilder.j

[Geotools-devel] [jira] Created: (GEOT-3511) Build failure in coverage if no local host name

[Ben Caradoc-Davies (JIRA)]

Build failure in coverage if no local host name
---

 Key: GEOT-3511
 URL: http://jira.codehaus.org/browse/GEOT-3511
 Project: GeoTools
  Issue Type: Bug
  Components: core coverage
Affects Versions: 8-M0
Reporter: Ben Caradoc-Davies
Priority: Minor


I have no idea how we can fix this. Building with no local host name causes JAI 
SerializableRenderedImage to throw in its constructor, breaking the build in 
coverage. Does this make these tests online tests.  :-)

Our buildbot is on a VM that has just been migrated, hence the naming outage.

From:
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules/Java-Advanced-Imaging/javax/media/jai/remote/SerializableRenderedImage.java.htm
{code}
try {
host = InetAddress.getLocalHost();
} catch (UnknownHostException e) {
throw new RuntimeException(e.getMessage());
}
{code}

Maven:

{code}
Results :

Tests in error: 
  testSerialization(org.geotools.coverage.grid.GridCoverageTest)
  testSerialization(org.geotools.coverage.grid.InterpolatorTest)

Tests run: 75, Failures: 0, Errors: 2, Skipped: 1

---
Test set: org.geotools.coverage.grid.GridCoverageTest
---
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.14 sec <<< 
FAILURE!
testSerialization(org.geotools.coverage.grid.GridCoverageTest)  Time elapsed: 
0.079 sec  <<< ERROR!
java.lang.RuntimeException: wsrv2: wsrv2
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:567)
at 
javax.media.jai.remote.SerializableRenderedImage.(SerializableRenderedImage.java:390)
at 
org.geotools.coverage.grid.GridCoverage2D.writeObject(GridCoverage2D.java:991)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at 
org.geotools.coverage.grid.GridCoverageTestBase.serialize(GridCoverageTestBase.java:391)
at 
org.geotools.coverage.grid.GridCoverageTest.testSerialization(GridCoverageTest.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at 
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at 
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at 
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at 
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at 
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at 
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at 
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at 
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.maven.surefire.booter.S

[Geotools-devel] [jira] Created: (GEOT-3475) Backport EMF 2.6.1 upgrade to stable branch

[Ben Caradoc-Davies (JIRA)]

Backport EMF 2.6.1 upgrade to stable branch
---

 Key: GEOT-3475
 URL: http://jira.codehaus.org/browse/GEOT-3475
 Project: GeoTools
  Issue Type: Improvement
  Components: ext xml-xsd
Affects Versions: 2.7.0
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
 Fix For: 2.7.0


EMF has been upgraded to 2.6.1 on trunk [see GEOT-3466]. Users have requested 
that change be backported to stable. Justin has indicated that we should wait 
until we are happy with it on trunk, and I concur.

This will also require GeoServer changes.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3466) Upgrade EMF to 2.6.1

[Ben Caradoc-Davies (JIRA)]

Upgrade EMF to 2.6.1


 Key: GEOT-3466
 URL: http://jira.codehaus.org/browse/GEOT-3466
 Project: GeoTools
  Issue Type: Improvement
  Components: ext xml-xsd
Affects Versions: 2.8-M1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies


{code}
 Original Message 
Subject: [ExternalEmail] [Geotools-devel] EMF upgrade
Date: Thu, 10 Mar 2011 12:00:02 +0800
From: Ben Caradoc-Davies 
To: Justin Deoliveira
CC: geotools-devel@lists.sourceforge.net

Justin,

I am quite keen to upgrade EMF to see if it helps resolve some of our 
outstanding issues:
http://jira.codehaus.org/browse/GEOT-3431
http://jira.codehaus.org/browse/GEOT-3327

I will not be able to devote serious time to this until 28 March at the 
earliest, but you could give me a few hints as to how this should be 
done. (If you are doing this yourself, please let me know.)

- What version of EMF should we target?

- The eclipse maven repos look far behind, and the last thing we need is 
another repo in our builds (and I'm sure Andrea will agree with me).

- EMF 2.6.1 is out:
http://www.eclipse.org/modeling/download.php?file=/modeling/emf/emf/downloads/drops/2.6.x/R201009141218/emf-xsd-SDK-2.6.1.zip

- One of us could extract the emf/xsd/common binary and source jars from 
the zip, rename them, and deploy them to the geotools repo. Is this how 
you uploaded the existing artifacts?

- This would also be a good time to put the dependencies under 
dependency management in the root pom. One example, from the gt-xsd-core 
pom.xml:

 
   org.eclipse.xsd
   xsd
   2.2.2
 
 
   org.eclipse.emf
   common
   2.2.1
 
 
   org.eclipse.emf
   ecore
   2.2.2
 

Just thinking aloud, so please interrupt me if I am going off track.  :-)

Kind regards,

-- 
Ben Caradoc-Davies 
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3462) app-schema FeatureTypeRegistry fails to handle substitution groups in unit tests

[Ben Caradoc-Davies (JIRA)]

app-schema FeatureTypeRegistry fails to handle substitution groups in unit tests


 Key: GEOT-3462
 URL: http://jira.codehaus.org/browse/GEOT-3462
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Reporter: Ben Caradoc-Davies
Assignee: Niels Charlier


Niels,

FeatureTypeRegistry is flooding the logs with WARNING messages when app-schema 
unit tests run (see Jody's original bug report below). As a temporary cosmetic 
fix, I will reduce the logging level to FINE to reduce annoyance of other 
developers. I suspect that there is an underlying problem that should be 
investigated. To see the log messages, see FeatureTypeRegistry:312, where you 
build substitutionGroup before putting it into UserData. Change the log level 
back to WARNING to see that createAttributeDescriptor is throwing an exception; 
I don't know why.

Kind regards,
Ben.

{code}
 Original Message 
Subject: app-schema log file use during testing
Date: Wed, 9 Mar 2011 08:50:11 +0800
From: Jody Garnett 
To: geotools dev
CC: Caradoc-Davies, Ben (CESRE, Kensington) 

Morning Ben:

I was performing a geotools build today ... and my log went mad with the 
following:
copedNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizedGenericNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizableScopedNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizableGenericNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizedScopedNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizedGenericNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizableScopedNameType
Mar 9, 2011 10:47:42 AM org.geotools.data.complex.config.FeatureTypeRegistry 
createAttributeDescriptor
WARNING: Could not create substitution descriptor: XSD type definition not 
found in schemas: {urn:cgi:xmlns:CGI:Utilities:1.0}LocalizableGenericNameType
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec

When testing the app schema resolver; do you think you can arrange to turn down 
the logging here? Or has something gone wrong with the test - and is this 
warning important to you?

--
Jody Garnett
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3436) Regression in app-schema feature chaining?

[Ben Caradoc-Davies (JIRA)]

Regression in app-schema feature chaining?
--

 Key: GEOT-3436
 URL: http://jira.codehaus.org/browse/GEOT-3436
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.7-RC1, 2.8-M1
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani
Priority: Critical


Rini, I think you have Morten's mapping files.

 Original Message 
Subject: Re: SV: SV: [ExternalEmail] Re: [Geoserver-users] ORA-01427 in RC1, 
app-schema
Date: Thu, 17 Feb 2011 11:59:04 +0800
From: Ben Caradoc-Davies 
To: Lindegaard, Morten
CC: geoserver-us...@lists.sourceforge.net

Thanks, Morten.

It looks like something has gone horribly wrong in the conversion of a 
filter to SQL. The SELECT with the clause "WHERE 0 = 1" is never going 
to return any rows.  :-(

I will create a Jira issue.

Kind regards,
Ben.

On 16/02/11 20:43, Lindegaard, Morten wrote:
> Hi Ben,
>
> Yes, the original SQL error has gone away. However, it might be because of 
> more immediate errors.
>
> When I use GeoServer 2.1 beta 3, my configuration seems to give the desired 
> results.
>
> The query
> http://localhost:8080/geoserver21b3/kms/wfs?version=1.1.0&service=WFS&request=GetFeature&typename=kms:Jordstykke&maxfeatures=4&filter=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ekms:featureID%3C/PropertyName%3E%3CLiteral%3E1613974%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E
>
> yields a response with data in GML, and the following is in the log:
>
> 2011-02-16 13:17:35,337 INFO [geoserver.wfs] -
> Request: getFeature
>  handle = null
>  service = WFS
>  version = 1.1.0
>  baseUrl = http://localhost:8080/geoserver21b3/
>  providedVersion = null
>  extendedProperties = {}
>  query = [net.opengis.wfs.impl.QueryTypeImpl@117e4ff (group: null, 
> propertyName: null, function: null, filter: [ kms:featureID = 1613974 ], 
> sortBy: null, featureVersion: null, handle: null, srsName: null, typeName: 
> [{http://schemas.kms.dk/wfs}Jordstykke])]
>  maxFeatures = 4
>  outputFormat = text/xml; subtype=gml/3.1.1
>  resultType = results
>  traverseXlinkDepth = null
>  traverseXlinkExpiry = null
>  formatOptions = {}
>  metadata = null
>
> I then use the same workspace configuration in GeoServer 2.1 RC 1, and the 
> query results in an error that puts the below entries in the log.
>
> I had expected that I would have been able to simply copy a configuration 
> from beta 3 to RC 1.
>
>
> Kind regards,
>   Morten
>
>
> 2011-02-16 12:53:05,476 DEBUG [geoserver.requests] - Query is 
> net.opengis.wfs.impl.QueryTypeImpl@b162fa (group: [], propertyName: [], 
> function: null, filter: [ kms:featureID = 1613974 ], sortBy: [], 
> featureVersion: null, handle: null, srsName: null, typeName: 
> [{http://schemas.kms.dk/wfs}Jordstykke])
>   To gt2: Query:
> feature type: Jordstykke
> filter: [ kms:featureID = 1613974 ]
> [properties:  ALL ]
> 2011-02-16 12:53:05,476 DEBUG [geotools.jdbc] - CREATE CONNECTION
> 2011-02-16 12:53:05,476 TRACE [geotools.core] - ENTRY 14
> 2011-02-16 12:53:05,476 DEBUG [geotools.filter] - exporting SQL 
> ComparisonFilter
> 2011-02-16 12:53:05,476 DEBUG [geotools.filter] - exporting PropertyName
> 2011-02-16 12:53:05,476 DEBUG [geotools.jdbc] - SELECT 
> KFID,UUID,FEATUREID,FEATURETYPE,FEATURECODE,DATASETIDENTIFIER,DATAQUALITYSPECIFICATION,DATAQUALITYSTATEMENT,DATAQUALITYDESCRIPTION,DATAQUALITYPROCESSOR,DATAQUALITYRESPONSIBLEPARTY,TIMEOFCREATION,TIMEOFPUBLICATION,TIMEOFREVISION,ESR_EJENDOMSNUMMER,KMS_SAGSID,KMS_JOURNALNUMMER,REGISTRERINGSDATO,EJERLAVSNAVN,LANDSEJERLAVSKODE,MATRIKELNUMMER,FAELLESLOD,MODERJORDSTYKKE,SUPMSAGSID,SKELFORRETNINGSSAGSID,REGISTRERETAREAL,AREALBEREGN,VEJAREAL,VEJAREALBEREGN,VANDAREALBEREGN,AREALTYPE,REGIONSKODE,REGIONSNAVN,KOMMUNEKODE,KOMMUNENAVN,SOGNEKODE,SOGNENAVN,RETSKREDSKODE,RETSKREDSNAVN,SURFACEPROPERTY
>  as SURFACEPROPERTY FROM LDS_2.KF_JORDSTYKKE_V WHERE FEATUREID = ?
> 2011-02-16 12:53:05,476 DEBUG [geotools.jdbc] - 1 = 1613974
> 2011-02-16 12:53:05,617 DEBUG [geotools.jdbc] - CREATE CONNECTION
> 2011-02-16 12:53:05,695 TRACE [geotools.core] - ENTRY -12.345
> 2011-02-16 12:53:05,695 DEBUG [geotools.jdbc] - SELECT 
> KFID,UUID,FEATUREID,FEATURETYPE,FEATURECODE,DATASETIDENTIFIER,DATAQUALITYSPECIFICATION,DATAQUALITYSTATEMENT,DATAQUALITYDESCRIPTION,DATAQUALITYPROCESSOR,DATAQUALITYRESPONSIBLEPARTY,TIMEOFCREATION,TIMEOFPUBLICATION,TIMEOFREVISION,ESR_EJENDOMSNUMMER,KMS_SAGSID,KMS_JOURNALNUMMER,REGISTRERINGSDATO,EJERLAVSNAVN,LANDSEJERLAVSKODE,MATRIKELNUMMER,FAELLESLOD,MODERJORDSTYKKE,SUPMSAGSID,SKELFORRETNINGSSAGSID,REGISTRERETAREAL,AREALBEREGN,VEJAREAL,VEJAREALBEREGN,VANDAREALBEREGN,AREALTYPE,REGIONSKODE,REGIONSNAVN,KOMMUNEKODE,KOMMUNENAVN,SOGNEKODE,SOGNENAVN,RETSKREDSKODE,RETSKREDSNAVN,SURFACEPR

[Geotools-devel] [jira] Created: (GEOT-3412) Improve support for cyclic dependencies by preventing an xsd-core XSD from being its own dependency

[Ben Caradoc-Davies (JIRA)]

Improve support for cyclic dependencies by preventing an xsd-core XSD from 
being its own dependency
---

 Key: GEOT-3412
 URL: http://jira.codehaus.org/browse/GEOT-3412
 Project: GeoTools
  Issue Type: Sub-task
  Components: ext xml-xsd
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
 Fix For: 2.7.0, 2.8-M1
 Attachments: XSD.patch

A tiny change to prevent infinite dependency recursion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3411) Improve xsd-core Schemas handling of paths with spaces

[Ben Caradoc-Davies (JIRA)]

Improve xsd-core Schemas handling of paths with spaces
--

 Key: GEOT-3411
 URL: http://jira.codehaus.org/browse/GEOT-3411
 Project: GeoTools
  Issue Type: Sub-task
  Components: ext xml-xsd
Affects Versions: 2.7.0, 2.8-M1
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
 Attachments: Schemas.patch

The attached patch improved the handling in xsd-core Schemas of paths with 
spaces. Instead of urldecoding the input location, DataUtilities.urlToFile is 
used for manipulations. This means that an invalid file: URL containing 
unescaped spaces is never constructed, facilitating the implementation of 
SchemaLocationResolver implementations that otherwise have trouble handling 
broken URLs.

I can hold this off stable until 2.7.0 is out, if you like.

(I have previously had to work around this behaviour in app-schema-resolver: 
this fix will allow that workaround to be fixed as well.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3403) app-schema DataAccessIntegrationTest.testFilters() fails in Eclipse

[Ben Caradoc-Davies (JIRA)]

app-schema DataAccessIntegrationTest.testFilters() fails in Eclipse
---

 Key: GEOT-3403
 URL: http://jira.codehaus.org/browse/GEOT-3403
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.8-M1
 Environment: JRE: jdk 1.5.0_22 i586 (i.e. 32-bit) running on Linux 
x86_64
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani


This test passes in Maven but fails in Eclipse:

{code}
java.lang.AssertionError: expected:<3> but was:<0>
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.failNotEquals(Assert.java:448)
at org.junit.Assert.assertEquals(Assert.java:102)
at org.junit.Assert.assertEquals(Assert.java:323)
at org.junit.Assert.assertEquals(Assert.java:319)
at 
org.geotools.data.complex.DataAccessIntegrationTest.testFilters(DataAccessIntegrationTest.java:378)
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3379) imagemosaic build failure in path with spaces

[Ben Caradoc-Davies (JIRA)]

imagemosaic build failure in path with spaces
-

 Key: GEOT-3379
 URL: http://jira.codehaus.org/browse/GEOT-3379
 Project: GeoTools
  Issue Type: Bug
  Components: gc imagemosaic
Affects Versions: 2.7-RC1
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-07 03:16:01+0800)
Java version: 1.5.0_22
Java home: /home/car605/junk/java/jdk1.5.0_22.i586/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux" version: "2.6.32.26-175.fc12.x86_64" arch: "i386" Family: 
"unix"

Reporter: Ben Caradoc-Davies
Priority: Blocker


gt-imagemosaic OverviewsControllerTest.testHeterogeneousGranules fails in a 
path with spaces because a space is double-escaped as %2520.

{code}
java.lang.IllegalArgumentException: Unable to get an input stream for the 
provided file 
file:/home/car605/geoserver/src%2520with%2520spaces/geotools-trunk/modules/plugin/imagemosaic/target/test-classes/org/geotools/gce/imagemosaic/test-data/heterogeneous/world_a.tif
at 
org.geotools.gce.imagemosaic.GranuleDescriptor.init(GranuleDescriptor.java:396)
at 
org.geotools.gce.imagemosaic.GranuleDescriptor.(GranuleDescriptor.java:548)
at 
org.geotools.gce.imagemosaic.GranuleDescriptor.(GranuleDescriptor.java:515)
at 
org.geotools.gce.imagemosaic.OverviewsControllerTest.testHeterogeneousGranules(OverviewsControllerTest.java:197)
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3354) Support encoding multiple WFS feature types with the same XSD type

[Ben Caradoc-Davies (JIRA)]

Support encoding multiple WFS feature types with the same XSD type
--

 Key: GEOT-3354
 URL: http://jira.codehaus.org/browse/GEOT-3354
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.7-beta1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies


When users define two WFS feature types (XSD elements) with the same XSD type, 
they encounter an exception at encode time. The reason the two types compare 
unequal is under investigation.

{code}
java.lang.IllegalArgumentException: Type with same name already exists in cache.
at org.geotools.gml2.FeatureTypeCache.put(FeatureTypeCache.java:45)
at 
org.geoserver.wfs.xml.v1_1_0.WFSConfiguration.configureContext(WFSConfiguration.java:233)
at org.geotools.xml.Configuration.setupContext(Configuration.java:645)
at org.geotools.xml.Encoder.(Encoder.java:229)
at 
org.geoserver.wfs.xml.GML3OutputFormat.createEncoder(GML3OutputFormat.java:213)
at 
org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:161)
at 
org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:141)
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3327) GML 3.2 AbstractGMLType XSDTypeDefinition is incomplete

[Ben Caradoc-Davies (JIRA)]

GML 3.2 AbstractGMLType XSDTypeDefinition is incomplete
---

 Key: GEOT-3327
 URL: http://jira.codehaus.org/browse/GEOT-3327
 Project: GeoTools
  Issue Type: Bug
  Components: core xml
Affects Versions: 2.7-M4
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Critical
 Attachments: AbstractGMLTypeTest.java

The XSDTypeDefinition for GML 3.2 AbstractGMLType is incomplete because 
metaDataProperty has no type definition. (This is the complex type definition 
created dynamically from the schema, not the compiled types in GMLSchema.) This 
is likely caused by its type being hidden in deprecatedTypes.xsd and GML 3.2 
relying on the single-point-of-entry gml.xsd.

One of the changes in GML 3.2 was to put a bunch of definitions in 
deprecatedTypes.xsd. This includes MetaDataPropertyType. This deprecated type 
is used in gmlBase.xsd, in particular, to define AbstractGMLType (via 
StandardObjectProperties). Yes, a deprecated type is used to define the base 
class of just about everything else. The particularly nasty thing about the way 
this was done is that deprecatedTypes.xsd is not imported by gmlBase.xsd. GML 
3.2 is only usable if you import gml.xsd and allow it to import both 
gmlBase.xsd and deprecatedTypes.xsd. Parsing gmlBase.xsd will not work. You can 
see this in Eclipse. I don't think EMF is very happy about this either. I have 
no idea how to fix it.

This failure is blocking app-schema support for GML 3.2.

The attached unit test demonstrates the failure. The GML 3.1 test passes but 
the GML 3.2 test fails. It is also worth noting that the getQName() for 
metaDataProperty prints no namespace prefix because the "element" of this 
XSDNamedComponent is set to null. All the other children have types. 

{code}
Child element declaration types for {http://www.opengis.net/gml}AbstractGMLType 
:
QName: gml:metaDataProperty URI: http://www.opengis.net/gml#metaDataProperty 
Type: org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@1493102 (element: 
[complexType: null]) (name: MetaDataPropertyType, targetNamespace: 
http://www.opengis.net/gml) (derivationMethod: , final: [], abstract: 
, contentTypeCategory: elementOnly, prohibitedSubstitutions: [], 
lexicalFinal: null, block: null, mixed: )
QName: gml:description URI: http://www.opengis.net/gml#description Type: 
org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@30ae41 (element: 
[complexType: null]) (name: StringOrRefType, targetNamespace: 
http://www.opengis.net/gml) (derivationMethod: extension, final: [], abstract: 
, contentTypeCategory: simple, prohibitedSubstitutions: [], 
lexicalFinal: null, block: null, mixed: )
QName: gml:name URI: http://www.opengis.net/gml#name Type: 
org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@4204 (element: [complexType: 
null]) (name: CodeType, targetNamespace: http://www.opengis.net/gml) 
(derivationMethod: extension, final: [], abstract: , 
contentTypeCategory: simple, prohibitedSubstitutions: [], lexicalFinal: null, 
block: null, mixed: )

Child element declaration types for 
{http://www.opengis.net/gml/3.2}AbstractGMLType :
QName: metaDataProperty URI: http://www.opengis.net/gml/3.2#metaDataProperty 
Type: null <<< FAILURE
QName: gml:description URI: http://www.opengis.net/gml/3.2#description Type: 
org.eclipse.xsd.impl.xsdsimpletypedefinitioni...@68cd79 (element: null) (name: 
StringOrRefType, targetNamespace: http://www.opengis.net/gml/3.2) (variety: 
atomic, final: null, lexicalFinal: null, validFacets: null)
QName: gml:descriptionReference URI: 
http://www.opengis.net/gml/3.2#descriptionReference Type: 
org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@89e2f1 (element: 
[complexType: null]) (name: ReferenceType, targetNamespace: 
http://www.opengis.net/gml/3.2) (derivationMethod: , final: [], 
abstract: , contentTypeCategory: empty, prohibitedSubstitutions: [], 
lexicalFinal: null, block: null, mixed: )
QName: gml:identifier URI: http://www.opengis.net/gml/3.2#identifier Type: 
org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@92668c (element: 
[complexType: null]) (name: CodeWithAuthorityType, targetNamespace: 
http://www.opengis.net/gml/3.2) (derivationMethod: restriction, final: [], 
abstract: , contentTypeCategory: simple, prohibitedSubstitutions: [], 
lexicalFinal: null, block: null, mixed: )
QName: gml:name URI: http://www.opengis.net/gml/3.2#name Type: 
org.eclipse.xsd.impl.xsdcomplextypedefinitioni...@18a9fc8 (element: 
[complexType: null]) (name: CodeType, targetNamespace: 
http://www.opengis.net/gml/3.2) (derivationMethod: extension, final: [], 
abstract: , contentTypeCategory: simple, prohibitedSubstitutions: [], 
lexicalFinal: null, block: null, mixed: )
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrator

[Geotools-devel] [jira] Created: (GEOT-3325) Change in gt-coverage Resample breaks the GeoServer build

[Ben Caradoc-Davies (JIRA)]

Change in gt-coverage Resample breaks the GeoServer build
-

 Key: GEOT-3325
 URL: http://jira.codehaus.org/browse/GEOT-3325
 Project: GeoTools
  Issue Type: Bug
  Components: core coverage
Affects Versions: 2.7-M4
Reporter: Ben Caradoc-Davies
Assignee: Simone Giannecchini
Priority: Blocker


The change to 
modules/library/coverage/src/main/java/org/geotools/coverage/processing/operation/Resample.java
 by simonegiannecchini in r36353 breaks the GeoServer build by causing wcs1_0 
org.geoserver.wcs.GetCoverageTest to fail in two places.

The problem is caused by the change in Resample.INTERPOLATION_TYPE valueClass 
from Object.class to String.class. Much of the change is related to adding 
generics and improving type checking. The GeoServer code is non-generic, and at 
wcs WCSUtil.resample (line 112) attempts to set an interpolation parameter 
value to an javax.media.jai.Interpolation. With the former valueClass 
Object.class this was permissible; with the change to String.class, the type 
mismatch is detected at runtime and Parameter.ensureValidValue throws an 
exception.

I am not sure is the GeoTools change is bad or GeoServer is doing the wrong 
thing. Should this parameter be a String or an Object?




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3310) app-schema feature chaining requests nonexistent properties

[Ben Caradoc-Davies (JIRA)]

app-schema feature chaining requests nonexistent properties
---

 Key: GEOT-3310
 URL: http://jira.codehaus.org/browse/GEOT-3310
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Reporter: Ben Caradoc-Davies
Assignee: Rini Angreani


 Original Message 
Subject: [Geoserver-users] App schema feature chaining issue
Date: Wed, 3 Nov 2010 05:46:22 +0800
From: Ryan Zoerb
To: geoserver-us...@lists.sourceforge.net

Hi everyone.  I'm trying to get application schema with feature chaining 
working, but I'm running into an issue.  I've attached the two mapping files 
I'm using.  WaterWell is the top level element, which can have several nested 
logElement's.  I've been able to successfully get GeoServer to return a correct 
response without feature chaining, but when I added the chaining, I get this 
Oracle error: 'ORA-00904: "TIMES": invalid identifier'.  Here's the query that 
GeoServer is doing that returns the error: 

SELECT 
GW_LEV_PK,AGENCY_CD,SITE_NO,DATES,VALUE,REMARK,REMARK_DS,SOURCE_CD,METHOD_CD,METHOD_DS,QW_ACCURACY,QW_ACCURACY_NM,HOST,DBNUM,DWH_INSERT,LEV_CN,LEV_CR,LEV_MN,LEV_MD,MP_LEV_VA,SL_LEV_VA,LEV_ENT_CD,LEV_STATISTICS_CD,LEV_STATISTICS_NM,DATE_ACY_CD,SL_DATUM_CD,LEV_PARTY_TX,LEV_WEB_CD,LEV_AGENCY_CD,LEV_MPNT_SEQ_NU,LEV_RMK_TX,LEV_EQPID_TX,DWH_SITE_ID,PARAMETER_CODE,SOURCE,VALUE_ALL,AGENCY_CD,SITE_NO,DATES,VALUE,STATUS_CD,STATUS_DS,SOURCE_CD,METHOD_CD,METHOD_DS,QW_ACCURACY,QW_ACCURACY_NM,HOST,DBNUM,DWH_INSERT,LEV_CN,LEV_CR,LEV_MN,LEV_MD,TIMES,MP_LEV_VA,SL_LEV_VA,LEV_ENT_CD,LEV_STATISTICS_CD,LEV_STATISTICS_NM,DATE_ACY_CD,SL_DATUM_CD,LEV_PARTY_TX,LEV_WEB_CD,LEV_AGENCY_CD,LEV_MPNT_SEQ_NU,LEV_RMK_TX,LEV_EQPID_TX,DWH_SITE_ID
 FROM GWSI_LEVELS WHERE SITE_NO = ?

The problem is that the GWSI_LEVELS table doesn't have a column called TIMES.  
All of the other columns are correct (even though most of them are in that list 
twice).  The pattern I see is that the primary key, GW_LEV_PK, is first in the 
list, then all of the columns are listed in the same order they are in the db 
(except for GW_LEV_PK).  Then, all the columns except the last three are listed 
again, but TIMES is put in GW_LEV_PK's column position.  Can anyone see what 
could be causing this, or is it a bug?

Thanks for any help,
Ryan


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3293) Build failure in gt-xsd-wfs WFSParsingTest and FeatureTypeListTypeBindingTest

[Ben Caradoc-Davies (JIRA)]

Build failure in gt-xsd-wfs WFSParsingTest and FeatureTypeListTypeBindingTest
-

 Key: GEOT-3293
 URL: http://jira.codehaus.org/browse/GEOT-3293
 Project: GeoTools
  Issue Type: Bug
  Components: ext xml-xsd
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira
Priority: Blocker


Justin, the build is failing in gt-xsd-wfs since your commit in r36272:

{code}
Tests in error: 
  testParseGetCapabilities(org.geotools.wfs.WFSParsingTest)
  testParse(org.geotools.wfs.bindings.FeatureTypeListTypeBindingTest)
{code}

{code}
---
Test set: org.geotools.wfs.WFSParsingTest
---
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 13.187 sec <<< 
FAILURE!
testParseGetCapabilities(org.geotools.wfs.WFSParsingTest)  Time elapsed: 0.069 
sec  <<< ERROR!
java.lang.RuntimeException: Parsing failed for WGS84BoundingBox: 
java.lang.RuntimeException: Unable to set property: LowerCorner for eobject: 
{http://www.opengis.net/ows}WGS84BoundingBoxType
at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:158)
at 
org.geotools.xml.impl.BindingWalker$BindingExecutionChain.execute(BindingWalker.java:215)
at org.geotools.xml.impl.BindingWalker.walk(BindingWalker.java:181)
at 
org.geotools.xml.impl.ElementHandlerImpl.endElement(ElementHandlerImpl.java:222)
at 
org.geotools.xml.impl.ParserHandler.endElement(ParserHandler.java:607)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.geotools.xml.Parser.parse(Parser.java:228)
at org.geotools.xml.Parser.parse(Parser.java:156)
at 
org.geotools.wfs.WFSParsingTest.testParseGetCapabilities(WFSParsingTest.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: java.lang.RuntimeException: Unable to set property: LowerCorner for 
eobject: {http://www.opengis.net/ows}WGS84BoundingBoxType
at 
org.geotools.xml.AbstractComplexEMFBinding.setProperty(AbstractComplexEMFBinding.java:290)
at 
org.geotools.xml.AbstractComplexEMFBinding.setProperties(AbstractComplexEMFBinding.java:204)
at 
org.geotools.xml.AbstractComplexEMFBinding.parse(AbstractComplexEMFBinding.java:145)
at 
org.geotools.ows.bindings.WGS84BoundingBoxTypeBinding.parse(WGS84BoundingBoxTypeBinding.java:106)
 

[Geotools-devel] [jira] Created: (GEOT-3290) Resource leak in PropertyFeatureSource breaks the build on Windows

[Ben Caradoc-Davies (JIRA)]

Resource leak in PropertyFeatureSource breaks the build on Windows
--

 Key: GEOT-3290
 URL: http://jira.codehaus.org/browse/GEOT-3290
 Project: GeoTools
  Issue Type: Bug
  Components: data property
Affects Versions: 2.6.6, 2.7-M4
Reporter: Ben Caradoc-Davies
Priority: Blocker
 Attachments: PropertyFeatureSource.patch

Attached patch fixes a resource leak in PropertyFeatureSource that breaks the 
build on Windows. The problem is the getCount method that fails to dispose a 
reader. When the test fixture is torn down, Windows refuses to let the file be 
deleted as it is still open.

This is unrelated to GEOT-3273.

{code}
 Original Message 
Subject: Re: [Geotools-devel] [ExternalEmail] Re: Build Failure: 
AppSchemaFileDataTest giveserrors
Date: Tue, 12 Oct 2010 09:56:31 +0800
From: Ben Caradoc-Davies 
CC: Tara Athan , "Tan, Florence (CESRE, Kensington)", 
"geotools-devel@lists.sourceforge.net"

Florence is also reporting this failure. Is anyone else seeing it on
Windows? Is it repeatable?

Maybe this is caused by the datastore resource leak:
http://jira.codehaus.org/browse/GEOT-3273

Even though the app-schema DataAccess is properly disposed, it does not
dispose the underlying simple feature data store, which then keeps the
property file open until it is garbage-collected.

Windows differs from other platforms that it does not let an application
delete an open file. This causes the tearDown in the test to fail. On
Unix platforms, file deletion is just unlinking, so this problem is not
evident (the file is only removed when it has no links and nothing has
it open).

On 04/10/10 13:30, Ben Caradoc-Davies wrote:
> That is really weird. It looks like the sort of failures you get on
> Windows when something else has the file open. Can you please manually
> delete the file (mvnn clean would be good) and make sure nothing else
> has it open? Might be TortoiseSVN or even a virus scanner. Because this
> is a temporary directory, I would not expect you to have it open in Eclipse.
>
> Regards,
> Ben.
>
>
> On 04/10/10 12:49, Tara Athan wrote:
>> Ben- regarding your question as to test failures: I'll reply separately
>> for the geotools and geoserver failures on the appropriate lists.
>> Ironically, it is my AppSchemaFileDataTest that is giving errors. Here
>> is the sure-fire report
>>
>> ---
>> Test set: org.geotools.data.complex.config.AppSchemaFileDataTest
>> ---
>> Tests run: 4, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.406
>> sec<<<   FAILURE!
>> testPropertiesMappings(org.geotools.data.complex.config.AppSchemaFileDataTest)
>> Time elapsed: 1 sec<<<   ERROR!
>> java.io.IOException: Unable to delete file:
>> target\test\AppSchemaFileDataTest\directory\PointFeatureGeomPropertyfile.properties
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3273) Application schema doesn't dispose datastores

[Ben Caradoc-Davies (JIRA)]

Application schema doesn't dispose datastores
-

 Key: GEOT-3273
 URL: http://jira.codehaus.org/browse/GEOT-3273
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.6.6, 2.7-M4
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
 Fix For: 2.6.6, 2.7-M4


{code}
 Original Message 
Subject: [Geotools-gt2-users] Application schema doesn't dispose datastores?
Date: Wed, 22 Sep 2010 06:54:01 +0800
From: Dustin Parker 
To: geotools-gt2-us...@lists.sourceforge.net

Hello again,

While making sure that my patch for the previous problem was working 
correctly, I noticed there were still some legitimate log messages being 
printed about JDBCDataStore.dispose(). Here's a stack trace for the 
creation of a data store that didn't get cleaned up:

> Daemon Thread [ScannerThread] (Suspended (breakpoint at line 366 in 
> org.geotools.jdbc.JDBCDataStore)) 
>   owns: java.lang.Class (org.geotools.data.DataAccessFinder) (id=738)  
>   owns: org.geoserver.catalog.ResourcePool$DataStoreCache  (id=758)   
>   owns: java.util.concurrent.ConcurrentHashMap  (id=759) 
>   owns: java.util.concurrent.ConcurrentHashMap  (id=760) 
>   owns: java.lang.Object  (id=761)
>   owns: org.apache.catalina.core.StandardContext  (id=762)
>   owns: java.util.HashMap  (id=328)  
>   owns: org.jboss.web.tomcat.service.TomcatDeployer  (id=763) 
>   owns: org.jboss.web.WebModule  (id=764) 
>   owns: org.jboss.system.ServiceController  (id=331)  
>   owns: org.jboss.web.tomcat.service.JBossWeb  (id=215)   
>   owns: org.jboss.deployment.scanner.URLDeploymentScanner  (id=216)   
>   org.geotools.jdbc.JDBCDataStore.setDatabaseSchema(java.lang.String) 
> line: 366   
>   
> org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory(org.geotools.jdbc.JDBCDataStoreFactory).createDataStore(java.util.Map)
>  line: 178
>   
> org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory(org.geotools.jdbc.JDBCDataStoreFactory).createDataStore(java.util.Map)
>  line: 50 
>   
> org.geotools.data.DataAccessFinder.getDataStore(java.util.Map,
>  java.util.Iterator) line: 129 
>  
>   
> org.geotools.data.DataAccessFinder.getDataStore(java.util.Map)
>  line: 95  
>   
> org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.aquireSourceDatastores()
>  line: 550 
>   
> org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings()
>  line: 180  
>   
> org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings(org.geotools.data.complex.config.AppSchemaDataAccessDTO)
>  line: 157   
>   
> org.geotools.data.complex.AppSchemaDataAccessFactory.createDataStore(java.util.Map)
>  line: 94
>   org.vfny.geoserver.util.DataStoreUtils.getDataAccess(java.util.Map) 
> line: 97
>   
> org.geoserver.catalog.ResourcePool.getDataStore(org.geoserver.catalog.DataStoreInfo)
>  line: 298  
>   
> org.geoserver.catalog.impl.DataStoreInfoImpl.getDataStore(org.opengis.util.ProgressListener)
>  line: 37   
>   
> org.geoserver.config.GeoServerLoader.readCatalog(org.geoserver.config.util.XStreamPersister)
>  line: 580  
>   
> org.geoserver.config.GeoServerLoader.loadCatalog(org.geoserver.catalog.Catalog,
>  org.geoserver.config.util.XStreamPersister) line: 160   
>   
> org.geoserver.config.GeoServerLoader.postProcessBeforeInitialization(java.lang.Object,
>  java.lang.String) line: 131  

The constructors for all the data stores that didn't get cleaned up 
passed through AppSchemaDataAccessConfigurator calls, so it seems the 
most likely culprit.

I have 2.6.1 loaded in my IDE, so I don't know if it's changed 
significantly since then, but this class's field

> private Map sourceDataStores;

is written to a few times, but the source data stores don't seem to get 
saved off anywhere or disposed of. Some FeatureSources are extracted 
from them as needed by mappings, so it's possible that those could get 
disposed later on, but if a data store isn't used in a mapping, there's 
no way. Any ideas on what to do? I'm happy to submit another patch or 
fix my setup ;)

-- 
Dustin Parker - Forward Slope, Inc.
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_

[Geotools-devel] [jira] Created: (GEOT-3271) Resource leak in app-schema vocab handling

[Ben Caradoc-Davies (JIRA)]

Resource leak in app-schema vocab handling
--

 Key: GEOT-3271
 URL: http://jira.codehaus.org/browse/GEOT-3271
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.7-M4
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies


org.geotools.filter.expression.VocabFunction does not dispose of its 
FileInputStream. This leak also prevents the file from being deleted under 
Windows.

{code}
 Original Message 
Subject: RE: Re: [Geoserver-users] Deleting a *.properties file when GeoServer 
has an open handle
Date: Mon, 20 Sep 2010 12:58:05 +0800
From: Angreani, Rini (CESRE, Kensington) 
To: Caradoc-Davies, Ben (CESRE, Kensington) 

Hi Ben,

The file content should look like this:

1GRAV=urn:cgi:classifier:CGI:SimpleLithology:2008:gravel
1TILL=urn:cgi:classifier:CGI:SimpleLithology:2008:diamictite
6ALLU=urn:cgi:classifier:CGI:SimpleLithology:2008:sediment

http://docs.geoserver.org/trunk/en/user/data/app-schema/vocab-functions.html
 
I think it just locates the file, and streams it. 
Actually after looking at VocabFunction, maybe we should close the stream after 
using it?

if( file.exists() ){
try {
properties.load( new FileInputStream( file ) );
} catch (FileNotFoundException e) {
throw new RuntimeException("Could not find file for lookup 
table "+urn );
} catch (IOException e) {
throw new RuntimeException("Difficulty parsing lookup table 
"+urn );
}
}

Sounds like we need to support vocab functions for databases (like simple 
features)? 
Gilly also asked about this last time. Perhaps for Auscope 3 :p 

Cheers
Rini
{code}

Original bug report:

{code}
 Original Message 
Subject: [Geoserver-users] Deleting a *.properties file when GeoServer has an 
open handle
Date: Mon, 20 Sep 2010 10:46:16 +0800
From: smas036
To: geoserver-us...@lists.sourceforge.net


Hi all, 

I'm trying to delete a .properties file that I use temporarily with the
app-schema extension but I'm unable to as GeoServer still has an open handle
on the file after a WFS request. The file is used as a vocab reference in
the mapping file. I'm using Windows Server 2008. Any ideas on how to get
GeoServer to release the file without shutting it down?

Cheers

Sina
{code}





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3268) Intermittent build failure in gt-feature-pregeneralized ShapeFilePreGeneralizedFeatureSourceTest

[Ben Caradoc-Davies (JIRA)]

Intermittent build failure in gt-feature-pregeneralized 
ShapeFilePreGeneralizedFeatureSourceTest


 Key: GEOT-3268
 URL: http://jira.codehaus.org/browse/GEOT-3268
 Project: GeoTools
  Issue Type: Bug
  Components: data shapefile
Affects Versions: 2.7-M4
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-07 03:16:01+0800)
Java version: 1.5.0_22
Java home: /home/car605/junk/java/jdk1.5.0_22.i586/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux" version: "2.6.32.21-166.fc12.x86_64" arch: "i386" Family: 
"unix"

Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime
Priority: Blocker


I am seeing intermittent build failures in gt-feature-pregeneralized (where by 
intermittent I mean it fails most of the time, but sometimes succeeds). I 
strongly suspect a shapefile handling race condition. At the other tests with 
the same abstract base class succeed.

This does not affect stable, does not affect Hudson, not my buildbot. Just my 
desktop. This looks like another Affects-Only-Ben bug. (Did we ever set that as 
a priority option?)

{code}
Failed tests: 
  
testFeatureReader(org.geotools.data.gen.ShapeFilePreGeneralizedFeatureSourceTest)
  
testFeatureReaderWithoutGeom(org.geotools.data.gen.ShapeFilePreGeneralizedFeatureSourceTest)
  
testGetFeatures(org.geotools.data.gen.ShapeFilePreGeneralizedFeatureSourceTest)
  
testGetFeatures3(org.geotools.data.gen.ShapeFilePreGeneralizedFeatureSourceTest)
  testGetSchema(org.geotools.data.gen.ShapeFilePreGeneralizedFeatureSourceTest)

Tests run: 52, Failures: 5, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.
{code}

The common symptom is an NPE thrown at ComplexTypeImpl:73:
{code}
throw new NullPointerException("PropertyDescriptor is null - did you request a 
property that does not exist?");
{code}

At this point the local variable properties is:
{code}
[GeometryDescriptorImpl the_geom  nillable 
0:1, null]
{code}

So the type is being constructed with a null property.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3253) Build failure in imagemosaic caused by GranuleDescriptor changes

[Ben Caradoc-Davies (JIRA)]

Build failure in imagemosaic caused by GranuleDescriptor changes


 Key: GEOT-3253
 URL: http://jira.codehaus.org/browse/GEOT-3253
 Project: GeoTools
  Issue Type: Bug
  Components: gc imagemosaic
Affects Versions: 2.7-M3
Reporter: Ben Caradoc-Davies
Assignee: Simone Giannecchini


Not a blocker because the build failure introduced in r36112 was reverted in 
r36113.

{code}
Changed by: simonegiannecchini
Changed at: Tue 24 Aug 2010 03:46:54
Revision: 36112
Changed files:
* 
modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/GranuleDescriptor.java
* 
modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/ReadType.java
Comments:
improving performance for ImageMosaic by reusing reader multiple times
{code}

{code}
[INFO] Building imagemosaic datasource module
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory /home/buildbot/GeoServerTrunkSlave/build with 
spaces/geotools-trunk/modules/plugin/imagemosaic/target
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] [compiler:compile]
[INFO] Compiling 33 source files to /home/buildbot/GeoServerTrunkSlave/build 
with spaces/geotools-trunk/modules/plugin/imagemosaic/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/home/buildbot/GeoServerTrunkSlave/build with 
spaces/geotools-trunk/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/GranuleDescriptor.java:[656,71]
 cannot find symbol
symbol  : method getSubSamplingFactor2(int,int)
location: class it.geosolutions.imageio.utilities.ImageIOUtilities
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3229) Build broken by bad docs geotools.version

[Ben Caradoc-Davies (JIRA)]

Build broken by bad docs geotools.version
-

 Key: GEOT-3229
 URL: http://jira.codehaus.org/browse/GEOT-3229
 Project: GeoTools
  Issue Type: Bug
  Components: doc
Affects Versions: 2.7-M3
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett
Priority: Blocker


Several trunk poms have a tag geotools.version, breaking the build.

{code}
$ find . -name pom.xml -exec grep -H 2.7-M2 {} \;
./docs/pom.xml:2.7-M2
./docs/pom.xml:  
./docs/tutorial/geometry/artifacts/pom.xml:
2.7-M2
./docs/tutorial/filter/artifacts/pom.xml:
2.7-M2
./docs/tutorial/map/artifacts/pom.xml:
2.7-M2
./docs/tutorial/feature/artifacts/pom.xml:  
2.7-M2
./docs/tutorial/quickstart/artifacts/pom.xml:
2.7-M2
./docs/tutorial/raster/artifacts/pom.xml:
2.7-M2
{code}

{code}
[INFO] Unable to find resource 'org.geotools:geotools:pom:2.7-M2' in repository 
central (http://repo1.maven.org/maven2)
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.geotools
ArtifactId: geotools
Version: 2.7-M2

Reason: Unable to download the artifact from any repository

  org.geotools:geotools:pom:2.7-M2

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)



[INFO] 
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
org.geotools:geotools for project: org.geotools:docs:jar:null for project 
org.geotools:docs:jar:null
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3225) Build broken by missing test data dotsStars.sld for gt-render LineTest.testDotsStars

[Ben Caradoc-Davies (JIRA)]

Build broken by missing test data dotsStars.sld for gt-render 
LineTest.testDotsStars


 Key: GEOT-3225
 URL: http://jira.codehaus.org/browse/GEOT-3225
 Project: GeoTools
  Issue Type: Bug
  Components: core render
Affects Versions: 2.7-M3
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime
Priority: Blocker
 Fix For: 2.7-M3


The test data "dotsStars.sld" is not present and the test fails.

{code}
java.lang.NullPointerException
at org.geotools.styling.SLDParser.setInput(SLDParser.java:249)
at org.geotools.styling.SLDParser.(SLDParser.java:173)
at 
org.geotools.renderer.lite.RendererBaseTest.loadStyle(RendererBaseTest.java:203)
at org.geotools.renderer.lite.LineTest.testDotsStars(LineTest.java:63)
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3223) Build failure in gt-charts ChartRenderingTest.testPieCharts caused by changes to graphic stroke rendering

[Ben Caradoc-Davies (JIRA)]

Build failure in gt-charts ChartRenderingTest.testPieCharts caused by changes 
to graphic stroke rendering
-

 Key: GEOT-3223
 URL: http://jira.codehaus.org/browse/GEOT-3223
 Project: GeoTools
  Issue Type: Bug
  Components: core render
Affects Versions: 2.7-M3
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime


Changes introduced in r35959 to (mostly) gt-render ([GEOT-3222] Improve graphic 
stroke rendering) cause ChartRenderingTest.testPieCharts to fail. Preliminary 
analysis confirms that nothing is being rendered to the test image.

{code}
java.lang.AssertionError
at 
org.geotools.renderer.chart.RendererBaseTest.showRender(RendererBaseTest.java:126)
at 
org.geotools.renderer.chart.ChartRenderingTest.testPieCharts(ChartRenderingTest.java:43)
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3193) Unit test failure in ImageMosaicFormatFactoryTest.testSystemLoaderUnbounded() caused by test order assumption

[Ben Caradoc-Davies (JIRA)]

Unit test failure in ImageMosaicFormatFactoryTest.testSystemLoaderUnbounded() 
caused by test order assumption
-

 Key: GEOT-3193
 URL: http://jira.codehaus.org/browse/GEOT-3193
 Project: GeoTools
  Issue Type: Bug
  Components: gc imagemosaic
Reporter: Ben Caradoc-Davies


ImageMosaicFormatFactoryTest.testSystemLoaderUnbounded() sets a system property 
to trigger the loading of a configuration property file in the static 
initialiser of ImageMosaicFormatFactory:
{code}
System.setProperty("mosaic.threadpoolconfig.path", file.getAbsolutePath());
{code}

Setting the system property has the nasty side-effect of modifying the 
behaviour of the static initialiser of ImageMosaicFormatFactory if and only if 
the static initialiser has not yet been called (i.e. the class has not been 
loaded in the test runner JVM). As a consequence, if 
ImageMosaicFormatFactoryTest is run by itself, it passes. If run after another 
test such as GranuleTest that causes ImageMosaicFormatFactory to be loaded, 
this test will fail because the static initialiser has already run, parameters 
are already set to hardcoded defaults, and the property file is never used.

Setting a system property from within a unit test is a bad practice because it 
causes unit tests to no longer be independent. Needing to do this suggests 
ImageMosaicFormatFactory should be refactored to improve testability.

I have disabled this test by adding a n...@ignore annotation in r35906 on trunk 
and r35907 on 2.6.x to fix the build. (This is why this issue is not a blocker.)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3177) Failing wfs tests excluded to fix the build

[Ben Caradoc-Davies (JIRA)]

Failing wfs tests excluded to fix the build
---

 Key: GEOT-3177
 URL: http://jira.codehaus.org/browse/GEOT-3177
 Project: GeoTools
  Issue Type: Bug
  Components: data wfs
Affects Versions: 2.7-RC1
Reporter: Ben Caradoc-Davies
Assignee: Gabriel Roldán


Two failing wfs tests have been excluded in the pom to fix the build.

{code}
Failed tests: 
  
testGetSupportedGetFeatureOutputFormats(org.geotools.data.wfs.v1_1_0.WFS_1_1_0_ProtocolTest)

Tests in error: 
  tesGetFeatureReader(org.geotools.data.wfs.v1_1_0.WFS_1_1_0_DataStoreTest)

Tests run: 88, Failures: 1, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.
{code}


svn commit -m "Excluded WFS_1_1_0_ProtocolTest and WFS_1_1_0_DataStoreTest to 
fix the build."
Sendingwfs/pom.xml
Transmitting file data .
Committed revision 35846.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

   

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Reopened: (GEOT-3166) Build failure in docs when building in a path with spaces (if sphinx installed)

[Ben Caradoc-Davies (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOT-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ben Caradoc-Davies reopened GEOT-3166:
--


Oops, saw your commit log still not tested on Windows.

> Build failure in docs when building in a path with spaces (if sphinx 
> installed)
> ---
>
> Key: GEOT-3166
> URL: http://jira.codehaus.org/browse/GEOT-3166
> Project: GeoTools
>  Issue Type: Bug
>  Components: doc
>Reporter: Ben Caradoc-Davies
>Assignee: Jody Garnett
>
> Yes, docs breaks the build!
> If sphinx is available, docs are built. Build fails if building in a path 
> with spaces, presumably because of unquoted property substitution.
> {code}
> [INFO] [antrun:run {execution: compile}]
> [INFO] Executing tasks
> build:
> sphinx:
>  [exec] Error: Cannot find source directory.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] An Ant BuildException has occured: The following error occurred while 
> executing this line:
> /home/car605/geoserver/src with spaces/geotools-trunk/docs/build.xml:13: The 
> following error occurred while executing this line:
> /home/car605/geoserver/src with spaces/geotools-trunk/docs/build.xml:28: exec 
> returned: 1
> {code}
> In build.xml, what happens if ${build.directory} contains spaces?
> {code}
> 
> {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3167) Build failure in demo gt-example cause by gt-process API change

[Ben Caradoc-Davies (JIRA)]

Build failure in demo gt-example cause by gt-process API change
---

 Key: GEOT-3167
 URL: http://jira.codehaus.org/browse/GEOT-3167
 Project: GeoTools
  Issue Type: Bug
Affects Versions: 2.7-RC2
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett
Priority: Blocker


Failure caused by change to gt-process  in r35797 by jive.

{code}
[INFO] Building Geotools Example Demo
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory /home/car605/geoserver/src with 
spaces/geotools-trunk/demo/example/target
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 15 resources
[WARNING] Overriding profile: 'null' (source: pom) with new instance from 
source: pom
[WARNING] Overriding profile: 'null' (source: pom) with new instance from 
source: pom
[WARNING] Overriding profile: 'null' (source: pom) with new instance from 
source: pom
[INFO] [compiler:compile]
[INFO] Compiling 57 source files to /home/car605/geoserver/src with 
spaces/geotools-trunk/demo/example/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/home/car605/geoserver/src with 
spaces/geotools-trunk/demo/example/src/main/java/org/geotools/demo/process/ProcessAPI.java:[75,80]
 cannot find symbol
symbol  : variable GT_NAMESPACE
location: interface org.geotools.process.ProcessFactory



/home/car605/geoserver/src with 
spaces/geotools-trunk/demo/example/src/main/java/org/geotools/demo/process/ProcessAPI.java:[75,80]
 cannot find symbol
symbol  : variable GT_NAMESPACE
location: interface org.geotools.process.ProcessFactory


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Thu Jul 01 13:24:14 WST 2010
[INFO] Final Memory: 23M/39M
[INFO] 
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3166) Build failure in docs when building in a path with spaces (if sphinx installed)

[Ben Caradoc-Davies (JIRA)]

Build failure in docs when building in a path with spaces (if sphinx installed)
---

 Key: GEOT-3166
 URL: http://jira.codehaus.org/browse/GEOT-3166
 Project: GeoTools
  Issue Type: Bug
  Components: doc
Reporter: Ben Caradoc-Davies


Yes, docs breaks the build!

If sphinx is available, docs are built. Build fails if building in a path with 
spaces, presumably because of unquoted property substitution.

{code}
[INFO] [antrun:run {execution: compile}]
[INFO] Executing tasks

build:

sphinx:
 [exec] Error: Cannot find source directory.
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: The following error occurred while 
executing this line:
/home/car605/geoserver/src with spaces/geotools-trunk/docs/build.xml:13: The 
following error occurred while executing this line:
/home/car605/geoserver/src with spaces/geotools-trunk/docs/build.xml:28: exec 
returned: 1
{code}

In build.xml, what happens if ${build.directory} contains spaces?
{code}

{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3146) Example online fixtures generated by jdbc-postgis / jdbc-oracle have wrong key for password

[Ben Caradoc-Davies (JIRA)]

Example online fixtures generated by jdbc-postgis / jdbc-oracle have wrong key 
for password
---

 Key: GEOT-3146
 URL: http://jira.codehaus.org/browse/GEOT-3146
 Project: GeoTools
  Issue Type: Bug
  Components: data oraclespatial, data postgis
Reporter: Ben Caradoc-Davies
Assignee: Justin Deoliveira


Online test fixture generation code for jdbc-oracle and jdbc-postgis creates 
example fixtures that have a key "password" in the properties file. Using 
fixture configuration files based on these causes 
{Oracle,Postgis}NGDataStoreFactoryTest to fail because they expect 
org.geotools.jdbc.JDBCDataStoreFactory.PASSWD.key ("passwd") as the key in the 
properties files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3143) FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper() that is not also a FeatureType

[Ben Caradoc-Davies (JIRA)]

FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper() 
that is not also a FeatureType
-

 Key: GEOT-3143
 URL: http://jira.codehaus.org/browse/GEOT-3143
 Project: GeoTools
  Issue Type: Bug
  Components: core main
Affects Versions: 2.7-M0, 2.6.4, 2.6.5, 2.7-M1
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
 Fix For: 2.6.5, 2.7-M1


FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper() 
that is not also a FeatureType. This is a simple oversight that caused by 
depending on builders that do not set non-features as super.

Discussion:
http://osgeo-org.1803224.n2.nabble.com/Issue-in-2-6-4-FeatureTypes-getAncestors-td5185387.html

{code}
 Original Message 
Subject: [Geotools-gt2-users] Issue in 2.6.4 FeatureTypes.getAncestors(...)
Date: Wed, 16 Jun 2010 15:52:58 +0800
From: Thorsten Reitz 
To: geotools-gt2-us...@lists.sourceforge.net

Hi GeoTools team,

I would have directly put that on the JIRA, but am not sure where to
register:

In GeoTools 2.6.4, there is an issue in FeatureTypes.getAncestors(...)
that will in some cases, specifically when a FeatureType's supertype is
not a FeatureType, but a ComplexType (as it is the case for the
AbstractFeatureType instance, for example, that GeoTools creates by
default) make the function loop indefinitely. This was resolved in 2.5.8
already. We'd suggest the following patch to the function:

public static List getAncestors(FeatureType featureType) {
  List ancestors = new ArrayList();
  AttributeType type = featureType;
  while (type.getSuper() != null) {
if (type.getSuper() instanceof FeatureType) {
  FeatureType superType = (FeatureType) featureType.getSuper();
  ancestors.add(superType);
}
type = type.getSuper();
  }
  return ancestors;
}

Kind regards,

Thorsten

-- 
Thorsten Reitz

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
{code}


{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

   

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3140) Build failure in AppSchemaConfigurationTest on Windows

[Ben Caradoc-Davies (JIRA)]

Build failure in AppSchemaConfigurationTest on Windows
--

 Key: GEOT-3140
 URL: http://jira.codehaus.org/browse/GEOT-3140
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.7-M1
 Environment: Windows
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies
Priority: Blocker
 Fix For: 2.6.5, 2.7-M1


{code}
 Original Message 
Subject: Re: AppSchemaConfigurationTest failure mystery?
Date: Tue, 15 Jun 2010 10:39:51 +0800
From: Jody Garnett
To: Caradoc-Davies, Ben (CESRE, Kensington) 
CC: Geotools-Devel list

Just verified on a windows machine with no local changes.
Jody

On 15/06/2010, at 12:35 PM, Ben Caradoc-Davies wrote:

> [Switched to the dev list]
> 
> Ooh, this might be a bad test. I assumed that the app-schema schema is first 
> in the list, as the schemas are now supposed to be sorted in dependency order 
> (app-schema -> GML -> XS) since Justin made it stable. But I do not know the 
> contract here, as it is undocumented.
> 
> Do you have any local changes?
> 
> Kind regards,
> Ben.
> 
> 
> 
> On 15/06/10 08:31, Jody Garnett wrote:
>> I am running into some app schema failures on my local machine trunk ... I 
>> notice Hudson is still up however? I am going to try building on another box 
>> and see what I can learn...
>> 
>> The test that is failing expects:
>> 
>> String schemaLocation = 
>> schemaIndex.getSchemas()[0].getSchemaLocation();
>> Assert.assertTrue(schemaLocation.startsWith("file:"));
>> Assert.assertTrue(schemaLocation.endsWith("cache-test.xsd"));
>> 
>> But the value of schemaLocation is:
>> 
>> file:/Users/jody/java/geotools/trunk/modules/extension/xsd/xsd-core/target/classes/org/geotools/xs/XMLSchema.xsd
>> 
>> 
>> ---
>> Test set: org.geotools.xml.AppSchemaConfigurationTest
>> ---
>> Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 6.349 sec<<< 
>>  FAILURE!
>> cache(org.geotools.xml.AppSchemaConfigurationTest)  Time elapsed: 3.657 
>> sec<<<  FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:47)
>> at junit.framework.Assert.assertTrue(Assert.java:20)
>> at junit.framework.Assert.assertTrue(Assert.java:27)
>> at 
>> org.geotools.xml.AppSchemaConfigurationTest.cache(AppSchemaConfigurationTest.java:132)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
>> at 
>> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
>> at 
>> org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
>> at 
>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
>> at 
>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
>> at 
>> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
>> at 
>> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>> at 
>> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>> at 
>> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>> at 
>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>> at 
>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at 
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>> at 
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at 
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>> at

[Geotools-devel] [jira] Created: (GEOT-3130) Add DataUtilities tests

[Ben Caradoc-Davies (JIRA)]

Add DataUtilities tests
---

 Key: GEOT-3130
 URL: http://jira.codehaus.org/browse/GEOT-3130
 Project: GeoTools
  Issue Type: Improvement
  Components: core main
Affects Versions: 2.6.5, 2.7-M1
Reporter: Ben Caradoc-Davies
Assignee: Jody Garnett
 Attachments: DataUtilitiesTest.patch

Add test coverage of collection factory method for List, and a 
length/size() sanity check, in response to a user list question.

Jody, please let me know if I can commit this.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3115) app-schema catalog lookup failure in a path with spaces

[Ben Caradoc-Davies (JIRA)]

app-schema catalog lookup failure in a path with spaces
---

 Key: GEOT-3115
 URL: http://jira.codehaus.org/browse/GEOT-3115
 Project: GeoTools
  Issue Type: Bug
  Components: data app-schema
Affects Versions: 2.7-M0, 2.6.5, 2.7-M1
Reporter: Ben Caradoc-Davies


Confirmed under Linux in Eclipse. Don't know why unit tests do not catch it in 
a path with spaces. Possibly because the testing environment has hygienically 
encoded all spaces in the catalog file URL.

 Original Message 
Subject: Re: [Geoserver-users] App-schema plugin tutorial files error
Date: Thu, 27 May 2010 02:18:52 +0800
From: babsip 
To: geoserver-us...@lists.sourceforge.net   


Hi Marco!

I don't know if you are still interested in this, but in case you are, I
think I found a solution. I had exactly the same problem (identical response
to a GetFeature-Request). Additionally, I found this error in the logfile:

2010-05-26 16:53:36,726 WARN [complex.config] - Exception resolving null
java.net.URISyntaxException: Illegal character in path at index 31:
file:/C:/ProgrammeBab/GeoServer
2.0.1/data_dir/schemas/geosciml/2.0/xsd/geosciml.xsd

These 2 links helped me find the solution:

http://blog.gmane.org/gmane.comp.gis.geoserver.user/month=20090801
http://blog.gmane.org/gmane.comp.gis.geoserver.user/month=20090801 
 http://jira.codehaus.org/browse/GEOT-2644 
http://jira.codehaus.org/browse/GEOT-2644 

The bottom line is: the path where the XSD files are located must not
contain blanks! Unfortunately, when you install GeoServer 2.0.1, it
automatically creates an installation folder with a blank ("GeoServer
2.0.1"). So I re-installed GeoServer in a path without a blank, and it
worked! Hooray! (Took me nearly a day to figure this out...)

Kind Regards
Barbara

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3112) gml3 unit test failures in Eclipse caused by EPSG versioning support

[Ben Caradoc-Davies (JIRA)]

gml3 unit test failures in Eclipse caused by EPSG versioning support


 Key: GEOT-3112
 URL: http://jira.codehaus.org/browse/GEOT-3112
 Project: GeoTools
  Issue Type: Bug
  Components: core referencing, ext xml-xsd
Reporter: Ben Caradoc-Davies


Two gt-xsd-gml3 unit tests fail in Eclipse only. The tests are 
EnvelopeTypeBindingTest and PointTypeBindingTest. The failures are the same, 
and appear as an incorrect srsName in an encoded geometry type. The underlying 
cause appears to be support for versioning of EPSG codes. Because of its 
different dependency model, Eclipse gets a gt-epsk-wkt test dependency that 
maven does not, and so gets a CRSAuthorityFactory implementation not used in 
maven tests (seeing this in maven requires sprinkling System.out breadcrumbs in 
the code). The EPSG versioning support seems to give the dodgy gt-epsg-wkt 
EPSGCRSAuthorityFactory priority over the production CRSAuthorityFactory 
implementation that ends up being used by maven tests.

Commenting out line 306 of URN_AuthorityFactory [the "new 
AllAuthoritiesFactory(hints)," line in createVersionedFactory()] causes the 
gt-xsd-gml3 unit tests to pass! I suspect this disables versioning support. I 
do not know enough about referencing to fix this properly. The referencing 
module is ... er ... full-featured.

{code}
junit.framework.ComparisonFailure: null 
expected:<[urn:x-ogc:def:crs:EPSG:]4326> but 
was:<[http://www.opengis.net/gml/srs/epsg.xml#]4326>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
org.geotools.gml3.bindings.EnvelopeTypeBindingTest.testEncode(EnvelopeTypeBindingTest.java:42)
{code}

{code}
junit.framework.ComparisonFailure: null 
expected:<[urn:x-ogc:def:crs:EPSG:]4326> but 
was:<[http://www.opengis.net/gml/srs/epsg.xml#]4326>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
org.geotools.gml3.bindings.PointTypeBindingTest.testEncode(PointTypeBindingTest.java:46)
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3110) OnlineTestSupport broken by GEOT-1981 changes

[Ben Caradoc-Davies (JIRA)]

OnlineTestSupport broken by GEOT-1981 changes
-

 Key: GEOT-3110
 URL: http://jira.codehaus.org/browse/GEOT-3110
 Project: GeoTools
  Issue Type: Bug
Reporter: Ben Caradoc-Davies
Assignee: Ben Caradoc-Davies


The changes in GEOT-1981 broke OnlineTestSupport, because JUnit 4 never calls 
run(). Guess I should have written that OnlineTestSupportTest after all.  ;-)

A little refactoring is required, to expose Justin's new functionality to the 
delegate used in the JUnit4 adapter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [jira] Created: (GEOT-3109) Intermittent build failure in H2DataStoreFactoryTest.testTCP() cause by race condition

[Ben Caradoc-Davies (JIRA)]

Intermittent build failure in H2DataStoreFactoryTest.testTCP() cause by race 
condition
--

 Key: GEOT-3109
 URL: http://jira.codehaus.org/browse/GEOT-3109
 Project: GeoTools
  Issue Type: Bug
  Components: data h2
Affects Versions: 2.6.5, 2.7-M0
Reporter: Ben Caradoc-Davies


H2DataStoreFactoryTest.testTCP() can fail if there is another 
H2DataStoreFactoryTest.testTCP() running concurrently. In this case, 
H2DataStoreFactoryTest.testTCP() failed on 2.6.x when it was unexpectedly able 
to connect to a server before it has started one. To what server did it 
connect? The server started by H2DataStoreFactoryTest.testTCP() for trunk, 
which had already passed the first check and started its own server.

Unit tests that obtain exclusive access to unique system resources such as 
network sockets will be vulnerable to this kind of failure.

{code}
---
Test set: org.geotools.data.h2.H2DataStoreFactoryTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.131 sec <<< 
FAILURE!
testTCP(org.geotools.data.h2.H2DataStoreFactoryTest)  Time elapsed: 0.128 sec  
<<< FAILURE!
junit.framework.AssertionFailedError: Should not have made a connection.
at junit.framework.Assert.fail(Assert.java:47)
at 
org.geotools.data.h2.H2DataStoreFactoryTest.testTCP(H2DataStoreFactoryTest.java:62)
{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--

___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel