Re: [Geotools-devel] Filter-CQL issues

[Devon Tucker]

I think, unfortunately, fixing this may be trickier than I had hoped. Part
of the problem is on the parsing end, because two valid property names get
parsed into the exact same thing.

"foo/bar" -> foo/bar (no quotes)
foo.bar   -> foo/bar
foo/bar   -> doesn't parse

Only the final one is correct. This is further complicated by the semantics
involved. foo.bar is parsed as a path whose parts are foo and bar, which is
then concatenated with a forward slash. "foo/bar" is initially correctly
parsed as a quoted property name, but then the quotes are stripped and then
becomes indistinguishable from foo.bar.

Also, I can't find anything in the OGC CQL spec that allows for quoted
identifiers.

OGC 07-006r1
 ::=
 |  } ]
 ::= 
 ::=  | 
 ::=  | 

 ::= 
 ::= 
  [{}...]
  

So yeah, not even really sure where to start with fixing this or even if it
is worth it for my use cases at least. For a start it should probably not
be losing semantically meaningful information on the parsing end (path vs.
quoted identifier with a forward slash in it), but right now this gets
parsed into an object model that is not quite a 1-to-1 match (OGC Filter
spec).

On Tue, Feb 5, 2019 at 10:20 AM Jody Garnett  wrote:

> In todays meeting we compared the library science CQL which uses
> "foo/bar.baz" with the OGC CSW CQL which uses "foo.bar.baz" - sigh :)
>
> - https://www.loc.gov/standards/sru/cql/spec.html
> - http://portal.opengeospatial.org/files/?artifact_id=20555
>
> --
> Jody Garnett
>
>
> On Tue, 5 Feb 2019 at 10:12, Andrea Aime 
> wrote:
>
>> HI Devon,
>> agree with the others that the best is to do a round trip test.
>> Just mind, while in memory a nested attribute reference should be xpath
>> like, a/b, while encoded
>> in CQL it should be a.b. So make sure it works fine both ways, I'd do two
>> round trip tests:
>>
>>- Start with "a/b" as PropertyName, encode and decode, you should be
>>getting back a PropertyName as "a/b"
>>- Start with "a.b" as a CQL string, decode and encode, you should get
>>back "a.b"
>>
>> Cheers
>> Andrea
>>
>> On Mon, Feb 4, 2019 at 6:41 PM Devon Tucker 
>> wrote:
>>
>>> Hi all,
>>>
>>> Working with the Filter -> CQL code recently (CQL.toCQL) I noticed that
>>> it is not producing correct CQL for attribute names. For example the
>>> following test case fails:
>>>
>>> https://gist.github.com/dvntucker/1d7f8c227eea44d9bd1563f0269e4b6a
>>>
>>> There are a number of issues here, but the biggest one is the
>>> forward-slash instead of a period, which is not correct by the CQL spec.
>>> Also, this identifier does not need to be quoted and I don't think quoting
>>> identifiers is in the CQL spec either.
>>>
>>> It looks like this is mainly an artifact from the parsing phase, where
>>> the periods are replaced with slashes to match XPath. I believe this part
>>> is correct, but needs to be corrected when producing CQL output. My only
>>> worry with changing this is potentially people relying on this behavior.
>>> Looking through GS/GT, it doesn't appear that this code path (Filter->CQL)
>>> is used a whole lot, and in fact where it is seems very likely to fail
>>> because of this (forward slash in identifier doesn't parse).
>>>
>>> Anyone see an issue with fixing this behavior?
>>>
>>> Cheers,
>>> Devon
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>>
>> Regards, Andrea Aime == GeoServer Professional Services from the experts!
>> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è 

[Geotools-devel] Filter-CQL issues

[Devon Tucker]

Hi all,

Working with the Filter -> CQL code recently (CQL.toCQL) I noticed that it
is not producing correct CQL for attribute names. For example the following
test case fails:

https://gist.github.com/dvntucker/1d7f8c227eea44d9bd1563f0269e4b6a

There are a number of issues here, but the biggest one is the forward-slash
instead of a period, which is not correct by the CQL spec. Also, this
identifier does not need to be quoted and I don't think quoting identifiers
is in the CQL spec either.

It looks like this is mainly an artifact from the parsing phase, where the
periods are replaced with slashes to match XPath. I believe this part is
correct, but needs to be corrected when producing CQL output. My only worry
with changing this is potentially people relying on this behavior. Looking
through GS/GT, it doesn't appear that this code path (Filter->CQL) is used
a whole lot, and in fact where it is seems very likely to fail because of
this (forward slash in identifier doesn't parse).

Anyone see an issue with fixing this behavior?

Cheers,
Devon
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Looking into contrast enhancement bug for mulit-band rasters

[Devon Tucker]

John, which version of GeoServer does this work in?

I looked into this a bit as well. I *believe* that the root issue is an
ArrayIndexOutOfBounds exception inside the IHSColorSpace conversion, which
occurs using either JAI or JAIEXT.

https://gist.github.com/dvntucker/b5198a7f7143c234a0613e03bb2970d3

I get the same exception in the JAIEXT version of IHSColorSpace as well.
This class is reading is reading past the raster bounds, which leads me to
believe there is something wrong with the Image Layout when doing the IHS
conversion.

One thing I did notice is that ContrastEnhancementNode is re-using the same
Hints over and over again, calling ImageWorker.setHints before every
operation:

https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/ContrastEnhancementNode.java

I'm not totally sure this is the correct way to use ImageWorker? As I
understand it from looking at the code, ImageWorker updates its own Hints
after each call in order to track the updated image layout. I _think_
calling setRenderingHints each time might be causing issues? However, when
I tried to remove all these calls it didn't seem to fix the issue, so I
don't know for sure.

It's also possible that the issue is simply a bug in the IHSColorSpace
conversion. Possibly a simple off by one error? I didn't look too closely
at the code to discern whether there might be an issue here. The bug is
replicated in both the Java and EXT versions, so I assumed not, but it's
worth looking at.

On Thu, Nov 9, 2017 at 8:04 AM, John Schulz 
wrote:

> Hi Daniele, and all,
>
> I'm looking into an issue involving a contrast enhancement bug for 3 and 4
> band rasters found here: https://osgeo-org.atlassian.net/browse/GEOT-5860
>
> In tracking down the bug it appears to be a regression.  I think that the
> issue stems from the IHS colorspace conversion section of the
> ContrastEnhancementNode, where the parameters of the image and the raster,
> at the very least, appear to get out of synch.
>
> I'm just looking to start a conversation as I get more familiar with issue
> and hoping to get some insight into when this regression came along.
>
> Cheers,
>
> John
>
> 
> --
> 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] Community Module Proposal: s3-geotiff

[Devon Tucker]

Hey all,

I have PRs for these ready:

https://github.com/geotools/geotools/pull/1610
https://github.com/geoserver/geoserver/pull/2388

Can I take the PSC +1's in this thread as the requisite approval for these
and proceed with PR review and merging?

Thanks,
Devon

On Wed, May 24, 2017 at 10:52 AM, Kevin Smith <smit...@draconic.ca> wrote:

> +1 for the GeoServer module.
>
> On 2017-05-23 02:11 PM, Ben Caradoc-Davies wrote:
> > +1 for both the GeoServer community module and the GeoTools unsupported
> > module. I have copied the GeoServer-devel list.
> >
> > Kind regards,
> > Ben.
> >
> > On 24/05/17 04:56, Devon Tucker wrote:
> >> Hi all,
> >>
> >> I mentioned this in a previous email either here or on gs-devel, but we
> >> have a simple-ish module we'd like to make into community/unsupported
> >> modules for GeoTools and GeoServer. They enable GeoTiffs to be served
> via
> >> Amazon S3 directly.
> >>
> >> The modules are fairly simple. In GeoTools there is a GridFormatFactory
> >> interface that's largely derivative of the GeoTiff module, as well as an
> >> ImageInputStream implementation that does most of the heavy lifting.
> This
> >> is also tied into EhCache caching in order to improve performance.
> >>
> >> In GeoServer there is a very trivial store UI screen. This exists only
> to
> >> get around some of the limitations currently in GeoServer when it comes
> to
> >> URL validation in the default grid store screens.
> >>
> >> I have branches created for each of these in my fork:
> >>
> >> https://github.com/dvntucker/geotools/tree/s3-geotiff-
> module/modules/unsupported/s3-geotiff
> >> https://github.com/dvntucker/geoserver/tree/s3-geotiff-gs/
> src/community/s3-geotiff
> >>
> >> Take a look if you like and let me know what you think.
> >>
> >> Cheers,
> >> Devon
>
> --
> Kevin Michael Smith
> <smit...@draconic.ca>
>
>
>
> 
> --
> 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] Fwd: [GeoTools Master] H2DataStoreFactoryTest Failure

[Devon Tucker]

I think we've figured it out. It was hosts business. The hostname on the
machine didn't have a hosts entry loopback.

On Fri, May 26, 2017 at 10:15 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Wondering, could the solutions in this mail thread apply on the new build
> server too?
>
> https://groups.google.com/forum/#!topic/h2-database/y3XoNVXyu1w
>
> Cheers
> Andrea
>
>
> On Fri, May 26, 2017 at 7:02 PM, Devon Tucker <dtuc...@boundlessgeo.com>
> wrote:
>
>> Hi all,
>>
>> Nick asked me to forward this. Apparently there's nothing running on that
>> port, so we're at a loss as to what the issue could be. I've created a gist
>> for the whole log, since it's fairly big.
>>
>> https://gist.github.com/dvntucker/6a3f6e0c828ef21b6e4d31fc8c0c2a05
>>
>> Cheers,
>> Devon
>>
>>
>> -- Forwarded message --
>> From: Nick Stires <nsti...@boundlessgeo.com>
>> Date: Fri, May 26, 2017 at 8:58 AM
>> Subject: [GeoTools Master] H2DataStoreFactoryTest Failure
>> To: Devon Tucker <dtuc...@boundlessgeo.com>
>>
>>
>> Apologies if this is a duplicate. I've had reports this didn't make it in
>> the bucket...
>>
>> Hello!
>>
>> I'm working to replace the aging Ares build server, and I've been stuck
>> on an issue with one of the GeoTools tests. The error is as follows:
>>
>> Running org.geotools.data.h2.H2DataStoreFactoryTest
>>> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.879
>>> sec <<< FAILURE! - in org.geotools.data.h2.H2DataStoreFactoryTest
>>> testTCP(org.geotools.data.h2.H2DataStoreFactoryTest)  Time elapsed:
>>> 1.578 sec  <<< ERROR!
>>> org.h2.jdbc.JdbcSQLException: Exception opening port H2 TCP Server
>>> (tcp://localhost:9092) (port may be in use), cause: timeout [90061-119]
>>> at org.h2.message.Message.getSQLException(Message.java:106)
>>> at org.h2.message.Message.getSQLException(Message.java:117)
>>> at org.h2.tools.Server.start(Server.java:361)
>>> at org.geotools.data.h2.H2DataStoreFactoryTest.testTCP(H2DataSt
>>> oreFactoryTest.java:94)
>>
>>
>> I'm hesitant to blame H2 itself, since other tests utilize it and run
>> without issue. Attached are the full debug log from:
>>
>>> geotools-master]$ mvn test 
>>> -Dtest=org.geotools.data.h2.H2DataStoreFactoryTest
>>> -DfailIfNoTests=false -X
>>
>>
>> Some more about the server itself. It's running Amazon Linux (CentOS
>> 6.8). SELinux and IPTables are both disabled. Per the logs, the software
>> versions are:
>>
>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>> 2015-11-10T16:41:47+00:00)
>>> Maven home: /opt/apache-maven
>>> Java version: 1.8.0_131, vendor: Oracle Corporation
>>> Java home: /usr/java/jdk1.8.0_131/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "linux", version: "4.9.27-14.31.amzn1.x86_64", arch: "amd64",
>>> family: "unix"
>>
>>
>> I have tried a handful of different Java flavors. Another build server on
>> the same OS is able to run with 1.8.0-101 OpenJDK.
>>
>> Any ideas on what could be causing this?
>>
>> Thanks!
>>
>> --
>> *Nick Stires*
>> DevOps Engineer | Boundless <https://boundlessgeo.com/>
>> nsti...@boundlessgeo.com
>> Mobile: +1 561-713-0922 <%28561%29%20713-0922>
>>
>>
>>
>>
>> 
>> --
>> 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
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica

[Geotools-devel] Fwd: [GeoTools Master] H2DataStoreFactoryTest Failure

[Devon Tucker]

Hi all,

Nick asked me to forward this. Apparently there's nothing running on that
port, so we're at a loss as to what the issue could be. I've created a gist
for the whole log, since it's fairly big.

https://gist.github.com/dvntucker/6a3f6e0c828ef21b6e4d31fc8c0c2a05

Cheers,
Devon


