Re: [Geotools-devel] GeoPackage Raster Mosaic tile order

[Torben Barsballe]

There is no easy automated way of detecting existing files, since the files
are technically valid, the tiles are just in the wrong order. Existing
files will be quite apparent from visual inspection however.

How many existing files are out there depends how many people have been
using the GeoServer GeoPackage WMS output format, as that is the only way
to generate these files.

Torben

On Thu, Apr 27, 2017 at 1:39 PM, Jody Garnett 
wrote:

> Any good idea on how to detect and fix existing files? How many existing
> files will be out there?
>
> --
> Jody Garnett
>
> On 26 April 2017 at 13:17, Torben Barsballe 
> wrote:
>
>> I've discovered some interesting behaviour in the GeoPackage Raster
>> Mosaic implementation over the last few days.
>>
>> I tried viewing a GeoPackage generated from the GeoServer GeoPackage WMS
>> output format in QGIS, and observed that tile order is reversed along the
>> y-axis.
>>
>> QGIS used GDAL for parsing GeoPackages. After running this issue by the
>> GDAL team, I was directed to this line of the OGC GeoPackage spec
>> :
>>
>> The tile coordinate (0,0) always refers to the tile in the upper left
>>> corner of the tile matrix at any zoom level, regardless of the actual
>>> availability of that tile
>>
>>
>> Adding some test cases to the GeoTools GeoPackage plugin, I can confirm
>> that GeoTools gets this order wrong. Among other things, this means that
>> GeoTools / GeoServer will incorrectly read valid GeoPackage files. A fix
>> can be found here: https://github.com/geotools/geotools/pull/1567
>>
>> Moving along to GeoServer, it appears there are similar problems with the
>> GeoServer GeoPackage Community module, namely in
>> the GeoPackageGetMapOutputFormat.
>>
>> I believe I have a fix, but am currently being slowed down by the fact
>> that the GeoPackage module tests don't seem to be passing on master.
>>
>>
>> *This issue does bring up a problem*: Because GeoTools / GeoServer is
>> consistently wrong (a GeoPackage generated by GeoServer will be read in as
>> "correct"), this bug fix could cause problems for anyone who has solely
>> been using GeoPackage Rasters that were generated by GeoTools / GeoServer.
>>
>> For more details:
>> https://osgeo-org.atlassian.net/browse/GEOT-5715
>> https://osgeo-org.atlassian.net/browse/GEOS-8112
>> https://trac.osgeo.org/gdal/ticket/6871
>>
>> Torben
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Support Optional Milliseconds in ISO8601 Dates

[Billy Newman]

Jody,

I am, in fact I did ;)

https://github.com/geotools/geotools/pull/1566 


-Billy

> On Apr 27, 2017, at 2:37 PM, Jody Garnett  wrote:
> 
> I am fine using Java 8 date time formatter. Are you in position to make a 
> pull request Billy?
> 
> --
> Jody Garnett
> 
> On 25 April 2017 at 18:26, Billy Newman  > wrote:
> I am looking at the possibility to add support for optional milliseconds in 
> an ISO8601 date string for the mongodb data module.  Currently the module 
> defines this SimpleDateFormatter:
> 
> static final SimpleDateFormat ISO8601_SDF = new 
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSXXX");
> 
> 
> Which works great if you are always parsing an ISO 8601 date string that 
> contains milliseconds.  However that formatter will not parse a date string 
> with milliseconds.
> 
> I have a couple questions:
> 
> 1.  Parsing an ISO 8601 string seems like a pretty common use case across 
> many of the geotools modules.  Does something already exist that does this?  
> I apologize if it does, I looked through the repo and couldn’t find anything.
> 
> 2. What are the thoughts on bringing in Java 8’s DateTimeFormatter?  Looks 
> like min version of Java is 8 so I don’t think there are any problems there.  
> I only ask because I don’t see DateTimeFormatter being used anywhere else.  
> Using DateTimeFormatter a format string can contain optional portions (e.g. 
> optional milliseconds):
> 
> DateTimeFormatter.ofPattern(“-MM-dd’T’HH:mm:ss[.SSS]XXX”), or even better 
> the built in DateTimeFormatter.ISO_DATE_TIME.
> 
> 
> -Billy
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> 
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/geotools-devel 
> 
> 
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoPackage Raster Mosaic tile order

[Jody Garnett]

Any good idea on how to detect and fix existing files? How many existing
files will be out there?

--
Jody Garnett

On 26 April 2017 at 13:17, Torben Barsballe 
wrote:

> I've discovered some interesting behaviour in the GeoPackage Raster Mosaic
> implementation over the last few days.
>
> I tried viewing a GeoPackage generated from the GeoServer GeoPackage WMS
> output format in QGIS, and observed that tile order is reversed along the
> y-axis.
>
> QGIS used GDAL for parsing GeoPackages. After running this issue by the
> GDAL team, I was directed to this line of the OGC GeoPackage spec
> :
>
> The tile coordinate (0,0) always refers to the tile in the upper left
>> corner of the tile matrix at any zoom level, regardless of the actual
>> availability of that tile
>
>
> Adding some test cases to the GeoTools GeoPackage plugin, I can confirm
> that GeoTools gets this order wrong. Among other things, this means that
> GeoTools / GeoServer will incorrectly read valid GeoPackage files. A fix
> can be found here: https://github.com/geotools/geotools/pull/1567
>
> Moving along to GeoServer, it appears there are similar problems with the
> GeoServer GeoPackage Community module, namely in
> the GeoPackageGetMapOutputFormat.
>
> I believe I have a fix, but am currently being slowed down by the fact
> that the GeoPackage module tests don't seem to be passing on master.
>
>
> *This issue does bring up a problem*: Because GeoTools / GeoServer is
> consistently wrong (a GeoPackage generated by GeoServer will be read in as
> "correct"), this bug fix could cause problems for anyone who has solely
> been using GeoPackage Rasters that were generated by GeoTools / GeoServer.
>
> For more details:
> https://osgeo-org.atlassian.net/browse/GEOT-5715
> https://osgeo-org.atlassian.net/browse/GEOS-8112
> https://trac.osgeo.org/gdal/ticket/6871
>
> Torben
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Support Optional Milliseconds in ISO8601 Dates

[Jody Garnett]

I am fine using Java 8 date time formatter. Are you in position to make a
pull request Billy?

--
Jody Garnett

On 25 April 2017 at 18:26, Billy Newman  wrote:

> I am looking at the possibility to add support for optional milliseconds
> in an ISO8601 date string for the mongodb data module.  Currently the
> module defines this SimpleDateFormatter:
>
> static final SimpleDateFormat ISO8601_SDF = new SimpleDateFormat("
> -MM-dd'T'HH:mm:ss.SSSXXX");
>
> Which works great if you are always parsing an ISO 8601 date string that
> contains milliseconds.  However that formatter will not parse a date string
> with milliseconds.
>
> I have a couple questions:
>
> 1.  Parsing an ISO 8601 string seems like a pretty common use case across
> many of the geotools modules.  Does something already exist that does
> this?  I apologize if it does, I looked through the repo and couldn’t find
> anything.
>
> 2. What are the thoughts on bringing in Java 8’s DateTimeFormatter?  Looks
> like min version of Java is 8 so I don’t think there are any problems
> there.  I only ask because I don’t see DateTimeFormatter being used
> anywhere else.  Using DateTimeFormatter a format string can contain
> optional portions (e.g. optional milliseconds):
>
> DateTimeFormatter.ofPattern(“-MM-dd’T’HH:mm:ss[.SSS]XXX”), or even
> better the built in DateTimeFormatter.ISO_DATE_TIME.
>
>
> -Billy
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Introduction

[John Schulz]

Hi all,
My name is John Schulz and I'm a new apprentice developer at
Boundless, and I am working with Dave Vick. I've met some of you
already and look forward to working with you all. I was hoping to be
set up on the JIRA development team so I can get some experience with
the bug stomp tomorrow.

Cheers!

-- 
John Schulz

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] GeoPackage Raster Mosaic tile order

[Torben Barsballe]

Hi Ben,

Thanks for tracking down all of this!

I've updated my PR 
accordingly, and tests now pass locally. Swapped SEVEN and FIFTEEN for
LAKES and STREAMS to get the GeoPackage feature tests working.

Torben

On Wed, Apr 26, 2017 at 10:47 PM, Ben Caradoc-Davies 
wrote:

> Torben,
>
> the underlying problem for GeoPackageGetFeatureOutputFormatTest is that
> SystemTestData.SEVEN has two geometry columns and this violates the
> GeoPackage spec:
>
> "Requirement 30: A feature table SHALL have only one geometry column."
> https://github.com/opengeospatial/geopackage/blob/master/
> spec/2a_features.adoc
>
> The SQL constraint matches the GeoPackage spec.
>
> Kind regards,
> Ben.
>
> On 27/04/17 15:05, Ben Caradoc-Davies wrote:
>
>> git blame indicates that the constraint was added in this commit:
>> https://github.com/geotools/geotools/commit/4c367628f7ca13d4
>> 3cebccb4a3ee50cd2d72bb3c
>> The constraint is straight out of the OGC GeoPackage Encoding Standard:
>> Appendix A: Table Definition SQL (Normative)
>> https://github.com/opengeospatial/geopackage/blob/master/
>> spec/annexes/ddl.adoc
>> Removing the constraint fixes GeoPackageGetFeatureOutputFormatTest
>>
> [...]
>
>> On 27/04/17 14:50, Ben Caradoc-Davies wrote:
>>
>>> The underlying cause is the SQLite extended result
>>> code 2067:
>>> https://sqlite.org/rescode.html
>>> (2067) SQLITE_CONSTRAINT_UNIQUE
>>> The SQLITE_CONSTRAINT_UNIQUE error code is an extended error code for
>>> SQLITE_CONSTRAINT indicating that a UNIQUE constraint failed.
>>> addGeometryColumnsEntry is called twice with these values:
>>> [Seven, pointProperty, Point, 32615, 0, 0]
>>> [Seven, boundedBy, Polygon, 32615, 0, 0]
>>> but gpkg_geometry_columns.sql has the following constraint that limits
>>> each table to one geometry column:
>>> CONSTRAINT uk_gc_table_name UNIQUE (table_name)
>>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5718) RenderListener.featureRendered called once per rule

[Andrea Aime [Administrator] (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5718  
 
 
  RenderListener.featureRendered called once per rule   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 27/Apr/17 1:02 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 If multiple rules match the same feature, the listener will be called multiple times.   
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.910.0#100040-sha1:0b083fc)