[Geotools-devel] [JIRA] (GEOT-5741) Upgrade PostgreSQL JDBC driver to 42.1.1

2017-05-29 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5741  
 
 
  Upgrade PostgreSQL JDBC driver to 42.1.1   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 18-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 jdbc-postgis plugin  
 
 
Created: 
 30/May/17 5:16 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.1010.2#100044-sha1:0b22eb5)

[Geotools-devel] [JIRA] (GEOT-5740) Move DataUtilities URL methods to new Urls class in gt-metadata

2017-05-29 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5740  
 
 
  Move DataUtilities URL methods to new Urls class in gt-metadata   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 18-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 main, metadata, referencing  
 
 
Created: 
 30/May/17 2:21 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 gt-main DataUtilities URL methods are duplicated in gt-referencing because the latter has no access to methods in gt-main as it depends on gt-referencing. The methods in gt-referencing have no unit test coverage. To fix this situation, permit gt-referencing access to these methods, and clean up this catch-all class into something more specific, this improvement will move DataUtilities URL methods to a new class org.geotools.util.Urls in gt-metadata. This improvement will remove all duplication and improve test coverage. fileToURL will be renamed fileToUrl for consistency. Existing DataUtilities URL methods will be retained, @deprecated, and implemented using Uris, so this change is fully backwards compatible. The solitary unit test for a URL method will be moved to org.geotools.util.UtilsTest in gt-metadata.

[Geotools-devel] [JIRA] (GEOT-5739) gt-referencing DataUtilities should be package-private

2017-05-28 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5739  
 
 
  gt-referencing DataUtilities should be package-private   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 16.3, 18-beta, 17.1, 16.4, 17.2  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 referencing  
 
 
Created: 
 29/May/17 7:04 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 gt-referencing contains a cut-down version of DataUtilities with only fileToURL and urlToFile; it cannot use the proper implementation in gt-main because this would introduce a cyclic Maven dependency. This copy becomes stale because it does not receive the maintenance applied to DataUtilities in gt-main. This class should have been package-private, but because it is public, it has been used in several other places where the official gt-main version should be used instead (courtesy of Eclipse suggestions). The fix is to change this class to package-private to hide it from unintended users and to fix all those classes outside gt-referencing that use it to use the official gt-main class instead.

[Geotools-devel] [JIRA] (GEOT-5738) DataUtilities.urlToFile does not percent-unescape URLs with no slash after file:

2017-05-28 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5738  
 
 
  DataUtilities.urlToFile does not percent-unescape URLs with no slash after file:   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 16.3, 18-beta, 17.1, 16.4, 17.2  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 main  
 
 
Created: 
 29/May/17 6:41 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 DataUtilities.urlToFile will percent-unencode file:///file%20caf%C3%A9 and file:/file%20caf%C3%A9 but not file:file%20caf%C3%A9 for which the "%20" is unencoded to a space but the "%C3%A9" is not (should be unencoded to "é").  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5737) DataUtilities.fileToUrl does not percent-encode non-ASCII characters

2017-05-28 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5737  
 
 
  DataUtilities.fileToUrl does not percent-encode non-ASCII characters   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 16.3, 18-beta, 17.1, 16.4, 17.2  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 main  
 
 
Created: 
 29/May/17 5:58 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Good grief. The Java standard library never fails to disappoint. After the File.toURL() debacle, you think the maintainers of the standard library would have learned, but no, they recommend File.toURI().toURL() as a workaround, when the implementation of URI.toURL() uses URI.toString() not URI.toASCIIString(), resulting in the failure to percent-encode non-ASCII characters (i.e. those above 0x7f). (new File("file café")).toURI().toURL().toString() -> String ends with file%20café Note the presence of "é", which is not permitted in a URI. Compare with: (new File("file café")).toURI().toASCIIString() -> String ends with file%20caf%C3%A9 Impact on GeoTools is that DataUtilities.fileToUrl, which uses File.toURI().toURL() , does not percent-encode non-ASCII characters. The solution is to use File.toURI().toASCIIString().

[Geotools-devel] [JIRA] (GEOT-5729) SchemaCache autoconfiguration fails for empty GeoServer data directory