-- Forwarded message --
From: Nick Stires <nsti...@boundlessgeo.com>
Date: Fri, May 26, 2017 at 8:58 AM
Subject: [GeoTools Master] H2DataStoreFactoryTest Failure
To: Devon Tucker <dtuc...@boundlessgeo.com>


Apologies if this is a duplicate. I've had reports this didn't make it in
the bucket...

Hello!

I'm working to replace the aging Ares build server, and I've been stuck on
an issue with one of the GeoTools tests. The error is as follows:

Running org.geotools.data.h2.H2DataStoreFactoryTest
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.879 sec
> <<< FAILURE! - in org.geotools.data.h2.H2DataStoreFactoryTest
> testTCP(org.geotools.data.h2.H2DataStoreFactoryTest)  Time elapsed: 1.578
> sec  <<< ERROR!
> org.h2.jdbc.JdbcSQLException: Exception opening port H2 TCP Server
> (tcp://localhost:9092) (port may be in use), cause: timeout [90061-119]
> at org.h2.message.Message.getSQLException(Message.java:106)
> at org.h2.message.Message.getSQLException(Message.java:117)
> at org.h2.tools.Server.start(Server.java:361)
> at org.geotools.data.h2.H2DataStoreFactoryTest.testTCP(H2DataSt
> oreFactoryTest.java:94)


I'm hesitant to blame H2 itself, since other tests utilize it and run
without issue. Attached are the full debug log from:

> geotools-master]$ mvn test -Dtest=org.geotools.data.h2.H2DataStoreFactoryTest
> -DfailIfNoTests=false -X


Some more about the server itself. It's running Amazon Linux (CentOS 6.8).
SELinux and IPTables are both disabled. Per the logs, the software versions
are:

> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T16:41:47+00:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_131/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.27-14.31.amzn1.x86_64", arch: "amd64",
> family: "unix"


I have tried a handful of different Java flavors. Another build server on
the same OS is able to run with 1.8.0-101 OpenJDK.

Any ideas on what could be causing this?

Thanks!

-- 
*Nick Stires*
DevOps Engineer | Boundless <https://boundlessgeo.com/>
nsti...@boundlessgeo.com
Mobile: +1 561-713-0922 <%28561%29%20713-0922>
--
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] Community Module Proposal: s3-geotiff

[Devon Tucker]

Hi all,

I mentioned this in a previous email either here or on gs-devel, but we
have a simple-ish module we'd like to make into community/unsupported
modules for GeoTools and GeoServer. They enable GeoTiffs to be served via
Amazon S3 directly.

The modules are fairly simple. In GeoTools there is a GridFormatFactory
interface that's largely derivative of the GeoTiff module, as well as an
ImageInputStream implementation that does most of the heavy lifting. This
is also tied into EhCache caching in order to improve performance.

In GeoServer there is a very trivial store UI screen. This exists only to
get around some of the limitations currently in GeoServer when it comes to
URL validation in the default grid store screens.

I have branches created for each of these in my fork:

https://github.com/dvntucker/geotools/tree/s3-geotiff-module/modules/unsupported/s3-geotiff
https://github.com/dvntucker/geoserver/tree/s3-geotiff-gs/src/community/s3-geotiff

Take a look if you like and let me know what you think.

Cheers,
Devon
--
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] Fwd: Community Interest Check: S3 GeoTiff Store

[Devon Tucker]

Meant to send this to gt-devel as well.


-- Forwarded message --
From: Devon Tucker <dtuc...@boundlessgeo.com>
Date: Fri, Mar 24, 2017 at 12:12 PM
Subject: Community Interest Check: S3 GeoTiff Store
To: geotools-gt2-us...@lists.sourceforge.net
Cc: Jim Hughes <jn...@ccri.com>


Hi all,

Internally here at Boundless we have developed an GeoTools store that
serves GeoTiffs from an S3 store. It's still somewhat raw, but in our
testing it works OK (as well as can be expected given the limitations with
S3). Is there any interest in either open sourcing this on its own, or
maybe even making it community modules for GeoTools and GeoServer? If so I
can discuss internally donating it to the community.

Cheers,
Devon
--
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] Reading GeoTiffs from HDFS

[Devon Tucker]

Hey everyone,

Chatted with Jim about this a couple weeks ago and I wanted to revisit it,
since we'd like to do something similar except with S3 instead of Hadoop,
although many of the changes would be very similar.

I'm interested in whether anyone has any objections to some of these
changes. In particular the changes to GeoServer to change the File
validation to allow URLs of any protocol and especially this change to the
code which searches for an appropriate ImageInputStreamSPI as detailed here:

https://github.com/jnh5y/geotools/commit/f2db29339c7f7e43d0c52ab93195babc1abb6f49

IMO it's a pretty sensible change, I think we do similar things elsewhere
(catching exceptions from SPIs that we try and moving on even if they throw
an exception.

Thoughts anyone? Any reason not to do this? I can do a PR pretty quickly
for it.

Cheers

On Fri, Apr 22, 2016 at 1:41 PM, Even Rouault 
wrote:

> Le vendredi 22 avril 2016 22:06:39, Jim Hughes a écrit :
> > Hi Chris,
> >
> > Nice!  That's a fun find.
> >
> > Generally, I do like the idea of using Map/Reduce or Spark to
> > pre-generate tiles or an image pyramid.  We've kicked around the idea of
> > GWC + M/R a few times in passing.  If one has Hadoop infrastructure
> > hanging around, it might make sense to use GeoTrellis, SpatialHadoop
> > (GeoJini), etc. for some of that processing.
> >
> > Either way, being able to read the odd raster file straight from hdfs://
> > or s3:// and have it cached in memory seems like an amusing/useful
> > project.  I'm hopeful we can nail down the details.
>
> Probably a bit out of topic, but in case that might be useful, GDAL for
> example can through its /vsicurl/ (and in the fresh new 2.1.0 /vsis3/)
> virtual
> file systems read remote http files by most its drivers. Perhaps that
> could be
> used through the imageio-ext GDAL bridge.
>
> http://www.gdal.org/cpl__vsi_8h.html#a4f791960f2d86713d16e99e9c0c36258
> http://www.gdal.org/cpl__vsi_8h.html#a5b4754999acd06444bfda172ff2aaa16
> http://download.osgeo.org/gdal/workshop/foss4ge2015/workshop
> _gdal.html#__RefHeading__5995_1333016408
> https://sgillies.net/2016/04/05/rasterio-0-34.html
>
> >
> > Cheers,
> >
> > Jim
> >
> > On 04/22/2016 02:27 PM, Chris Snider wrote:
> > > I did find this reference (helpful ?):
> > > https://github.com/openreserach/bin2seq/blob/master/src/
> main/java/com/ope
> > > nresearchinc/hadoop/sequencefile/GeoTiff.java
> > >
> > > " /@formatter:off
> > > /**
> > >
> > >   *
> > >   * A program to demo retrive attributes from Geotiff images as Hadoop
> > >   SequenceFile stored on hdfs:// or s3:// *
> > >   *
> > >   * @author heq
> > >   */
> > >
> > > // @formatter:on"
> > >
> > > Chris Snider
> > > Senior Software Engineer
> > > Intelligent Software Solutions, Inc.
> > >
> > >
> > >
> > > -Original Message-
> > > From: Chris Snider [mailto:chris.sni...@issinc.com]
> > > Sent: Friday, April 22, 2016 12:11 PM
> > > To: Jim Hughes ; Simone Giannecchini
> > >  Cc:
> > > geoserver-de...@lists.sourceforge.net; GeoTools Developers list
> > >  Subject: Re: [Geoserver-devel]
> > > [Geotools-devel] Reading GeoTiffs from HDFS
> > >
> > > Hi,
> > >
> > > I don't know that much about HDFS, but is there something that can be
> > > setup like a map/reduce function directly in the HDFS servers that can
> > > do some of the restriction of byte level data returned? Yarn/Sparql,
> > > some other acronym?  I assume it would have to be administrator
> > > responsibility to add said process to the server stack if it is even
> > > possible.
> > >
> > > Chris Snider
> > > Senior Software Engineer
> > > Intelligent Software Solutions, Inc.
> > >
> > >
> > > -Original Message-
> > > From: Jim Hughes [mailto:jn...@ccri.com]
> > > Sent: Friday, April 22, 2016 12:05 PM
> > > To: Simone Giannecchini 
> > > Cc: geoserver-de...@lists.sourceforge.net; GeoTools Developers list
> > >  Subject: Re: [Geoserver-devel]
> > > [Geotools-devel] Reading GeoTiffs from HDFS
> > >
> > > Hi Simone,
> > >
> > > Thanks for the feedback!
> > >
> > > As quick response, for #1, I agree that using mosaicing / an image
> > > pyramid would be a great option.  I was mainly working at the prototype
> > > phase, and I wanted to have a discussion on the mailing lists
> > > (especially since changes are required in ImageIO-Ext or GeoTools and
> > > GeoServer.)
> > >
> > > For #2, I do like the idea of having a cahce in the ImageInputStream.
> > >
> > >   From that suggestion, I take it that you'd be willing to entertain
> > >
> > > changes to the current ImageInputStreams and the additional of some way
> > > to cache data.
> > >
> > > In terms of caching, do you have any suggestions?  Also, I'd be
> > > interested in any advice for how we can configure that cache and make
> > > those options available to a 

Re: [Geotools-devel] GeoTools 16.0 blocker

[Devon Tucker]

Hello all,

Apologies for the issue. I have a PR ready for a workaround:

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

Not ideal, but I tried what I thought would be the simplest fix and it
didn't work. Unfortunately configuration initialization for ImageMosaic is
a bit messy.

Let me know if there are issues.

Devon

On Wed, Oct 26, 2016 at 9:47 AM, Stefano Costa <
stefano.co...@geo-solutions.it> wrote:

> Ah!
>
> I experienced the same failure while preparing this PR:
> https://github.com/geotools/geotools/pull/1363
>
> Then I noticed the Travis build was passing and I thought the failure was
> specific to my laptop... seems like it's not.
>
>
>
> On Wed, Oct 26, 2016 at 6:20 PM, Ian Turton  wrote:
>
>>
>> ​
>> Here is the screen shot of the failing test images -
>>
>> Failed tests:
>>   HeterogenousCRSTest.testHeterogeneousCRS:56->testMosaic:105 Images are
>> visibly different, found 2147483647 different pixels, against a
>> threshold of 1000
>>
>> Ian
>> --
>> Ian Turton
>>
>> 
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
>
> Best regards,
> Stefano Costa
>
> ==
> GeoServer Professional Services from the experts! Visithttp://goo.gl/it488V 
> for more information.
> ==
> Dott. Stefano Costa
> Senior Software Engineer
>
> GeoSolutions S.A.S.Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> http://www.geo-solutions.ithttp://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5556) Updating a reprojecting imagemosaic fails with NPE

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5556  
 
 
  Updating a reprojecting imagemosaic fails with NPE   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Devon Tucker  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 25/Oct/16 11:48 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 When trying to update a reprojecting image mosaic store the catalog update fails with a null pointer exception inside the ReprojectingGranuleHandler.java. It looks like the MosaicConfiguration isn't properly being propagated during an update.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] gt 15.x/gwc 1.9.2/gs 2.9.x release delayed one more day due to a blocker

[Devon Tucker]

Hi all,

I have time to do the 2.9.2 release if it would help out.

Cheers,
Devon

On Wed, Sep 21, 2016 at 12:31 AM, Andrea Aime 
wrote:

> Hi,
> sad news, the blocker from yesterday was solved, but I found a new one
> (cannot update stores, GeoServer complains the store
> already exists) and realszed that the XEE vulnerability reported on WMS
> cascading has not yet been solved.
> Until both are fixed we won't be able to release 2.9.2.
> I have someone working on the store saving issue, but no one at the moment
> on the XEE one. Discussion about it on the geotools-devel list is ongoing.
>
> Cheers
> Andrea
>
>
> On Tue, Sep 20, 2016 at 11:38 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> Hi,
>> we have found out a bug caused by a backport on 2.9.x happened after the
>> 2.9.1
>> release that occasionally causes the GWC cached layers configuration to
>> be wiped out.
>> We are working on a fix:
>> https://osgeo-org.atlassian.net/browse/GEOS-7750
>>
>> The bug per se make the loading of a GWC layer fail, and the GWC
>> integration just deletes the cached layers it cannot load,
>> not 100% sure this is a good behavior but it makes some sense in a
>> clustered environment I guess.
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility  for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> ---
>>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with 

[Geotools-devel] GeoTools 16-beta Released

[Devon Tucker]

Hi all,

GeoTools 16-beta is now available.

The GeoTools team is pleased to announce the release of GeoTools 16-beta

:

   - geotools-16-beta-bin.zip
   

   - geotools-16-beta-doc.zip
   

   - geotools-16-beta-userguide.zip
   

   - geotools-16-beta-project.zip
   


This release is also available from our Maven repository
.
This release is made in conjunction with GeoServer 2.10-beta.

Highlights from our issue tracker release-notes

:

   - CSS now supports rendering transformations
   - Well known symbols added for QGIS interoperability
   - Support for the Azimuthal Equidistant projection


   

   - ImageMosaic now allows for heterogenous CRS in its granules.

For more information see the 16-beta release notes

and
the release notes for previous releases (M0

).
About GeoTools 16

   - The old wfs module has now been replaced with the wfs-ng module
   - The NetCDF module now uses NetCDF-Java 4.6.6
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeoTools 16-beta

[Devon Tucker]

Hi all,

GeoTools 16-beta artifacts are built:

http://ares.boundlessgeo.com/geotools/release/16-beta/

Please test out as you see fit. I'm installing them now.

Cheers,
Devon
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5516) NetCDF - add_offset and scale_factor attributes not respected

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5516  
 
 
  NetCDF - add_offset and scale_factor attributes not respected   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Devon Tucker  
 
 
