[Geotools-devel] [JIRA] (GEOT-5647) Support ESRI substitute for EPSG:3857

2017-02-13 Thread Andrea Aime [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5647  
 
 
  Support ESRI substitute for EPSG:3857   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 referencing  
 
 
Created: 
 13/Feb/17 7:38 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 This is what ESRI uses for EPSG:3857: "PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]" Other software like proj learned to parse this, we should try too.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] JDBC Callbacks

2017-02-13 Thread Justin Deoliveira 
Thanks Andrea!

I’ll definitely update the proposal to make it clear that what is being
covered is just the “simple case”. Part of the rationale of the factory was
that we could eventually add new callback interfaces as needed, so there
should be some room to “grow” to account for this other stuff.

-Justin

On Mon, Feb 13, 2017 at 7:49 AM Andrea Aime 
wrote:

> Hi Justin,
> had a quick look, the proposal looks good to me.
> From an implementation point of view, what about joins, aggregate queries
> being optimized out, and the like? (maybe also writing)
> I believe you don't intend to cover them, I'd suggest to update the
> proposal so that it makes it clear those are left out intentionally
> (although, for aggregations for example, a superclass of the current
> reader callback could be used, just thinking out loud here, this
> is not a request for change).
>
> Cheers
> Andrea
>
>
> On Mon, Feb 13, 2017 at 2:25 PM, Justin Deoliveira 
> wrote:
>
> Hi folks,
>
> I’ve incorporated Jody’s feedback and updated the proposal, and submitted
> a pull request.
>
>   https://github.com/geotools/geotools/pull/1474
>
> I’ll let this one simmer for a day or so and if I don’t get any more
> feedback I’ll call for the official vote.
>
> Thanks!
>
> -Justin
>
> On Thu, Feb 9, 2017 at 1:07 PM Justin Deoliveira 
> wrote:
>
> Hey Jody, thanks for the feedback.
>
> Answers inline.
>
> On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett 
> wrote:
>
> Thanks Justin,
>
> Some questions:
> - Does your before query and after query methods ... need an indication of
> what the sql query is?
>
> Yeah, we should probably pass in some context about the query being
> executed, as well as with the other callbacks. I will work on that.
>
> - I also note that our GeoTools Query data structure provides a "name"
> that is intended to be used for logging, callbacks, and so on - you may
> wish to make use of it?
>
> Good idea, I think that gets passed all the way down to the reader? If so
> I’ll pass that through as well.
>
> - Why does the factory need a name?
>
>
> So that it can be specified via data store parameter or system property.
> For example if my callback factory is named “foo” i want to enable it via
> “gt2.jdbc.callback=foo”.  Perhaps “id” would be a better property name?
>
>
> --
> Jody Garnett
>
> On 9 February 2017 at 06:39, Justin Deoliveira  wrote:
>
> Hi folks,
>
> A while back I sent some email about adding some code to the jdbc
> datastores to facilitate the idea of capturing metrics for jdbc data
> access. Here is what I have come up with in terms of a proposal.
>
>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
>
> Looking forward to getting some feedback.
>
> Thanks!
>
> -Justin
>
>
> --
> 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
>
>
>
>
> --
> ==
> 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 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

Re: [Geotools-devel] JDBC Callbacks

2017-02-13 Thread Andrea Aime 
Hi Justin,
had a quick look, the proposal looks good to me.
>From an implementation point of view, what about joins, aggregate queries
being optimized out, and the like? (maybe also writing)
I believe you don't intend to cover them, I'd suggest to update the
proposal so that it makes it clear those are left out intentionally
(although, for aggregations for example, a superclass of the current reader
callback could be used, just thinking out loud here, this
is not a request for change).

Cheers
Andrea


On Mon, Feb 13, 2017 at 2:25 PM, Justin Deoliveira 
wrote:

> Hi folks,
>
> I’ve incorporated Jody’s feedback and updated the proposal, and submitted
> a pull request.
>
>   https://github.com/geotools/geotools/pull/1474
>
> I’ll let this one simmer for a day or so and if I don’t get any more
> feedback I’ll call for the official vote.
>
> Thanks!
>
> -Justin
>
> On Thu, Feb 9, 2017 at 1:07 PM Justin Deoliveira 
> wrote:
>
>> Hey Jody, thanks for the feedback.
>>
>> Answers inline.
>>
>> On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett 
>> wrote:
>>
>> Thanks Justin,
>>
>> Some questions:
>> - Does your before query and after query methods ... need an indication
>> of what the sql query is?
>>
>> Yeah, we should probably pass in some context about the query being
>> executed, as well as with the other callbacks. I will work on that.
>>
>> - I also note that our GeoTools Query data structure provides a "name"
>> that is intended to be used for logging, callbacks, and so on - you may
>> wish to make use of it?
>>
>> Good idea, I think that gets passed all the way down to the reader? If so
>> I’ll pass that through as well.
>>
>> - Why does the factory need a name?
>>
>>
>> So that it can be specified via data store parameter or system property.
>> For example if my callback factory is named “foo” i want to enable it via
>> “gt2.jdbc.callback=foo”.  Perhaps “id” would be a better property name?
>>
>>
>> --
>> Jody Garnett
>>
>> On 9 February 2017 at 06:39, Justin Deoliveira 
>> wrote:
>>
>> Hi folks,
>>
>> A while back I sent some email about adding some code to the jdbc
>> datastores to facilitate the idea of capturing metrics for jdbc data
>> access. Here is what I have come up with in terms of a proposal.
>>
>>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
>>
>> Looking forward to getting some feedback.
>>
>> Thanks!
>>
>> -Justin
>>
>> 
>> --
>> 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
>
>


-- 
==
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

[Geotools-devel] [JIRA] (GEOT-5646) Make GridCoverarageRenderer turn nodata/out of ROI pixels into transparent before rendering onto Graphics2D

2017-02-13 Thread Andrea Aime [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5646  
 
 
  Make GridCoverarageRenderer turn nodata/out of ROI pixels into transparent before rendering onto Graphics2D   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 13/Feb/17 3:14 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 Right now the image is renderer as is, but Graphics2D.drawRendereredImage does not know how to handle neither nodata nor ROI  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by

Re: [Geotools-devel] JDBC Callbacks

2017-02-13 Thread Justin Deoliveira 
Hi folks,

I’ve incorporated Jody’s feedback and updated the proposal, and submitted a
pull request.

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

I’ll let this one simmer for a day or so and if I don’t get any more
feedback I’ll call for the official vote.

Thanks!

-Justin

On Thu, Feb 9, 2017 at 1:07 PM Justin Deoliveira  wrote:

> Hey Jody, thanks for the feedback.
>
> Answers inline.
>
> On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett 
> wrote:
>
> Thanks Justin,
>
> Some questions:
> - Does your before query and after query methods ... need an indication of
> what the sql query is?
>
> Yeah, we should probably pass in some context about the query being
> executed, as well as with the other callbacks. I will work on that.
>
> - I also note that our GeoTools Query data structure provides a "name"
> that is intended to be used for logging, callbacks, and so on - you may
> wish to make use of it?
>
> Good idea, I think that gets passed all the way down to the reader? If so
> I’ll pass that through as well.
>
> - Why does the factory need a name?
>
>
> So that it can be specified via data store parameter or system property.
> For example if my callback factory is named “foo” i want to enable it via
> “gt2.jdbc.callback=foo”.  Perhaps “id” would be a better property name?
>
>
> --
> Jody Garnett
>
> On 9 February 2017 at 06:39, Justin Deoliveira  wrote:
>
> Hi folks,
>
> A while back I sent some email about adding some code to the jdbc
> datastores to facilitate the idea of capturing metrics for jdbc data
> access. Here is what I have come up with in terms of a proposal.
>
>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
>
> Looking forward to getting some feedback.
>
> Thanks!
>
> -Justin
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5645) GridCoverageRenderer needs to set a ROI on each reprojection to account for valid pixels

2017-02-13 Thread Andrea Aime [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5645  
 
 
  GridCoverageRenderer needs to set a ROI on each reprojection to account for valid pixels   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 13/Feb/17 10:52 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 Right now the ROI is set only when multiple coverages need to be reprojected (due to multiple reads happening as an effect of advanced projection handling). Set the ROI anyways to allow for proper transparency handling  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geotools-devel] [JIRA] (GEOT-5644) Merge/affine reduction may lose background pixel values

2017-02-13 Thread Andrea Aime [Administrator] (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrea Aime [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5644  
 
 
  Merge/affine reduction may lose background pixel values   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 coverage  
 
 
Created: 
 13/Feb/17 10:41 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Andrea Aime [Administrator]  
 

  
 
 
 
 

 
 While performing the warp/affine reduction the background values set in the warp are lost, causing transparency issues later down the road  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA