[Geotools-devel] Proposal: SQL Encoding of Vendor Provided Custom Functions

[Carsten Klein]

Hi there,

first, many thanks for giving attention to this proposal :-)

Basically, I will be fine with any solution or modification of the 
proposal, as long as "SQL Encoding of Vendor Provided Custom Functions" 
will be the outcome of the change.


See remarks inline and some summary below:


Discussion:

 *

Jody would like to avoid functionality that only works in PostGIS
(for example?) to avoid breaking WFS. *Agree. I guess, this
requires using per-datastore tag interfaces.*

 *

Apparently this is already the case with some placeholder
functions (KNN for example)

 *

Why? Because then the WFS GetCapabilities advertises functionality
that “does not work” (this is somewhat a limitation of the WFS
standard)

 *

Still the  approach could be okay for GeoTools Java programmers,
but does it really affect GeoServer?


What to do?

 *

SLD already has a mechanism for this? Providing a “fallback value”
if the function is not available in that context … *Havn't looked
into SLD implementation that deep. The Function interface has
support for a fallback value. However, don't know whether SLD
supports specifying a function's fallback value. *

 *

We could use the marker interface to avoid listing these functions
in WFS GetCapabilities *We could even invert this and could by
default not list any of these custom functions (the marker
interface could then trigger the function being listed) *


Goal is to make the SQL generation / encoding extensible:

 *

seems okay; but is “per datastore” *Yes. That is because GeoTool's
SQL function encoding is already "per datastore" and this proposal
is just a small addition to it. *

 *

even that should be fine as long as their is a java fallback so it
can be listed in WFS GetCapabilities

 *

If there is no fallback java implementation? Do not list in WFS
GetCapabilities, but could be used in SLD (if there is a fallback
value for safety) *The latter two points are to the vendor's
discretion (using the marker interface) *


The limitations about exact function name match?

 *

that is not so good as different databases may have different
function names, or small SQL snippets … *With real project
specific custom functions, one could likely always arrange it so
that the GeoTools function name equals the SQL function's name.
However, this could be done (see below). But, is it really worth it? *


Jody: WIth the changes above I think this could be a good addition…


Action: Wait for Carsten to read the above SQL Function discussion, 
and we can discuss further in email




*Fallback Value and WFS GetCapabilities - Summary*

If your biggest concern is, that a function listed in WFS 
GetCapabilities will not work with *any* datastore, the simplest 
solution could be to generally avoid listing these functions tagged with 
the SQLEncodableFunction interface (with no exception using another 
marker interface).


Using per-datastore tag interfaces (in contrast to one global tag 
interface SQLEncodableFunction) could at least prevent SQL encoding for 
those datastores, whose tag interfaces the function's class does not 
explicitly implement. Without SQL encoding, the function's Java 
implementation is responsible for generating its return value.


However, with SQL encoding of custom functions, there's always the 
chance of failure if the SQL function is not available in a certain 
database.


*
*

*The limitations about exact function name match*

Simple would be to allow for a different function name in SQL. We could 
add a method getSQLFunctionName() to (super) interface 
SQLEncodableFunction. Then, in method getFunctionName(Function function) 
in class org.geotools.data.jdbc.FilterToSQL (not "per-datastore"!) we 
check whether the function is an instance of this interface, get the SQL 
function name and return that if it's not null. By using another new 
interface for that renaming purpose, this feature would be available for 
all functions (independent from this proposal).


More complex would it be to let the function's implementing class 
serialize the whole function call on its own (like in e.g. 
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-oracle/src/main/java/org/geotools/data/oracle/OracleFilterToSQL.java#L217). 
As with the simple SQL name replacement above, a new method


public Object visit(Function function, Object extraData, FilterToSQL 
filterToSQL, [DatastoreType datastoreType])


could be declared. Details to be clarified.

This method could even be called datastore independently from 
org.geotools.data.jdbc.FilterToSQL.visit(Function function, Object 
extraData). However, it would be good to know for what 
datastore/database this encoding is for. I've found nothing in 
org.geotools.data.jdbc.FilterToSQL that could give us the datastore or 
its type. Likely passing the store type as well requires calling this 

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

[Torben Barsballe]

+1

Cheers,
Torben

On Fri, Oct 28, 2022 at 11:36 AM Jody Garnett 
wrote:

> Proposal is available:
>
>- https://github.com/geotools/geotools/wiki/Java-11-LTS
>- https://osgeo-org.atlassian.net/browse/GEOT-7254
>- Prior discussion is here
>
> 
>
>
> PMC members are asked to respond by Nov 12th:
>
>- Andrea Aime
>- Ian Turton
>- Jody Garnett +1 initial proposal
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> Community support and discussion of this proposal is welcomed.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

[Andrea Aime]

I've made a draft PR for the switch here:

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

Updates pom files, github actions, and documentation. The tutorials need to
be re-tested, some of them seem really outdated
(I've made a brief attempt on Windows and things have changed significantly
there, but not an end to end test)

Cheers
Andrea

On Fri, Oct 28, 2022 at 8:36 PM Jody Garnett  wrote:

> Proposal is available:
>
>- https://github.com/geotools/geotools/wiki/Java-11-LTS
>- https://osgeo-org.atlassian.net/browse/GEOT-7254
>- Prior discussion is here
>
> 
>
>
> PMC members are asked to respond by Nov 12th:
>
>- Andrea Aime
>- Ian Turton
>- Jody Garnett +1 initial proposal
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> Community support and discussion of this proposal is welcomed.
> --
> Jody Garnett
> ___
> 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://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

[Nuno Oliveira]

+1, assuming that this proposal is for GeoTools 29.0

On Sat, Oct 29, 2022 at 1:54 PM Ian Turton  wrote:

> +1
>
> Ian
>
> On Fri, 28 Oct 2022, 19:36 Jody Garnett,  wrote:
>
>> Proposal is available:
>>
>>- https://github.com/geotools/geotools/wiki/Java-11-LTS
>>- https://osgeo-org.atlassian.net/browse/GEOT-7254
>>- Prior discussion is here
>>
>> 
>>
>>
>> PMC members are asked to respond by Nov 12th:
>>
>>- Andrea Aime
>>- Ian Turton
>>- Jody Garnett +1 initial proposal
>>- Nuno Oliveira
>>- Simone Giannecchini
>>- Torben Barsballe
>>
>> Community support and discussion of this proposal is welcomed.
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 

Regards,

Nuno Oliveira

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Technical Lead / Project Manager


GeoSolutions Group
phone: +39 0584 962313
fax:  +39 0584 1660272

https://www.geosolutionsgroup.com/
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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

[Ian Turton]

+1

Ian

On Fri, 28 Oct 2022, 19:36 Jody Garnett,  wrote:

> Proposal is available:
>
>- https://github.com/geotools/geotools/wiki/Java-11-LTS
>- https://osgeo-org.atlassian.net/browse/GEOT-7254
>- Prior discussion is here
>
> 
>
>
> PMC members are asked to respond by Nov 12th:
>
>- Andrea Aime
>- Ian Turton
>- Jody Garnett +1 initial proposal
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> Community support and discussion of this proposal is welcomed.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

[Jody Garnett]

Proposal is available:

   - https://github.com/geotools/geotools/wiki/Java-11-LTS
   - https://osgeo-org.atlassian.net/browse/GEOT-7254
   - Prior discussion is here
   



PMC members are asked to respond by Nov 12th:

   - Andrea Aime
   - Ian Turton
   - Jody Garnett +1 initial proposal
   - Nuno Oliveira
   - Simone Giannecchini
   - Torben Barsballe

Community support and discussion of this proposal is welcomed.
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal for the HTTPResponse interface

[Roar Brænden]

Thanks for the feedback, Jody!

First off, there are cases when the HTTPResponse is wrapped over a 
FileInputStream. Maybe it's mostly for unit tests, but I think I've seen it in 
other situations (like caching perhaps).
Therefore I intentionally avoided the getStatusCode method, but surely we could 
introduce it, and simply return 200 or 404 in cases we have a FileInputStream.

Still I would like to keep the isOK as the main method to check if the server 
has given a good response. I haven't settled on any list of status codes were 
isOK should return true. I'm open for suggestions, but a minimum would be that 
SimpleHttpResponse want throw an exception when calling getInputStream. I'm 
also thinking that we should have that method open for overrides by subclasses, 
and let them decide if the response is OK.

When it comes to the redirects, I think they should be handled by the 
delegating http client. And I think they do.

I will have another look at the examples, and also your suggestion with 
getResponseStream(boolean allowErrorResponse).

Best regards,

Roar Brænden



> 27. mai 2022 kl. 04:32 skrev Jody Garnett :
> 
> Thanks for the proposal Roar:
> 
> The GeoTools wiki is not restricted, we can consider setting that up as 
> needed.
> 
> If I understand correctly the proposal is:
> boolean isOK(): returns true for HTTP status 200
> not quite sure if you want to consider some of the other success codes such 
> as 201 here also?
> Can/should this handle redirects?
> InputStream getErrorStream(): provides the error response content when isOK() 
> false
> Unclear what this does if isOK() true? Do you wish to throw an exception to 
> indicate error stream is not available?
> InputStream getResponseStream(): provides the response when isOK() is true, 
> or throws an IOException (presumably with the contents of the error response?)
> Glad your proposal includes examples:
> - Where we would parse a ServiceException: Before and after show different 
> logic (the first assumes failure)
> - Where we can't handle the error response.: Does not show use of 
> getErrorStream()
> 
> Let me try and write an example that uses both getErrorStream() and 
> getResponseStream() to see if I understand the proposal:
> 
> try {
> if (httpResponse.isOK()) {
> return ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
> }
> else {
> if 
> ("application/vnd.ogc.se_xml".equalsIgnoreCase(httpResponse.getContentType()))
>  {
> throw parseXMLException(httpResponse.getErrorStream());
> }
> else if 
> (httpResponse.getContentType().toLowerCase().startsWith("text/")){
> throw parseException(httpResponse.getErrorStream());
> }
>else {
> throw new IOException("Server returned error on request");
> }
> } finally {
> httpResponse.dispose();
> }
> 
> 
> Feedback:
> - This is an HTTP Request, can we just see the response code? If we had a 
> status code isOK() becomes making a check against Arrays.asList(200,201,203);
> - Your ticket examples with HTTP 400 and 415 requests do not seem to be 
> addressed here?
> - Tempting to document httpResponse.getContentType() as returning lowercase 
> to avoid requiring equalsIgnoreCase() and toLowerCase() be used by all client 
> code ever
> - Having two method names is difficult, and it maybe easier for users of the 
> API if you added httpResponse.getResponseStream(boolean allowsErrorResponse)
> - Even better would be httpResponse.getResponseStream(int httpStatusCode ) 
> providing you make the status code available
> 
> Putting these ideas together:
> 
> try {
> if (httpResponse.getStatus() == 200) {
> return ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
> }
> if (httpResponse.getStatus() == 400) {
> if 
> ("application/vnd.ogc.se_xml".equals(httpResponse.getContentType())) {
> String message = 
> parseXmlException(httpResponse.getErrorStream(400));
> throw new HttpException(400,message);
> }
> else if (httpResponse.getContentType().startsWith("text/")){
> String message = 
> parseTextException(httpResponse.getErrorStream(400)); 
> throw new HttpException(400,message);
> }
>}
>throw new HttpException(httpResponse.getStatus(),"Couldn't get image of 
> tile: " + tile.getId());
> } finally {
> httpResponse.dispose();
> }
> 
> Food for thought.
> --
> Jody Garnett
> 
> 
> On Wed, 25 May 2022 at 00:34, Roar Brænden  > wrote:
> Hi,
> 
> I have a Proposal for the gt-http library. More specific the HTTPResponse 
> interface. I followed the instructions at the Wiki page, and created a New 
> Page, but when I clicked Save Page I didn't get a Pull Request as the 
> instructions indicated. It seems like the Page was created and freely visible.
> 
> https://github.com/geotools/geotools/wiki/HTTPResponse-handling-error-responses
>  

Re: [Geotools-devel] Proposal for the HTTPResponse interface

[Jody Garnett]

Just saw my example was messed up, now uses httpResponse.getResponseStream
consistently:

try {
if (httpResponse.getStatus() == 200) {
return
ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
}
if (httpResponse.getStatus() == 400) {
if
("application/vnd.ogc.se_xml".equals(httpResponse.getContentType())) {
String message =
parseXmlException(httpResponse.getResponseStream(400));
throw new HttpException(400,message);
}
else if (httpResponse.getContentType().startsWith("text/")){
String message =
parseTextException(httpResponse.getResponseStream(400));
throw new HttpException(400,message);
}
   }
   throw new HttpException(httpResponse.getStatus(),"Couldn't get image of
tile: " + tile.getId());
} finally {
httpResponse.dispose();
}

--
Jody Garnett


On Thu, 26 May 2022 at 19:32, Jody Garnett  wrote:

> Thanks for the proposal Roar:
>
> The GeoTools wiki is not restricted, we can consider setting that up as
> needed.
>
> If I understand correctly the proposal is:
>
>- boolean *isOK()*: returns true for HTTP status 200
>   - not quite sure if you want to consider some of the other success
>   codes such as 201 here also?
>   - Can/should this handle redirects?
>- InputStream *getErrorStream()*: provides the error response content
>when isOK() false
>   - Unclear what this does if isOK() true? Do you wish to throw an
>   exception to indicate error stream is not available?
>- InputStream *getResponseStream()*: provides the response when isOK()
>is true, or throws an IOException (presumably with the contents of the
>error response?)
>
> Glad your proposal includes examples:
> - Where we would parse a ServiceException: Before and after show different
> logic (the first assumes failure)
> - Where we can't handle the error response.: Does not show use
> of getErrorStream()
>
> Let me try and write an example that uses both getErrorStream() and
> getResponseStream() to see if I understand the proposal:
>
> try {
> if (httpResponse.isOK()) {
> return
> ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
> }
> else {
> if
> ("application/vnd.ogc.se_xml".equalsIgnoreCase(httpResponse.getContentType()))
> {
> throw parseXMLException(httpResponse.getErrorStream());
> }
> else if
> (httpResponse.getContentType().toLowerCase().startsWith("text/")){
> throw parseException(httpResponse.getErrorStream());
> }
>else {
> throw new IOException("Server returned error on request");
> }
> } finally {
> httpResponse.dispose();
> }
>
>
> Feedback:
> - This is an HTTP Request, can we just see the response code? If we had a
> status code isOK() becomes making a check against
> Arrays.asList(200,201,203);
> - Your ticket examples with HTTP 400 and 415 requests do not seem to be
> addressed here?
> - Tempting to document httpResponse.getContentType() as returning
> lowercase to avoid requiring equalsIgnoreCase() and toLowerCase() be used
> by all client code ever
> - Having two method names is difficult, and it maybe easier for users of
> the API if you added httpResponse.getResponseStream(boolean
> allowsErrorResponse)
> - Even better would be httpResponse.getResponseStream(int httpStatusCode )
> providing you make the status code available
>
> Putting these ideas together:
>
> try {
> if (httpResponse.getStatus() == 200) {
> return
> ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
> }
> if (httpResponse.getStatus() == 400) {
> if
> ("application/vnd.ogc.se_xml".equals(httpResponse.getContentType())) {
> String message =
> parseXmlException(httpResponse.getErrorStream(400));
> throw new HttpException(400,message);
> }
> else if (httpResponse.getContentType().startsWith("text/")){
> String message = parseTextException(
> httpResponse.getErrorStream(400));
> throw new HttpException(400,message);
> }
>}
>throw new HttpException(httpResponse.getStatus(),"Couldn't get image of
> tile: " + tile.getId());
> } finally {
> httpResponse.dispose();
> }
>
> Food for thought.
> --
> Jody Garnett
>
>
> On Wed, 25 May 2022 at 00:34, Roar Brænden 
> wrote:
>
>> Hi,
>>
>> I have a Proposal for the gt-http library. More specific the HTTPResponse
>> interface. I followed the instructions at the Wiki page, and created a New
>> Page, but when I clicked Save Page I didn't get a Pull Request as the
>> instructions indicated. It seems like the Page was created and freely
>> visible.
>>
>>
>> https://github.com/geotools/geotools/wiki/HTTPResponse-handling-error-responses
>>
>> Could you please have a look, and maybe give some feedback?
>>
>> Best regards,
>> Roar Brænden
>>
>>
>> ___
>> GeoTools-Devel mailing list

Re: [Geotools-devel] Proposal for the HTTPResponse interface

[Jody Garnett]

Thanks for the proposal Roar:

The GeoTools wiki is not restricted, we can consider setting that up as
needed.

If I understand correctly the proposal is:

   - boolean *isOK()*: returns true for HTTP status 200
  - not quite sure if you want to consider some of the other success
  codes such as 201 here also?
  - Can/should this handle redirects?
   - InputStream *getErrorStream()*: provides the error response content
   when isOK() false
  - Unclear what this does if isOK() true? Do you wish to throw an
  exception to indicate error stream is not available?
   - InputStream *getResponseStream()*: provides the response when isOK()
   is true, or throws an IOException (presumably with the contents of the
   error response?)

Glad your proposal includes examples:
- Where we would parse a ServiceException: Before and after show different
logic (the first assumes failure)
- Where we can't handle the error response.: Does not show use
of getErrorStream()

Let me try and write an example that uses both getErrorStream() and
getResponseStream() to see if I understand the proposal:

try {
if (httpResponse.isOK()) {
return
ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
}
else {
if
("application/vnd.ogc.se_xml".equalsIgnoreCase(httpResponse.getContentType()))
{
throw parseXMLException(httpResponse.getErrorStream());
}
else if
(httpResponse.getContentType().toLowerCase().startsWith("text/")){
throw parseException(httpResponse.getErrorStream());
}
   else {
throw new IOException("Server returned error on request");
}
} finally {
httpResponse.dispose();
}


Feedback:
- This is an HTTP Request, can we just see the response code? If we had a
status code isOK() becomes making a check against
Arrays.asList(200,201,203);
- Your ticket examples with HTTP 400 and 415 requests do not seem to be
addressed here?
- Tempting to document httpResponse.getContentType() as returning lowercase
to avoid requiring equalsIgnoreCase() and toLowerCase() be used by all
client code ever
- Having two method names is difficult, and it maybe easier for users of
the API if you added httpResponse.getResponseStream(boolean
allowsErrorResponse)
- Even better would be httpResponse.getResponseStream(int httpStatusCode )
providing you make the status code available

Putting these ideas together:

try {
if (httpResponse.getStatus() == 200) {
return
ImageIOExt.readBufferedImage(httpResponse.getResponseStream());
}
if (httpResponse.getStatus() == 400) {
if
("application/vnd.ogc.se_xml".equals(httpResponse.getContentType())) {
String message =
parseXmlException(httpResponse.getErrorStream(400));
throw new HttpException(400,message);
}
else if (httpResponse.getContentType().startsWith("text/")){
String message = parseTextException(
httpResponse.getErrorStream(400));
throw new HttpException(400,message);
}
   }
   throw new HttpException(httpResponse.getStatus(),"Couldn't get image of
tile: " + tile.getId());
} finally {
httpResponse.dispose();
}

Food for thought.
--
Jody Garnett


On Wed, 25 May 2022 at 00:34, Roar Brænden 
wrote:

> Hi,
>
> I have a Proposal for the gt-http library. More specific the HTTPResponse
> interface. I followed the instructions at the Wiki page, and created a New
> Page, but when I clicked Save Page I didn't get a Pull Request as the
> instructions indicated. It seems like the Page was created and freely
> visible.
>
>
> https://github.com/geotools/geotools/wiki/HTTPResponse-handling-error-responses
>
> Could you please have a look, and maybe give some feedback?
>
> Best regards,
> Roar Brænden
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal for the HTTPResponse interface

[Roar Brænden]

Hi,

I have a Proposal for the gt-http library. More specific the HTTPResponse 
interface. I followed the instructions at the Wiki page, and created a New 
Page, but when I clicked Save Page I didn't get a Pull Request as the 
instructions indicated. It seems like the Page was created and freely visible.

https://github.com/geotools/geotools/wiki/HTTPResponse-handling-error-responses 


Could you please have a look, and maybe give some feedback?

Best regards,
Roar Brænden


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

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

 This change is merged, and visible in our documentation (example the
header on Quickstart.java example here

).

The developers guide has the new header
 under
code style.
--
Jody Garnett


On Mar 29, 2022 at 10:42:08 AM, Jody Garnett  wrote:

> Thanks everyone, going ahead (to fix small sortpom issue first) with merge.
> --
> Jody Garnett
>
>
> On Mar 29, 2022 at 10:24:04 AM, Torben Barsballe <
> torbenbarsba...@gmail.com> wrote:
>
>> +1 from me
>> Cheers,
>> Torben
>>
>>
>> On Fri, Mar 18, 2022 at 1:50 PM Jody Garnett 
>> wrote:
>>
>>> I would like to do a quick proposal:
>>>
>>> > Use CC0 for our documentation and source code examples, in keeping
>>> with our public domain policy in the developers guide
>>>
>>> CC0 is as I understand it a more useful way to release copyright, while
>>> public domain can be american centric.
>>>
>>> Context - tripped over a couple of things looking at tutorial code:
>>> - Sample code was changed to LGPL at some point, when the project policy
>>> is public domain
>>> - Some of the pom.xml and pom2.xml examples no longer match since these
>>> projects are not tested except by hand. I have learned a bit about maven
>>> and we can set these up as distinct standalone projects (using deploy.skip)
>>> to avoid publishing.
>>>
>>> There is a pull request here
>>> https://github.com/geotools/geotools/pull/3823 showing the result
>>> (including developers guide change).
>>> --
>>> Jody Garnett
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

 Thanks everyone, going ahead (to fix small sortpom issue first) with merge.
--
Jody Garnett


On Mar 29, 2022 at 10:24:04 AM, Torben Barsballe 
wrote:

> +1 from me
> Cheers,
> Torben
>
>
> On Fri, Mar 18, 2022 at 1:50 PM Jody Garnett 
> wrote:
>
>> I would like to do a quick proposal:
>>
>> > Use CC0 for our documentation and source code examples, in keeping with
>> our public domain policy in the developers guide
>>
>> CC0 is as I understand it a more useful way to release copyright, while
>> public domain can be american centric.
>>
>> Context - tripped over a couple of things looking at tutorial code:
>> - Sample code was changed to LGPL at some point, when the project policy
>> is public domain
>> - Some of the pom.xml and pom2.xml examples no longer match since these
>> projects are not tested except by hand. I have learned a bit about maven
>> and we can set these up as distinct standalone projects (using deploy.skip)
>> to avoid publishing.
>>
>> There is a pull request here
>> https://github.com/geotools/geotools/pull/3823 showing the result
>> (including developers guide change).
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Torben Barsballe]

+1 from me
Cheers,
Torben


On Fri, Mar 18, 2022 at 1:50 PM Jody Garnett  wrote:

> I would like to do a quick proposal:
>
> > Use CC0 for our documentation and source code examples, in keeping with
> our public domain policy in the developers guide
>
> CC0 is as I understand it a more useful way to release copyright, while
> public domain can be american centric.
>
> Context - tripped over a couple of things looking at tutorial code:
> - Sample code was changed to LGPL at some point, when the project policy
> is public domain
> - Some of the pom.xml and pom2.xml examples no longer match since these
> projects are not tested except by hand. I have learned a bit about maven
> and we can set these up as distinct standalone projects (using deploy.skip)
> to avoid publishing.
>
> There is a pull request here
> https://github.com/geotools/geotools/pull/3823 showing the result
> (including developers guide change).
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

Thanks Andrea, some good news - because of how the header regex was setup
there was no need to use property expansion to select a different set of
rules.

As the QA check is not really desired in a standalone project I have
isolated it into a profile (could not see any way to reduce duplication).

To get a clean standalone pom.xml for examples I ended up using sphinx very
carefully in the docs:

   .. literalinclude:: /../../tutorials/quickstart/pom.xml
:language: xml
:end-before: 
:append: 

It has now been five days, and I would like to ask for any further input,
or this PR to be merged.

Yes this is quick, our proposal procedure is:

- svn access for changes is granted within 3 days from the proposal
>
- proposal is accepted ‘automatically’ within 15 days (unless objections
> are raised)
>

--
Jody Garnett


On Mar 21, 2022 at 1:43:58 AM, Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi Jody,
> I did not know the answer, so I did a quick research. It seems one can
> configure property expansion
> in the checkstyle configuration file, that would allow to switch expected
> header on a per module basis:
>
>
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/custom-property-expansion.html#:~:text=Checkstyle%20uses%20the%20property%20expansion,the%20checks%20performed%20by%20Checkstyle
> .
>
> Cheers
> Andrea
>
> On Mon, Mar 21, 2022 at 3:39 AM Jody Garnett 
> wrote:
>
>> Thanks Ian,
>>
>> I actually have a technical question for Andrea on this one, one of the
>> tasks is "Check if docs can skip QA check for LGPL headers". Any tips on
>> how to set that up, or override the configuration to check for CC0 headers?
>> --
>> Jody Garnett
>>
>>
>> On Mar 19, 2022 at 2:20:08 AM, Ian Turton  wrote:
>>
>>> +1
>>>
>>> Ian
>>>
>>> On Fri, 18 Mar 2022 at 20:59, Jody Garnett 
>>> wrote:
>>>
 Here is proposal
 https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0
 --
 Jody Garnett


 On Fri, 18 Mar 2022 at 13:48, Jody Garnett 
 wrote:

> I would like to do a quick proposal:
>
> > Use CC0 for our documentation and source code examples, in keeping
> with our public domain policy in the developers guide
>
> CC0 is as I understand it a more useful way to release copyright,
> while public domain can be american centric.
>
> Context - tripped over a couple of things looking at tutorial code:
> - Sample code was changed to LGPL at some point, when the project
> policy is public domain
> - Some of the pom.xml and pom2.xml examples no longer match since
> these projects are not tested except by hand. I have learned a bit about
> maven and we can set these up as distinct standalone projects (using
> deploy.skip) to avoid publishing.
>
> There is a pull request here
> https://github.com/geotools/geotools/pull/3823 showing the result
> (including developers guide change).
> --
> Jody Garnett
>
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel

>>>
>>>
>>> --
>>> Ian Turton
>>>
>> ___
>> 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://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> 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, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
___
GeoTools-Devel mailing 

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Andrea Aime]

Hi Jody,
I did not know the answer, so I did a quick research. It seems one can
configure property expansion
in the checkstyle configuration file, that would allow to switch expected
header on a per module basis:

https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/custom-property-expansion.html#:~:text=Checkstyle%20uses%20the%20property%20expansion,the%20checks%20performed%20by%20Checkstyle
.

Cheers
Andrea

On Mon, Mar 21, 2022 at 3:39 AM Jody Garnett  wrote:

> Thanks Ian,
>
> I actually have a technical question for Andrea on this one, one of the
> tasks is "Check if docs can skip QA check for LGPL headers". Any tips on
> how to set that up, or override the configuration to check for CC0 headers?
> --
> Jody Garnett
>
>
> On Mar 19, 2022 at 2:20:08 AM, Ian Turton  wrote:
>
>> +1
>>
>> Ian
>>
>> On Fri, 18 Mar 2022 at 20:59, Jody Garnett 
>> wrote:
>>
>>> Here is proposal
>>> https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Fri, 18 Mar 2022 at 13:48, Jody Garnett 
>>> wrote:
>>>
 I would like to do a quick proposal:

 > Use CC0 for our documentation and source code examples, in keeping
 with our public domain policy in the developers guide

 CC0 is as I understand it a more useful way to release copyright, while
 public domain can be american centric.

 Context - tripped over a couple of things looking at tutorial code:
 - Sample code was changed to LGPL at some point, when the project
 policy is public domain
 - Some of the pom.xml and pom2.xml examples no longer match since these
 projects are not tested except by hand. I have learned a bit about maven
 and we can set these up as distinct standalone projects (using deploy.skip)
 to avoid publishing.

 There is a pull request here
 https://github.com/geotools/geotools/pull/3823 showing the result
 (including developers guide change).
 --
 Jody Garnett

>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>> Ian Turton
>>
> ___
> 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://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob:   +39  333 8128928

https://www.geosolutionsgroup.com/

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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

 Thanks Ian,

I actually have a technical question for Andrea on this one, one of the
tasks is "Check if docs can skip QA check for LGPL headers". Any tips on
how to set that up, or override the configuration to check for CC0 headers?
--
Jody Garnett


On Mar 19, 2022 at 2:20:08 AM, Ian Turton  wrote:

> +1
>
> Ian
>
> On Fri, 18 Mar 2022 at 20:59, Jody Garnett  wrote:
>
>> Here is proposal
>> https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0
>> --
>> Jody Garnett
>>
>>
>> On Fri, 18 Mar 2022 at 13:48, Jody Garnett 
>> wrote:
>>
>>> I would like to do a quick proposal:
>>>
>>> > Use CC0 for our documentation and source code examples, in keeping
>>> with our public domain policy in the developers guide
>>>
>>> CC0 is as I understand it a more useful way to release copyright, while
>>> public domain can be american centric.
>>>
>>> Context - tripped over a couple of things looking at tutorial code:
>>> - Sample code was changed to LGPL at some point, when the project policy
>>> is public domain
>>> - Some of the pom.xml and pom2.xml examples no longer match since these
>>> projects are not tested except by hand. I have learned a bit about maven
>>> and we can set these up as distinct standalone projects (using deploy.skip)
>>> to avoid publishing.
>>>
>>> There is a pull request here
>>> https://github.com/geotools/geotools/pull/3823 showing the result
>>> (including developers guide change).
>>> --
>>> Jody Garnett
>>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
> Ian Turton
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Ian Turton]

+1

Ian

On Fri, 18 Mar 2022 at 20:59, Jody Garnett  wrote:

> Here is proposal
> https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0
> --
> Jody Garnett
>
>
> On Fri, 18 Mar 2022 at 13:48, Jody Garnett  wrote:
>
>> I would like to do a quick proposal:
>>
>> > Use CC0 for our documentation and source code examples, in keeping with
>> our public domain policy in the developers guide
>>
>> CC0 is as I understand it a more useful way to release copyright, while
>> public domain can be american centric.
>>
>> Context - tripped over a couple of things looking at tutorial code:
>> - Sample code was changed to LGPL at some point, when the project policy
>> is public domain
>> - Some of the pom.xml and pom2.xml examples no longer match since these
>> projects are not tested except by hand. I have learned a bit about maven
>> and we can set these up as distinct standalone projects (using deploy.skip)
>> to avoid publishing.
>>
>> There is a pull request here
>> https://github.com/geotools/geotools/pull/3823 showing the result
>> (including developers guide change).
>> --
>> Jody Garnett
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Ian Turton
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

Here is proposal
https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0
--
Jody Garnett


On Fri, 18 Mar 2022 at 13:48, Jody Garnett  wrote:

> I would like to do a quick proposal:
>
> > Use CC0 for our documentation and source code examples, in keeping with
> our public domain policy in the developers guide
>
> CC0 is as I understand it a more useful way to release copyright, while
> public domain can be american centric.
>
> Context - tripped over a couple of things looking at tutorial code:
> - Sample code was changed to LGPL at some point, when the project policy
> is public domain
> - Some of the pom.xml and pom2.xml examples no longer match since these
> projects are not tested except by hand. I have learned a bit about maven
> and we can set these up as distinct standalone projects (using deploy.skip)
> to avoid publishing.
>
> There is a pull request here
> https://github.com/geotools/geotools/pull/3823 showing the result
> (including developers guide change).
> --
> Jody Garnett
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

[Jody Garnett]

I would like to do a quick proposal:

> Use CC0 for our documentation and source code examples, in keeping with
our public domain policy in the developers guide

CC0 is as I understand it a more useful way to release copyright, while
public domain can be american centric.

Context - tripped over a couple of things looking at tutorial code:
- Sample code was changed to LGPL at some point, when the project policy is
public domain
- Some of the pom.xml and pom2.xml examples no longer match since these
projects are not tested except by hand. I have learned a bit about maven
and we can set these up as distinct standalone projects (using deploy.skip)
to avoid publishing.

There is a pull request here https://github.com/geotools/geotools/pull/3823
showing the result (including developers guide change).
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

[Andrea Aime]

Thanks to all that voted here on the list, or directly on the proposal.
Not all votes have been cast, but according to our procedures "proposal is
accepted ‘automatically’ within 15 days (unless objections are raised
)"
With this, the proposal is approved

Cheers
Andrea


On Mon, Apr 12, 2021 at 12:59 PM Nuno Oliveira <
nuno.olive...@geo-solutions.it> wrote:

> +1
>
> On Wed, Mar 24, 2021 at 10:24 AM Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> +0
>>
>> Regards,
>> Simone Giannecchini
>> ==
>> GeoServer Professional Services from the experts!
>> Visit http://bit.ly/gs-services 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
>>
>> ---
>> 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, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail.
>>
>>
>> On Wed, Mar 24, 2021 at 11:16 AM Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> Hi all,
>>> I have written a quick proposal to add vendor options to rules, since
>>> it's an API change:
>>>
>>>
>>> https://github.com/geotools/geotools/wiki/Vendor-options-options-map-for-rules
>>>
>>> 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
>>> --- *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, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
> Regards,
> Nuno Oliveira
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
>
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> 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
>
> ---
>
> 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 

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

[Nuno Oliveira]

+1

On Wed, Mar 24, 2021 at 10:24 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> +0
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://bit.ly/gs-services 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
>
> ---
> 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, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Wed, Mar 24, 2021 at 11:16 AM Andrea Aime 
> wrote:
>
>> Hi all,
>> I have written a quick proposal to add vendor options to rules, since
>> it's an API change:
>>
>>
>> https://github.com/geotools/geotools/wiki/Vendor-options-options-map-for-rules
>>
>> 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
>> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
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

---

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, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is 

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

[Simone Giannecchini]

+0

Regards,
Simone Giannecchini
==
GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services 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

---
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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.


On Wed, Mar 24, 2021 at 11:16 AM Andrea Aime 
wrote:

> Hi all,
> I have written a quick proposal to add vendor options to rules, since it's
> an API change:
>
>
> https://github.com/geotools/geotools/wiki/Vendor-options-options-map-for-rules
>
> 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
> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal, adding vendor option support to Rule

[Andrea Aime]

Hi all,
I have written a quick proposal to add vendor options to rules, since it's
an API change:

https://github.com/geotools/geotools/wiki/Vendor-options-options-map-for-rules

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
--- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Nuno Oliveira]

+1

On Fri, Nov 6, 2020 at 8:59 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> +1
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://bit.ly/gs-services 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
>
> ---
> 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, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Wed, Nov 4, 2020 at 7:33 AM Jody Garnett 
> wrote:
>
>> +1 for the proposal, I understand the need for Map
>>
>> On Sat, Oct 31, 2020 at 4:01 AM Andrea Aime 
>> wrote:
>>
>>> Hi all,
>>> as previously discussed, I've worked on switching DataStore/DataAccess
>>> factory parameters from Map to Map
>>> (yes, ?, not Object, the proposal has rationale for it).
>>>
>>> The proposal is here:
>>>
>>> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-from-Map-String,-Serializable--to-Map-String,-%3F-
>>>
>>> The PR here (still working some updates, but essentially reviewable
>>> already):
>>> https://github.com/geotools/geotools/pull/3195
>>>
>>> Comments and reviews welcomed!
>>>
>>> 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
>>> --- *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, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>> --
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
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

---

Con riferimento alla normativa sul trattamento dei 

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Torben Barsballe]

+1, looks like a good change and reasonably backwards-compatible.

I was going to add a comment about GeoServer compatibility, since the
proposal didn't mention it, but I see you've already got a seperate PR for
that, so nevermind - everything looks good.

Cheers,
Torben

On Fri, Nov 6, 2020 at 1:23 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> +1
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://bit.ly/gs-services 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
>
> ---
> 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, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Wed, Nov 4, 2020 at 7:33 AM Jody Garnett 
> wrote:
>
>> +1 for the proposal, I understand the need for Map
>>
>> On Sat, Oct 31, 2020 at 4:01 AM Andrea Aime 
>> wrote:
>>
>>> Hi all,
>>> as previously discussed, I've worked on switching DataStore/DataAccess
>>> factory parameters from Map to Map
>>> (yes, ?, not Object, the proposal has rationale for it).
>>>
>>> The proposal is here:
>>>
>>> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-from-Map-String,-Serializable--to-Map-String,-%3F-
>>>
>>> The PR here (still working some updates, but essentially reviewable
>>> already):
>>> https://github.com/geotools/geotools/pull/3195
>>>
>>> Comments and reviews welcomed!
>>>
>>> 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
>>> --- *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, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>> --
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Simone Giannecchini]

+1

Regards,
Simone Giannecchini
==
GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services 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

---
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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.


On Wed, Nov 4, 2020 at 7:33 AM Jody Garnett  wrote:

> +1 for the proposal, I understand the need for Map
>
> On Sat, Oct 31, 2020 at 4:01 AM Andrea Aime 
> wrote:
>
>> Hi all,
>> as previously discussed, I've worked on switching DataStore/DataAccess
>> factory parameters from Map to Map
>> (yes, ?, not Object, the proposal has rationale for it).
>>
>> The proposal is here:
>>
>> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-from-Map-String,-Serializable--to-Map-String,-%3F-
>>
>> The PR here (still working some updates, but essentially reviewable
>> already):
>> https://github.com/geotools/geotools/pull/3195
>>
>> Comments and reviews welcomed!
>>
>> 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
>> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> --
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Jody Garnett]

+1 for the proposal, I understand the need for Map

On Sat, Oct 31, 2020 at 4:01 AM Andrea Aime 
wrote:

> Hi all,
> as previously discussed, I've worked on switching DataStore/DataAccess
> factory parameters from Map to Map
> (yes, ?, not Object, the proposal has rationale for it).
>
> The proposal is here:
>
> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-from-Map-String,-Serializable--to-Map-String,-%3F-
>
> The PR here (still working some updates, but essentially reviewable
> already):
> https://github.com/geotools/geotools/pull/3195
>
> Comments and reviews welcomed!
>
> 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
> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-- 
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Ian Turton]

+1

Ian

On Sat, 31 Oct 2020 at 11:03, Andrea Aime 
wrote:

> Looks like Github wiki does not like "<" and ">" in the page titles...
> updated proposal reference here:
>
> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-map-values-from-String-to-generic-object
>
> 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
> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Ian Turton
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Andrea Aime]

Looks like Github wiki does not like "<" and ">" in the page titles...
updated proposal reference here:
https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-map-values-from-String-to-generic-object

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
--- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

[Andrea Aime]

Hi all,
as previously discussed, I've worked on switching DataStore/DataAccess
factory parameters from Map to Map
(yes, ?, not Object, the proposal has rationale for it).

The proposal is here:
https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-from-Map-String,-Serializable--to-Map-String,-%3F-

The PR here (still working some updates, but essentially reviewable
already):
https://github.com/geotools/geotools/pull/3195

Comments and reviews welcomed!

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
--- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: change from webdav to nexus

[Jody Garnett]

Master is now migrated, there is a pull request to update the docs
 also.

This change should be back ported to active branches (although a redirect
is possible our experience last time showed that maven was unable to
process redirects).

Note users can modify their settings.xml file locally consider osgeo
releases repo as a "mirror" of repo.boundlessgeo.com (that is a good idea
and I will add it to the wiki page).
--
Jody Garnett


On Mon, 6 Apr 2020 at 17:28, Jody Garnett  wrote:

> Sounds good, I have updated the wiki page
> 
>  based
> on this thread.
> --
> Jody Garnett
>
>
> On Mon, 6 Apr 2020 at 16:39, Torben Barsballe 
> wrote:
>
>>
>> 1) I will note that repo.boundlessgeo.com was set up to allow for
>> separate repos, we just chose not to use that option in GeoServer. I assume
>> that was just done for convenience, and not for any particular reason...
>>
>> 2) I'm looking at the repo updates in GeoTools, and it turns out GeoTools
>> does not actually use the GeoSolutions repository at all, expecting
>> everything to be mirrored in repo.boundlessgeo.com. So yes, we should
>> probably mirror those artifacts in this osgeo repository too (for now, I'm
>> just going to include the GeoSolutions repo, as the last on the list).
>>
>> Cheers,
>> Torben
>>
>> On Mon, Apr 6, 2020 at 2:41 PM Jody Garnett 
>> wrote:
>>
>>> Good thinking, updated the repository accordingly.
>>>
>>> Worth discussing:
>>>
>>> 1) The approach has a clear distinction between "snapshot" and "release"
>>> repository (previously repo.boundlessgeo.com was used for both
>>> snapshots and releases) ... I think this approach will build faster
>>> 2) The release repository does not currently mirror the GeoSolutions
>>> repository; we may wish to do so to improve build times, or we may wish to
>>> invite the jai-ext and imageio-ext projects to use this repository
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Mon, 6 Apr 2020 at 13:46, Torben Barsballe 
>>> wrote:
>>>
 One comment on the proposal itself - at least during the migration, we
 should avoid using the same repository id for the nexus repo as for the
 webdav repo ("osgeo") to make configuration credential management easier
 (I've been using "nexus" as the id of the nexus repo so far).
 If we want to change the id over to "osgeo" after the migration is
 complete, that would be fine.

 Other than that, +1

 Cheers,
 Torben

 On Mon, Apr 6, 2020 at 12:18 PM Jody Garnett 
 wrote:

> Catching up on this activity.
>
> * Tom (and Torben) were able to transfer the vast majority of the
> repo.boundlessgeo.com content over.
> * I am running the script to transfer webdav folder over now.
>
> To help with communication I wrote this activity up as a proposal
> here, the work is already in progress but please review and/or vote to
> double check if I have missed any tasks.
>
> *
> https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository
>
> Ideally we can setup some redirects so downstream applications can
> continue to build (although I seem to recall that some maven tools did not
> handle redirects well).
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

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

Re: [Geotools-devel] proposal: change from webdav to nexus

[Jody Garnett]

Sounds good, I have updated the wiki page

based
on this thread.
--
Jody Garnett


On Mon, 6 Apr 2020 at 16:39, Torben Barsballe 
wrote:

>
> 1) I will note that repo.boundlessgeo.com was set up to allow for
> separate repos, we just chose not to use that option in GeoServer. I assume
> that was just done for convenience, and not for any particular reason...
>
> 2) I'm looking at the repo updates in GeoTools, and it turns out GeoTools
> does not actually use the GeoSolutions repository at all, expecting
> everything to be mirrored in repo.boundlessgeo.com. So yes, we should
> probably mirror those artifacts in this osgeo repository too (for now, I'm
> just going to include the GeoSolutions repo, as the last on the list).
>
> Cheers,
> Torben
>
> On Mon, Apr 6, 2020 at 2:41 PM Jody Garnett 
> wrote:
>
>> Good thinking, updated the repository accordingly.
>>
>> Worth discussing:
>>
>> 1) The approach has a clear distinction between "snapshot" and "release"
>> repository (previously repo.boundlessgeo.com was used for both snapshots
>> and releases) ... I think this approach will build faster
>> 2) The release repository does not currently mirror the GeoSolutions
>> repository; we may wish to do so to improve build times, or we may wish to
>> invite the jai-ext and imageio-ext projects to use this repository
>> --
>> Jody Garnett
>>
>>
>> On Mon, 6 Apr 2020 at 13:46, Torben Barsballe 
>> wrote:
>>
>>> One comment on the proposal itself - at least during the migration, we
>>> should avoid using the same repository id for the nexus repo as for the
>>> webdav repo ("osgeo") to make configuration credential management easier
>>> (I've been using "nexus" as the id of the nexus repo so far).
>>> If we want to change the id over to "osgeo" after the migration is
>>> complete, that would be fine.
>>>
>>> Other than that, +1
>>>
>>> Cheers,
>>> Torben
>>>
>>> On Mon, Apr 6, 2020 at 12:18 PM Jody Garnett 
>>> wrote:
>>>
 Catching up on this activity.

 * Tom (and Torben) were able to transfer the vast majority of the
 repo.boundlessgeo.com content over.
 * I am running the script to transfer webdav folder over now.

 To help with communication I wrote this activity up as a proposal here,
 the work is already in progress but please review and/or vote to double
 check if I have missed any tasks.

 *
 https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository

 Ideally we can setup some redirects so downstream applications can
 continue to build (although I seem to recall that some maven tools did not
 handle redirects well).
 --
 Jody Garnett
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

Re: [Geotools-devel] proposal: change from webdav to nexus

[Torben Barsballe]

1) I will note that repo.boundlessgeo.com was set up to allow for
separate repos, we just chose not to use that option in GeoServer. I assume
that was just done for convenience, and not for any particular reason...

2) I'm looking at the repo updates in GeoTools, and it turns out GeoTools
does not actually use the GeoSolutions repository at all, expecting
everything to be mirrored in repo.boundlessgeo.com. So yes, we should
probably mirror those artifacts in this osgeo repository too (for now, I'm
just going to include the GeoSolutions repo, as the last on the list).

Cheers,
Torben

On Mon, Apr 6, 2020 at 2:41 PM Jody Garnett  wrote:

> Good thinking, updated the repository accordingly.
>
> Worth discussing:
>
> 1) The approach has a clear distinction between "snapshot" and "release"
> repository (previously repo.boundlessgeo.com was used for both snapshots
> and releases) ... I think this approach will build faster
> 2) The release repository does not currently mirror the GeoSolutions
> repository; we may wish to do so to improve build times, or we may wish to
> invite the jai-ext and imageio-ext projects to use this repository
> --
> Jody Garnett
>
>
> On Mon, 6 Apr 2020 at 13:46, Torben Barsballe 
> wrote:
>
>> One comment on the proposal itself - at least during the migration, we
>> should avoid using the same repository id for the nexus repo as for the
>> webdav repo ("osgeo") to make configuration credential management easier
>> (I've been using "nexus" as the id of the nexus repo so far).
>> If we want to change the id over to "osgeo" after the migration is
>> complete, that would be fine.
>>
>> Other than that, +1
>>
>> Cheers,
>> Torben
>>
>> On Mon, Apr 6, 2020 at 12:18 PM Jody Garnett 
>> wrote:
>>
>>> Catching up on this activity.
>>>
>>> * Tom (and Torben) were able to transfer the vast majority of the
>>> repo.boundlessgeo.com content over.
>>> * I am running the script to transfer webdav folder over now.
>>>
>>> To help with communication I wrote this activity up as a proposal here,
>>> the work is already in progress but please review and/or vote to double
>>> check if I have missed any tasks.
>>>
>>> *
>>> https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository
>>>
>>> Ideally we can setup some redirects so downstream applications can
>>> continue to build (although I seem to recall that some maven tools did not
>>> handle redirects well).
>>> --
>>> Jody Garnett
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: change from webdav to nexus

[Jody Garnett]

Good thinking, updated the repository accordingly.

Worth discussing:

1) The approach has a clear distinction between "snapshot" and "release"
repository (previously repo.boundlessgeo.com was used for both snapshots
and releases) ... I think this approach will build faster
2) The release repository does not currently mirror the GeoSolutions
repository; we may wish to do so to improve build times, or we may wish to
invite the jai-ext and imageio-ext projects to use this repository
--
Jody Garnett


On Mon, 6 Apr 2020 at 13:46, Torben Barsballe 
wrote:

> One comment on the proposal itself - at least during the migration, we
> should avoid using the same repository id for the nexus repo as for the
> webdav repo ("osgeo") to make configuration credential management easier
> (I've been using "nexus" as the id of the nexus repo so far).
> If we want to change the id over to "osgeo" after the migration is
> complete, that would be fine.
>
> Other than that, +1
>
> Cheers,
> Torben
>
> On Mon, Apr 6, 2020 at 12:18 PM Jody Garnett 
> wrote:
>
>> Catching up on this activity.
>>
>> * Tom (and Torben) were able to transfer the vast majority of the
>> repo.boundlessgeo.com content over.
>> * I am running the script to transfer webdav folder over now.
>>
>> To help with communication I wrote this activity up as a proposal here,
>> the work is already in progress but please review and/or vote to double
>> check if I have missed any tasks.
>>
>> *
>> https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository
>>
>> Ideally we can setup some redirects so downstream applications can
>> continue to build (although I seem to recall that some maven tools did not
>> handle redirects well).
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: change from webdav to nexus

[Torben Barsballe]

One comment on the proposal itself - at least during the migration, we
should avoid using the same repository id for the nexus repo as for the
webdav repo ("osgeo") to make configuration credential management easier
(I've been using "nexus" as the id of the nexus repo so far).
If we want to change the id over to "osgeo" after the migration is
complete, that would be fine.

Other than that, +1

Cheers,
Torben

On Mon, Apr 6, 2020 at 12:18 PM Jody Garnett  wrote:

> Catching up on this activity.
>
> * Tom (and Torben) were able to transfer the vast majority of the
> repo.boundlessgeo.com content over.
> * I am running the script to transfer webdav folder over now.
>
> To help with communication I wrote this activity up as a proposal here,
> the work is already in progress but please review and/or vote to double
> check if I have missed any tasks.
>
> *
> https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository
>
> Ideally we can setup some redirects so downstream applications can
> continue to build (although I seem to recall that some maven tools did not
> handle redirects well).
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: change from webdav to nexus

[Jody Garnett]

With the build going out this week we have an opportunity to try out the
repository management changes.
--
Jody Garnett


On Mon, 6 Apr 2020 at 12:16, Jody Garnett  wrote:

> Catching up on this activity.
>
> * Tom (and Torben) were able to transfer the vast majority of the
> repo.boundlessgeo.com content over.
> * I am running the script to transfer webdav folder over now.
>
> To help with communication I wrote this activity up as a proposal here,
> the work is already in progress but please review and/or vote to double
> check if I have missed any tasks.
>
> *
> https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository
>
> Ideally we can setup some redirects so downstream applications can
> continue to build (although I seem to recall that some maven tools did not
> handle redirects well).
> --
> Jody Garnett
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: change from webdav to nexus

[Jody Garnett]

Catching up on this activity.

* Tom (and Torben) were able to transfer the vast majority of the
repo.boundlessgeo.com content over.
* I am running the script to transfer webdav folder over now.

To help with communication I wrote this activity up as a proposal here, the
work is already in progress but please review and/or vote to double check
if I have missed any tasks.

*
https://github.com/geotools/geotools/wiki/Change-from-webdav-to-nexus-repository

Ideally we can setup some redirects so downstream applications can continue
to build (although I seem to recall that some maven tools did not handle
redirects well).
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Ian Turton]

+0 on length

+1 on a limit

Ian

On Tue, 3 Mar 2020 at 19:36, Jody Garnett  wrote:

> Our current proposal time limit was set in the days of subversion when we
> had a single "trunk" and relatively strong divisions between modules in our
> library. The idea being that a 3-day waiting period was good enough for
> feedback before starting work :)
>
> To avoid stagnation by lack of interest/time from community members the
> following assurances are provided:
>
>
>- svn access for changes is granted within 3 days from the proposal
>- proposal is accepted ‘automatically’ within 15 days (unless
>objections are raised)
>
> Now that we have GitHub and pull requests developers can work more
> independently "svn access" is no longer a bottleneck, however it is still
> easy to let proposals alone for days without feedback (and then be
> surprised when the pull request comes in.
>
> I would like to propose reducing our "accepted automatically" time to 10
> days (giving two work weeks, and two weekends for PMC feedback).
>
> I think we can also start sharing proposals with the user list
>
> Here is what that change looks like:
>
> To avoid stagnation by lack of interest/time from community members:
>
>
>- please share work-in-progress as a draft pull request for early
>   feedback
>   - community feedback and welcomed and encouraged
>   - any remaining proposal PMC votes considered +0  ‘automatically’
>   after 10 days
>
>
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Ian Turton
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Nuno Oliveira]

I think 14 days is too much, but looks like everyone else is happy with
14 days, so +0
On Tue, 2020-03-03 at 11:42 -0800, Jody Garnett wrote:
> Sorry I should of said 14 days (so that we get a balance of weekend,
> workweek, and one of our meetings for discussion). Thanks!
> 
> And here is my +1
> 
> --
> Jody Garnett
> 
> 
> On Tue, 3 Mar 2020 at 11:35, Jody Garnett 
> wrote:
> > Our current proposal time limit was set in the days of subversion
> > when we had a single "trunk" and relatively strong
> > divisions between modules in our library. The idea being that a 3-
> > day waiting period was good enough for feedback before starting
> > work :)
> > 
> > To avoid stagnation by lack of interest/time from community members
> > the following assurances are provided:
> > svn access for changes is granted within 3 days from the proposal
> > proposal is accepted ‘automatically’ within 15 days (unless
> > objections are raised)
> > Now that we have GitHub and pull requests developers can work more
> > independently "svn access" is no longer a bottleneck, however it is
> > still easy to let proposals alone for days without feedback (and
> > then be surprised when the pull request comes in.
> > 
> > I would like to propose reducing our "accepted automatically" time
> > to 10 days (giving two work weeks, and two weekends for PMC
> > feedback).
> > 
> > I think we can also start sharing proposals with the user list
> > 
> > Here is what that change looks like:
> > 
> > To avoid stagnation by lack of interest/time from community
> > members:
> > please share work-in-progress as a draft pull request for early
> > feedback
> > community feedback and welcomed and encouraged
> > any remaining proposal PMC votes considered +0  ‘automatically’
> > after 10 days
> > 
> > --
> > Jody Garnett
> > 
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the
experts! 
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
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

---

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, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Andrea Aime]

+1 with having a limit (it's really missing in GeoServer I believe)
Don't care too much if 14 or 10 days, minor difference.

Cheers
Andrea

On Tue, Mar 3, 2020 at 8:45 PM Jody Garnett  wrote:

> Sorry I should of said 14 days (so that we get a balance of weekend,
> workweek, and one of our meetings for discussion). Thanks!
>
> And here is my +1
>
> --
> Jody Garnett
>
>
> On Tue, 3 Mar 2020 at 11:35, Jody Garnett  wrote:
>
>> Our current proposal time limit was set in the days of subversion when we
>> had a single "trunk" and relatively strong divisions between modules in our
>> library. The idea being that a 3-day waiting period was good enough for
>> feedback before starting work :)
>>
>> To avoid stagnation by lack of interest/time from community members the
>> following assurances are provided:
>>
>>
>>- svn access for changes is granted within 3 days from the proposal
>>- proposal is accepted ‘automatically’ within 15 days (unless
>>objections are raised)
>>
>> Now that we have GitHub and pull requests developers can work more
>> independently "svn access" is no longer a bottleneck, however it is still
>> easy to let proposals alone for days without feedback (and then be
>> surprised when the pull request comes in.
>>
>> I would like to propose reducing our "accepted automatically" time to 10
>> days (giving two work weeks, and two weekends for PMC feedback).
>>
>> I think we can also start sharing proposals with the user list
>>
>> Here is what that change looks like:
>>
>> To avoid stagnation by lack of interest/time from community members:
>>
>>
>>- please share work-in-progress as a draft pull request for early
>>   feedback
>>   - community feedback and welcomed and encouraged
>>   - any remaining proposal PMC votes considered +0  ‘automatically’
>>   after 10 days
>>
>>
>> --
>> Jody Garnett
>>
> ___
> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Simone Giannecchini]

See other email.

I would prefer 10 but if anybody else wants 10 who am I to disagree?

Il giorno mar 3 mar 2020 alle 20:43 Jody Garnett 
ha scritto:

> Sorry I should of said 14 days (so that we get a balance of weekend,
> workweek, and one of our meetings for discussion). Thanks!
>
> And here is my +1
>
> --
> Jody Garnett
>
>
> On Tue, 3 Mar 2020 at 11:35, Jody Garnett  wrote:
>
>> Our current proposal time limit was set in the days of subversion when we
>> had a single "trunk" and relatively strong divisions between modules in our
>> library. The idea being that a 3-day waiting period was good enough for
>> feedback before starting work :)
>>
>> To avoid stagnation by lack of interest/time from community members the
>> following assurances are provided:
>>
>>
>>- svn access for changes is granted within 3 days from the proposal
>>- proposal is accepted ‘automatically’ within 15 days (unless
>>objections are raised)
>>
>> Now that we have GitHub and pull requests developers can work more
>> independently "svn access" is no longer a bottleneck, however it is still
>> easy to let proposals alone for days without feedback (and then be
>> surprised when the pull request comes in.
>>
>> I would like to propose reducing our "accepted automatically" time to 10
>> days (giving two work weeks, and two weekends for PMC feedback).
>>
>> I think we can also start sharing proposals with the user list
>>
>> Here is what that change looks like:
>>
>> To avoid stagnation by lack of interest/time from community members:
>>
>>
>>- please share work-in-progress as a draft pull request for early
>>   feedback
>>   - community feedback and welcomed and encouraged
>>   - any remaining proposal PMC votes considered +0  ‘automatically’
>>   after 10 days
>>
>>
>> --
>> Jody Garnett
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-- 
Regards,
Simone Giannecchini.
GeoSolutions Director

- sent from my mobile, apologies for brevity and typos-
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Jody Garnett]