Attachments: 
 o3_no2_so.nc  
 
 
Components: 
 coverage-multidim  
 
 
Created: 
 08/Sep/16 8:57 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 A NetCDF file with scale_factor and add_offset variable attributes does not have these attributes correctly applied when reading. For example, this call fails: 

 

float[] result = coverage
.evaluate((DirectPosition) new DirectPosition2D(DefaultGeographicCRS.WGS84, 5.0, 45.0),
new float[1]);

assertEquals(1.615991, result[0], 1e-6f);
 

 java.lang.AssertionError:  Expected :1.615991 Actual :6.159914016723633 Fails on the attached NETCDF file (the NO2 layer) where the scale_factor is 0.1 and the add_offset is 1

Re: [Geotools-devel] NetCDF - Use of original datatype vs. enhanced datatype

[Devon Tucker]

Crap, hit send too quickly:

I have a PR against my own fork here to illustrate the changes.

https://github.com/dvntucker/geotools/pull/4/files

1) A couple static blocks were changing the NetCDF default enhance mode to
just Enhance.CoordSystems. I removed these calls since Enhance.CoordSystems
is already part of the defaults, along with Enhance.ScaleMissing and
Enhance.ConvertEnums. I don't know a whole lot about NetCDF, but it seems
like these defaults should be kept in place? Is there a reason to keep this
call? All the tests pass fine without it.

2) The original datatype was being used to create the sample/color model in
the raster, instead of the enhanced datatype. So even after changing the
defaults the NetCDF reader was creating a raster with integer bands and
failing to write to it. I changed the utility method used to get the
datatype to use the getDataType method instead of the getOriginalDatatype
method. The only niggle here is that the utility method name
(getRawDataType) suggests that the method actually IS interested in the
base datatype, but... it's only ever used when creating the sample model,
so... not sure if the base type would ever be useful there. Maybe the
utility method should be renamed?

Anyone have any feedback or reasons not to make these changes? All the
tests pass with them.

Cheers,
Devon

On Wed, Sep 7, 2016 at 2:37 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:

> Hi all,
>
> I was looking into why the NetCDF reader isn't respecting scale_factor and
> add_offset and found a few things that I'm looking for feedback on.
>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] NetCDF - Use of original datatype vs. enhanced datatype

[Devon Tucker]

Hi all,

I was looking into why the NetCDF reader isn't respecting scale_factor and
add_offset and found a few things that I'm looking for feedback on.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Build failed in Jenkins: geotools-master-docs #7

[Devon Tucker]

Hi all,

Apologies for the stream of commits from Jody and I. Apparently my first order 
of business on getting commit access has been a bunch of changes straight to 
master :( We were under the gun to get the tutorials updated and running for 
our workshop in Bonn.

Thanks,
Devon

> On Aug 22, 2016, at 12:53 AM, moni...@boundlessgeo.com wrote:
> 
> See 
> 
> Changes:
> 
> [dtucker] - Update most of the doc examples to get rid of redundant type
> 
> [dtucker] Adding an IntelliJ quick start to the tutorial
> 
> --
> [...truncated 2677 lines...]
>  adding: user/tutorial/filter/images/postgisWizard1.png (deflated 7%)
>  adding: user/tutorial/filter/query.rst (deflated 65%)
>  adding: user/tutorial/filter/artifacts/ (stored 0%)
>  adding: user/tutorial/filter/artifacts/pom.xml (deflated 72%)
>  adding: user/tutorial/artifacts/ (stored 0%)
>  adding: user/tutorial/artifacts/output2 (deflated 75%)
>  adding: user/tutorial/artifacts/output (deflated 53%)
>  adding: user/tutorial/artifacts/example.properties (deflated 21%)
>  adding: user/conf.py (deflated 38%)
>  adding: user/welcome/ (stored 0%)
>  adding: user/welcome/architecture.rst (deflated 76%)
>  adding: user/welcome/netbeans.rst (deflated 56%)
>  adding: user/welcome/udig.rst (deflated 55%)
>  adding: user/welcome/upgrade.rst (deflated 76%)
>  adding: user/welcome/userlistguide.rst (deflated 55%)
>  adding: user/welcome/support.rst (deflated 56%)
>  adding: user/welcome/license.rst (deflated 58%)
>  adding: user/welcome/eclipse.rst (deflated 48%)
>  adding: user/welcome/faq.rst (deflated 65%)
>  adding: user/welcome/standards.rst (deflated 54%)
>  adding: user/welcome/application.rst (deflated 61%)
>  adding: user/welcome/jump.rst (deflated 56%)
>  adding: user/welcome/use.rst (deflated 64%)
>  adding: user/welcome/javaEE.rst (deflated 60%)
>  adding: user/welcome/geomajas.rst (deflated 57%)
>  adding: user/welcome/geoserver.rst (deflated 55%)
>  adding: user/welcome/index.rst (deflated 45%)
>  adding: user/welcome/integration.rst (deflated 41%)
>  adding: user/library/ (stored 0%)
>  adding: user/library/cql/ (stored 0%)
>  adding: user/library/cql/internal.rst (deflated 73%)
>  adding: user/library/cql/ecql.rst (deflated 71%)
>  adding: user/library/cql/faq.rst (deflated 58%)
>  adding: user/library/cql/cql.rst (deflated 67%)
>  adding: user/library/cql/index.rst (deflated 46%)
>  adding: user/library/opengis/ (stored 0%)
>  adding: user/library/opengis/feature.rst (deflated 56%)
>  adding: user/library/opengis/progress.rst (deflated 60%)
>  adding: user/library/opengis/unit.rst (deflated 46%)
>  adding: user/library/opengis/model.rst (deflated 71%)
>  adding: user/library/opengis/coverage.rst (deflated 62%)
>  adding: user/library/opengis/text.rst (deflated 59%)
>  adding: user/library/opengis/faq.rst (deflated 46%)
>  adding: user/library/opengis/name.rst (deflated 42%)
>  adding: user/library/opengis/type.rst (deflated 53%)
>  adding: user/library/opengis/filter.rst (deflated 67%)
>  adding: user/library/opengis/geometry.rst (deflated 54%)
>  adding: user/library/opengis/parameter.rst (deflated 47%)
>  adding: user/library/opengis/cs.rst (deflated 72%)
>  adding: user/library/opengis/index.rst (deflated 52%)
>  adding: user/library/opengis/se.rst (deflated 59%)
>  adding: user/library/xml/ (stored 0%)
>  adding: user/library/xml/resolving.rst (deflated 58%)
>  adding: user/library/xml/internal/ (stored 0%)
>  adding: user/library/xml/internal/configuration.rst (deflated 68%)
>  adding: user/library/xml/internal/code.rst (deflated 71%)
>  adding: user/library/xml/internal/bindings.rst (deflated 74%)
>  adding: user/library/xml/internal/overview.rst (deflated 72%)
>  adding: user/library/xml/internal/tutorial.rst (deflated 72%)
>  adding: user/library/xml/internal/index.rst (deflated 63%)
>  adding: user/library/xml/style.rst (deflated 68%)
>  adding: user/library/xml/faq.rst (deflated 65%)
>  adding: user/library/xml/filter.rst (deflated 71%)
>  adding: user/library/xml/geometry.rst (deflated 68%)
>  adding: user/library/xml/index.rst (deflated 43%)
>  adding: user/library/coverage/ (stored 0%)
>  adding: user/library/coverage/image.rst (deflated 68%)
>  adding: user/library/coverage/pyramid.rst (deflated 50%)
>  adding: user/library/coverage/netCDF.rst (deflated 22%)
>  adding: user/library/coverage/grid.rst (deflated 64%)
>  adding: user/library/coverage/oracle.rst (deflated 55%)
>  adding: user/library/coverage/image-collection.rst (deflated 46%)
>  adding: user/library/coverage/pgraster.rst (deflated 58%)
>  adding: user/library/coverage/multidim.rst (deflated 56%)
>  adding: user/library/coverage/arcsde.rst (deflated 56%)
>  adding: user/library/coverage/internal/ (stored 0%)
>  adding: user/library/coverage/internal/format.rst (deflated 64%)
>  adding: user/library/coverage/internal/index.rst (deflated 30%)
>  adding: 

[Geotools-devel] [JIRA] (GEOT-5498) Reprojecting mosaic fails with an interpolation set

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5498  
 
 
  Reprojecting mosaic fails with an interpolation set   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 21/Aug/16 2:46 PM  
 
 
Environment: 
 If you add add an interpolation to a reprojecting mosaic it fails with a NPE: org.geotools.data.DataSourceException: Unable to create this mosaic  at org.geotools.gce.imagemosaic.RasterLayerResponse.prepareResponse(RasterLayerResponse.java:661) at org.geotools.gce.imagemosaic.RasterLayerResponse.processRequest(RasterLayerResponse.java:538) at org.geotools.gce.imagemosaic.RasterLayerResponse.createResponse(RasterLayerResponse.java:510) at org.geotools.gce.imagemosaic.RasterManager.read(RasterManager.java:1185) at org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:895) at org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:874) at org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:808) at org.geotools.gce.imagemosaic.HeterogenousCRSTest.testMosaic(HeterogenousCRSTest.java:95) at org.geotools.gce.imagemosaic.HeterogenousCRSTest.testWithInterpolation(HeterogenousCRSTest.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160

Re: [Geotools-devel] devon committer nomination

[Devon Tucker]

Great, thanks everyone. Very happy to be on board and working with the
community.

Cheers,
Devon

On Tue, Aug 16, 2016 at 11:53 AM, Ben Caradoc-Davies 
wrote:

> There having been at least three +1 votes and no -1 votes, Devon is duly
> approved as a Committer:
> http://docs.geotools.org/latest/developer/roles/committer.html
>
> Welcome, Devon. Thank you for your work on the 15.1 release.
>
> Kind regards,
> Ben.
>
> On 17/08/16 06:26, Jody Garnett wrote:
>
>> This got a bit lost, deep in a thread on "dtucker jira team".
>>
>> I would like to nominate Devon for GeoTools commit access:
>>
>> *I am happy to recommend Devon for commit access, the above pull requests
>> show attention to detail, and clear communication with respect to feedback
>> and broken builds. Devon has a good understanding of how we work on
>> geotools-devel, taking part at all levels form documentation (adding to
>> the
>> tutorials), writing proposals, and most decently performing the GeoTools
>> 15.1 release. Commit access would enable Devon to be more effective as he
>> continues to help out.*
>>
>>
>> So far we have:
>>
>>
>>- Andrea Aime +1 second
>>- Ben Caradoc-Davies +1
>>- Christian Mueller +1
>>- Ian Turton
>>- Jody Garnett +1 nomination
>>- Justin Deoliveira
>>- Simone Giannecchini
>>
>> Ian, Justin, Simone could you reply? For your considering here is a
>> link to pull
>> requests
>> > otools/geotools/pulls?utf8%3D%25E2%259C%2593%26q%3Dis%253Apr
>> %2520author%253Advntucker%2520=gmail=
>> 1471458086665000=AFQjCNFoe8lonKoYLqVCUlhgwXwoIuhqhA>
>> from Devon.
>>
>> --
>> Jody Garnett
>>
>>
>>
>> 
>> --
>>
>>
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools 16-M0 release artifacts available for testing

[Devon Tucker]

> (2) gt-complex-16-M0-tests.jar is present. This is the only *-tests.jar 
> included
in the bin-zip. I wonder why?

Maybe something do do with the following? Only a guess.



org.apache.maven.plugins
maven-source-plugin


package

test-jar





org.apache.maven.plugins
maven-jar-plugin


package

test-jar






On Fri, Aug 12, 2016 at 5:20 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
>
> Looks like my failed test refers to the JAI version, and is thus
system-specific. Given that it works on other systems, I am not especially
concerned about this failure (although I evedently need to the JAI version
on my system)
>
> Torben
>
> On Fri, Aug 12, 2016 at 5:06 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
>>
>> I'm seeing this error in the gt-metadata module, but others are unable
to reproduce:
>> Failed tests:
>>   GeoToolsTest.testVersion:162 expected:<1.1.[3]> but was:<1.1.[2]>
>>
>> Torben
>>
>> On Fri, Aug 12, 2016 at 5:02 PM, Devon Tucker <devonrtuc...@gmail.com>
wrote:
>>>
>>> Running a mvn install now.
>>>
>>> On Fri, Aug 12, 2016 at 4:50 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
>>>>
>>>> The GeoTools 16-M0 release artifacts available for testing from:
>>>> http://ares.boundlessgeo.com/geotools/release/16-M0/
>>>>
>>>> Torben
>>>>
>>>>
--
>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
>>>> patterns at an interface-level. Reveals which users, apps, and
protocols are
>>>> consuming the most bandwidth. Provides multi-vendor support for
NetFlow,
>>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>>> planning reports. http://sdm.link/zohodev2dev
>>>> ___
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>
>>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools 16-M0 release artifacts available for testing

[Devon Tucker]

Install succeeded for me.

On Fri, Aug 12, 2016 at 5:06 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> I'm seeing this error in the gt-metadata module, but others are unable to
> reproduce:
> Failed tests:
>   GeoToolsTest.testVersion:162 expected:<1.1.[3]> but was:<1.1.[2]>
>
> Torben
>
> On Fri, Aug 12, 2016 at 5:02 PM, Devon Tucker <devonrtuc...@gmail.com>
> wrote:
>
>> Running a mvn install now.
>>
>> On Fri, Aug 12, 2016 at 4:50 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> The GeoTools 16-M0 release artifacts available for testing from:
>>> http://ares.boundlessgeo.com/geotools/release/16-M0/
>>>
>>> Torben
>>>
>>> 
>>> --
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols
>>> are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning reports. http://sdm.link/zohodev2dev
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools 16-M0 release artifacts available for testing

[Devon Tucker]

Running a mvn install now.

On Fri, Aug 12, 2016 at 4:50 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> The GeoTools 16-M0 release artifacts available for testing from:
> http://ares.boundlessgeo.com/geotools/release/16-M0/
>
> Torben
>
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeoTools 15.1 Released

[Devon Tucker]

Hi all,

Apologies for the delay on the release announcement email. Better late than
never I hope.

The GeoTools team is pleased to announce GeoTools 15.1!

   - geotools-15.1-bin.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-bin.zip/download>
   - geotools-15.1-doc.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-doc.zip/download>
   - geotools-15.1-userguide.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-userguide.zip/download>
   - geotools-15.1-project.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-project.zip/download>

This release is also available from our Maven repository
<http://download.osgeo.org/webdav/geotools/>. A reminder that Java 8 is now
required, please view the install guide
<http://docs.geotools.org/latest/userguide/build/install/index.html> for
details. This release is made by Devon Tucker (Boundless) in conjunction
with GeoWebCache 1.9.1 and GeoServer 2.9.1

GeoTools 15.1 is the latest stable release of the 15.x series and is
recommended for all new projects.
Features and Improvements

   - Upgraded to NetCDF-Java 4.6.6
   - Support for rotated pole projection NetCDF and GRIB2 files, including
   the native GRIB2 file format used by the NOAA Rapid Refresh (RAPv3)
   weather forecast model <http://rapidrefresh.noaa.gov/>
   - Support for multivalued xlink:href ClientProperty in app-schema
   mappings





Bug Fixes

   - ExtractsBoundFilterVisitor has been updated to work correctly with
   Filter 2.0 functions (such as temporal queries). Thanks to Andrew Hulbert
   (CCRi).
   - PropertyDataStore now correctly writing 3D geometries
   - Fixed in the new fast GML 3 encoder path, which was not properly
   encoding pure geometry collections, and data with 3d coordinates
   - WorldFile reader now correctly reading raster lock
   - GridCoverageRenderer no longer throwing NullPointerException in
   certain cases where the coverage is outside the request bounds
   - JDBCDataStore correctly updating and deleting features with a compound
   CRS in geometries

And more! For more information see 15.1 release notes
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=13000=Text=10001>
and
the release notes for previous releases (M0
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=11402==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | Beta 1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12101==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | Beta 2
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12601==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | RC1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12900==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | 15.0
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=13002==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C60a562a29d3c23854fbe594a81086dd4338711c1%7Clout>
 | 15.1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=13000=Text=10001>
 ).
About GeoTools 15 What's new in GeoTools 15:

   - Java 8 is now required. Please view the install guide
   <http://docs.geotools.org/latest/userguide/build/install/index.html> for
   details.
   - Group By feature collection
   
<http://docs.geotools.org/stable/userguide/library/main/collection.html#group-by-visitor>
visitor.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5484) ImageMosaic not handling footprint behavior in single granule case

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5484  
 
 
  ImageMosaic not handling footprint behavior in single granule case   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 2.8, 2.9  
 
 