2017-05-15 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5729  
 
 
  SchemaCache autoconfiguration fails for empty GeoServer data directory   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 18-beta, 17.1, 16.4  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 xml  
 
 
Created: 
 16/May/17 4:26 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 SchemaCache.buildAutomaticallyConfiguredUsingFileUrl fails when used on an empty GeoServer data directory because the heuristic in isSuitableDirectoryToContainCache is too strict. Only the workspaces directory is present when GeoServer is started with an empty directory (except the workspaces directory required to define the app-schema data store). A warning should be logged if unable to build a cache and automaticConfigurationEnabled is true.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5709) Support coverage property SourceUrl

2017-04-19 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5709  
 
 
  Support coverage property SourceUrl   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 20/Apr/17 3:58 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Add a coverage property SourceUrl for NetCDF and ImageMosaic readers that can be discovered by NetCDFOutputManager in GeoServer gs-netcdf-out. The property is a URL for the source of the coverage. See: [GSIP 158 - NetCDF Output Support for Variable Attributes and Extra Variables](https://github.com/geoserver/geoserver/wiki/GSIP-158).  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geotools-devel] [JIRA] (GEOT-5696) Feature chaining on xs:anyType encodes superfluous toString text

2017-04-08 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5696  
 
 
  Feature chaining on xs:anyType encodes superfluous toString text   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 16.3, 18-beta, 17.1  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 app-schema plugin  
 
 
Created: 
 09/Apr/17 2:26 AM  
 
 
Environment: 
 The output of GeoServer gs-app-schema-test FeatureChainingWfsTest.testAnyTypeAndAnyElement shows that feature chaining on xs:anyType encodes superfluous feature toString as text, in addition to the correct encoding of the feature: 

 

[...]
[FeatureImpl:MappedFeatureMappedFeatureType id=mf1=[ComplexAttributeImpl:nameCodeType=[AttributeImpl:simpleContentstring=GUNTHORPE FORMATION], ComplexAttributeImpl:positionalAccuracyCGI_NumericValuePropertyType=[ComplexAttributeImpl:CGI_NumericValueCGI_NumericValueType=[ComplexAttributeImpl:principalValueMeasureType=[AttributeImpl:simpleContentdouble=200.0]]], GeometryAttributeImpl:shapeGeometryPropertyType crs=GEOGCS[WGS 84, 
  DATUM[World Geodetic System 1984, 
SPHEROID[WGS 84, 6378137.0, 298.257223563, AUTHORITY[EPSG,7030]], 
AUTHORITY[EPSG,6326]], 
  PRIMEM[Greenwich, 0.0, AUTHORITY[EPSG,8901]], 
  UNIT[degree, 0.017453292519943295], 
  AXIS[Geodetic latitude, NORTH], 
  AXIS[Geodetic longitude, EAST], 
  AUTHORITY[EPSG,4326]]=POLYGON ((52.5 -1.2, 52.6 -1.2, 52.6 -1.1, 52.5 -1.1, 52.5 -1.2)), ComplexAttributeImpl:samplingFrameSpatiallyExtensiveSamplingFeaturePropertyType=[], ComplexAttributeImpl:specificationGeologicFeaturePropertyType=[FeatureImpl:GeologicUnitGeologicUnitType id=gu.25699=[ComplexAttributeImpl:descriptionStringOrRefType=[AttributeImpl:simpleContentstring=Olivine basalt, tuff, microgabbro, minor sedimentary rocks], ComplexAttributeImpl:nameCodeType=[AttributeImpl:simpleContentstring=Yaugher Volcanic Group], ComplexAttributeImpl:nameCodeType=[AttributeImpl:simpleContentstring=-Py], ComplexAttributeImpl:observationMethodCGI_TermValuePropertyType=[ComplexAttributeImpl:CGI_TermValueCGI_TermValueType=[ComplexAttributeImpl:valueCodeWithAuthorityType=[AttributeImpl:simpleContentstring=urn:ogc:def:nil:OGC::missing]]], AttributeImpl:purposeDescriptionPurposeType=instance, ComplexAttributeImpl:geologicUnitTypeReferenceType=[],

[Geotools-devel] [JIRA] (GEOT-5675) Division by zero in NetCDFPolyphemusTest

2017-03-15 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5675  
 
 
  Division by zero in NetCDFPolyphemusTest   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 17-RC1, 18-beta  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 15/Mar/17 10:43 PM  
 
 
Environment: 
 NetCDFPolyphemusTest encounters and ignores a division by zero. This test appears to log and ignore most exceptions, so it is not really unit-testing anything. 

 
Mar 16, 2017 10:31:58 AM org.geotools.coverage.io.netcdf.NetCDFPolyphemusTest geoToolsReader
WARNING: / by zero
java.lang.ArithmeticException: / by zero
	at org.geotools.coverage.io.netcdf.NetCDFPolyphemusTest.geoToolsReader(NetCDFPolyphemusTest.java:201)
 

  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5564) Invalid CSS font-family causes LabelUnderlineTest to fail on OpenJDK

2016-11-04 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5564  
 
 
  Invalid CSS font-family causes LabelUnderlineTest to fail on OpenJDK   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 17-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 render  
 
 
Created: 
 05/Nov/16 4:39 AM  
 
 
Environment: 
 Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T05:41:47+13:00) Maven home: /home/ben/java/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.8.0-1-amd64", arch: "amd64", family: "unix"  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 An invalid CSS font-family in underlineStyle.sld causes LabelUnderlineTest to fail OpenJDK. Rendered output likely depends on local font fallback settings (i.e. whether Vera is an alias for Bitstream Vera Serif or Bitstream Vera Sans): 

 
Failed tests: 
  LabelUnderlineTest.testLabelsUnderline:76 Images are visibly different, found 10686 different pixels, against a threshold of 1200
You can add -Dorg.geotools.image.test.interactive=true to show a dialog comparing them (requires GUI support)
 

 I suspect that in underlineStyle.sld:

[Geotools-devel] [JIRA] (GEOT-5545) ImageMosaicEgrTest failures on OpenJDK

2016-10-16 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5545  
 
 
  ImageMosaicEgrTest failures on OpenJDK   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 17-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Attachments: 
 testAllImagesVector.png, testLeftRightOnTopVector.png, testRedCoversAllVector.png  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 16/Oct/16 10:58 PM  
 
 
Environment: 
 openjdk-8-jdk 8u102-b14.1-2 amd64 on Debian unstable. Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T05:41:47+13:00) Maven home: /home/ben/java/maven Java version: 1.8.0_102, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.7.0-1-amd64", arch: "amd64", family: "unix"  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Slight rendering differences cause three ImageMosaicEgrTest tests to fail on OpenJDK: 

 
Failed tests: 
ImageMosaicEgrTest.testRedCoversAllVector:228->testRedCoversAll:237->testOutputCoverage:348 Images are visibly different, found 113 different pixels, against a threshold of 0
You can add -Dorg.geotools.image.test.interactive=true to show a dialog

[Geotools-devel] [JIRA] (GEOT-5527) PostgreSQL 9.6 breaks ASC_OR_DESC for index

2016-09-25 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5527  
 
 
  PostgreSQL 9.6 breaks ASC_OR_DESC for index   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15.1, 16-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Attachments: 
 org.geotools.data.postgis.PostgisDataStoreOnlineTest.txt, org.geotools.data.postgis.PostgisPrimaryKeyOnlineTest.txt, org.geotools.data.postgis.ps.PostgisDataStoreOnlineTest.txt, org.geotools.data.postgis.ps.PostgisPrimaryKeyOnlineTest.txt  
 
 
Components: 
 jdbc-postgis plugin  
 
 
Created: 
 26/Sep/16 1:20 AM  
 
 
Environment: 
 postgresql-9.6 9.6~rc1-1+b1 / postgresql-9.6-postgis-2.3 2.3.0~rc1+dfsg-1~exp2 on debian unstable (with postgis from experimental)  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 gt-jdbc-postgis tests fail against PostgreSQL 9.6 because most columns of the pg_am table have been removed, causing tests to fail with org.postgresql.util.PSQLException: ERROR: column am.amcanorder does not exist (see attached logs). The fix is included in JDBC driver 9.4.1209 or later: https://github.com/pgjdbc/pgjdbc/pull/560 I propose that GeoTools master and 15.x upgrade to 9.4.121 (latest stable).

[Geotools-devel] [JIRA] (GEOT-5524) Incorrect detection of GRIB files with WMO header

2016-09-20 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5524  
 
 
  Incorrect detection of GRIB files with WMO header   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15.1, 16-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 netcdf  
 
 
Created: 
 21/Sep/16 4:22 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 NetCDFImageReaderSpi incorrectly assumes that GRIB files start with the bytes "GRIB". However, some GRIB files start with a World Meteorological Organization (WMO) header added by, for example, the US National Weather Service Telecommunications Gateway. For example, the existing test data weird.model in weird.zip stars with a WMO header for "KKCI", the "International Civil Aviation Organization (ICAO)-approved identifier of the office originating the product". The Center Identifiers List idetifies this office this as "KKCI - Aviation Weather Center, Kansas City, MO". NetCDFImageReaderSpi uses an undocumented system property NETCDF_FORCE_OPEN_CHECK to overcome this limitation by forcing a full NetcdfDataset.acquireDataset on all files, but this is problematic because this search is expensive and requires users to enable this behaviour; users may not know about this property, and may not know that their data file needs it. Furthermore, this property is applied to all (for example) GeoServer instances in the same JVM. The proposed solution is to instead emulate the behaviour of NetCDF-Java, which searches the first 16000 bytes for "GRIB". See: https://github.com/Unidata/thredds/blob/master/grib/src/main/java/ucar/nc2/grib/grib1/Grib1RecordScanner.java#L81 https://github.com/Unidata/thredds/blob/master/grib/src/main/java/ucar/nc2/grib/grib2/Grib2RecordScanner.java#L29 The file in question is already being opened and the additional

[Geotools-devel] [JIRA] (GEOT-5521) Support Azimuthal Equidistant projection

2016-09-14 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5521  
 
 
  Support Azimuthal Equidistant projection   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 15.2, 16-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Attachments: 
 ice-oblique-7m.png, ice-polar-5m.png  
 
 
Components: 
 referencing  
 
 
Created: 
 15/Sep/16 4:17 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Support the Azimuthal Equidistant projection. This implementation does not include the Guam or Micronesia variants. Attached GeoServer ice edge samples demonstrate output for the following projections (with lines in epsg.properties): (1) ice-polar-5m.png: North Polar Azimuthal Equidistant with central meridian at 0 degrees, with bounds +/-5e6 in projected coordinates: 

 
115=PROJCS["North Polar Azimuthal Equidistant", GEOGCS["WGS84", DATUM["WGS84", SPHEROID["WGS84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["degree", 0.017453292519943295]], PROJECTION["Azimuthal_Equidistant"], PARAMETER["longitude_of_center", 0], PARAMETER["latitude_of_center", 90], UNIT["metre", 1], AXIS["X", EAST], AXIS["Y", NORTH], AUTHORITY["EPSG", "115"]]
 

 (2) ice-oblique-7m.png: North American Oblique Azimuthal Equidistant centred on -106 degrees west and 54 degrees north, with

[Geotools-devel] [JIRA] (GEOT-5487) Cropped coverage with longitudes in (0, 360) can be rendered black

2016-08-12 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5487  
 
 
  Cropped coverage with longitudes in (0,360) can be rendered black   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15.2, 15.1, 16-beta, 16-M0  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 render  
 
 
Created: 
 13/Aug/16 5:18 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Continuous map wrapping envelope expansion combined with support for coverages with longitudes in (0,360) causes some cropped coverages to be rendered as black. The proposed solution is to make the additional envelopes added for continuous map wrapping be a translation of the original envelope, without unnecessary envelope expansion to +180 or -180.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5469) Support multivalued xlink:href ClientProperty on properties with empty content model

2016-07-23 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5469  
 
 
  Support multivalued xlink:href ClientProperty on properties with empty content model   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 app-schema plugin  
 
 
Created: 
 24/Jul/16 5:51 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 The app-schema plugin ignores multivalued ClientProperty on properties that have an empty content model (i.e. do not have a nested complex type), even when a denormalised feature chaining source is provided, because there is no nested feature or complex property to store state.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geotools-devel] [JIRA] (GEOT-5452) Add rotated pole GRIB2 tests

2016-06-23 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5452  
 
 
  Add rotated pole GRIB2 tests   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Attachments: 
 cosmo-eu.grib2, cosmo-eu-grib2.txt, rap-native.grib2, rap-native-grib2.txt  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 24/Jun/16 2:45 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Add tests that rotated pole GRIB2 files are read with the expected projection parameters. The tiny synthetic GRIB2 files used in these tests (240 and 438 byes) were created by hand from original RAP native and COSMO EU files each over 100 MB in size. I have attached notes on the procedure to create these files *.txt files. In a nutshell: 
 
grab one message with wgrib2 in ieee data format 
 
 
create synthetic data with python 
 
 
splice everything together with head and cat 
 
 
use a hex editor (ghex) with python hex calculations to update all the sizes and dimensions in the header; note that all values in the GRIB2 headers are big-endian so check that box in ghex

[Geotools-devel] [JIRA] (GEOT-5434) Upgrade to NetCDF-Java 4.6.6

2016-06-03 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5434  
 
 
  Upgrade to NetCDF-Java 4.6.6   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 15.1, 16-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 04/Jun/16 7:02 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Upgrade to NetCDF-Java 4.6.6 to get new features, including support for GRIB2 files with rotated pole projection such as the native grid for NOAA's Rapid Refresh (RAP) weather forecast model: http://rapidrefresh.noaa.gov/ See: https://github.com/bencaradocdavies/geoserver/wiki/RAP-Native-Grid https://github.com/bencaradocdavies/geoserver/wiki/RAP-Native-Grid-Single-File https://github.com/bencaradocdavies/geoserver/wiki/RAP-Native-Grid-ImageMosaic  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5428) Support NetCDF rotated pole projection

2016-05-31 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5428  
 
 
  Support NetCDF rotated pole projection   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 01/Jun/16 6:47 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.25.1#10-sha1:fa89b69)

[Geotools-devel] [JIRA] (GEOT-5406) Ignore NetCDF grid_mapping_name that is present but unsupported

2016-04-22 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5406  
 
 
  Ignore NetCDF grid_mapping_name that is present but unsupported   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 23/Apr/16 12:01 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 The current behaviour of NetCDFProjection when encountering an unsupported NetCDF grid_mapping_name is to throw a NullPointerException. This fix changes the behaviour to instead log a message and return null, consistent with the behaviour earlier in the method for a missing grid_mapping_name.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geotools-devel] [JIRA] (GEOT-5396) Incorrect General Oblique transform

2016-04-01 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5396  
 
 
  Incorrect General Oblique transform   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-beta2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 referencing  
 
 
Created: 
 02/Apr/16 2:10 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 See discussion: http://osgeo-org.1560.x6.nabble.com/Problem-with-General-Oblique-transform-latitude-td5257089.html Implementation: https://github.com/geotools/geotools/blob/master/modules/library/referencing/src/main/java/org/geotools/referencing/operation/projection/GeneralOblique.java Original feature Jira issue: GEOT-5190 General Oblique Transform for Rotated Pole Coordinates https://osgeo-org.atlassian.net/browse/GEOT-5190 While attempting use the General Oblique transform, I have encountered a  discrepancy between the latitude of the origin and the projected latitude. In the test script: https://github.com/geotools/geotools/blob/master/modules/library/referencing/src/test/resources/org/geotools/referencing/test-data/scripts/GeneralOblique.txt The test General Oblique coordinate system is specified with: 

 
PARAMETER["central_meridian", 19.3],
PARAMETER["latitude_of_origin", 37.5]
 

 The following assertion is made: 

 
source pt = (0, 0)
target pt = (19.30,52.50)

[Geotools-devel] [JIRA] (GEOT-5395) Build failure in gt-grib with -Dnetcdf.version 4.6.4 or later

2016-04-01 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5395  
 
 
  Build failure in gt-grib with -Dnetcdf.version 4.6.4 or later   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-beta2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 02/Apr/16 1:52 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 GeoTools master currently uses 4.6.2. If netcdf.version is upgraded to 4.6.4 or later, the build fails. For example, in modules/plugin/coverage-multidim/grib running: 

 
mvn -nsu -Dnetcdf.version=4.6.4 test
 

 results in: 

 
Failed tests:  GribTest.testGribImageWithLargeBBOX:306->Assert.assertNotNull:631->Assert.assertNotNull:621->Assert.assertTrue:41->Assert.fail:86 null  GribTest.testGribImage:199->testGribFile:233->Assert.assertNotNull:631->Assert.assertNotNull:621->Assert.assertTrue:41->Assert.fail:86 null  GribUtilitiesTest>GribTest.testGribImageWithLargeBBOX:306->Assert.assertNotNull:631->Assert.assertNotNull:621->Assert.assertTrue:41->Assert.fail:86 null  GribUtilitiesTest>GribTest.testGribImage:199->GribTest.testGribFile:233->Assert.assertNotNull:631->Assert.assertNotNull:621->Assert.assertTrue:41->Assert.fail:86 null
 

 The build passes

[Geotools-devel] [JIRA] (GEOT-5370) Build failure in xmlcodegen

2016-02-22 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5370  
 
 
  Build failure in xmlcodegen   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-beta  
 
 
Assignee: 
 Jody Garnett [Administrator]  
 
 
Components: 
 main  
 
 
Created: 
 22/Feb/16 11:55 PM  
 
 
Environment: 
 Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T05:41:47+13:00) Maven home: /home/ben/java/maven Java version: 1.8.0_72-internal, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-1-amd64", arch: "amd64", family: "unix"  
 
 
Priority: 
  Highest  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 After the merge of GEOT-5367 changes on master, the build fails with Maven 3.3.9 in xmlcodegen. The failure can be fixed but reverting these two commits: Rename enum GroupByInternalVisitor to Aggregate https://github.com/geotools/geotools/commit/917d43efca4a920ec3153304d644883101ca3921 GEOT-5367 Add a group by visitor https://github.com/geotools/geotools/commit/64431c658b14c0ddb9a05c3e1b3205d5be5627c2 To reproduce and test the reversion, run: 

 
mvn -o -Dall -DskipTests -pl modules/library/main,modules/library/jdbc,modules/plugin/jdbc/jdbc-postgis,modules/unsupported/process-feature,build/maven/xmlcodegen clean install

[Geotools-devel] [JIRA] (GEOT-5361) Complex feature WFS client breaks GeoServer external WFS data store

2016-02-11 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5361  
 
 
  Complex feature WFS client breaks GeoServer external WFS data store   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-M0, 14.2, 14.1, 14.0, 14-RC1, 14-beta, 14-M1, 14-M0, 14.3, 15-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 wfs-ng  
 
 
Created: 
 11/Feb/16 11:26 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 http://osgeo-org.1560.x6.nabble.com/Adding-a-remote-WFS-data-store-in-2-8-1-and-2-8-2-doesn-t-work-td5250121.html The complex feature WFS client appears to be interfering with the simple feature WFS client. There appears to be nothing that prevents the complex feature WFS client provider from advertising that it canProcess a data store configuration that was intended for the simple feature client. This can cause GeoServer external WFS data stores to fail (depending on SPI order?). Solution is to disable the complex feature WFS client for GML compliance level < 1.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5356) Add GetStyles support to gt-wms

2016-02-08 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5356  
 
 
  Add GetStyles support to gt-wms   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 15-beta  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 wms extension  
 
 
Created: 
 09/Feb/16 1:07 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 See: https://github.com/geotools/geotools/pull/1055  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geotools-devel] [JIRA] (GEOT-5343) Support matchCase on PropertyIsLike in Filter 2.0

2016-01-22 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5343  
 
 
  Support matchCase on PropertyIsLike in Filter 2.0   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-beta  
 
 
Assignee: 
 Ben Caradoc-Davies [Administrator]  
 
 
Components: 
 xsd extensions  
 
 
Created: 
 23/Jan/16 4:26 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Waiting on OGC to update Filter 2.0 schemas to add matchCase on PropertyIsLike as was done in the Filter 1.1.3 schemas:  Forwarded Message  Subject: Re: [Geoserver-users] Exception with Filter 2.0 and matchCase="false" on PropertyIsLike Date: Sat, 23 Jan 2016 16:14:11 +1300 From: Ben Caradoc-Davies To: Nhan Vo CC: geoserver-us...@lists.sourceforge.net Nhan Vo, I have contacted the chair of the OGC WFS/FES standard technical committee, who has confirmed that the lack of matchCase on PropertyIsLike in the Filter 2.0.2 schemas and standard is a known issue. He is following up with OGC. When the Filter 2.0 schemas are updated to include matchCase on PropertyIsLike, we just need to apply this change to the schemas in gt-xsd-fes and GeoServer will start permitting matchCase on PropertyIsLike. We should also add test coverage for matchCase to gs-wfs Filter_2_0_0_KvpParserTest, once this new test is merged and matchCase is in the Filter 2.0 schemas. Test coverage will prevent any future regressions. Kind regards, Ben. On 22/01/16 01:23, Ben Caradoc-Davies wrote: > I looked a little deeper and matchCase="false" should be supported on > PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated > GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support: > http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html >

[Geotools-devel] [JIRA] (GEOT-5319) Build failure in FileWrapperResourceTheoryTest.theoryAddingFileToDirectoryAddsResource on Windows

2015-12-02 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ben Caradoc-Davies [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5319  
 
 
  Build failure in FileWrapperResourceTheoryTest.theoryAddingFileToDirectoryAddsResource on Windows   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Niels Charlier  
 
 
Created: 
 03/Dec/15 12:53 AM  
 
 
Environment: 
 Windows GeoSolutions Jenkins  
 
 
Priority: 
  Highest  
 
 
Reporter: 
 Ben Caradoc-Davies [Administrator]  
 

  
 
 
 
 

 
 Niels, after your most recent ResourceStore changes, we see a failure in FileWrapperResourceTheoryTest.theoryAddingFileToDirectoryAddsResource on Windows. It looks like a fully qualified filename starting with with C:\Windows is being appended to another filename. What should happen? http://winbuild.geo-solutions.it/jenkins/job/GeoServer-Master/org.geoserver$gs-platform/2428/testReport/junit/org.geoserver.platform.resource/FileWrapperResourceTheoryTest/theoryAddingFileToDirectoryAddsResource/ 

 
Expected: is resource that is defined
 but: was 
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at org.junit.Assert.assertThat(Assert.java:832)
	at org.geoserver.platform.resource.ResourceTheoryTest.theoryAddingFileToDirectoryAddsResource(ResourceTheoryTest.java:452)

[Geotools-devel] [JIRA] (GEOT-5308) app-schema Vocab function does not honour relative vocabulary properties file path

2015-11-17 Thread Ben Caradoc-Davies [Administrator] (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ben Caradoc-Davies [Administrator] created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5308 
 
 
 
  app-schema Vocab function does not honour relative vocabulary properties file path  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14.0, 13.3, 15-beta 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 app-schema plugin 
 
 
 

Created:
 

 17/Nov/15 11:11 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Ben Caradoc-Davies [Administrator] 
 
 
 
 
 
 
 
 
 
 
The app-schema Vocab CQL function is documented as supporting a vocabulary properties file "URI" that can be absolute or relative to the mapping file, but only an absolute file path works. See: http://docs.geoserver.org/latest/en/user/data/app-schema/cql-functions.html 
Vocabulary properties file paths relative to the containing mapping file should be supported if possible. In any case, the documentation must match the implementation. 
--- Forwarded Message  Subject: RE: [Geoserver-users] app-schema mapping.properties file location Date: Tue, 17 Nov 2015 21:59:22 + From: Bruce Simons To: Ben Caradoc-Davies CC: geoserver-us...@lists.sourceforge.net, Jody Garnett 
Thanks Ben, Putting the absolute path worked without the chmod:  om:observedProperty  xlink:href Vocab(METHOD, 'C:\Program Files\Apache Software Foundation\Tomcat