Sorry I should of said 14 days (so that we get a balance of weekend,
workweek, and one of our meetings for discussion). Thanks!

And here is my +1

--
Jody Garnett


On Tue, 3 Mar 2020 at 11:35, Jody Garnett  wrote:

> Our current proposal time limit was set in the days of subversion when we
> had a single "trunk" and relatively strong divisions between modules in our
> library. The idea being that a 3-day waiting period was good enough for
> feedback before starting work :)
>
> To avoid stagnation by lack of interest/time from community members the
> following assurances are provided:
>
>
>- svn access for changes is granted within 3 days from the proposal
>- proposal is accepted ‘automatically’ within 15 days (unless
>objections are raised)
>
> Now that we have GitHub and pull requests developers can work more
> independently "svn access" is no longer a bottleneck, however it is still
> easy to let proposals alone for days without feedback (and then be
> surprised when the pull request comes in.
>
> I would like to propose reducing our "accepted automatically" time to 10
> days (giving two work weeks, and two weekends for PMC feedback).
>
> I think we can also start sharing proposals with the user list
>
> Here is what that change looks like:
>
> To avoid stagnation by lack of interest/time from community members:
>
>
>- please share work-in-progress as a draft pull request for early
>   feedback
>   - community feedback and welcomed and encouraged
>   - any remaining proposal PMC votes considered +0  ‘automatically’
>   after 10 days
>
>
> --
> Jody Garnett
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

[Simone Giannecchini]

+1

Il giorno mar 3 mar 2020 alle 20:36 Jody Garnett 
ha scritto:

> Our current proposal time limit was set in the days of subversion when we
> had a single "trunk" and relatively strong divisions between modules in our
> library. The idea being that a 3-day waiting period was good enough for
> feedback before starting work :)
>
> To avoid stagnation by lack of interest/time from community members the
> following assurances are provided:
>
>
>- svn access for changes is granted within 3 days from the proposal
>- proposal is accepted ‘automatically’ within 15 days (unless
>objections are raised)
>
> Now that we have GitHub and pull requests developers can work more
> independently "svn access" is no longer a bottleneck, however it is still
> easy to let proposals alone for days without feedback (and then be
> surprised when the pull request comes in.
>
> I would like to propose reducing our "accepted automatically" time to 10
> days (giving two work weeks, and two weekends for PMC feedback).
>
> I think we can also start sharing proposals with the user list
>
> Here is what that change looks like:
>
> To avoid stagnation by lack of interest/time from community members:
>
>
>- please share work-in-progress as a draft pull request for early
>   feedback
>   - community feedback and welcomed and encouraged
>   - any remaining proposal PMC votes considered +0  ‘automatically’
>   after 10 days
>
>
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-- 
Regards,
Simone Giannecchini.
GeoSolutions Director

- sent from my mobile, apologies for brevity and typos-
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: reduce proposal time limit to ten days

[Jody Garnett]

Our current proposal time limit was set in the days of subversion when we
had a single "trunk" and relatively strong divisions between modules in our
library. The idea being that a 3-day waiting period was good enough for
feedback before starting work :)

To avoid stagnation by lack of interest/time from community members the
following assurances are provided:


   - svn access for changes is granted within 3 days from the proposal
   - proposal is accepted ‘automatically’ within 15 days (unless objections
   are raised)

Now that we have GitHub and pull requests developers can work more
independently "svn access" is no longer a bottleneck, however it is still
easy to let proposals alone for days without feedback (and then be
surprised when the pull request comes in.

I would like to propose reducing our "accepted automatically" time to 10
days (giving two work weeks, and two weekends for PMC feedback).

I think we can also start sharing proposals with the user list

Here is what that change looks like:

To avoid stagnation by lack of interest/time from community members:


   - please share work-in-progress as a draft pull request for early
  feedback
  - community feedback and welcomed and encouraged
  - any remaining proposal PMC votes considered +0  ‘automatically’
  after 10 days


--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Torben Barsballe]

+1

Cheers,
Torben

On Tue, Oct 9, 2018 at 1:49 PM Jody Garnett  wrote:

> I would like to ask the GeoTools PMC to approve the following proposal:
>
> *Approve up to $1500 to support code sprint participants*
>
>
> Our budget request is here
>  where we
> asked for $1500 help attend bonn code sprint to look at JAI replacement. We
> did not end up using these funds. *Aside: In addition to the $1500
> requested we have had an additional donation of $1500 for SLD
> interoperability we should use this calendar year.*
>
> If I can ask PMC members to respond to this email by the end of the week
> Oct 12th:
>
>- Andrea Aime
>- Ben Caradoc-Davies
>- Ian Turton
>- Jody Garnett +1 (initial motion)
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Andrea Aime]

+1

Cheers
Andrea

On Tue, Oct 9, 2018 at 10:51 PM Jody Garnett  wrote:

> I would like to ask the GeoTools PMC to approve the following proposal:
>
> *Approve up to $1500 to support code sprint participants*
>
>
> Our budget request is here
>  where we
> asked for $1500 help attend bonn code sprint to look at JAI replacement. We
> did not end up using these funds. *Aside: In addition to the $1500
> requested we have had an additional donation of $1500 for SLD
> interoperability we should use this calendar year.*
>
> If I can ask PMC members to respond to this email by the end of the week
> Oct 12th:
>
>- Andrea Aime
>- Ben Caradoc-Davies
>- Ian Turton
>- Jody Garnett +1 (initial motion)
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> --
> Jody Garnett
> ___
> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Nuno Oliveira]

+1

On 10/10/2018 08:32 AM, Simone Giannecchini wrote:

+1

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

---
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, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential
or otherwise protected from disclosure. We remind that - as provided
by European Regulation 2016/679 “GDPR” - copying, dissemination or use
of this e-mail or the information herein by anyone other than the
intended recipient is prohibited. If you have received this email by
mistake, please notify us immediately by telephone or e-mail.

On Wed, Oct 10, 2018 at 9:10 AM Ian Turton  wrote:

+1 from me

Ian

On Tue, 9 Oct 2018, 21:49 Jody Garnett,  wrote:

I would like to ask the GeoTools PMC to approve the following proposal:

Approve up to $1500 to support code sprint participants


Our budget request is here where we asked for $1500 help attend bonn code 
sprint to look at JAI replacement. We did not end up using these funds. Aside: 
In addition to the $1500 requested we have had an additional donation of $1500 
for SLD interoperability we should use this calendar year.

If I can ask PMC members to respond to this email by the end of the week Oct 
12th:

Andrea Aime
Ben Caradoc-Davies
Ian Turton
Jody Garnett +1 (initial motion)
Nuno Oliveira
Simone Giannecchini
Torben Barsballe

--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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


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


--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
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

---

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, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.



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

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Simone Giannecchini]

+1

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

---
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, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential
or otherwise protected from disclosure. We remind that - as provided
by European Regulation 2016/679 “GDPR” - copying, dissemination or use
of this e-mail or the information herein by anyone other than the
intended recipient is prohibited. If you have received this email by
mistake, please notify us immediately by telephone or e-mail.

On Wed, Oct 10, 2018 at 9:10 AM Ian Turton  wrote:
>
> +1 from me
>
> Ian
>
> On Tue, 9 Oct 2018, 21:49 Jody Garnett,  wrote:
>>
>> I would like to ask the GeoTools PMC to approve the following proposal:
>>
>> Approve up to $1500 to support code sprint participants
>>
>>
>> Our budget request is here where we asked for $1500 help attend bonn code 
>> sprint to look at JAI replacement. We did not end up using these funds. 
>> Aside: In addition to the $1500 requested we have had an additional donation 
>> of $1500 for SLD interoperability we should use this calendar year.
>>
>> If I can ask PMC members to respond to this email by the end of the week Oct 
>> 12th:
>>
>> Andrea Aime
>> Ben Caradoc-Davies
>> Ian Turton
>> Jody Garnett +1 (initial motion)
>> Nuno Oliveira
>> Simone Giannecchini
>> Torben Barsballe
>>
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


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

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Ian Turton]

+1 from me

Ian

On Tue, 9 Oct 2018, 21:49 Jody Garnett,  wrote:

> I would like to ask the GeoTools PMC to approve the following proposal:
>
> *Approve up to $1500 to support code sprint participants*
>
>
> Our budget request is here
>  where we
> asked for $1500 help attend bonn code sprint to look at JAI replacement. We
> did not end up using these funds. *Aside: In addition to the $1500
> requested we have had an additional donation of $1500 for SLD
> interoperability we should use this calendar year.*
>
> If I can ask PMC members to respond to this email by the end of the week
> Oct 12th:
>
>- Andrea Aime
>- Ben Caradoc-Davies
>- Ian Turton
>- Jody Garnett +1 (initial motion)
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

[Jody Garnett]

I would like to ask the GeoTools PMC to approve the following proposal:

*Approve up to $1500 to support code sprint participants*


Our budget request is here
 where we
asked for $1500 help attend bonn code sprint to look at JAI replacement. We
did not end up using these funds. *Aside: In addition to the $1500
requested we have had an additional donation of $1500 for SLD
interoperability we should use this calendar year.*

If I can ask PMC members to respond to this email by the end of the week
Oct 12th:

   - Andrea Aime
   - Ben Caradoc-Davies
   - Ian Turton
   - Jody Garnett +1 (initial motion)
   - Nuno Oliveira
   - Simone Giannecchini
   - Torben Barsballe

--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

> By the way, how does Jigsaw work with optional dependencies? Can we
> still leave out unused dependencies like with the current classpath? Or
> will Java 11 spit the dummy?
>

Good question, here is my speculation:

If the dependency is something like log4j and we have adapting code that we
can use if it is available - we should be able to use reflection on the
module-info.java to check if something is around providing that package.
Cannot see any real benefit over our current technique of doing
Class.forName call and catching an exception :P

Modules still follow SPI - so can make functionality available via
ServiceLocator. That should work for both modules and classpath
implementations.

For the oracle case - our oracle dummy jar should be fine to compile a
module against. I am just going to ask the DataStore factory have
isAvailable to check for the JDBCDriver and isAvailableStatus to explain to
the user what went wrong if necessary.

If we were purely going to Java 11 we could have the gt-jdbc-oracle module
require the jdbc driver and refuse to load if it was not available.

We will need to understand the impact on downstream, especially
> GeoServer. Especially gs-app-schema-test. Especially especially tests
> that depend on GeoTools tests. I am still trying to understand the
> implications


Is there anything we can sort out prior to the code sprint here? For
geotools tests we should probably test on the classpath, if we eventually
modularize the tests we would need to explicitly grant access.

looks like surefire uses a hack, --patch-module to allow tests to be slide
loaded along side the module they are testing.[1]

Red Hat are supporting OpenJDK 8 until 2023. OpenJDK 8 forever!
>

Pragmatic, as I expected this is our Python 2 vs 3 moment.

[1]
https://stackoverflow.com/questions/46613214/java-9-maven-junit-does-test-code-need-module-info-java-of-its-own-and-wher
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Ben Caradoc-Davies]

On 27/09/2018 10:01, Jody Garnett wrote:

Hey Ben - are you available for the code sprint? Completely understand if
you are not being a small business, but we would really love your help.


Sorry, I am not likely to be available.


Additional comments/confusion inline:
On Wed, 26 Sep 2018 at 14:50, Ben Caradoc-Davies  wrote:

Does Jigsaw prevent classpath trickery like gt-xsd-gml3
org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required
to make tests pass in Eclipse.

What CLASSPATH trickery is that? Reading the java docs:
* * A disabled version of {@link EPSGCRSAuthorityFactory} that exists
solely as a workaround for*
* * Eclipse capture of transitive dependencies. The real implementation in
gt-epsg-wkt; Maven does*
* * the right thing and does not include the provider at test time, but
Eclipse captures it as a*
* * transitive dependency, causing the wrong provider to be used for
srsName encoding. The presence*
* * of this class allows gt-xsd-gml3 unit tests to pass in Eclipse.*
Since you are the author you may need to explain the trick?


Eclipse puts project classes before dependency classes on the classpath. 
This class allows us to replace an unwanted class in a transitive 
dependency (Eclipse includes more dependencies than Maven) that 
otherwise causes tests to fail (axis order, IIRC?). Jigsaw exists to 
prevent this.


By the way, how does Jigsaw work with optional dependencies? Can we 
still leave out unused dependencies like with the current classpath? Or 
will Java 11 spit the dummy?



Are modules like gt-app-schema that define classes in several packages
also defined in other modules affected by this change?

Yes, they will need to be untangled.
I guess that it might be because only one module can publish a package, but

this depends
on whether any other module consumes these classes.

Normally it would - ie if we were going all in on Java 11 and using
module-info.java to carefully control what we are publishing.
We are not .. as an "automatic module" all the public packages are
published.


We will need to understand the impact on downstream, especially 
GeoServer. Especially gs-app-schema-test. Especially especially tests 
that depend on GeoTools tests. I am still trying to understand the 
implications.



Thanks for the excellent proposal, by the way. This is the most

comprehensible explanation of Jigsaw that I have seen.

No worries, there are a couple features that make it not as scary as I
first feared. And indeed some (like "automatic modules" acting as a bridge
to the classpath) that can be used to make our transition gradual and not
stuck on waiting for everything ever to be turned into modules.


I added Nuno and Torben to the proposal.

Red Hat are supporting OpenJDK 8 until 2023. OpenJDK 8 forever!

Kind regards,

--
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] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

Hey Ben - are you available for the code sprint? Completely understand if
you are not being a small business, but we would really love your help.

Additional comments/confusion inline:
On Wed, 26 Sep 2018 at 14:50, Ben Caradoc-Davies  wrote:

> Does Jigsaw prevent classpath trickery like gt-xsd-gml3
> org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required
> to make tests pass in Eclipse.
>
>
What CLASSPATH trickery is that? Reading the java docs:

* * A disabled version of {@link EPSGCRSAuthorityFactory} that exists
solely as a workaround for*
* * Eclipse capture of transitive dependencies. The real implementation in
gt-epsg-wkt; Maven does*
* * the right thing and does not include the provider at test time, but
Eclipse captures it as a*
* * transitive dependency, causing the wrong provider to be used for
srsName encoding. The presence*
* * of this class allows gt-xsd-gml3 unit tests to pass in Eclipse.*

Since you are the author you may need to explain the trick?


> Are modules like gt-app-schema that define classes in several packages
> also defined in other modules affected by this change?


Yes, they will need to be untangled.

I guess that it might be because only one module can publish a package, but
> this depends
> on whether any other module consumes these classes.
>

Normally it would - ie if we were going all in on Java 11 and using
module-info.java to carefully control what we are publishing.
We are not .. as an "automatic module" all the public packages are
published.

Thanks for the excellent proposal, by the way. This is the most
> comprehensible explanation of Jigsaw that I have seen.
>

No worries, there are a couple features that make it not as scary as I
first feared. And indeed some (like "automatic modules" acting as a bridge
to the classpath) that can be used to make our transition gradual and not
stuck on waiting for everything ever to be turned into modules.
--
Jody
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Ben Caradoc-Davies]

Does Jigsaw prevent classpath trickery like gt-xsd-gml3 
org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required 
to make tests pass in Eclipse.


Are modules like gt-app-schema that define classes in several packages 
also defined in other modules affected by this change? I guess that it 
might be because only one module can publish a package, but this depends 
on whether any other module consumes these classes.


Thanks for the excellent proposal, by the way. This is the most 
comprehensible explanation of Jigsaw that I have seen.


Kind regards,
Ben.

On 18/09/2018 11:16, Jody Garnett wrote:

Proposal is here: Restructure GeoTools into Jigsaw modules


Feedback welcome, I expect we will have some discussion before voting.
--
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] proposal: Restructure GeoTools into Jigsaw modules

[Andrea Aime]

On Wed, Sep 26, 2018 at 8:12 PM Jody Garnett  wrote:

>
> "I think it is a requirement for the work". The work is "Restructure
>> GeoTools into Jigsaw modules" and covers two items:
>> * Providing an automatic module name for each jar
>> * Refactoring the codebase to avoid package conflicts
>>
>> Can you explain how this package renaming is required for the job, or how
>> the goal would be unattainable without, or would require more
>> time to attain if we did not do this package rename?
>>
>
> Renaming the "org.opengis" packages, or moving their classes elsewhere, is
> not required to do the work.
>

Thanks for confirming


> - I think it is smart as we are in conflict over the use of these package
> names (not sure about you but I get emails from the ogc about this)
> - No party interested in OGC GeoAPI compatibility has come forward
>
> This is a good opportunity to fix as the library is already being
> refactored.
>

It is indeed, and we can do it at the end once everything else is working,
ending up with an unfinished port because we wasted
time on a good but unrelated opportunity would simply be irresponsible.


> The upgrade work will have to go over all supported modules, all
>> unsupported of common usage (e..g, wfs, css, csv), and make sure they still
>> work.
>> That's a ton of stuff, we are talking hundreds of modules spread across
>> various projects that we'll have to vet both at compile time and at runtime.
>> I'm worried that we might not have the manpower to do so, and yet,
>> failing to do so will give us a crippled GeoServer that would need further
>> (unfunded) work in the months to come.
>>
>
> I agree we need a lot more people for the code sprint. I made a blog post
> on the geoserver blog seeking contributors (and sponsors so we can attract
> more contributors who would otherwise be paying out of pocket to attend).
>

What we have now in the table is likely who we can expect to participate
full time. We might get more, but not for sure, and probably not full time.
Hence me pushing for keeping the sprint focused.

Cheers
Andrea

-- 

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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

> "I think it is a requirement for the work". The work is "Restructure
> GeoTools into Jigsaw modules" and covers two items:
> * Providing an automatic module name for each jar
> * Refactoring the codebase to avoid package conflicts
>
> Can you explain how this package renaming is required for the job, or how
> the goal would be unattainable without, or would require more
> time to attain if we did not do this package rename?
>

Renaming the "org.opengis" packages, or moving their classes elsewhere, is
not required to do the work.
- I think it is smart as we are in conflict over the use of these package
names (not sure about you but I get emails from the ogc about this)
- No party interested in OGC GeoAPI compatibility has come forward

This is a good opportunity to fix as the library is already being
refactored.

The more I look into it, the more I'm worried, globally. Looking around, we
> are the community that has some migration steps laid out,
> I did not see others with the same level of detail. I'm thus guessing
> we'll have to spend some time assisting other communities in their
> migration as well.
>

I was worried as well, and then I noticed:
- We can leave many dependencies on the CLASSPATH (no package conflicts on
the classpath)
- GeoTools can act as a bridge to libraries on the CLASSPATH (so modules
using GeoTools do not have to care)
- GeoServer can run on the CLASSPATH (see separate email on geoserver-devel)

Making jai-ext,imageio-ext,jaitools[1],geotools,geowebcache and geoserver
> build on java 11 will require quite the effort, two projects need
> to migrate to a newer version of Spring, we have to setup a new log4j
> dependency (and associated migration guides), and I don't see yet
> a list of other dependencies that might need updates.
>

I think the dependency review is what I will work on for friday then.


> All libraries using reflection might be in trouble[2], one that comes to
> mind is XStream for example:
> https://github.com/x-stream/xstream/issues/101
> I believe there might be others too, like for example the CSS module
> depends on asm, which in turn uses Unsafe, and the parsing library
> has not been updated in a long time (the project is simply done, but with
> these changes, it may become broken and might require
> either a fork of the library or a rewrite of the parser with a different
> technology (e.g., antlr).
> There same might be true for Hibernate[3] (which is used by GeoFence).
>

Short term remaining on the CLASSPATH should allow these to run. Libraries
like xstream can be granted reflection access to our code allowing them to
continue to operate long term. Spring 5 has an ASM fork which we can look
at.

The upgrade work will have to go over all supported modules, all
> unsupported of common usage (e..g, wfs, css, csv), and make sure they still
> work.
> That's a ton of stuff, we are talking hundreds of modules spread across
> various projects that we'll have to vet both at compile time and at runtime.
> I'm worried that we might not have the manpower to do so, and yet, failing
> to do so will give us a crippled GeoServer that would need further
> (unfunded) work in the months to come.
>

I agree we need a lot more people for the code sprint. I made a blog post
on the geoserver blog seeking contributors (and sponsors so we can attract
more contributors who would otherwise be paying out of pocket to attend).


> I agree, was hoping to use eclipse "api baseline" automatically collect
>> refactoring that could be applied to GeoServer and other codebases.
>> Sed script is easier for everyone so may be worth creating manually.
>>
>
> We'll have multiple people using different IDEs working on that, so I
> don't see how a eclipse based solution would pan out... wouldn't
> it require to have one developer using eclipse perform all the package
> renames, with all projects loaded (so that renames spread across),
> in advance of the sprint?
>

No it saves up the renames (kind of like a sed script but smarter) and then
they can be replayed on different projects. Admittedly this solution is
Eclipse IDE based but it may be better then writing our own SED scripts.

[1]: we still depend on jaitools, wondering if we'll be forced to finish
> the migration to jai-ext, or if we'll just manage
>   to have it work as is and focus on the actual hard issues
>

It should be fine on the classpath.


> [2]: one workaround would be to open all packages to reflection by force
> of command line options, but this would
>   be both cumbersome for those installing GeoServer from WAR, and not
> future proof
>

I hope for this release to run on the classpath, and as we move some jars
to the module path we can be sure each one opens up additional XStream
reflection access if needed (I hope most things we serialize are public and
not a problem for xstream).


> [3]: This talks a bit about challenges with Hibernate,
>   https://dzone.com/articles/a-practical-guide-to-java-9-migration
>

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Andrea Aime]

On Tue, Sep 25, 2018 at 9:13 PM Jody Garnett  wrote:

> I like the direction, but does not seem a requirement, more of a nice to
>> have. Can we do it towards the end, when everything
>> is building and ready to merge in mainline?
>>
>
> We may be able to move it near the end - but I think it is a requirement
> for the work. As such I would rather tackle this head on, so we can manage
> the interfaces coming from gt-opengis and gt-api sensibly.
>

"I think it is a requirement for the work". The work is "Restructure
GeoTools into Jigsaw modules" and covers two items:
* Providing an automatic module name for each jar
* Refactoring the codebase to avoid package conflicts

Can you explain how this package renaming is required for the job, or how
the goal would be unattainable without, or would require more
time to attain if we did not do this package rename?

The more I look into it, the more I'm worried, globally. Looking around, we
are the community that has some migration steps laid out,
I did not see others with the same level of detail. I'm thus guessing we'll
have to spend some time assisting other communities in their migration as
well.
Making jai-ext,imageio-ext,jaitools[1],geotools,geowebcache and geoserver
build on java 11 will require quite the effort, two projects need
to migrate to a newer version of Spring, we have to setup a new log4j
dependency (and associated migration guides), and I don't see yet
a list of other dependencies that might need updates.
All libraries using reflection might be in trouble[2], one that comes to
mind is XStream for example: https://github.com/x-stream/xstream/issues/101
I believe there might be others too, like for example the CSS module
depends on asm, which in turn uses Unsafe, and the parsing library
has not been updated in a long time (the project is simply done, but with
these changes, it may become broken and might require
either a fork of the library or a rewrite of the parser with a different
technology (e.g., antlr).
There same might be true for Hibernate[3] (which is used by GeoFence).

And this is just off the top of my head... has anyone run jdeps on the full
set of jars used in a GeoServer vanilla install (still a small subset
or our universe of jars, but a significant one)  to get a feel of where we
stand? If not I plan to do so myself as spare time allows (might take some
time, need to finish read the book first to understand the implications of
the report better).

The upgrade work will have to go over all supported modules, all
unsupported of common usage (e..g, wfs, css, csv), and make sure they still
work.
That's a ton of stuff, we are talking hundreds of modules spread across
various projects that we'll have to vet both at compile time and at runtime.
I'm worried that we might not have the manpower to do so, and yet, failing
to do so will give us a crippled GeoServer that would need further
(unfunded) work in the months to come.

3. Priority to change packages, but strictly not change interface / class
>>> names
>>>
>>> If we relaxed the "no changing classnames" guidelines we could gather
>>> these into a single package:
>>> - org.geotools.style.PolygonSymbolizer - readonly
>>> - org.geotools.style.PolygonSymbolizer2 - mutable
>>> - org.geotools.style.PolygonSymbolizerImpl
>>>
>>
>> What about a grep/sed/ant/whatever script based approach instead? We
>> could test the script on an un-upgraded version of GeoServer.
>>
>
> I agree, was hoping to use eclipse "api baseline" automatically collect
> refactoring that could be applied to GeoServer and other codebases.
> Sed script is easier for everyone so may be worth creating manually.
>

We'll have multiple people using different IDEs working on that, so I don't
see how a eclipse based solution would pan out... wouldn't
it require to have one developer using eclipse perform all the package
renames, with all projects loaded (so that renames spread across),
in advance of the sprint?


What do you think about "PolygonSymbolizer" and "PolygonSymbolizer2" though?
>

I haven't reached there yet, still trying to collect my thoughts on the
global sprint effort, looking at the whole
playing field before getting into specific issues.

Cheers
Andrea

[1]: we still depend on jaitools, wondering if we'll be forced to finish
the migration to jai-ext, or if we'll just manage
  to have it work as is and focus on the actual hard issues
[2]: one workaround would be to open all packages to reflection by force of
command line options, but this would
  be both cumbersome for those installing GeoServer from WAR, and not
future proof
[3]: This talks a bit about challenges with Hibernate,
  https://dzone.com/articles/a-practical-guide-to-java-9-migration

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

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

Okay Java 11 is here:

- http://jdk.java.net/11
-
https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html

I would like to start on branch for this restricting on Friday, or
experiment to resolving any feedback/questions from this discussion thread.
Candidates for experimentation:
- breaking the library into much smaller modules (to see if we like that
approach)
- Eclipse "api-baseline" based refactor of geotools, then replay the same
steps on GeoServer
- Refactor of geotools, along side sed script for updating GeoServer
--
Jody Garnett


On Mon, 17 Sep 2018 at 16:16, Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

1. remove org.opengis packages

>
>> It seems like good timing, and with the module system any conflict over
>> org.opengis packages will be more keenly felt.
>>
>> Here is the proposal renaming org.opengis to org.geotools.api:
>> - org.geotools.api.filter.Filter
>> - org.geotools.api.filter.PropertyIsEqualTo
>> - org.geotools.filter.FilterAbstract
>> - org.geotools.filter.IsEqualsToImpl
>>
>
> I like the direction, but does not seem a requirement, more of a nice to
> have. Can we do it towards the end, when everything
> is building and ready to merge in mainline?
>

We may be able to move it near the end - but I think it is a requirement
for the work. As such I would rather tackle this head on, so we can manage
the interfaces coming from gt-opengis and gt-api sensibly.


> 2. folding gt-cql together gt-main
>>
>> ECQL is now a well established stable part of our library, moving it
>> closer should allow us to use it in more places helping with ease of use.
>>
>

> Hmm... tentatively -1. OGC is working on lighter protocols and with those
> will likely come (finally) some easier
> to use filtering languages. I've tried to promote CQL with no success so
> far. I'd wait and see what comes up instead
> of making CQL "built-in".
>

That is a good reason to be -1, we may be able to make it an extension
(something that makes the core geotools library easier to use).


> Also the direction of Java 9 modularity seems, from what I've read so far,
> to have relatively small and focused modules,
> with eventual aggregator modules (e.g. java.base) that contain nothing but
> dependencies. If we headed that direction we'd rather have to split main
> into smaller bits. Not saying we must or should, just noting a difference
>  in approach.
>

I am willing to try this as an experiment. I note that the individuals
modules in the JRE have *lots* of packages in them (even though they have
an aggregator module as an easy way to depend on "everything").  Indeed all
the illustrations have "..." in them to avoid listing all the packages.

3. Priority to change packages, but strictly not change interface / class
>> names
>>
>> If we relaxed the "no changing classnames" guidelines we could gather
>> these into a single package:
>> - org.geotools.style.PolygonSymbolizer - readonly
>> - org.geotools.style.PolygonSymbolizer2 - mutable
>> - org.geotools.style.PolygonSymbolizerImpl
>>
>
> What about a grep/sed/ant/whatever script based approach instead? We could
> test the script on an un-upgraded version of GeoServer.
>

I agree, was hoping to use eclipse "api baseline" automatically collect
refactoring that could be applied to GeoServer and other codebases.
Sed script is easier for everyone so may be worth creating manually.

What do you think about "PolygonSymbolizer" and "PolygonSymbolizer2" though?
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

Thanks for the discussion - you have given me some items to think about.

For the plugins I only found a few conflicts, gt-epsg-hsql for example,
where an implementation uses the same package name on purpose (I think to
access some package visible API).

Technically there is one other approach to the split-package issue - but it
is only available if using module-info.java.  An implementation (in an
otherwise conflicting package) can be made available via ServiceLocator.
There is a section in module-info.java that replaces META_INF/services. The
class cannot be seen, but the implementation is available as an instance of
the requested service.

On Sat, Sep 22, 2018 at 2:42 AM Andrea Aime 
wrote:

> 4. Priority to core library, plugins are expected to repackage
>>
>> I am pretty content with this direction, the majority of plugins have
>> their own distinct package. I am not sure if more sensitivity is required
>> here?
>>
>
> Unsure. The direction you're proposing here looks sensible, but I haven't
> read enough to know
> if there are other approaches to handle the "split package" issue.
>
> Cheers
> Andrea
>
> --
>
> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
-- 
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Andrea Aime]