Assignee: 
 Devon Tucker  
 
 
Attachments: 
 notransparency.png, withtransparency.png  
 
 
Components: 
 imagemosaic plugin  
 
 
Created: 
 10/Aug/16 12:26 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 During mosaicking when there is only one granule to be mosaicked a simplified code path is followed that doesn't do any mosaic operation, only scales/borders/etc. as needed. This path does not deal with footprint behavior when it's CUT though. See the attached screenshots for examples (the data in the image has been over-pixellated to anonymize it).   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] Idea: FeatureStream

[Devon Tucker]

Hi all,

Jody and I were talking today about and idea he has been agitating for a
while. We'd like to basically implement the Java 8 streaming interface for
features on top of FeatureSource or FeatureCollection. Just throwing this
out there for early feedback to see what people think.

Jody thinks that much of that API can be implemented in terms of the
existing functionality fairly simply/efficiently while others can be
delegated to simpler Stream objects (created from builder utilities).

Interested in what people think. We'll probably do a quick proposal shortly.

Cheers,
Devon
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools 15.1 artifacts available for testing

[Devon Tucker]

The release is now published to Maven and SourceForge. I have a draft blog
post ready to go, please take a read over and let me know if there are any
issues:

The GeoTools team is pleased to announce GeoTools 15.1!

   - geotools-15.1-bin.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-bin.zip/download>
   - geotools-15.1-doc.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-doc.zip/download>
   - geotools-15.1-userguide.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-userguide.zip/download>
   - geotools-15.1-project.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.1/geotools-15.1-project.zip/download>

This release is also available from our Maven repository
<http://download.osgeo.org/webdav/geotools/>. Java 8 is now required,
please view the install guide
<http://docs.geotools.org/latest/userguide/build/install/index.html> for
details. This release is made by Devon Tucker in conjunction with
GeoWebCache 1.9.1 and GeoServer 2.9.1


GeoTools 15.1 is the latest stable release of the 15.x series and is
recommended for all new projects.
Features and Improvements

   - [GEOT-5428 <https://osgeo-org.atlassian.net/browse/GEOT-5428>] -
   Support NetCDF rotated pole projection
   - [GEOT-5434 <https://osgeo-org.atlassian.net/browse/GEOT-5434>] -
   Upgrade to NetCDF-Java 4.6.6





Bug Fixes

   - [GEOT-5477 <https://osgeo-org.atlassian.net/browse/GEOT-5477>] - An
   heterogeneous mosaic of NetCDF may ignore requested dimension values
   - [GEOT-5478 <https://osgeo-org.atlassian.net/browse/GEOT-5478>] -
   ExtractBoundsFilterVisitor fails with AND'd DURING filter
   - [GEOT-5447 <https://osgeo-org.atlassian.net/browse/GEOT-5447>] -
   PropertyDataStore fails to write geometries with 3d ordinates
   - [GEOT-5448 <https://osgeo-org.atlassian.net/browse/GEOT-5448>] - GML3
   parser reads poslist in 3d crs as a 2d one
   - [GEOT-5419 <https://osgeo-org.atlassian.net/browse/GEOT-5419>] -
   WorldFile reader doesn't release raster file lock
   - [GEOT-5421 <https://osgeo-org.atlassian.net/browse/GEOT-5421>] -
   NullPointerException when GridCoverage goes offscreen
   - [GEOT-5453 <https://osgeo-org.atlassian.net/browse/GEOT-5453>] -
   JDBCDataStore fails to update and delete features with a compound CRS in
   geometries

And more! For more information see 15.1 release notes
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=13000=Text=10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C60a562a29d3c23854fbe594a81086dd4338711c1%7Clout>
and
the release notes for previous releases (M0
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=11402==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | Beta 1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12101==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | Beta 2
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12601==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | RC1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12900==10001=Create_token=BMGO-EVM2-SZYH-VJUH|3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3|lout>
 | 15.0
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=13002==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C60a562a29d3c23854fbe594a81086dd4338711c1%7Clout>
).
About GeoTools 15

What's new in GeoTools 15:

   - Java 8 is now required. Please view the install guide
   <http://docs.geotools.org/latest/userguide/build/install/index.html> for
   details.
   - Group By feature collection
   
<http://docs.geotools.org/stable/userguide/library/main/collection.html#group-by-visitor>
visitor.




On Tue, Aug 2, 2016 at 4:04 PM, Jody Garnett <jody.garn...@gmail.com> wrote:

> So the README:
> - had Java 8 instructions
> - links went to latest (and not stable)
>
> Not worth holding up the release over :P
>
> --
> Jody Garnett
>
> On 2 August 2016 at 15:54, Jody Garnett <jody.garn...@gmail.com> wrote:
>
>> Thanks, looks good on my end, even checked the README.html
>>
>>
>> --
>> Jody Garnett
>>
>> On 2 August 2016 at 15:39, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>
>>> I'm able to build and install the artifacts. Going to hit publish now.
>>>
>>> Cheers
>>>
>>> On Tue, Aug 2, 2016 at 3:00 PM, Devon Tucker <devonrtuc...@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> GeoTools

Re: [Geotools-devel] GeoTools 15.1 artifacts available for testing

[Devon Tucker]

I'm able to build and install the artifacts. Going to hit publish now.

Cheers

On Tue, Aug 2, 2016 at 3:00 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:

> Hi all,
>
> GeoTools 15.1 candidate binaries are available for testing:
>
> <http://ares.boundlessgeo.com/geotools/release/15.1/>
> <http://ares.boundlessgeo.com/geotools/release/15.1/>
> http://ares.boundlessgeo.com/geotools/release/15.1/
>
> Please test and let me know if there are issues. I will be testing now.
>
> Thanks,
> Devon
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeoTools 15.1 artifacts available for testing

[Devon Tucker]

Hi all,

GeoTools 15.1 candidate binaries are available for testing:



http://ares.boundlessgeo.com/geotools/release/15.1/

Please test and let me know if there are issues. I will be testing now.

Thanks,
Devon
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] gt-imagemosaic schema up to date?

[Devon Tucker]

Hi Daniele,

That makes sense. I guess that raises the question of what to do with the
XSD now. Should it go away, or should we attempt to update it to match the
current generated objects? Does anyone actually use the XSD?

On Thu, Jul 21, 2016 at 2:17 AM, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Devon,
> If my memory serves me right, the schema has been used as starting point
> to make the creation of the classes easier with XJC but some manual tweaks
> have been performed afterwards on the generated classes.
>
> Does it helps?
>
> Cheers,
> Daniele
>
>
>
> On Thu, Jul 21, 2016 at 12:45 AM, Devon Tucker <devonrtuc...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Quick question that maybe someone can answer: in gt-imagemosaic there is
>> an indexer.xsd schema that seems to define the Indexer object, plus classes
>> that appear to have been generated from this schema. It's not clear though
>> how these objects were generated. If I use XJC by default I get objects
>> that are a decent bit different (mostly API differences, but a few names
>> are different as well). Anyone know how these were generated?
>>
>> Thanks,
>> Devon
>>
>>
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning
>> reports.http://sdm.link/zohodev2dev
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] gt-imagemosaic schema up to date?

[Devon Tucker]

Hi all,

Quick question that maybe someone can answer: in gt-imagemosaic there is an
indexer.xsd schema that seems to define the Indexer object, plus classes
that appear to have been generated from this schema. It's not clear though
how these objects were generated. If I use XJC by default I get objects
that are a decent bit different (mostly API differences, but a few names
are different as well). Anyone know how these were generated?

Thanks,
Devon
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Build failed in Jenkins: geotools-master-online #548

[Devon Tucker]

FYI, I have a temporary fix ready for this:



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

Need some time to work on a true fix though.

Cheers,
Devon

On Tue, Jul 5, 2016 at 7:41 AM,  wrote:

> See 
>
> --
> [...truncated 4791 lines...]
>  [exec] copying downloadable files... [ 71%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/src/main/java/org/geotools/po/bindings/PurchaseOrderTypeBinding.java
> >
>  [exec] copying downloadable files... [ 73%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/modules/library/sample-data/src/main/resources/org/geotools/test-data/shapes/streams.prj
> >
>  [exec] copying downloadable files... [ 76%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/user/tutorial/quickstart/artifacts/pom.xml
> >
>  [exec] copying downloadable files... [ 78%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/src/main/java/org/geotools/po/bindings/Items_itemBinding.java
> >
>  [exec] copying downloadable files... [ 80%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/src/main/java/org/geotools/tutorial/csv/CSVTest.java
> >
>  [exec] copying downloadable files... [ 82%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/modules/unsupported/csv/src/main/java/org/geotools/data/csv/CSVFeatureStore.java
> >
>  [exec] copying downloadable files... [ 84%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/user/tutorial/feature/artifacts/locations.csv
> >
>  [exec] copying downloadable files... [ 86%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/user/tutorial/datastore/artifacts/pom.xml
> >
>  [exec] copying downloadable files... [ 89%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/modules/unsupported/csv/src/main/java/org/geotools/data/csv/parse/CSVAttributesOnlyStrategy.java
> >
>  [exec] copying downloadable files... [ 91%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/modules/unsupported/csv/src/main/java/org/geotools/data/csv/parse/CSVIterator.java
> >
>  [exec] copying downloadable files... [ 93%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/user/artifacts/xml/pom3.xml
> >
>  [exec] copying downloadable files... [ 95%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/src/main/java/org/geotools/tutorial/filter/QueryLab.java
> >
>  [exec] copying downloadable files... [ 97%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/src/main/java/org/geotools/po/bindings/ItemsBinding.java
> >
>  [exec] copying downloadable files... [100%] <
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/modules/unsupported/csv/src/main/java/org/geotools/data/csv/parse/CSVLatLonStrategy.java
> >
>
>  [exec] copying static files... done
>  [exec] dumping search index... done
>  [exec] dumping object inventory... done
>  [exec] build succeeded.
>
> web:
>
> sphinx:
>  [echo] Running sphinx-build -D release=16-SNAPSHOT -W -b html -d "<
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/target/web/doctrees;>
> . "<
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/target/web/html
> ">
>  [exec] Making output directory...
>  [exec] Running Sphinx v1.2b1
>  [exec] loading pickled environment... not yet created
>  [exec] building [html]: targets for 3 source files that are out of
> date
>  [exec] updating environment: 3 added, 0 changed, 0 removed
>  [exec] reading sources... [ 33%] about
>  [exec] reading sources... [ 66%] getinvolved
>  [exec] reading sources... [100%] index
>
>  [exec] looking for now-outdated files... none found
>  [exec] pickling environment... done
>  [exec] checking consistency... done
>  [exec] preparing documents... done
>  [exec] writing output... [ 33%] about
>  [exec] writing output... [ 66%] getinvolved
>  [exec] writing output... [100%] index
>
>  [exec] writing additional files... search
>  [exec] copying static files... done
>  [exec] dumping search index... done
>  [exec] dumping object inventory... done
>  [exec] build succeeded.
>
> developer:
>
> sphinx:
>  [echo] Running sphinx-build -D release=16-SNAPSHOT -W -b html -d "<
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/target/developer/doctrees;>
> . "<
> http://ares.boundlessgeo.com/jenkins/job/geotools-master-online/ws/docs/target/developer/html
> ">
>  [exec] Making output directory...
>  [exec] Running Sphinx 

[Geotools-devel] Proposal: MosaicProducer changes

[Devon Tucker]

Hi all,

Consider this email a pre-proposal of sorts, since we don't have a proposal
for it ready yet, but wanted to get the ball rolling ASAP for feedback and
discussion. Should have an actual proposal written soon-ish.

As some of you know we've been working on support for heterogenous CRS with
on-the-fly reprojection in ImageMosaic and now we're looking at changing
the actual mosaicking code. A brief rundown of how I imagined this code
working:

(for reference, here's a dirty class diagram of what exists currently
https://www.dropbox.com/s/tjb5yzx9fuer6ov/mosaicproducer.png?dl=0)

Currently there's machinery in ImageMosaic for stacking multiple
dimensions. This is handled inside the RasterLayerResponse by:

- Creating a GranuleCollector per domain requested
- Dispatching each Granule to the appropriate GranuleCollector
- Mosaic each GranuleCollector
- Mosaic the results of each of those "submosaics"

I'm leaning towards sort of generalizing this process. This way we can
delegate granules that may need special handling (say, because they're in a
different projection from the target response). Hopefully I can write this
up a little more thoroughly soon-ish when I'm less busy with the previous
proposal.

Anyway, happy to hear feedback or comments on this area, I know we had some
before in a previous thread:


http://osgeo-org.1560.x6.nabble.com/On-the-fly-reprojection-in-ImageMosaic-td5260919.html

Cheers
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

[Devon Tucker]

Yes, it's ready for review :D

On Tue, Jun 21, 2016 at 5:01 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:

> We can always squash the commits when merging to master.
>
> Is the proposal ready for review now?
>
> --
> Jody Garnett
>
> On 21 June 2016 at 16:55, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Ok so after going down the road of using the PropertiesCollector
>> interface for doing the granule geometry handling and decided to go with my
>> original plan of creating a separate interface for this. I have updated the
>> proposal accordingly.
>>
>> Also, I created a pull request for reference, since it might be easier to
>> follow these changes that way.
>>
>> <https://github.com/geotools/geotools/pull/1220>
>> <https://github.com/geotools/geotools/pull/1220>
>> https://github.com/geotools/geotools/pull/1220
>>
>> I can spend some time cleaning up those commits, since I notice now that
>> there's a few checkpoint commits in there.
>>
>> Cheers
>>
>> On Mon, Jun 20, 2016 at 5:06 PM, Devon Tucker <devonrtuc...@gmail.com>
>> wrote:
>>
>>> The GranuleAcceptor stuff is done on that branch. I have the
>>> PropertiesCollector stuff done locally, but there's some iffy stuff there.
>>> Handling the granule envelope in a PropertiesCollector should be fine, but
>>> there is an issue with how StructuredGridCoverages are handled:
>>>
>>>
>>> https://github.com/dvntucker/geotools/blob/granule_acceptors/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/ImageMosaicConfigHandler.java#L512
>>>
>>> For StructuredGCs all the feature attributes are copied right off the
>>> feature from the input reader, then the properties collectors are called.
>>> I'm not really sure how this would tie in to using a PropertiesCollector
>>> the pre-process the incoming coverage envelope, which makes me wonder if
>>> it's a good idea at all.
>>>
>>>
>>>
>>> On Mon, Jun 20, 2016 at 2:53 PM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Reviewing
>>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility
>>>> it appears up to date (with a remove CatalogManager heading). Are you going
>>>> to verify the approach (on that branch) and then send us an email for the
>>>> completed proposal?
>>>>
>>>> It is hard to leap into this proposal and provide any useful feedback
>>>> as a PMC member, I think the productive conversation is with Simone as
>>>> module maintainer.
>>>> --
>>>> Jody
>>>>
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On 20 June 2016 at 13:48, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Based on discussions with Simone and Jody we have made a few changes
>>>>> to this proposal:
>>>>>
>>>>> - CatalogManager gets deleted, its methods moved either to
>>>>> ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations
>>>>>
>>>>> - Instead of delegating granule acceptance to CatalogManager, as was
>>>>> originally proposed, this functionality is broken out into its own
>>>>> interface + factory SPI.
>>>>>
>>>>> - I changed the granule envelope handling to just use the existing
>>>>> PropertiesCollector API, since it already sets attributes on the index
>>>>> feature, I don't really see why not? Not sure if anyone would object to
>>>>> this.
>>>>>
>>>>> Also there's a new branch with most of this implemented:
>>>>>
>>>>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>>>>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>>>>> https://github.com/dvntucker/geotools/tree/granule_acceptors
>>>>>
>>>>> As usual, let me know if there's any questions or feedback.
>>>>>
>>>>> On Wed, Jun 15, 2016 at 5:38 AM, Simone Giannecchini <
>>>>> simone.giannecch...@geo-solutions.it> wrote:
>>>>>
>>>>>> Dear Devon,
>>>>>> a few things:
>>>>>>
>>>>>> -0- we should really get rid of this CatalogManager as i

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

[Devon Tucker]

Ok so after going down the road of using the PropertiesCollector interface
for doing the granule geometry handling and decided to go with my original
plan of creating a separate interface for this. I have updated the proposal
accordingly.

Also, I created a pull request for reference, since it might be easier to
follow these changes that way.

<https://github.com/geotools/geotools/pull/1220>
<https://github.com/geotools/geotools/pull/1220>
https://github.com/geotools/geotools/pull/1220

I can spend some time cleaning up those commits, since I notice now that
there's a few checkpoint commits in there.

Cheers

On Mon, Jun 20, 2016 at 5:06 PM, Devon Tucker <devonrtuc...@gmail.com>
wrote:

> The GranuleAcceptor stuff is done on that branch. I have the
> PropertiesCollector stuff done locally, but there's some iffy stuff there.
> Handling the granule envelope in a PropertiesCollector should be fine, but
> there is an issue with how StructuredGridCoverages are handled:
>
>
> https://github.com/dvntucker/geotools/blob/granule_acceptors/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/ImageMosaicConfigHandler.java#L512
>
> For StructuredGCs all the feature attributes are copied right off the
> feature from the input reader, then the properties collectors are called.
> I'm not really sure how this would tie in to using a PropertiesCollector
> the pre-process the incoming coverage envelope, which makes me wonder if
> it's a good idea at all.
>
>
>
> On Mon, Jun 20, 2016 at 2:53 PM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Reviewing
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility
>> it appears up to date (with a remove CatalogManager heading). Are you going
>> to verify the approach (on that branch) and then send us an email for the
>> completed proposal?
>>
>> It is hard to leap into this proposal and provide any useful feedback as
>> a PMC member, I think the productive conversation is with Simone as module
>> maintainer.
>> --
>> Jody
>>
>>
>> --
>> Jody Garnett
>>
>> On 20 June 2016 at 13:48, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Based on discussions with Simone and Jody we have made a few changes to
>>> this proposal:
>>>
>>> - CatalogManager gets deleted, its methods moved either to
>>> ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations
>>>
>>> - Instead of delegating granule acceptance to CatalogManager, as was
>>> originally proposed, this functionality is broken out into its own
>>> interface + factory SPI.
>>>
>>> - I changed the granule envelope handling to just use the existing
>>> PropertiesCollector API, since it already sets attributes on the index
>>> feature, I don't really see why not? Not sure if anyone would object to
>>> this.
>>>
>>> Also there's a new branch with most of this implemented:
>>>
>>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>>> https://github.com/dvntucker/geotools/tree/granule_acceptors
>>>
>>> As usual, let me know if there's any questions or feedback.
>>>
>>> On Wed, Jun 15, 2016 at 5:38 AM, Simone Giannecchini <
>>> simone.giannecch...@geo-solutions.it> wrote:
>>>
>>>> Dear Devon,
>>>> a few things:
>>>>
>>>> -0- we should really get rid of this CatalogManager as is (a class
>>>> with only static methods as its state its spread over N other classes)
>>>> -1- we can already mosaick images with different colormodels (to a
>>>> certain extent, it does not make sense to mosaick a float raster with
>>>> an RGB). RGB, Gray and Palette can be mosaicked as of today
>>>> -4- I would add some UML diagrams to your proposal to show what we
>>>> have now and what we have afterwards
>>>>
>>>> I noticed that you are half-way through with your refactor and its
>>>> probably too early to look into it but I have two things I wanted to
>>>> bring up.
>>>> First of all, I believe you shuold look at the refactor of the
>>>> indexing together with this, I would not split them otherwise your
>>>> refactor in this case could be too narrow.
>>>> Let me explain, your goal here is to improve the harvesting process
>>>> allowing implementors to change how harvested elements are disca

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

[Devon Tucker]

The GranuleAcceptor stuff is done on that branch. I have the
PropertiesCollector stuff done locally, but there's some iffy stuff there.
Handling the granule envelope in a PropertiesCollector should be fine, but
there is an issue with how StructuredGridCoverages are handled:

https://github.com/dvntucker/geotools/blob/granule_acceptors/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/ImageMosaicConfigHandler.java#L512

For StructuredGCs all the feature attributes are copied right off the
feature from the input reader, then the properties collectors are called.
I'm not really sure how this would tie in to using a PropertiesCollector
the pre-process the incoming coverage envelope, which makes me wonder if
it's a good idea at all.



On Mon, Jun 20, 2016 at 2:53 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:

> Reviewing
> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility
> it appears up to date (with a remove CatalogManager heading). Are you going
> to verify the approach (on that branch) and then send us an email for the
> completed proposal?
>
> It is hard to leap into this proposal and provide any useful feedback as a
> PMC member, I think the productive conversation is with Simone as module
> maintainer.
> --
> Jody
>
>
> --
> Jody Garnett
>
> On 20 June 2016 at 13:48, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Hi all,
>>
>> Based on discussions with Simone and Jody we have made a few changes to
>> this proposal:
>>
>> - CatalogManager gets deleted, its methods moved either to
>> ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations
>>
>> - Instead of delegating granule acceptance to CatalogManager, as was
>> originally proposed, this functionality is broken out into its own
>> interface + factory SPI.
>>
>> - I changed the granule envelope handling to just use the existing
>> PropertiesCollector API, since it already sets attributes on the index
>> feature, I don't really see why not? Not sure if anyone would object to
>> this.
>>
>> Also there's a new branch with most of this implemented:
>>
>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>> <https://github.com/dvntucker/geotools/tree/granule_acceptors>
>> https://github.com/dvntucker/geotools/tree/granule_acceptors
>>
>> As usual, let me know if there's any questions or feedback.
>>
>> On Wed, Jun 15, 2016 at 5:38 AM, Simone Giannecchini <
>> simone.giannecch...@geo-solutions.it> wrote:
>>
>>> Dear Devon,
>>> a few things:
>>>
>>> -0- we should really get rid of this CatalogManager as is (a class
>>> with only static methods as its state its spread over N other classes)
>>> -1- we can already mosaick images with different colormodels (to a
>>> certain extent, it does not make sense to mosaick a float raster with
>>> an RGB). RGB, Gray and Palette can be mosaicked as of today
>>> -4- I would add some UML diagrams to your proposal to show what we
>>> have now and what we have afterwards
>>>
>>> I noticed that you are half-way through with your refactor and its
>>> probably too early to look into it but I have two things I wanted to
>>> bring up.
>>> First of all, I believe you shuold look at the refactor of the
>>> indexing together with this, I would not split them otherwise your
>>> refactor in this case could be too narrow.
>>> Let me explain, your goal here is to improve the harvesting process
>>> allowing implementors to change how harvested elements are discarded
>>> as well as how they are preprocessed or manipulated and this is not
>>> isolated from the harvesting itself.
>>>
>>> I believe catalogmanager (although) the nice name, might go away and
>>> this kind of behavior could be isolated into smaller API likewise we
>>> did with the properties collector so that one can drop them inside the
>>> imagemosaic and ask it through the indexmanager to apply them.
>>> Ideally one could rather write its one harvester and completely
>>> customize how we put things inside the GranuleCatalog.
>>>
>>> Let me know what you think about this.
>>>
>>>
>>> Regards,
>>> Simone Giannecchini
>>> ==
>>> GeoServer Professional Services from the experts!
>>> Visit http://goo.gl/it488V for more information.
>>> ==
>>> Ing. Simone Giannecchini
>>> @simogeo
>>> Founder/Director
>>>
>>> GeoSolutions S.A.

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

[Devon Tucker]

Hi all,

Based on discussions with Simone and Jody we have made a few changes to
this proposal:

- CatalogManager gets deleted, its methods moved either to
ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations

- Instead of delegating granule acceptance to CatalogManager, as was
originally proposed, this functionality is broken out into its own
interface + factory SPI.

- I changed the granule envelope handling to just use the existing
PropertiesCollector API, since it already sets attributes on the index
feature, I don't really see why not? Not sure if anyone would object to
this.

Also there's a new branch with most of this implemented:

<https://github.com/dvntucker/geotools/tree/granule_acceptors>
<https://github.com/dvntucker/geotools/tree/granule_acceptors>
https://github.com/dvntucker/geotools/tree/granule_acceptors

As usual, let me know if there's any questions or feedback.

On Wed, Jun 15, 2016 at 5:38 AM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Dear Devon,
> a few things:
>
> -0- we should really get rid of this CatalogManager as is (a class
> with only static methods as its state its spread over N other classes)
> -1- we can already mosaick images with different colormodels (to a
> certain extent, it does not make sense to mosaick a float raster with
> an RGB). RGB, Gray and Palette can be mosaicked as of today
> -4- I would add some UML diagrams to your proposal to show what we
> have now and what we have afterwards
>
> I noticed that you are half-way through with your refactor and its
> probably too early to look into it but I have two things I wanted to
> bring up.
> First of all, I believe you shuold look at the refactor of the
> indexing together with this, I would not split them otherwise your
> refactor in this case could be too narrow.
> Let me explain, your goal here is to improve the harvesting process
> allowing implementors to change how harvested elements are discarded
> as well as how they are preprocessed or manipulated and this is not
> isolated from the harvesting itself.
>
> I believe catalogmanager (although) the nice name, might go away and
> this kind of behavior could be isolated into smaller API likewise we
> did with the properties collector so that one can drop them inside the
> imagemosaic and ask it through the indexmanager to apply them.
> Ideally one could rather write its one harvester and completely
> customize how we put things inside the GranuleCatalog.
>
> Let me know what you think about this.
>
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39 333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a resul

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Jody I'm not sure what a good name for the class is. Its chief
responsibilities (before this proposal) were collecting attributes from the
incoming granule, creating its new feature and updating the GranuleStore,
creating the index schema, and instantiating the GranuleCatalog from the
reader configuration. Now that I type all that out I don't think
CatalogManager is that bad a name?

On Tue, Jun 14, 2016 at 10:42 AM, Jody Garnett <jody.garn...@gmail.com>
wrote:

> I note the prior proposal had CatalogManager renamed to
> GranuleCatalogManager is that still appropriate?
>
> Will you be removing the original proposal then?
>
> --
> Jody Garnett
>
> On 9 June 2016 at 16:39, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Thanks for all the feedback. Like Jody said, we're probably going to
>> break the proposal apart a bit. I've started pulling apart the
>> index/catalog management into its own proposal:
>>
>>
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-Catalog-management-for-improved-extensibility
>>
>> Still a work in progress. Will work on adding code examples for the
>> catalog manager part. In the meantime you can take a look at the WIP here:
>>
>> https://github.com/dvntucker/geotools/tree/im_api_refactor
>>
>> The biggest thing to note is that:
>>
>> - A number of methods in CatalogManager have been changed from static to
>> non-static
>> - CatalogManager has been added as a field to the ImageMosaicConfigHandler
>> - Logic that was in ImageMosaicConfigHandler for checking ColorModel and
>> CRS has been moved to CatalogManager (see the second part of the proposal)
>>
>> Cheers
>>
>> On Wed, Jun 8, 2016 at 1:08 PM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Thanks for email feedback Andrea, Daniele. Had a good chat with Simone
>>> 
>>>
>>> Going to try and break this proposal into three small proposals on 1)
>>> index generation 2) dynamic processing 3) harvest flexibility.
>>>
>>> Some of the functionality (like data prep) is indeed already covered. I
>>> was not aware, for example, that geoserver importer could be used add
>>> granules to an *existing* mosaic (that is not functionality that can be
>>> done for vector import).
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 5 April 2016 at 16:44, Devon Tucker <devonrtuc...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Just noticed that there wasn't a dedicated email thread for this
>>>> proposal and figured I'd kick one off since I've also been involved in it.
>>>>
>>>>
>>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>>>
>>>> I think the description gives a pretty good rationale for what we want
>>>> to accomplish with this proposal and I'd like to solicit any discussion,
>>>> advice, feedback, etc. from everyone.
>>>>
>>>> Cheers,
>>>> Devon
>>>>
>>>>
>>>> --
>>>>
>>>> ___
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>>
>>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal: Refactor ImageMosaic index management

[Devon Tucker]

Hi all,

After discussions about the ImageMosaic API proposal we have decided to
break it up into a few smaller pieces that are hopefully both more
manageable to implement and easier to understand. First up is a proposal to
refactor the ImageMosaic CatalogManager to allow parts of it to be
overridden. The first new proposal is here:











https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility

I've been doing the work on my own branch here:

https://github.com/dvntucker/geotools/tree/im_api_refactor

Further to that, I have another branch where I've been storing R work
done against that branch. Most of that work was done much earlier, but I've
been porting my previous test cases to the new branch as I go along for
verification purposes.

Please take a look and let me know if there's anything that isn't clear.
This proposal is much simpler than the previous one.

Cheers
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Thanks for all the feedback. Like Jody said, we're probably going to break
the proposal apart a bit. I've started pulling apart the index/catalog
management into its own proposal:

https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-Catalog-management-for-improved-extensibility

Still a work in progress. Will work on adding code examples for the catalog
manager part. In the meantime you can take a look at the WIP here:

https://github.com/dvntucker/geotools/tree/im_api_refactor

The biggest thing to note is that:

- A number of methods in CatalogManager have been changed from static to
non-static
- CatalogManager has been added as a field to the ImageMosaicConfigHandler
- Logic that was in ImageMosaicConfigHandler for checking ColorModel and
CRS has been moved to CatalogManager (see the second part of the proposal)

Cheers

On Wed, Jun 8, 2016 at 1:08 PM, Jody Garnett <jody.garn...@gmail.com> wrote:

> Thanks for email feedback Andrea, Daniele. Had a good chat with Simone 
>
> Going to try and break this proposal into three small proposals on 1)
> index generation 2) dynamic processing 3) harvest flexibility.
>
> Some of the functionality (like data prep) is indeed already covered. I
> was not aware, for example, that geoserver importer could be used add
> granules to an *existing* mosaic (that is not functionality that can be
> done for vector import).
>
> --
> Jody Garnett
>
> On 5 April 2016 at 16:44, Devon Tucker <devonrtuc...@gmail.com> wrote:
>
>> Hi all,
>>
>> Just noticed that there wasn't a dedicated email thread for this proposal
>> and figured I'd kick one off since I've also been involved in it.
>>
>>
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>
>> I think the description gives a pretty good rationale for what we want to
>> accomplish with this proposal and I'd like to solicit any discussion,
>> advice, feedback, etc. from everyone.
>>
>> Cheers,
>> Devon
>>
>>
>> --
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Also, would it be possible to get commit access to the gt-dem plugin as
well as a branch created for the ImageMosaic API work?

Thanks,
Devon

On Thu, Jun 2, 2016 at 4:19 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:

> Hi Andrea,
>
> Thanks for the questions.
>
> On Wed, Jun 1, 2016 at 11:02 AM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> Hi Jody,
>> at present I cannot vote on the proposal because I have troubles getting
>> a grip on it.
>>
>> Here are a few things that might help understanding, section by section:
>>
>>- *Description*: this is fine, makes sense, no questions (one thing,
>>the recursive file loading during indexing is already the default behavior
>>as far as I know)
>>- *Index Generation: *quite a bit lost here, how are
>>MosaicIndexConfiguration and GranuleCatalogManager going to be used by the
>>existing classes? Or are they replacing it? I'd need to understand how the
>>existing code is going to get reshuffled into a generic machiner plus
>>default implementations of the two above objects? Also, can you provide an
>>example of an alternate implementation (being the refactor targeted to
>>extensibility)
>>- *Harvesting: *same as above, how is the code going to be moved
>>around, and examples of alternate implementations
>>
>>
> I hope to clarify these parts soon. To be honest, these parts were done
> earlier in the project and we've zig-zagged multiple times since then, so
> even I need to revisit to solidify and clarify this section. To give some
> perspective on the original motivations behind this part, at the time we
> were:
>
> - Performing some pre-processing on rasters before indexing them (adding
> overlays, creating alpha bands, generating elevation outlier footprints)
> - Collecting custom properties from rasters during indexing (resolution,
> date stamps, various tiff metadata, sample date, etc.)
> - Looking at harvesting granules on demand either via. rest or the
> geoserver UI.
> - Exposing more of this configuration through a custom store and layer
> config in GeoServer.
> - Index generation code is very isolated as it stands. It's tough to
> programmatically configure index generation.
>
>
>>
>>- *Delegate coverage acceptance/rejection to a predicate object*:
>>makes sense I guess, so the reason to have this plugable is because you
>>might roll a collector that has less limitations than the default ones?
>>
>> Exactly.
>
>>
>>- *Pre-process Granule Footprint Before Indexing*: makes sense,
>>thinking out loud is the footprint the only thing that needs reprocessing?
>>
>> No, it's not really the only thing that need reprocessing. In fact
> PropertyCollectors have a tangentially related responsibility (and are used
> in roughly the same spot). Maybe this functionality could be combined
> somehow, and make monolithic some sort of monolithic visitor which would be
> responsible for:
>
> - Collecting properties from granules
> - Pre-processing the granule footprint if needed
> - Populating the index feature
>
> And so on. I'll have to think about this one a bit more, but as the
> proposal stands at least FootprintProcessor has a very clear responsibility.
>
>>
>>- *Generalize Mosaicking per GranuleCollector and Update
>>GranuleCollector to a tree-like hierarchy*: an example would be useful
>>
>> I can do an example for this. The motivation here is to delegate the
> actual mosaicking to an object which may internally be delegating to other
> mosaicking objects. For example, the default implementation would have the
> logic for mosaicking per-resolution first, then resampling and mosaicking
> those results.
>
>>
>>- *Enhance the GranuleDescriptor and GranuleCatalogVisitor
>>interfaces: *same as above, examples of these "arbitrary properties"
>>to be used would be useful
>>
>> I will provide examples for this as well. In our RnD it was necessary to
> set the CRS on each granule descriptor.
>
> Hope this clarifies a bit. I expect to be working on this the rest of the
> week and be able to answer remaining questions.
>
> Cheers
>
> Cheers
>> Andrea
>>
>>
>> On Wed, Jun 1, 2016 at 2:48 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Proposal is updated:
>>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>>
>>> I reworded the API change section with clear BEFORE/AFTER descriptions
>>> making it easier to follow. After this I am fa

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Hi Andrea,

Thanks for the questions.

On Wed, Jun 1, 2016 at 11:02 AM, Andrea Aime 
wrote:

> Hi Jody,
> at present I cannot vote on the proposal because I have troubles getting a
> grip on it.
>
> Here are a few things that might help understanding, section by section:
>
>- *Description*: this is fine, makes sense, no questions (one thing,
>the recursive file loading during indexing is already the default behavior
>as far as I know)
>- *Index Generation: *quite a bit lost here, how are
>MosaicIndexConfiguration and GranuleCatalogManager going to be used by the
>existing classes? Or are they replacing it? I'd need to understand how the
>existing code is going to get reshuffled into a generic machiner plus
>default implementations of the two above objects? Also, can you provide an
>example of an alternate implementation (being the refactor targeted to
>extensibility)
>- *Harvesting: *same as above, how is the code going to be moved
>around, and examples of alternate implementations
>
>
I hope to clarify these parts soon. To be honest, these parts were done
earlier in the project and we've zig-zagged multiple times since then, so
even I need to revisit to solidify and clarify this section. To give some
perspective on the original motivations behind this part, at the time we
were:

- Performing some pre-processing on rasters before indexing them (adding
overlays, creating alpha bands, generating elevation outlier footprints)
- Collecting custom properties from rasters during indexing (resolution,
date stamps, various tiff metadata, sample date, etc.)
- Looking at harvesting granules on demand either via. rest or the
geoserver UI.
- Exposing more of this configuration through a custom store and layer
config in GeoServer.
- Index generation code is very isolated as it stands. It's tough to
programmatically configure index generation.


>
>- *Delegate coverage acceptance/rejection to a predicate object*:
>makes sense I guess, so the reason to have this plugable is because you
>might roll a collector that has less limitations than the default ones?
>
> Exactly.

>
>- *Pre-process Granule Footprint Before Indexing*: makes sense,
>thinking out loud is the footprint the only thing that needs reprocessing?
>
> No, it's not really the only thing that need reprocessing. In fact
PropertyCollectors have a tangentially related responsibility (and are used
in roughly the same spot). Maybe this functionality could be combined
somehow, and make monolithic some sort of monolithic visitor which would be
responsible for:

- Collecting properties from granules
- Pre-processing the granule footprint if needed
- Populating the index feature

And so on. I'll have to think about this one a bit more, but as the
proposal stands at least FootprintProcessor has a very clear responsibility.

>
>- *Generalize Mosaicking per GranuleCollector and Update
>GranuleCollector to a tree-like hierarchy*: an example would be useful
>
> I can do an example for this. The motivation here is to delegate the
actual mosaicking to an object which may internally be delegating to other
mosaicking objects. For example, the default implementation would have the
logic for mosaicking per-resolution first, then resampling and mosaicking
those results.

>
>- *Enhance the GranuleDescriptor and GranuleCatalogVisitor interfaces:
>*same as above, examples of these "arbitrary properties" to be used
>would be useful
>
> I will provide examples for this as well. In our RnD it was necessary to
set the CRS on each granule descriptor.

Hope this clarifies a bit. I expect to be working on this the rest of the
week and be able to answer remaining questions.

Cheers

Cheers
> Andrea
>
>
> On Wed, Jun 1, 2016 at 2:48 AM, Jody Garnett 
> wrote:
>
>> Proposal is updated:
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>
>> I reworded the API change section with clear BEFORE/AFTER descriptions
>> making it easier to follow. After this I am far more comfortable with the
>> proposal as a whole. I have some specific class naming doubts (is
>> GranuleCatalogManager really a manager) but they can be sorted out during
>> the refactor.
>>
>> +1
>>
>> A couple feedbacks:
>>>
>> - (done) go ahead and merge back to master, we can edit there as a group
>>> :)
>>> - (done) for the API change on MosaicIndexConfiguration - can you take
>>> the cometary out to some bullet points so we can see the proposed class in
>>> one go
>>> - (done) the tasks section seems incomplete, we mostly use this to check
>>> that you have enough resources/time to get the work done
>>> - loadGranuleCatalogFromDataStore seems a bit odd to make, taking a
>>> properties file (I guess of connection parameters) rather than a DataStore?
>>> We have the Repository API that meets this need for app-schema and
>>> pregeneralized datastore (I do not 

[Geotools-devel] [JIRA] (GEOT-5430) ArrayIndexOutOfBoundsException with PerpendicularOffset

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5430  
 
 
  ArrayIndexOutOfBoundsException with PerpendicularOffset   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15.0  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 exception.txt, shore_corrected.zip, shore.sld  
 
 
Components: 
 render  
 
 
Created: 
 01/Jun/16 11:08 PM  
 
 
Environment: 
 Any  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 Browsing a layer with a PerpendicularOffset styling can somtimes cause an ArrayIndexOutOfBoundsException. See the attached log snippet, shapefile, and style. The request itself was: RawKvp =  {REQUEST=GetMap, FORMAT=image/png, SRS=EPSG:2263, BBOX=995646.4764052024,214704.64625684023,999312.2141587015,217931.36311005297, VERSION=1.1.1, STYLES=, SERVICE=WMS, WIDTH=769, HEIGHT=677, TRANSPARENT=true, LAYERS=cite:shore_corrected} It looks like what's going on is that the StreamingRenderer is not checking for an empty geometry after clipping, which seems to occur if invalid geometries are either present in the feature itself, or if they are produced by some of the simplifications involved (even when the clipping is done "safely" by buffering to feature by zero to fix it). The uploaded shapefile reports no invalid features according to GDAL/OGR. I have a fix for this issue r

Re: [Geotools-devel] GeoTools 15.0 Released

[Devon Tucker]

Whoops, stripped out some formatting in the email, here are the links to
the downloads:


   - geotools-15.0-bin.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-bin.zip/download>
   - geotools-15.0-doc.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-doc.zip/download>
   - geotools-15.0-userguide.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-project.zip/download>
   - geotools-15.0-project.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-project.zip/download>


On Mon, May 30, 2016 at 2:56 PM, Devon Tucker <devonrtuc...@gmail.com>
wrote:

> GeoTools 15.0 Released
>
> The GeoTools team is pleased to announce GeoTools 15.0!
>
> geotools-15.0-bin.zip
> geotools-15.0-doc.zip
> geotools-15.0-userguide.zip
> geotools-15.0-project.zip
>
> This release is also available from our Maven repository. Java 8 is now
> required, please view the install guide for details.
>
> http://geotoolsnews.blogspot.ca/2016/05/geotools-150-released_30.html
>
> Cheers
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] GeoTools 15.0 Released

[Devon Tucker]

GeoTools 15.0 Released

The GeoTools team is pleased to announce GeoTools 15.0!

geotools-15.0-bin.zip
geotools-15.0-doc.zip
geotools-15.0-userguide.zip
geotools-15.0-project.zip

This release is also available from our Maven repository. Java 8 is now
required, please view the install guide for details.

http://geotoolsnews.blogspot.ca/2016/05/geotools-150-released_30.html

Cheers
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] 15.0 Release blog draft

[Devon Tucker]

Hey all,

Jody enlisted me to help with the GeoTools release. I've got a draft of the
release blog post ready and would like some feedback on it, especially if
you know of any interesting new features or bug fixes that we should
highlight.

If you have access to the GeoTools Blogger account you can check it out
there, otherwise I'll paste the text here:

The GeoTools team is pleased to announce GeoTools 14-RC1:

   - geotools-15.0-bin.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-bin.zip/download>
   - geotools-15.0-doc.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-doc.zip/download>
   - geotools-15.0-userguide.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-project.zip/download>
   - geotools-15.0-project.zip
   
<https://sourceforge.net/projects/geotools/files/GeoTools%2015%20Releases/15.0/geotools-15.0-project.zip/download>

This release is also available from our Maven repository
<http://download.osgeo.org/webdav/geotools/>.


This release is made by Jody Garnett and Devon Tucker (Boundless) in
conjunction with GeoWebCache 1.9.0 and GeoServer 2.9.0


New features and improvements:

   - Support for perpendicular offset in SLD
   - Support sinusoidal projection in GeoTIFF
   - Support Vector footprints in GDAL plugin
   - Add a group by visitor in JDBC
   - Add compatibility for negative date and XDate type in JDBC datastore
   - New and improved support for Rotated Pole Projection
   - Ignore NetCDF grid_mapping_name that is present but unsupported
   - Allow users to zoom in and out using the mouse scroll wheel in
   JMapPane



Bug fixes:

   - ImageWorker equates setting background values to setting NoData
   - JDBCDataStore initialization not thread-save
   - GridCoverage2DRIA can leave border operations in the tile cache
   without disposing them
   - LikeFilter fails with unicode chars (Ñ...)
   - Speed up rendering SVGs as graphic fills over complex geometries
   - SimpleDateFormat string has MONTH (MM) and Minutes (mm) swapped in
   GeoPackage
   - GeometryClipper can generate polygons without any inner area, laid on
   the clipping area border
   - ProcessFunctionFactory is not robust to failing processes


And more! For more information see 15.0 release notes
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?projectId=10001=13002>
as well as the release notes for M0
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=11402==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3%7Clout>,
Beta 1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12101==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3%7Clout>,
Beta 2
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12601==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3%7Clout>
and RC1
<https://osgeo-org.atlassian.net/secure/ReleaseNote.jspa?version=12900==10001=Create_token=BMGO-EVM2-SZYH-VJUH%7C3d37bc9c7749ef20bde1d4b83ac230c95ac1efc3%7Clout>
.
About GeoTools 15

GeoTools 15 features and improvements:

   - Java 8 is now required. Please view the install guide
   <http://docs.geotools.org/latest/userguide/build/install/index.html> for
   details.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Hi all,

I've been working on fleshing this proposal out and adding a bit to it. See
the conversation on on-the-fly reprojection in ImageMosaic. My updated API
proposal is on my own Wiki for now, I can update the master one but I
wanted to solicit early feedback. Please let me know if something doesn't
make sense. Wanted to throw it out there earlier for feedback rather than
later:

https://github.com/dvntucker/geotools/wiki/Refactor-ImageMosaic-for-extensibility

Cheers,
Devon

On Fri, Apr 22, 2016 at 1:20 AM, Niels Charlier  wrote:

> On 21-04-16 20:01, Jody Garnett wrote:
>
> Thanks for the clarification Niels, I was not aware that Prop was part of
> the current API.
>
> Still we have some duplication here right? Should we try running the
> property collectors, look at the results, and generate the schema
> appropriate to store the results?
>
>
> Jody, have a look at this:
> http://geoserver.geo-solutions.it/multidim/en/imagemosaic/mosaic_indexer.html#imagemosaic-xml-indexer-example
> You see that in the current index configuration file, there is a separate
> section for the schemas and the property collectors. Both sections provide
> a completely different kind of information.
>
> I do not think that there is duplication. You cannot run property
> collectors if you do not have a schema yet. The property collectors are run
> per feature (granule). The schema is made before you can even create
> features. The schema is defined per coverage inside the store and can
> differ between them. The property collectors are unaware of the coverages,
> and they may operate for multiple. Once the schema has been created for a
> coverage, the features are created and then values might be needed for each
> feature. This is the time that (for some properties) the appropriate
> property collectors are looked up and called to fill in those values.
> In summary:
> the schema -> defines the metadata (table structure) of the index per
> coverage
> the property collectors -> defines how to grab the data for the index
> (from the metadata of the granules)
> two different functions altogether.
>
>
>
>
> --
> Jody Garnett
>
> On 21 April 2016 at 03:00, Niels Charlier  wrote:
>
>> On 17-04-16 04:17, Jody Garnett wrote:
>>
>>> This proposal (and email thread) should be orthogonal to the RnD
>>> discussion on setting up a mosaic with multiple projections.
>>>
>>> This mosaic is focused on creating/managing the index used. One part I
>>> cannot wrap my head around is the workflow behind these two methods -
>>> createSchema(String name, CoordinateReferenceSystem crs) which creates the
>>> FeatureType used for the index, and Collection
>>> getPropertiesCollectors().
>>> It seems these two methods need to be implemented together, a single
>>> PropertyCollector may collect more than once value on examining a raster. I
>>> am not sure how to line up these collected values with the created schema
>>> without more information.
>>>
>>
>> Just to be clear, the proposal doesn't change anything about
>> PropertyCollectors work. This would simply continue to work as it is
>> working right now, until somebody makes a proposal to change it to
>> something else!
>>
>> These two things have a completely different function. The schema defines
>> the structure of the index.
>>
>> Property Collectors are customisable mechanisms that provides (some of
>> the) values of the index per granule, taking information from the file
>> and/or the coverage metadata.
>>
>> The schema creation includes attributes that are not collected with a
>> PropertyCollector (such as location), while one Propery Collector can
>> potentially supply multiple attribute values.
>>
>>
>>  We also have String getParameter(Prop prop) defined, but the class Prop
>>> is not included in the proposal.
>>>
>>
>> Prop already exists in the current API.
>>
>>
>>> Suggestions:
>>> - Use a list of PropertiesCollectors to provide order, which can then be
>>> used to determine the Schema?
>>> - Language consistency - raster / granule
>>> - Language consistency - could we use AttributeDescriptor rather than
>>> introduce a new thing called "Prop" ?
>>>
>>
>> You do know that Props are configuration properties, nothing to do with
>> features?
>>
>> - Are the class responsibilities clear: GranuleCatalogManager,
>>> GranuleCatalog, GranuleStore, MosaicHarvester, etc...
>>>
>>> (It could also be that since I am unfamiliar with the internals being
>>> refactored that I am just struggling with the language - so if everyone
>>> else is okay ...)
>>>
>>>
>>> Regards
>> Niels
>>
>
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> 

Re: [Geotools-devel] On-the-fly reprojection in ImageMosaic

[Devon Tucker]

Hi all,

Still plugging away at this. I have a rough prototype mostly done that
reprojects on the fly. Been working out of this branch:

https://github.com/dvntucker/geotools/tree/gt-dem-scratch

Keep in mind that's pretty much all prototyping.

Some of the things I've done:

- Update mosaic configuration with declared CRS
- Update the index generation to reproject the individual coverage envelope
into the mosaic CRS
- Reproject the raster as needed. Right now I'm just doing it by loading
the raster up in a GridCoverage and using Resampler2D to reproject it.
Obviously this introduces a dependency on gt-coverage, which I'm not sure
is kosher ultimately, but it was easier than plugging in all the machinery
to do it otherwise.

I think next step is to step back, take some notes and look at refining the
API proposal.

Cheers,
Devon

On Fri, Apr 29, 2016 at 3:47 PM, Devon Tucker <devonrtuc...@gmail.com>
wrote:

> Hi Andrea,
>
> Thanks for the feedback and braindump, much appreciated. I'm back in town
> this week and looking further into this next week. I think we are going to
> be trying to achieve a rough, throw away first pass at this and let that
> inform the existing ImageMosaic API change proposal and further work on
> dynamic reprojection in the ImageMosaic.
>
> Personally I'd like to see the ImageMosaic opened up in such a way that
> dynamic reprojection could be done as a plugin without effectively
> impacting how it currently operates. I'm hoping that sometime next week I
> can take a second pass through Niel's API change proposal and solicit more
> feedback on it.
>
> Cheers,
> Devon
> dtuc...@boundlessgeo.com
>
>
> On Tue, Apr 19, 2016 at 2:50 AM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> On Sun, Apr 17, 2016 at 12:10 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Thanks for the brain dump Andrea (and to Devon for starting this
>>> conversation). The key reason we are reaching out to geotools-devel is the
>>> sheer wasted disk space represented by a static "gdal command line"
>>> solution (which no doubt would perform better).
>>>
>>
>> If you have dynamic stacking order requirements (per user profiling), it
>> would not work regardless
>>
>>
>>>
>>> Devon has been exploring the dynamic approach (using a resample prior to
>>> mosaic) in a branch. We did not consider grouping granules with similar CRS
>>> - as our unsupported/dem use cases focuses on many overlapping granules
>>> that are sorted according to need (resolution, date, etc...).
>>>
>>
>> We have always done this in custom implementations, partly for
>> performance issues, partly for quality ones (black lines and visible seams
>> generally make the result unacceptable, regardless of how fast/slow the
>> solution would be).
>>
>>
>>>
>>> This work will be a balancing between meeting our use-case - and leaving
>>> the design open for other stories that are perhaps more common. Thank you
>>> for the information on "excess granule removal" - while I have identified
>>> it as a risk I am not sure it will be addressed in this first cut.
>>>
>>
>> Roger that
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>&g

Re: [Geotools-devel] On-the-fly reprojection in ImageMosaic

[Devon Tucker]

Hi Andrea,

Thanks for the feedback and braindump, much appreciated. I'm back in town
this week and looking further into this next week. I think we are going to
be trying to achieve a rough, throw away first pass at this and let that
inform the existing ImageMosaic API change proposal and further work on
dynamic reprojection in the ImageMosaic.

Personally I'd like to see the ImageMosaic opened up in such a way that
dynamic reprojection could be done as a plugin without effectively
impacting how it currently operates. I'm hoping that sometime next week I
can take a second pass through Niel's API change proposal and solicit more
feedback on it.

Cheers,
Devon
dtuc...@boundlessgeo.com


On Tue, Apr 19, 2016 at 2:50 AM, Andrea Aime 
wrote:

> On Sun, Apr 17, 2016 at 12:10 AM, Jody Garnett 
> wrote:
>
>> Thanks for the brain dump Andrea (and to Devon for starting this
>> conversation). The key reason we are reaching out to geotools-devel is the
>> sheer wasted disk space represented by a static "gdal command line"
>> solution (which no doubt would perform better).
>>
>
> If you have dynamic stacking order requirements (per user profiling), it
> would not work regardless
>
>
>>
>> Devon has been exploring the dynamic approach (using a resample prior to
>> mosaic) in a branch. We did not consider grouping granules with similar CRS
>> - as our unsupported/dem use cases focuses on many overlapping granules
>> that are sorted according to need (resolution, date, etc...).
>>
>
> We have always done this in custom implementations, partly for performance
> issues, partly for quality ones (black lines and visible seams generally
> make the result unacceptable, regardless of how fast/slow the solution
> would be).
>
>
>>
>> This work will be a balancing between meeting our use-case - and leaving
>> the design open for other stories that are perhaps more common. Thank you
>> for the information on "excess granule removal" - while I have identified
>> it as a risk I am not sure it will be addressed in this first cut.
>>
>
> Roger that
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] On-the-fly reprojection in ImageMosaic

[Devon Tucker]

Hi Simone,

Thanks for the input. I'll take a look at StreamingRenderer although
according to Jody it may not be appropriate since we would like to do WCS
output as well.

Your advice for initially mosaicking by CRS is definitely well-received.
Good idea.

Cheers,
Devon

On Tue, Apr 12, 2016 at 11:03 AM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Ciao Devon,
> quick answer, andrea will provide more.
>
> We have implemented something similar a few times in the past for
> clients specific customizations so we have a pretty clear idea on what
> to do.
> First thing, GeoServer is already able to mosaic raster in different
> CRS but at an higher level, inside the streaming renderer which leans
> onto the streaming renderer for reprojecting.
>
> Bring this at a lower level is challenging if we want to keep both
> performance and quality or at least if we want to be able to control
> them. If I had to suggest something right now, I would suggest to
> group them by source CRS then mosaick them and then reproject each
> mosaic to the target CRS so that raster data in the same CRS with
> different resolutions can be handled separately.
>
> Let's see what andrea says...
>
> Putting this on the table upfront, don't come up with a PR that will
> touch 1k files  (i.e impossible to review) without having discussed
> the approach before because it will hardly be accepted.
> No intent to be a showstopper, I'd like this functionality to get in
> but you are biting on an hard candy trying to implement it.
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39 333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
> On Tue, Apr 12, 2016 at 7:17 PM, Devon Tucker <devonrtuc...@gmail.com>
> wrote:
> > Hi all,
> >
> > We've been looking into doing on-the-fly reprojection in image mosaic to
> > handle multiple projections dynamically (kinda similar to what QGIS can
> do).
> > Some of the issues with this we've worked out already, but one thing I've
> > been wondering is where might be an appropriate place in the code to do
> the
> > actual resampling.
> >
> > My first thought would be somewhere in the RasterLayerResponse either in
> the
> > prepareResponse or produce methods either during or after the granules
> are
> > collected, but I'm definitely interested in advice/feedback on what's
> > good/appropriate.
> >
> > Also interested in feedback on this idea in general and maybe issues or
> > corner cases we may not have thought about.
> >
> 

[Geotools-devel] On-the-fly reprojection in ImageMosaic

[Devon Tucker]

Hi all,

We've been looking into doing on-the-fly reprojection in image mosaic to
handle multiple projections dynamically (kinda similar to what QGIS can
do). Some of the issues with this we've worked out already, but one thing
I've been wondering is where might be an appropriate place in the code to
do the actual resampling.

My first thought would be somewhere in the RasterLayerResponse either in
the prepareResponse or produce methods either during or after the granules
are collected, but I'm definitely interested in advice/feedback on what's
good/appropriate.

Also interested in feedback on this idea in general and maybe issues or
corner cases we may not have thought about.

Thanks,
Devon Tucker
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

For my own part, Niels maybe you could throw in some small examples of how
these API changes would be used in practice to accomplish some of the items
in the description? For example, how could I customize the directory
walking with the new API?

Thanks,
Devon

On Tue, Apr 5, 2016 at 4:44 PM, Devon Tucker <devonrtuc...@gmail.com> wrote:

> Hi all,
>
> Just noticed that there wasn't a dedicated email thread for this proposal
> and figured I'd kick one off since I've also been involved in it.
>
>
> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>
> I think the description gives a pretty good rationale for what we want to
> accomplish with this proposal and I'd like to solicit any discussion,
> advice, feedback, etc. from everyone.
>
> Cheers,
> Devon
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] ImageMosaic API refactor proposal

[Devon Tucker]

Hi all,

Just noticed that there wasn't a dedicated email thread for this proposal
and figured I'd kick one off since I've also been involved in it.

https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility

I think the description gives a pretty good rationale for what we want to
accomplish with this proposal and I'd like to solicit any discussion,
advice, feedback, etc. from everyone.

Cheers,
Devon
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5321) Create a tutorial for CoverageProcessor

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5321  
 
 
  Create a tutorial for CoverageProcessor   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 docs  
 
 
Created: 
 10/Dec/15 7:45 PM  
 
 
Priority: 
  Low  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 jgarnett suggested writing a tutorial covering CoverageProcessor to do operations like crop on a coverage to tile it, similar to gdal_retile.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.0-OD-02-030#71001-sha1:2ba8c0f

[Geotools-devel] [JIRA] (GEOT-5318) GridCoverageRenderer fails on indexed image with null background color

[Devon Tucker (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devon Tucker created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5318  
 
 
  GridCoverageRenderer fails on indexed image with null background color   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 03/Dec/15 12:15 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Devon Tucker  
 

  
 
 
 
 

 
 While fixing GEOS-7270 I found that rendering an coverage with an indexed color model via GridCoverageRenderer.renderImage(reader,...) produced a null pointer exception: 

 

java.lang.NullPointerException: Argument "bgColor" should not be null.
	at org.geotools.resources.image.ColorUtilities.findColorIndex(ColorUtilities.java:506)
	at org.geotools.renderer.lite.gridcoverage2d.GridCoverageRenderer.renderImage(GridCoverageRenderer.java:822)
 

 The problem comes from attempting to expand the color model on an indexed raster even when a background color hasn't been provided.  
 

  
 
 
 
 

 
 
 

 
 
 A

[Geotools-devel] [JIRA] (GEOT-5284) Sun Coding Conventions link incorrect on Coding Style docs

[Devon Tucker (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Devon Tucker created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5284 
 
 
 
  Sun Coding Conventions link incorrect on Coding Style docs  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 docs 
 
 
 

Created:
 

 06/Nov/15 12:40 AM 
 
 
 

Environment:
 
 
Any 
 
 
 

Priority:
 
  Low 
 
 
 

Reporter:
 
 Devon Tucker 
 
 
 
 
 
 
 
 
 
 
The Sun Coding Conventions link in the Coding Style documentation doesn't work: 
http://docs.geotools.org/latest/developer/conventions/code/style.html 
Points to http://java.sun.com/docs/codeconv/ which in turn redirects to the Oracle TN homepage (http://www.oracle.com/technetwork/java/index.html). 
I THINK this is the intended link: 
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html 
However, I'm not sure how appropriate it is to link to coding conventions that are so out of date