On Fri, Sep 21, 2018 at 8:10 PM Jody Garnett  wrote:

> That is great - which book?
>

This one, in its current "early access" version:
https://www.manning.com/books/the-java-module-system
So far good book, the prose flows and has good information.


> 1. remove org.opengis packages
>
> It seems like good timing, and with the module system any conflict over
> org.opengis packages will be more keenly felt.
>
> Here is the proposal renaming org.opengis to org.geotools.api:
> - org.geotools.api.filter.Filter
> - org.geotools.api.filter.PropertyIsEqualTo
> - org.geotools.filter.FilterAbstract
> - org.geotools.filter.IsEqualsToImpl
>

I like the direction, but does not seem a requirement, more of a nice to
have. Can we do it towards the end, when everything
is building and ready to merge in mainline?


> 2. folding gt-cql together gt-main
>
> ECQL is now a well established stable part of our library, moving it
> closer should allow us to use it in more places helping with ease of use.
>

Hmm... tentatively -1. OGC is working on lighter protocols and with those
will likely come (finally) some easier
to use filtering languages. I've tried to promote CQL with no success so
far. I'd wait and see what comes up instead
of making CQL "built-in".
Also the direction of Java 9 modularity seems, from what I've read so far,
to have relatively small and focused modules,
with eventual aggregator modules (e.g. java.base) that contain nothing but
dependencies.
If we headed that direction we'd rather have to split main into smaller
bits. Not saying we must or should, just noting a difference
in approach.


>
> 3. Priority to change packages, but strictly not change interface / class
> names
>
> Goal is to allow clients to confidently fix their imports using "organize
> imports" or similar.
>
> While keeping this goal we *could* fold most interfaces back into place:
> - org.geotools.filter.Filter
> - org.geotools.filter.PropertyIsEqualTo
> - org.geotools.filter.FilterAbstract
> - org.geotools.filter.IsEqualsToImpl
>
> However the style interfaces narrowly avoid conflict:
> - org.geotools.style.PolygonSymbolizer - readonly
> - org.geotools.styling.PolygonSymbolizer - mutable
> - org.geotools.styling.PolygonSymbolizerImpl
>
> If we relaxed the "no changing classnames" guidelines we could gather
> these into a single package:
> - org.geotools.style.PolygonSymbolizer - readonly
> - org.geotools.style.PolygonSymbolizer2 - mutable
> - org.geotools.style.PolygonSymbolizerImpl
>

What about a grep/sed/ant/whatever script based approach instead? We could
test the script on an un-upgraded version of GeoServer.


> 4. Priority to core library, plugins are expected to repackage
>
> I am pretty content with this direction, the majority of plugins have
> their own distinct package. I am not sure if more sensitivity is required
> here?
>

Unsure. The direction you're proposing here looks sensible, but I haven't
read enough to know
if there are other approaches to handle the "split package" issue.

Cheers
Andrea

-- 

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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

That is great - which book?

I trust your intelligence on a wide range of matters, while you research
the technical side - there are a couple strategic decisions in the middle
of this proposal that I would appreciate your guidance / input on.

1. remove org.opengis packages

It seems like good timing, and with the module system any conflict over
org.opengis packages will be more keenly felt.

Here is the proposal renaming org.opengis to org.geotools.api:
- org.geotools.api.filter.Filter
- org.geotools.api.filter.PropertyIsEqualTo
- org.geotools.filter.FilterAbstract
- org.geotools.filter.IsEqualsToImpl

2. folding gt-cql together gt-main

ECQL is now a well established stable part of our library, moving it closer
should allow us to use it in more places helping with ease of use.

3. Priority to change packages, but strictly not change interface / class
names

Goal is to allow clients to confidently fix their imports using "organize
imports" or similar.

While keeping this goal we *could* fold most interfaces back into place:
- org.geotools.filter.Filter
- org.geotools.filter.PropertyIsEqualTo
- org.geotools.filter.FilterAbstract
- org.geotools.filter.IsEqualsToImpl

However the style interfaces narrowly avoid conflict:
- org.geotools.style.PolygonSymbolizer - readonly
- org.geotools.styling.PolygonSymbolizer - mutable
- org.geotools.styling.PolygonSymbolizerImpl

If we relaxed the "no changing classnames" guidelines we could gather these
into a single package:
- org.geotools.style.PolygonSymbolizer - readonly
- org.geotools.style.PolygonSymbolizer2 - mutable
- org.geotools.style.PolygonSymbolizerImpl

4. Priority to core library, plugins are expected to repackage

I am pretty content with this direction, the majority of plugins have their
own distinct package. I am not sure if more sensitivity is required here?





--
Jody Garnett


On Wed, 19 Sep 2018 at 09:49, Andrea Aime 
wrote:

> Hi Jody,
> I got myself a book on java modularity and reading through it in my spare
> time.
> Will take a couple of weeks I believe before I can add any intelligent
> comment on the proposal, sorry :-)
>
> Cheers
> Andrea
>
> On Tue, Sep 18, 2018 at 1:18 AM Jody Garnett 
> wrote:
>
>> Proposal is here: Restructure GeoTools into Jigsaw modules
>> 
>>
>> Feedback welcome, I expect we will have some discussion before voting.
>> --
>> Jody Garnett
>> ___
>> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Andrea Aime]

Hi Jody,
I got myself a book on java modularity and reading through it in my spare
time.
Will take a couple of weeks I believe before I can add any intelligent
comment on the proposal, sorry :-)

Cheers
Andrea

On Tue, Sep 18, 2018 at 1:18 AM Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
> ___
> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Torben Barsballe]

I've looked over the proposal, and we reviewed it during yesterday's PMC
meeting.

First off, thanks for putting this together.

During discussion, you mentioned we could have Eclipse generate a
refactoring script to use when refactoring other projects to conform to the
GeoTools API changes - while this is an implementation detail, it would be
worthwhile including it in the proposal (And, longer term, including it in
the docs / migration guide).

The outlined approach looks solid, and seems consistent with what I
discovered when working on the initial Java 9 compatibility efforts.
This is going to be a lot of work, and includes substantial API changes,
but everything here seems necessary to support current versions of Java.

+1

Torben




On Mon, Sep 17, 2018 at 4:17 PM Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

[Jody Garnett]

Proposal is here: Restructure GeoTools into Jigsaw modules


Feedback welcome, I expect we will have some discussion before voting.
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

[Jody Garnett]

+1

Had nothing to add to the discussion :)
On Wed, Jun 20, 2018 at 5:21 AM Andrea Aime 
wrote:

> Ok, thanks everybody for your vote.
> The request for vote has been out for a couple of weeks and the PR is
> ready for merging so... merging :-)
>
> Cheers
> Andrea
>
> On Tue, Jun 19, 2018 at 5:51 PM, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> Ouch,
>> I am +1 on this one while I wait for the Raster Algebra integration ;)
>>
>> 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
>>
>> ---
>> 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, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail.
>>
>>
>> On Tue, Jun 19, 2018 at 5:48 PM Andrea Aime 
>> wrote:
>>
>>> Hi folks,
>>> the proposal has been out a couple of weeks, anyone else plans to vote?
>>> We're missing Simone and Jody
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Wed, Jun 6, 2018 at 4:38 PM, Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 We already discussed in on the mailing list a bit, here is the format
 proposal:


 https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName

 Votes welcomed (and discussion too, in case you missed it previously)
 :-)

 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
 --- *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, è tenuta/o a cancellarlo, ogni altra
 operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
 This email is intended only for the person or entity to which it is
 addressed and may contain information that is privileged, confidential or
 otherwise protected from disclosure. We remind that - as provided by
 European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
 e-mail or the information herein by anyone other than the intended
 recipient is prohibited. If you have received this email by mistake, please
 notify us immediately by telephone or e-mail.*

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

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

[Andrea Aime]

Ok, thanks everybody for your vote.
The request for vote has been out for a couple of weeks and the PR is ready
for merging so... merging :-)

Cheers
Andrea

On Tue, Jun 19, 2018 at 5:51 PM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Ouch,
> I am +1 on this one while I wait for the Raster Algebra integration ;)
>
> 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
>
> ---
> 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, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Tue, Jun 19, 2018 at 5:48 PM Andrea Aime 
> wrote:
>
>> Hi folks,
>> the proposal has been out a couple of weeks, anyone else plans to vote?
>> We're missing Simone and Jody
>>
>> Cheers
>> Andrea
>>
>>
>> On Wed, Jun 6, 2018 at 4:38 PM, Andrea Aime > > wrote:
>>
>>> We already discussed in on the mailing list a bit, here is the format
>>> proposal:
>>>
>>> https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-
>>> SelectChannelName
>>>
>>> Votes welcomed (and discussion too, in case you missed it previously) :-)
>>>
>>> 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 --- *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, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>>
>>
>>
>>
>> --
>>
>> 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, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se 

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

[Simone Giannecchini]

Ouch,
I am +1 on this one while I wait for the Raster Algebra integration ;)

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

---
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, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.


On Tue, Jun 19, 2018 at 5:48 PM Andrea Aime 
wrote:

> Hi folks,
> the proposal has been out a couple of weeks, anyone else plans to vote?
> We're missing Simone and Jody
>
> Cheers
> Andrea
>
>
> On Wed, Jun 6, 2018 at 4:38 PM, Andrea Aime 
> wrote:
>
>> We already discussed in on the mailing list a bit, here is the format
>> proposal:
>>
>>
>> https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName
>>
>> Votes welcomed (and discussion too, in case you missed it previously) :-)
>>
>> 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
>> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
>
>
>
> --
>
> 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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
> 

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

[Andrea Aime]

Hi folks,
the proposal has been out a couple of weeks, anyone else plans to vote?
We're missing Simone and Jody

Cheers
Andrea


On Wed, Jun 6, 2018 at 4:38 PM, Andrea Aime 
wrote:

> We already discussed in on the mailing list a bit, here is the format
> proposal:
>
> https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-
> SelectChannelName
>
> Votes welcomed (and discussion too, in case you missed it previously) :-)
>
> 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
> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>



-- 

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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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] Proposal: Allow usage of expressions in SelectChannelName

[Ben Caradoc-Davies]

+1. That looks quite useful.

Kind regards,
Ben.

On 07/06/18 02:38, Andrea Aime wrote:

We already discussed in on the mailing list a bit, here is the format
proposal:

https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName

Votes welcomed (and discussion too, in case you missed it previously) :-)

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
--- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*



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



--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

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

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

[Andrea Aime]

On Wed, Jun 6, 2018 at 4:46 PM, Ian Turton  wrote:

> +1 from me.
>

Thanks!


> PS now I'm worried I should have done a proposal for the change to like
> filters to take expressions instead of propertynames (but I thought it was
> just a bug :-))
>

Why don't we discuss it on a separate mail, with some context about
affected areas and the like? :-)

Cheers
Andrea

-- 

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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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] Proposal: Allow usage of expressions in SelectChannelName

[Ian Turton]

+1 from me.

Ian

PS now I'm worried I should have done a proposal for the change to like
filters to take expressions instead of propertynames (but I thought it was
just a bug :-))


On Wed, 6 Jun 2018 at 15:38, Andrea Aime 
wrote:

> We already discussed in on the mailing list a bit, here is the format
> proposal:
>
>
> https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName
>
> Votes welcomed (and discussion too, in case you missed it previously) :-)
>
> 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
> --- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
> --
> 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
>


-- 
Ian Turton
--
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] Proposal: Allow usage of expressions in SelectChannelName

[Andrea Aime]

We already discussed in on the mailing list a bit, here is the format
proposal:

https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName

Votes welcomed (and discussion too, in case you missed it previously) :-)

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
--- *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, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
--
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] Proposal: Refactor ImageMosaic index management

[Simone Giannecchini]

As discussed during the meeting, I am going to merge now.
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, Jun 28, 2016 at 8:38 PM, Devon Tucker  wrote:
> Just FYI my PR for this proposal now builds against -Dall (Jody pointed out
> a compilation error in coveragetools this morning) and is ready to go for
> me.
>
> Cheers
>
> On Sat, Jun 25, 2016 at 2:07 PM, Ben Caradoc-Davies 
> wrote:
>>
>> +1. (Simone I also added your vote to the wiki.)
>>
>> A link to encourage those who have not voted to do so:
>>
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility
>>
>> Kind regards,
>> Ben.
>>
>> On 25/06/16 04:45, Simone Giannecchini wrote:
>> > Dear All,
>> > me, Devon and Jody have worked together on refining the code being the
>> > proposal to round some corners.
>> >
>> > Now I can give my +1.
>> > 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
>>
>> --
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
>>
>>
>> --
>> 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
>
>

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

[Simone Giannecchini]

Yes,
we worked together to isolate the changes into simple SPI mechanism.

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 Fri, Jun 24, 2016 at 6:56 PM, Andrea Aime
 wrote:
> Hi,
> I believe that's all it takes, given Simone's the module maintainer and all
> changes are in the imagemosaic module, right?
>
> Cheers
> Andrea
>
> On Fri, Jun 24, 2016 at 6:45 PM, Simone Giannecchini
>  wrote:
>>
>> Dear All,
>> me, Devon and Jody have worked together on refining the code being the
>> proposal to round some corners.
>>
>> Now I can give my +1.
>> 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, 

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

[Simone Giannecchini]

Dear All,
me, Devon and Jody have worked together on refining the code being the
proposal to round some corners.

Now I can give my +1.
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 Wed, Jun 22, 2016 at 6:59 PM, Simone Giannecchini
 wrote:
> Dear Devon,
> some feedback on the proposal:
>
> -1- I would rename GranuleGeometryHandler to GranuleHandler (or
> something GranuleiNDEXHandler) like sine one can pretty much do
> anything  with this
> -2- I would want two different methods just one like:
>
> void handleGeometry(
> GridCoverage2DReader inputReader,
> SimpleFeature targetFeature,
> SimpleFeatureType targetFeatureType,
> SimpleFeature inputFeature,
> SimpleFeatureType inputFeatureType,
> MosaicConfigurationBean mosaicConfiguration);
>
> and some code in it to differentiate makes things simpler
>
> -3- I am wondering if we might want to have multiple GranuleHandlers
> like we have for the other SPIs, probably not...
>
> I will send you a PR with some feedback along these lines; since we
> are here, we need some unit tests for the new classes we have created.
> With this feedback fixed you have my +1.
>
> 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
> 

[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

[Simone Giannecchini]

Dear Devon,
some feedback on the proposal:

-1- I would rename GranuleGeometryHandler to GranuleHandler (or
something GranuleiNDEXHandler) like sine one can pretty much do
anything  with this
-2- I would want two different methods just one like:

void handleGeometry(
GridCoverage2DReader inputReader,
SimpleFeature targetFeature,
SimpleFeatureType targetFeatureType,
SimpleFeature inputFeature,
SimpleFeatureType inputFeatureType,
MosaicConfigurationBean mosaicConfiguration);

and some code in it to differentiate makes things simpler

-3- I am wondering if we might want to have multiple GranuleHandlers
like we have for the other SPIs, probably not...

I will send you a PR with some feedback along these lines; since we
are here, we need some unit tests for the new classes we have created.
With this feedback fixed you have my +1.

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 Wed, Jun 22, 2016 at 6:31 AM, Jody Garnett  wrote:
> Thanks, proposal is clear, scope/purpose clear, technical details are easier
> to follow with class diagram.
>
> +1
>
> And it looks like you are pretty much done the work, except for user docs...
>
> --
> Jody Garnett
>
> On 21 June 2016 at 17:04, Devon Tucker  wrote:
>>
>> Yes, it's ready for review :D
>>
>> On Tue, Jun 21, 2016 at 5:01 PM, Jody Garnett 
>> 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  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

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

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

[Jody Garnett]

Thanks, proposal is clear, scope/purpose clear, technical details are
easier to follow with class diagram.

+1

And it looks like you are pretty much done the work, except for user docs...

--
Jody Garnett

On 21 June 2016 at 17:04, Devon Tucker  wrote:

> Yes, it's ready for review :D
>
> On Tue, Jun 21, 2016 at 5:01 PM, Jody Garnett 
> 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  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
>>>
>>> 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 
>>> 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 
 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  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
>>
>> 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 

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

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

[Jody Garnett]

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

 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 

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

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

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

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

[Jody Garnett]

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

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

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 result of e-mail
> transmission, viruses, etc.
>
>
> On Tue, Jun 14, 2016 at 8:09 PM, Devon Tucker 
> wrote:
> > Hi all,
> >
> > After discussions about the ImageMosaic API proposal we have decided to
> > break it up into a few smaller pieces that 

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

[Simone Giannecchini]

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 result of e-mail
transmission, viruses, etc.


On Tue, Jun 14, 2016 at 8:09 PM, Devon Tucker  wrote:
> 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 

[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] Proposal: ask OSGeo for legal advice on copyright headers

[Jody Garnett]

Thanks Ben, the board has agreed to help (and have an open source law firm
they have worked with previously).

--
Jody Garnett

On 6 June 2016 at 12:54, Ben Caradoc-Davies  wrote:

> Jody,
>
> the vote of the committee is unanimous:
>
> Andrea Aime: +1
> Ben Caradoc-Davies: +1
> Christian Mueller: +1
> Ian Turton: +1
> Jody Garnett: +1
> Justin Deoliveira: +1
> Simone Giannecchini: +1
>
> Kind regards,
> Ben.
>
>
> On 01/06/16 07:56, Ben Caradoc-Davies wrote:
>
>> I propose that we ask OSGeo to: "Obtain legal advice on the need for and
>> form of source code copyright headers."
>>
>> So far we have three +1 votes but we need more. PMC?
>>
>> Kind regards,
>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
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] Proposal: ask OSGeo for legal advice on copyright headers

[Ben Caradoc-Davies]

Jody,

the vote of the committee is unanimous:

Andrea Aime: +1
Ben Caradoc-Davies: +1
Christian Mueller: +1
Ian Turton: +1
Jody Garnett: +1
Justin Deoliveira: +1
Simone Giannecchini: +1

Kind regards,
Ben.

On 01/06/16 07:56, Ben Caradoc-Davies wrote:
> I propose that we ask OSGeo to: "Obtain legal advice on the need for and
> form of source code copyright headers."
>
> So far we have three +1 votes but we need more. PMC?
>
> Kind regards,
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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] proposal:

[Ben Caradoc-Davies]

Ignore that: I think *everyone* has voted. Jody, I will summarise. Is 
there anything else you need?

On 07/06/16 07:47, Ben Caradoc-Davies wrote:
> I asked in my email last week, but have not yet received any more votes.
>
> On 07/06/16 06:08, Jody Garnett wrote:
>> The 2nd person with an action item is Ben (who is asking the PSC to
>> authorize me to get legal advice via OSGeo).

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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] proposal:

[Ben Caradoc-Davies]

I asked in my email last week, but have not yet received any more votes.

On 07/06/16 06:08, Jody Garnett wrote:
> The 2nd person with an action item is Ben (who is asking the PSC to
> authorize me to get legal advice via OSGeo).

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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] proposal:

[Jody Garnett]

You are quick, I am making the pull request now - if you can review and
merge.

The 2nd person with an action item is Ben (who is asking the PSC to
authorize me to get legal advice via OSGeo).

--
Jody Garnett

On 6 June 2016 at 11:06, Justin Deoliveira  wrote:

> Thanks Jody!
>
> I got a little lost in the shuffle so can you let me know what the next
> steps are for me? You had mentioned that you had some changes to the dev
> guide that you wanted me to review?
>
>
> On Mon, Jun 6, 2016 at 12:04 PM Jody Garnett 
> wrote:
>
>> This motion is now passed: "Apply OSGeo copyright on
>> creation/contribution"
>>
>> And response via email:
>>
>>- Andrea Aime +1 (second)
>>- Ben Caradoc-Davies +1
>>- Christian Mueller +1
>>- Ian Turton +1
>>- Jody Garnett +1 (motion)
>>- Justin Deoliveira +1
>>- Simone Giannecchin +1
>>
>> Community response:
>>
>>- Torben: Seems like a good idea
>>
>>
>> --
>> Jody Garnett
>>
>> On 31 May 2016 at 14:56, Jody Garnett  wrote:
>>
>>> We have the following motion:
>>>
>>> "Apply OSGeo copyright on creation/contribution"
>>>
>>> And response via email:
>>>
>>>- Andrea Aime +1 (second)
>>>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>>>- Christian Mueller
>>>- Ian Turton
>>>- Jody Garnett +1 (motion)
>>>- Justin Deoliveira +0 (agreement but no clear vote)
>>>- Simone Giannecchini
>>>
>>> Community response:
>>>
>>>- Torben: Seems like a good idea
>>>
>>> With this motion approved I will update the developers guide as outlined
>>> in the proposal
>>> 
>>> .
>>> --
>>> Jody Garnett
>>>
>>
>> --
>> 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
>>
>
--
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] proposal:

[Justin Deoliveira]

Thanks Jody!

I got a little lost in the shuffle so can you let me know what the next
steps are for me? You had mentioned that you had some changes to the dev
guide that you wanted me to review?


On Mon, Jun 6, 2016 at 12:04 PM Jody Garnett  wrote:

> This motion is now passed: "Apply OSGeo copyright on
> creation/contribution"
>
> And response via email:
>
>- Andrea Aime +1 (second)
>- Ben Caradoc-Davies +1
>- Christian Mueller +1
>- Ian Turton +1
>- Jody Garnett +1 (motion)
>- Justin Deoliveira +1
>- Simone Giannecchin +1
>
> Community response:
>
>- Torben: Seems like a good idea
>
>
> --
> Jody Garnett
>
> On 31 May 2016 at 14:56, Jody Garnett  wrote:
>
>> We have the following motion:
>>
>> "Apply OSGeo copyright on creation/contribution"
>>
>> And response via email:
>>
>>- Andrea Aime +1 (second)
>>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>>- Christian Mueller
>>- Ian Turton
>>- Jody Garnett +1 (motion)
>>- Justin Deoliveira +0 (agreement but no clear vote)
>>- Simone Giannecchini
>>
>> Community response:
>>
>>- Torben: Seems like a good idea
>>
>> With this motion approved I will update the developers guide as outlined
>> in the proposal
>> 
>> .
>> --
>> Jody Garnett
>>
>
> --
> 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
>
--
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] proposal:

[Jody Garnett]

This motion is now passed: "Apply OSGeo copyright on creation/contribution"

And response via email:

   - Andrea Aime +1 (second)
   - Ben Caradoc-Davies +1
   - Christian Mueller +1
   - Ian Turton +1
   - Jody Garnett +1 (motion)
   - Justin Deoliveira +1
   - Simone Giannecchin +1

Community response:

   - Torben: Seems like a good idea


--
Jody Garnett

On 31 May 2016 at 14:56, Jody Garnett  wrote:

> We have the following motion:
>
> "Apply OSGeo copyright on creation/contribution"
>
> And response via email:
>
>- Andrea Aime +1 (second)
>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>- Christian Mueller
>- Ian Turton
>- Jody Garnett +1 (motion)
>- Justin Deoliveira +0 (agreement but no clear vote)
>- Simone Giannecchini
>
> Community response:
>
>- Torben: Seems like a good idea
>
> With this motion approved I will update the developers guide as outlined
> in the proposal
> 
> .
> --
> Jody Garnett
>
--
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] proposal:

[Christian Mueller]

Hi

Added my +1 to the proposal

Cheers

On Wed, Jun 1, 2016 at 8:49 PM, Ben Caradoc-Davies  wrote:

> Have you seen my old ring? I seem to have lost it.  :-)
>
> On 02/06/16 00:48, Justin Deoliveira wrote:
> > Been a long road to get essentially back to
> > where we started :)
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> 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
>



-- 
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
--
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] proposal:

[Jody Garnett]

Thanks, we are currently at:


   - Andrea Aime +1 (second)
   - Ben Caradoc-Davies +1
   - Christian Mueller
   - Ian Turton +1
   - Jody Garnett +1 (motion)
   - Justin Deoliveira +1
   - Simone Giannecchini +1

Community response:

   - Torben: Seems like a good idea

I am going to start on a pull request for you to review Justin, hopefully
Christian get's back to this thread so we can declare this passed.

While we are back where we started, we have a much better understanding of
where here is - thanks to everyone for keeping this professional (difficult
with such a bike shed problem).


--
Jody Garnett

On 31 May 2016 at 14:56, Jody Garnett  wrote:

> We have the following motion:
>
> "Apply OSGeo copyright on creation/contribution"
>
> And response via email:
>
>- Andrea Aime +1 (second)
>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>- Christian Mueller
>- Ian Turton
>- Jody Garnett +1 (motion)
>- Justin Deoliveira +0 (agreement but no clear vote)
>- Simone Giannecchini
>
> Community response:
>
>- Torben: Seems like a good idea
>
> With this motion approved I will update the developers guide as outlined
> in the proposal
> 
> .
> --
> Jody Garnett
>
--
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] proposal:

[Ben Caradoc-Davies]

Have you seen my old ring? I seem to have lost it.  :-)

On 02/06/16 00:48, Justin Deoliveira wrote:
> Been a long road to get essentially back to
> where we started :)

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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] proposal:

[Justin Deoliveira]

Updated proposal with my +1. Been a long road to get essentially back to
where we started :)

On Wed, Jun 1, 2016 at 2:34 AM Ian Turton  wrote:

> +1
>
> Ian
> On 31 May 2016 23:57, "Jody Garnett"  wrote:
>
>> We have the following motion:
>>
>> "Apply OSGeo copyright on creation/contribution"
>>
>> And response via email:
>>
>>- Andrea Aime +1 (second)
>>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>>- Christian Mueller
>>- Ian Turton
>>- Jody Garnett +1 (motion)
>>- Justin Deoliveira +0 (agreement but no clear vote)
>>- Simone Giannecchini
>>
>> Community response:
>>
>>- Torben: Seems like a good idea
>>
>> With this motion approved I will update the developers guide as outlined
>> in the proposal
>> 
>> .
>> --
>> Jody Garnett
>>
>>
>> --
>> 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
>>
>>
> --
> 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
>
--
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] Proposal: ask OSGeo for legal advice on copyright headers

[Ian Turton]

+1
Ian
On 31 May 2016 21:57, "Ben Caradoc-Davies"  wrote:

> I propose that we ask OSGeo to: "Obtain legal advice on the need for and
> form of source code copyright headers."
>
> So far we have three +1 votes but we need more. PMC?
>
> Kind regards,
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> 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
>
--
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] proposal:

[Ian Turton]

+1

Ian
On 31 May 2016 23:57, "Jody Garnett"  wrote:

> We have the following motion:
>
> "Apply OSGeo copyright on creation/contribution"
>
> And response via email:
>
>- Andrea Aime +1 (second)
>- Ben Caradoc-Davies +0 (agreement but no clear vote)
>- Christian Mueller
>- Ian Turton
>- Jody Garnett +1 (motion)
>- Justin Deoliveira +0 (agreement but no clear vote)
>- Simone Giannecchini
>
> Community response:
>
>- Torben: Seems like a good idea
>
> With this motion approved I will update the developers guide as outlined
> in the proposal
> 
> .
> --
> Jody Garnett
>
>
> --
> 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
>
>
--
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