Re: [Geotools-devel] Issue with mosaic of indexed png's

[Justin Deoliveira]

Thanks for the input guys. Your suggestions make sense. I'll try removing
the seek and see how that works with all of the geotools/geoserver unit
tests and also do some smoke testing. I'll file a bug in jira with all of
the details as well.

On Thu, Oct 31, 2019 at 3:55 AM Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Justin,
> I tracked a bit the git history and it looks like that this seek(0) is
> there since 2012 (that is where the git history ends more or less).
> Not sure if that seek(0) has been put there for a real reason (since JAI
> uses deferred execution and reader can start the actual read only once
> need) or as a some kind of precaution.
> I think that you could try removing that line and do some GeoServer tests
> using ImageMosaic with configured "use JAI imageread" and see what happens
> under load.
>
> Please, let us know.
> Regards,
> Daniele
>
>
>
>
>
>
> On Thu, Oct 31, 2019 at 10:05 AM Andrea Aime 
> wrote:
>
>> Hi Justin,
>> before we add a flag to work around it, I was wondering if the issue
>> could be fixed in a different way, like, at the source.
>>
>> Looking at the FileImageInputStreamImpl, I've noticed one oddball thing,
>> but it's probably not related: the lines do not seem matching up.
>>
>> https://github.com/geosolutions-it/imageio-ext/blob/master/library/streams/src/main/java/it/geosolutions/imageio/stream/input/FileImageInputStreamExtImpl.java#L285
>>
>> Anyways, the error in question is a few lines above... seems someone is
>> reading the header (to get the color model as you say), the PNGImageReader
>> calls flushBefore updating the flushedPos, and then the seek(0) in
>> ReadType.JAI_IMAGEREAD fails. Hum... I'm wondering if the seek(0) really
>> necessary, given that the reader has been provided as parameter? (e.g., is
>> it the same read on which we called to get the color model?). Another
>> option could be to temporarily pass a wrapping input stream killing the
>> flushbefore, just for the sake of reading the header...
>>
>> Daniele's input much appreciated too :-D
>>
>> Cheers
>> Andrea
>>
>>
>> On Wed, Oct 30, 2019 at 9:43 PM Justin Deoliveira 
>> wrote:
>>
>>> Hi folks,
>>>
>>> I am working on upgrading an application from a much older version of
>>> geotools (15.1) to the latest stable. I've hit a roadblock regarding image
>>> mosaics consisting of indexed PNG files that I think I have narrowed down
>>> to this change:
>>>
>>>
>>> https://github.com/geotools/geotools/commit/585b021d15df7d132bd6963d7fb78338e814b625
>>>
>>>
>>> What appears to be happening is that the call to getRawColorModel is
>>> advancing the underlying image stream. Later on in the process that same
>>> stream stream is "seeked" back to the zero position in preparation for the
>>> actual read operation, and that throws an exception:
>>>
>>> java.lang.IllegalArgumentException: pos < flushedPos!
>>> at
>>> it.geosolutions.imageio.stream.input.FileImageInputStreamExtImpl.seek(FileImageInputStreamExtImpl.java:285)
>>> at
>>> org.geotools.coverage.grid.io.imageio.ReadType$2.read(ReadType.java:131)
>>> at
>>> org.geotools.gce.imagemosaic.GranuleDescriptor.loadRaster(GranuleDescriptor.java:928)
>>>
>>>
>>> I am guessing it's perhaps some limitation with the PNG format (which I
>>> know is about the worst possible format to be rendering imagery from 樂 ).
>>>
>>> So I guess my first question is would this be considered a bug? Or more
>>> or a limitation with this particular file format? I am guessing a bug since
>>> prior to this change this scenario works.
>>>
>>> Assuming that bug is the consensus I'd be happy to attempt a patch but
>>> probably need some guidance on how to proceed. My initial thought for a
>>> "quick fix" was that perhaps we could add a flag to the mosaic
>>> configuration or a read parameter that specified explicitly that the images
>>> in the mosaic have an IndexColorModel so that we can forgo the check and
>>> hence not pre-advance the image stream?
>>>
>>> Thoughts appreciated.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>>
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>&g

[Geotools-devel] Issue with mosaic of indexed png's

[Justin Deoliveira]

Hi folks,

I am working on upgrading an application from a much older version of
geotools (15.1) to the latest stable. I've hit a roadblock regarding image
mosaics consisting of indexed PNG files that I think I have narrowed down
to this change:

https://github.com/geotools/geotools/commit/585b021d15df7d132bd6963d7fb78338e814b625


What appears to be happening is that the call to getRawColorModel is
advancing the underlying image stream. Later on in the process that same
stream stream is "seeked" back to the zero position in preparation for the
actual read operation, and that throws an exception:

java.lang.IllegalArgumentException: pos < flushedPos!
at
it.geosolutions.imageio.stream.input.FileImageInputStreamExtImpl.seek(FileImageInputStreamExtImpl.java:285)
at org.geotools.coverage.grid.io.imageio.ReadType$2.read(ReadType.java:131)
at
org.geotools.gce.imagemosaic.GranuleDescriptor.loadRaster(GranuleDescriptor.java:928)


I am guessing it's perhaps some limitation with the PNG format (which I
know is about the worst possible format to be rendering imagery from 樂 ).

So I guess my first question is would this be considered a bug? Or more or
a limitation with this particular file format? I am guessing a bug since
prior to this change this scenario works.

Assuming that bug is the consensus I'd be happy to attempt a patch but
probably need some guidance on how to proceed. My initial thought for a
"quick fix" was that perhaps we could add a flag to the mosaic
configuration or a read parameter that specified explicitly that the images
in the mosaic have an IndexColorModel so that we can forgo the check and
hence not pre-advance the image stream?

Thoughts appreciated.

Thanks!

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

Re: [Geotools-devel] Update of Graph Module

[Justin Deoliveira]

Hey Ian, great stuff!

If you want to step up to take on that module you're more than welcome too.
I unfortunately don't have time these days to remain an active maintainer
on the project, I can only contribute as my project work allows me too. So
it's all yours. Your proposed changes all sound great.

-Justin

On Fri, Mar 15, 2019 at 11:45 AM Ian Turton  wrote:

> I've just put in a PR (https://github.com/geotools/geotools/pull/2321)
> against the GeoTools graph module. Basically, I've moved it to using typed
> collections and java.util collections over hand crafted implementations. I
> don't know how much time you have to look after this module Justin, if you
> would like I could step up and help maintain it, if you'd like?
>
> What I had actually started on was adding  equality and hashcode methods
> to Edge and Node so that I could check if collections of Edges or Nodes
> contained the edge or node I'm currently using. But this breaks a number of
> the tests so I'm now not sure if adding the same edge twice (or more) is a
> useful thing that ought to be allowed or if I can quietly modify the tests
> without anyone noticing?
>
> Cheers
>
> Ian
>
> --
> Ian Turton
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Postgis raster module

[Justin Deoliveira]

Ok, build checks all passed and PR merged.

On Wed, Feb 27, 2019 at 8:47 AM Justin Deoliveira 
wrote:

> Cool. I did add it to the unsupported/pom.xml as one of the modules
> included in a normal build. So fingers crossed :)
>
> On Wed, Feb 27, 2019 at 8:44 AM Andrea Aime 
> wrote:
>
>> On Wed, Feb 27, 2019 at 4:34 PM Justin Deoliveira 
>> wrote:
>>
>>> One thing I forgot as usual is the copyright headers... I'll add those
>>> too :)
>>>
>>
>> If you put the module in the build, CheckStyle will complain :-p
>>
>> 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] Postgis raster module

[Justin Deoliveira]

Cool. I did add it to the unsupported/pom.xml as one of the modules
included in a normal build. So fingers crossed :)

On Wed, Feb 27, 2019 at 8:44 AM Andrea Aime 
wrote:

> On Wed, Feb 27, 2019 at 4:34 PM Justin Deoliveira 
> wrote:
>
>> One thing I forgot as usual is the copyright headers... I'll add those
>> too :)
>>
>
> If you put the module in the build, CheckStyle will complain :-p
>
> 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] Postgis raster module

[Justin Deoliveira]

Haha, all good , thanks Andrea. I'll submit a pull request shortly and if
all the build checks are happy I'll go ahead and merge. One thing I forgot
as usual is the copyright headers... I'll add those too :)

On Wed, Feb 27, 2019 at 7:34 AM Andrea Aime 
wrote:

> On Wed, Feb 27, 2019 at 3:30 PM Andrea Aime 
> wrote:
>
>> Hi Justin,
>> I don't have time to review the code
>>
>
> As in, no time "right now" :-p
>
> 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] Postgis raster module

[Justin Deoliveira]

Hi folks,

Following up on a post from a few months back I've been working on a module
that supports reading rasters from a postgis database. I'd like to
contribute it as an unsupported module module for now.

The code can be found here:


https://github.com/jdeolive/geotools/tree/postgis-raster/modules/unsupported/postgis-raster

A few details about the module:

- It's a standalone reader, no dependencies on the core imagemosaic or
imagemosaic-jdbc modules
- It supports time dimension, but not elevation
- It supports jndi connections or a direct connection pool, same as jdbc
datastores
- It's not a structured coverage reader in that it's not possible to read
multiple coverages with one reader, but I plan to add that

It's a work in progress to be sure, I am sure there are lots of
improvements to be made, etc... getting eyes on the code from the raster
experts I am sure will bring up a number of things so be kind ;) Kidding,
feedback very welcome.

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

Re: [Geotools-devel] Raster classifier operation for large inputs

[Justin Deoliveira]

Hey Andrea,

All of your changes sound good to me. Only question I have is whether your
proposed change will replace what is there? Or is your thought to add some
config parameter that would trigger the histogram / approximation based
method?

As for moving the code to jai-text definitely makes sense to me.

-Justin

On Wed, Nov 14, 2018 at 10:00 AM Andrea Aime 
wrote:

> Hi,
> I'm looking into extending the GeoServer SLDService API to work against
> raster data too.
> The current code in that module works off the vector classification
> functions for equal intervals, natural breaks and quantiles.
>
> When looking at extending it for rasters, I stumbled into
> the ClassBreaksOpImage and its subclasses, which
> does more or less what I need... with a hitch though: the rasters that I'm
> playing with can be large and have floats/doubles
>
> Looking at the implementation for quantilies and natural breaks I've
> noticed that all input values get collected
> either in a List or a Map, where the doubles are
> the values and the integer is a pixel count.
> Mind, this is the same as vector code is doing, but getting to a million
> of those in raster space only requires a 1000x1000
> image... and millions of double values (or map entries) take up a lot of
> space. I could look into using non boxed
> variants, but the issue is not really that one, it's just that keeping
> track of all values requires too much space.
>
> So I'd like to add an approximate calculator instead that collects
> histograms, and the works off the result applying the
> same logic as today. Ideally, these would be new entries in
> the ClassificationMethod enumeration, say
> QUANTILE_HISTOGRAM and NATURAL_BREAKS_HISTOGRAM, and ClassBreaksOpImage
> would have an
> extra optional parameter to decide the bucket count (with some reasonable
> defaults, e.g. 256 for byte data,
> 1000 for any other type).
> Working off histograms has a clear benefit, the size of the working memory
> is fixed at the start, and it's possible
> to use primitives in the data structure, of course it also means the
> resulting classification won't be exact, but
> should be close enough.
> The downside is that the min/max values need to be known in advance to
> build the buckets, so for the histogram
> based methods the "extrema" parameter in the ClassBreaksOpImage will be
> mandatory (exception thrown if not provided).
>
> How does that sound?
>
> Cheers
> Andrea
>
> PS: most operations are in jai-ext, mind if the ClassBreaksOpImage gets
> moved there, in its own module?
>
> --
>
> 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

[Geotools-devel] Stepping aside from PMC

[Justin Deoliveira]

Hi folks,

Some of you are probably shocked that I am still actually still on the PMC
given my level of involvement over the past few years but technically I am.
I figure there are other developers who are far more active with GeoTools
than myself who would make great PMC members so I am happy to step aside
and let someone else take the spot if interested. I’ll leave it in the
capable hands of the currently active PMC to figure out who that is.

Thanks and awesome work to the core team who keep GeoTools going!

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

Re: [Geotools-devel] About the OGR failures

[Justin Deoliveira]

Hey guys. Definitely ok with moving the jni based module back to
unsupported. As you know I havent been much of a maintainer for quite some
time now so I'm fine with whatever you guys think best.

On Sat, Apr 21, 2018, 2:19 AM Andrea Aime 
wrote:

> On Sat, Apr 21, 2018 at 12:08 AM, Ben Caradoc-Davies 
> wrote:
>
>> On 20/04/18 18:24, Andrea Aime wrote:
>>
>>> On Fri, Apr 20, 2018 at 1:16 AM, Jody Garnett 
>>> wrote:
>>>
 Andrea, I often often been frustrated with build difficulties on this
 one
 over the years. I understand it is not supported, so just remain
 frustrated
 - usually removing GDAL when it showed up on my path.

>>> Well, the module is actually in supported land, and cannot stay there in
>>> this condition.
>>> The JNI part is equally broken, but at least it's not breaking the build.
>>> I have too many modules to look after, time to cut some dead branches
>>>
>>
>> +1 to demote modules that we do not support to unsupported status.
>>
>> Note however that we do have some community interest in GDAL and we
>> should give them a chance to assess whether they are willing to support
>> this module.
>>
>
> Yes, we can move the module down to unsupported and remove it from the
> -Dall build.
> Question, should I move out only the BridJ module, or also the JNI one?
> Is anyone still caring for it? Justin, you're the maintainer right?
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 
> 55054  Massarosa
> 
> (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
--
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] [Geowebcache-devel] Codebase reformat using Google/AOSP format

[Justin Deoliveira]

+1


On April 15, 2018 at 7:55:46 AM, Andrea Aime (andrea.a...@geo-solutions.it)
wrote:

Hi Ian,
yep, I surely hope it will make everybody's life easier in the medium-long
term,
even if there will be an adjustment period at the beginning

Cheers
Andrea

On Sun, Apr 15, 2018 at 2:25 PM, Ian Turton  wrote:

> +1
>
> Thanks for this, it will make life so much easier
>
> Ian
>
> On 15 April 2018 at 10:47, Andrea Aime 
> wrote:
>
>> Hi all,
>> sorry for the cross posting, but this proposal is best applied on all
>> projects toghether, and would
>> have the same contents on all projects (if really needed, I can
>> copy/paste on GeoServer's wiki):
>>
>> https://github.com/geotools/geotools/wiki/Codebase-Reformat
>>
>> The last discussion and vote showed that everybody is comfortable with
>> the AOSP format, so that's
>> the one that has been chosen.
>>
>> Please vote :-)
>>
>> Once voting is done we'll have to coordinate a bit in order to avoid
>> major issues with pull request
>> merging (although I believe some work will end up having merge issues
>> anyways, don't think we
>> can review and merge all outstanding pull requests).
>>
>> Cheers
>> Andrea
>>
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 
>> 55054  Massarosa
>> 
>> (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility  for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geowebcache-devel mailing list
>> geowebcache-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geowebcache-devel
>>
>>
>
>
> --
> Ian Turton
>



--

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

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

Re: [Geotools-devel] Enhancing GeoJSON serialisation for deep properties

[Justin Deoliveira]

I’m the original author of most of that code, but as Andrea states I
haven’t had the time to be a decent maintainer of it, so definitely go
ahead with your improvements, having support for “deep” or “complex”
properties would be great. That module is fair game!

A word of warning: the way the parser is implemented it has some
limitations and complexities. It’s a purely streaming based parser that
looks a lot like the XML sax interfaces, and because of that and the way it
manages state can be brittle and very dependent on how things are ordered
in a JSON document. I think there are a handful of tickets open with regard
to ordering of properties.

One of the things I wanted to do in that module was re-implement it in a
way that was more of a hybrid streaming approach where the only time we
“stream" is when it’s required (for feature collections) and for most other
objects just load everything into a map/list like data structure before
parsing it to a feature, geometry, etc… Unfortunately no such time do that
has presented itself :)


On March 16, 2018 at 5:47:02 AM, Andrea Aime (andrea.a...@geo-solutions.it)
wrote:

On Fri, Mar 16, 2018 at 12:25 PM, Jesper Steen Møller 
wrote:

> Hi list
>
> My use case for working with GeoJSON has hit upon a limitation in the
> GeoJSON reader, regarding "deep" objects in a Feature's properties. This is
> permitted by the spec, but isn't handled well in the deserializer (see
> GEOT-5158  and GEOT-4100
> ).
>
> I'm guessing there's an issue in writing, too.
>
> I'd be happy to prepare a PR for a generic handling of deep properties,
> using either List<> and Map<> or the appropriate JSON types, if you are
> interested.
> I want to implement it in a way so that reading a GeoJSON containing deep
> properties into Features and serializing it back out would work without
> loss.
>
> But first, I'd like to hear if any of the maintainers have any opinions
> regarding such a change?
>

The gt-geojson module is in "unsupported", thus un-maintained.
I believe nobody will complain, but let's hear others :-)


> Have any of the other formats similar "deep properties" - GML for instance?
>

GML nested properties have to abide to a schema, we have app-schema and
associated GML encoder support for that already.
But not for features having lists/maps inside, there is no support for it,
and no way to build a schema for them either right now.
Hope this helps.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

--

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] Motion: CSS module graduation

[Justin Deoliveira]

+1.

On Sun, Jul 30, 2017 at 3:10 PM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob:   +39  333 8128928 <+39%20333%20812%208928>
>
> 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 Sun, Jul 30, 2017 at 11:38 AM, Andrea Aime
>  wrote:
> > Hi all,
> > I'm hereby proposing the graduation of the CSS module.
> >
> > Gold star requirements:
> >
> > Module maintainers: Andrea Aime
> > Passes IP check, basically has correct headers
> >
> > It's basically fully written by me, including the test files. See also
> >
> https://github.com/geotools/geotools/blob/master/modules/unsupported/css/REVIEW.md
> >
> > Releasable - has no non blocking bugs in jira
> >
> > No blockers in Jira
> >
> > Used in anger - Used by GeoServer or uDig or Geomajas (ie some kind of
> large
> > real world datasets)
> >
> > Yes, has been used in the CSS GeoServer extension for a while
> >
> > Optimised - has been tuned to meet hard performance requirements (example
> > shapefile)
> >
> > Recently tuned for translation large CSS documents (e.g., OSM roads, 500+
> > lines of CSS, translates into SLD in around a second on a first gen core
> i7)
> >
> > Supported - user docs, module maintainer watches user list, answers email
> > etc.. (example referencing)
> >
> > Documentation at
> > http://docs.geotools.org/latest/userguide/unsupported/css.html and
> > http://docs.geoserver.org/latest/en/user/styling/css/index.html
> >
> > Follow the Developers Guide
> >
> > Formatting cleaned up
> > Analyzed with SpotBugs (successor to FindBugs), found 4 small issues that
> > were fixed
> >
> > Code coverage
> >
> > EclEmma in Eclipse reports a coverage of 73% (cobertura does not work
> with
> > Java 8 bytecode)
> >
> > The module would be graduated into modules/extension.
> >
> > 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 <+39%200584%20962313>
> > fax: +39 0584 1660272 <+39%200584%20166%200272>
> > mob: +39  339 8844549 <+39%20339%20884%204549>
> >
> > http://www.geo-solutions.it
> > http://twitter.com/geosolutions_it
> >
> > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> >
> > Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i
> > file/s allegato/i sono da considerarsi strettamente riservate. Il loro
> > utilizzo è consentito esclusivamente al destinatario del messaggio, per
> le
> > finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio
> > senza esserne il 

Re: [Geotools-devel] Move DataUtilities URL methods to new Urls class in gt-metadata [GEOT-5740]

[Justin Deoliveira]

I would prefer Urls, think it reads nicer. $0.02

On Tue, May 30, 2017 at 1:38 AM Andrea Aime 
wrote:

> And I'd say "don't touch" :-) (take it as a -0)
> I agree common conventions is good. And agree that we might want to set
> one convention from here onwards.
> But can we please do it without breaking backwards compatibility (or
> possibly generating a lot of deprecated methods?).
>
> I'd suggest to put effort where (at least personally I feel it's) more
> valuable, like helping users, writing docs, fixing bugs... but of course,
> it's just me :-p
>
> Cheers
> Andrea
>
>
> On Tue, May 30, 2017 at 7:15 AM, Ben Caradoc-Davies 
> wrote:
>
>> Developers,
>>
>> Do you want "Urls" or "URLs"?
>>
>> Jody writes: "Please follow java naming conventions Urls renames to URLs"
>>
>> And I responded: "@jodygarnett we might need to put Urls vs URLs to a
>> vote on the mailing list. Looking through the dependencies we have (visible
>> from GeoServer gs-web-app Start) we have a huge mix of URL versus Url
>> prefixes. There is at least one other Urls class out there. I think we ask
>> the developers what they want. There is a modern style that three-letter
>> acronyms get lowercase tail letters when forming CamelCase/PascalCase. Does
>> this rule apply when adding an "s" in the style of "Lists", "Collections",
>> and "Streams"? I thought yes, but happy to change it to match majority
>> preference."
>>
>> Wiremock has an Urls class for its static URL helper methods.
>>
>> You say tomayto, I say tomahto, ...
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 30/05/17 14:23, Ben Caradoc-Davies wrote:
>>
>>> I want to move the DataUtilities URL methods to new Urls class in
>>> gt-metadata. Current methods will be retained and @deprecated:
>>>
>>> Jira:
>>>
>>> [GEOT-5740] Move DataUtilities URL methods to new Urls class in
>>> gt-metadata
>>> https://osgeo-org.atlassian.net/browse/GEOT-5740
>>>
>>> Pull request for master:
>>>
>>> [GEOT-5740] Move DataUtilities URL methods to new Urls class in
>>> gt-metadata (master)
>>> https://github.com/geotools/geotools/pull/1604
>>>
>>> The main change is that methods like DataUtilities.fileToURL and
>>> DataUtilities.urlToFile become shorter: Urls.fileToUrl and
>>> Urls.urlToFile respectively. There is a small amount of code preening. I
>>> also updated the docs and examples to use the new API.
>>>
>>> Kind regards,
>>>
>>>
>> --
>> 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
>>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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
> 

Re: [Geotools-devel] A bunch of color operation functions

[Justin Deoliveira]

A big +1 on making them central, give in that we now have sld, css, and
ysld I think as much as we can share among them the better!

On Sun, Apr 23, 2017 at 3:46 AM Andrea Aime 
wrote:

> Hi,
> this pull request adds a bunch of lesscss.org color operation functions:
> https://github.com/geotools/geotools/pull/1562
>
> At first I was thinking to add them in the CSS module, but realized I
> could actually
> just make them standard GeoTools functions and add some syntactic sugar to
> the
> CSS module to make them look as native ones.
>
> Mind, it's not the full set of lesscss.org color functions, the blending
> functions
> are not there (volunteers welcomed) and those manipulating the alpha
> channel
> are also missing as opacity is handled in a different way in SLD
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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.
>
> ---
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Question about centroid sampling code

[Justin Deoliveira]

Haha. 5% of Andrea still equals 200% of any mere mortal ;) so much
appreciated! This gives me a couple of things to explore. Thanks again!



On Wed, Apr 12, 2017 at 10:22 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> sorry I'm currently in a meeting that will last till the end of day so
> you're getting 5% of my attention :-p (better that or full attention in the
> weekend?)
> Re-read again, yeah, go ahead with what you're proposing, it sounds more
> than reasonable.
>
> Cheers
> Andrea
>
>
> On Wed, Apr 12, 2017 at 6:20 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hmmm… I could explore that but it seems like a kind of round about away to
> go and more invasive. All I need is a central point to use as the placemark
> so I prefer to just call that same sampling routine to get it, which as far
> as I can tell should be a 100% safe refactoring. If we’re not comfortable
> with exposing that code that is currently in label cache I guess I could
> just copy and modify the code to behave how I need and just have it live in
> the KML module rather than expose it as public api in GeoTools?
>
> On Wed, Apr 12, 2017 at 10:15 AM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
> On Wed, Apr 12, 2017 at 5:36 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Thanks Andrea, I thought that might be the case. And yes, my intention is
> to try and use this code for KML in order to choose a placemark placement
> that lies inside the polygon.
>
> Any objection to adding multiple arguments (or maybe multiple methods)
> that would invoke the same code but allowing for both options? Option 1
> being the exact way it is today and option 2 being the number of samples?
>
>
> Thinking out loud, what about transforming the geometry into a fictional
> screen instead before submitting it to the labeller?
> Should be one affine transform away (like, a handful of lines of code,
> creating a Affine based MathTransform and applying it to the geometries,
> you can get the transform from RendererUtilties.worldToScreenTransform).
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU

Re: [Geotools-devel] Question about centroid sampling code

[Justin Deoliveira]

Hmmm… I could explore that but it seems like a kind of round about away to
go and more invasive. All I need is a central point to use as the placemark
so I prefer to just call that same sampling routine to get it, which as far
as I can tell should be a 100% safe refactoring. If we’re not comfortable
with exposing that code that is currently in label cache I guess I could
just copy and modify the code to behave how I need and just have it live in
the KML module rather than expose it as public api in GeoTools?

On Wed, Apr 12, 2017 at 10:15 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Wed, Apr 12, 2017 at 5:36 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Thanks Andrea, I thought that might be the case. And yes, my intention is
> to try and use this code for KML in order to choose a placemark placement
> that lies inside the polygon.
>
> Any objection to adding multiple arguments (or maybe multiple methods)
> that would invoke the same code but allowing for both options? Option 1
> being the exact way it is today and option 2 being the number of samples?
>
>
> Thinking out loud, what about transforming the geometry into a fictional
> screen instead before submitting it to the labeller?
> Should be one affine transform away (like, a handful of lines of code,
> creating a Affine based MathTransform and applying it to the geometries,
> you can get the transform from RendererUtilties.worldToScreenTransform).
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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.
>
> ---
>
--
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] Question about centroid sampling code

[Justin Deoliveira]

Thanks Andrea, I thought that might be the case. And yes, my intention is
to try and use this code for KML in order to choose a placemark placement
that lies inside the polygon.

Any objection to adding multiple arguments (or maybe multiple methods) that
would invoke the same code but allowing for both options? Option 1 being
the exact way it is today and option 2 being the number of samples?


On Wed, Apr 12, 2017 at 8:45 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Ah wait,
> it might be that it normally is, during map rendering, but the KML code is
> not working against a screen, and that's why
> you are asking this question?
>
> Cheers
> Andrea
>
>
> On Wed, Apr 12, 2017 at 4:44 PM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
> Hi Justin,
> are you sure that's a "unit"? I thought it was pixel. Aren't the
> geometries reprojected and brought to screen space already at that point?
>
> Cheers
> Andrea
>
> On Wed, Apr 12, 2017 at 4:36 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hi folks,
>
> I am working on patch that takes some code from the LabelCacheImpl into
> RendererUtilities. Basically I want to re-use the logic that attempts to
> find a central point that actually lies within a polygon.
>
> The code I have a question about is this, where the size of a sampling
> “step” is computed:
>
> https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/label/LabelCacheImpl.java#L1282-L1286
>
> Which if I interpret correctly means always use a step size of “5 units”.
> It seems like this would result in a very different amount of steps for
> things like geometry size, projection, etc… But perhaps that is the
> intention, which is why I am asking. Ultimately what I am wondering is if
> it would make sense to specify as an input to the routine the “number of
> samples” one would want to perform and then calculate the step size based
> on that?
>
> Thanks!
>
> -Justin
>
>
>
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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.
>
> --

[Geotools-devel] Question about centroid sampling code

[Justin Deoliveira]

Hi folks,

I am working on patch that takes some code from the LabelCacheImpl into
RendererUtilities. Basically I want to re-use the logic that attempts to
find a central point that actually lies within a polygon.

The code I have a question about is this, where the size of a sampling
“step” is computed:

https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/label/LabelCacheImpl.java#L1282-L1286

Which if I interpret correctly means always use a step size of “5 units”.
It seems like this would result in a very different amount of steps for
things like geometry size, projection, etc… But perhaps that is the
intention, which is why I am asking. Ultimately what I am wondering is if
it would make sense to specify as an input to the routine the “number of
samples” one would want to perform and then calculate the step size based
on that?

Thanks!

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

Re: [Geotools-devel] XML Binding Generation?

[Justin Deoliveira]

I think porting over the old models would be great topic for a code sprint.
Especially since there will be a bit of stuff around the models (custom xml
bindings, request handling in geoserver, etc…) that also needs to change.

On Fri, Apr 7, 2017 at 9:12 AM Nuno Oliveira 
wrote:

> Image-mosaic uses JAXB for parsing indexer files (Indexer.xsd and
> Indexer.java).
>
> I add to generate the bindings for the Indexer and with JAXB it was dead
> easy (a command line tool if my memory serves me well):
>
> https://github.com/geotools/geotools/pull/1330/files#diff-21bc719f7346cc82417653798eb636a9
>
> XML encoder and EMF models relationship is pretty strong indeed.
>
> The first time I looked at EMF it looked like an alien thing to me (it
> still looks like that sometimes) :)
>
>
> On 04/07/2017 03:38 PM, Andrea Aime wrote:
>
> On Fri, Apr 7, 2017 at 4:35 PM, Ian Turton  wrote:
>
> Well today's experiments have shown that you can build a model with EMF -
> we just need to bump the EMF version we use from 1.6 to 1.12 which seems to
> keep every thing happy(ish).
>
>
> +1 for upgrading (after a round of build tests maybe :-p)
>
>
> To be honest I'm still a little unsure of what EMF is gaining me but I am
> making progress.
>
>
> Easier gt-xsd binding writing probably? The parser/encoder has a special
> nice relationship with EMF models
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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.
>
> ---
>
>
> --
> 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 
> listGeoTools-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> --
> ==
> 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 <+39%200584%20962313>
> fax:   +39 0584 1660272 <+39%200584%20166%200272>
> mob:   +39  333 8128928 <+39%20333%20812%208928>
> http://www.geo-solutions.ithttp://twitter.com/geosolutions_it
>
> ---
>
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i 
> file/s allegato/i sono
> da considerarsi strettamente riservate. Il loro utilizzo è consentito 
> esclusivamente al destinatario del messaggio, per le finalità indicate
> nel messaggio stesso. Qualora riceviate questo messaggio senza 

Re: [Geotools-devel] XML Binding Generation?

[Justin Deoliveira]

Who was it that once said something about complaining without offering up
any alternative to make it better…?

That said I agree with Andrea, given the chance to do this over again I
would certainly push for not using EMF and the way those model generations
work. I would say moving forward that definitely for newer models being
added not to follow the EMF pattern, and use something like JAXB.

About the models that exist though… it would be a serious undertaking to
port them to something else. Also keeping in mind that at the time they
were built the only parser I could find that could actually handle some of
the crazy OGC schemas was the EMF one… as some of the JAXB stuff was still
in infancy at that point, or just couldn’t handle the craziness. Hopefully
that has changed now. That said perhaps with some search and replace
goodness those models could be converted… it might be worth starting with
one of the simpler ones to see if those classes could be reused in a jaxb
context.

$0.02

On Fri, Apr 7, 2017 at 3:20 AM Andrea Aime 
wrote:

> Hi Ian,
> yep, it's a royal pain... the latest model I've generated, I've done the
> EMF way, but it required
> grabbing a Eclipse as old as the tutorial, then generating the object
> model from the schema, and twaking
> the interfaces and re-generating the EMF model iteratively until I got to
> a satisfactory point
> (or lost patience/hope and called it good enough).
>
> Cheers
> Andrea
>
>
> On Fri, Apr 7, 2017 at 11:03 AM, Ian Turton  wrote:
>
> Do we as a project have a view on how to generate bindings from an XML
> schema?
>
> The XML Faq (
> http://docs.geotools.org/latest/userguide/library/xml/faq.html) helpfully
> lists 7 different parsing approaches while the internals page (
> http://docs.geotools.org/latest/userguide/library/xml/internal/index.html)
> has links to (essentially) blank pages about the modules involved in xml
> handling. If I look at the tutorial (
> http://docs.geotools.org/latest/userguide/library/xml/internal/tutorial.html)
> it uses JAXB (which apparently none of our modules do). There is also a
> guide to the codegen methodolgy (
> http://docs.geotools.org/latest/userguide/library/xml/internal/code.html)
> which doesn't seem to match what modules on the ground (e,g, wfs) do and
> seems to only generate an empty schema class. Then there is EMF, but the
> latest tutorial for that is from 2014 (
> http://eclipsesource.com/blogs/tutorials/emf-tutorial/) so it's either
> very out of date or very stable.
>
> Personally I'd lean towards JAXB as it is built in and the OGC provide
> prebuilt jars (https://repo1.maven.org/maven2/org/jvnet/ogc/) for most of
> their standards. But as JABX is currently the only XML technology we don't
> use I'm wary of adding yet another XML technology to our stack.
>
> Thoughts?
>
> Ian
>
>
> --
> 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
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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 

Re: [Geotools-devel] Adding a kerning vendor option and enable it by default

[Justin Deoliveira]

I think anything that makes rendering look better out of the box is a big
win. I would say as long as the performance hit isn't catastrophic this
would be worth it. $0.02
On Sun, Mar 26, 2017 at 8:49 AM Andrea Aime 
wrote:

> Hi,
> a question on stackoverflow [1] prompted me to look into font kerning in
> java. After a few
> attempts I managed to enable it and imho indeed the result looks
> prettier... but one has to
> look carefully :-)
>
> I've created a before and after example, with a "difference" image
> highlighting in red what
> changed (so that you don't get lost looking for the differences, mind,
> some labels changed just slightly,
> others in a more visible way):
>
>- Before:
>http://demo.geo-solutions.it/share/kerning/roads_no_kerning.png
>- After: http://demo.geo-solutions.it/share/kerning/roads_kerning.png
>- Difference: http://demo.geo-solutions.it/share/kerning/difference.png
>
> I still need to run a few extra tests (and check how much performance
> we're going to lose
> by enabling it, as it requires a more complex layout), but given the
> results, I'd be inclined
> to enable this by default, with a vendor option to turn it off in case
> someone finds issues with it.
>
> Opinions?
>
> Cheers
> Andrea
>
> [1]
> http://gis.stackexchange.com/questions/233346/kerning-in-geoserver-labels
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Commit Access request for Unsupported Module MapBoxStyles

[Justin Deoliveira]

Welcome David!

+1.

I am sure Jody has already pointed it out to you but in case not, here is
good info about the committer process and stuff in general:

  http://docs.geotools.org/latest/developer/roles/index.html


-Justin


On Wed, Mar 1, 2017 at 2:39 PM David Vick  wrote:

> Hello,
>
> My name is David Vick.  I am a developer working for Boundless and have
> recently been assigned to work on the unsupported module for MapBox
> styles.  I am requesting commit access to GeoTools in support of this work.
>
> Regards,
>
> David Vick
>
> Professional Services Engineer | Boundless 
> dv...@boundlessgeo.com
> mobile: +1-636-698-3174 <(636)%20698-3174>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Next skype meeting?

[Justin Deoliveira]

Hey folks,

I am going to make an effort to try and attend the bi-weekly skype
meetings. Based on the last reminder email from Ben the next meeting will
be Tuesday, Feb 21, at 16:30 UTC? Do I have that right?

Thanks!

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

Re: [Geotools-devel] Call for vote on JDBC Callback proposal

[Justin Deoliveira]

Thanks folks for all of the feedback. Since I got a majority of positive
votes I went ahead and merged the code and closed out the proposal.

On Thu, Feb 16, 2017 at 1:20 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> Justin,
>
> I am comfortable with either option, so implementer choice.
>
> The origin of the term "gt2" is slowly being lost in the mists of time.
> We have already dropped the "2." from the front of our versions.  :-)
>
> Kind regards,
> Ben.
>
> On 16/02/17 16:18, Justin Deoliveira wrote:
> > Thanks Ben! As mentioned on the pull request I was following the only
> other
> > system property for jdbc I found: “gt2.jdbc.trace”. I do prefer your
> > suggestion aesthetically but I think I would stick with the consistency
> if
> > it were my call.  But if folks feel strongly about it happy to change it
> as
> > well, no strong preference. We could also potentially rename the trace
> > property to “geotools.jdbc.trace” so that everyone wins :) … but not sure
> > how strongly people feel we have to maintain backward compatibility with
> > that.
> >
> > On Wed, Feb 15, 2017 at 7:03 PM Ben Caradoc-Davies <b...@transient.nz>
> wrote:
> >
> >> +1.
> >>
> >> My only comment is that the system property could perhaps be called
> >> "geotools.jdbc.callback" rather than "gt2.jdbc.callback".
> >>
> >> Kind regards,
> >> Ben.
> >>
> >> On 16/02/17 03:32, Justin Deoliveira wrote:
> >>> Thanks to everyone who submitted feedback on the idea, I’ve
> incorporated
> >> it
> >>> into the proposal and I would like to call for a formal vote.
> >>>
> >>>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
> >>>
> >>> Thanks!
> >>>
> >>> -Justin
> >>>
> >>>
> >>>
> >>>
> >>
> --
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >>>
> >>>
> >>>
> >>> ___
> >>> GeoTools-Devel mailing list
> >>> GeoTools-Devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >>>
> >>
> >> --
> >> Ben Caradoc-Davies <b...@transient.nz>
> >> Director
> >> Transient Software Limited <http://transient.nz/>
> >> New Zealand
> >>
> >
>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> 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] Call for vote on JDBC Callback proposal

[Justin Deoliveira]

Thanks Ben! As mentioned on the pull request I was following the only other
system property for jdbc I found: “gt2.jdbc.trace”. I do prefer your
suggestion aesthetically but I think I would stick with the consistency if
it were my call.  But if folks feel strongly about it happy to change it as
well, no strong preference. We could also potentially rename the trace
property to “geotools.jdbc.trace” so that everyone wins :) … but not sure
how strongly people feel we have to maintain backward compatibility with
that.

On Wed, Feb 15, 2017 at 7:03 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> +1.
>
> My only comment is that the system property could perhaps be called
> "geotools.jdbc.callback" rather than "gt2.jdbc.callback".
>
> Kind regards,
> Ben.
>
> On 16/02/17 03:32, Justin Deoliveira wrote:
> > Thanks to everyone who submitted feedback on the idea, I’ve incorporated
> it
> > into the proposal and I would like to call for a formal vote.
> >
> >   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
> >
> > Thanks!
> >
> > -Justin
> >
> >
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >
> >
> >
> > ___
> > GeoTools-Devel mailing list
> > GeoTools-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> 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] Call for vote on JDBC Callback proposal

[Justin Deoliveira]

Thanks Jody!

I’ve address most of the feedback minus the comment about using the factory
finder… didn’t quite follow that one.

On Wed, Feb 15, 2017 at 11:42 AM Jody Garnett <jody.garn...@gmail.com>
wrote:

I added my +1, and provided a review for your pull request.


--
Jody Garnett

On 15 February 2017 at 06:32, Justin Deoliveira <jdeol...@gmail.com> wrote:

Thanks to everyone who submitted feedback on the idea, I’ve incorporated it
into the proposal and I would like to call for a formal vote.

  https://github.com/geotools/geotools/wiki/JDBC-Callbacks

Thanks!

-Justin

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

Re: [Geotools-devel] JDBC Callbacks

[Justin Deoliveira]

Thanks Andrea!

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

-Justin

On Mon, Feb 13, 2017 at 7:49 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> had a quick look, the proposal looks good to me.
> From an implementation point of view, what about joins, aggregate queries
> being optimized out, and the like? (maybe also writing)
> I believe you don't intend to cover them, I'd suggest to update the
> proposal so that it makes it clear those are left out intentionally
> (although, for aggregations for example, a superclass of the current
> reader callback could be used, just thinking out loud here, this
> is not a request for change).
>
> Cheers
> Andrea
>
>
> On Mon, Feb 13, 2017 at 2:25 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hi folks,
>
> I’ve incorporated Jody’s feedback and updated the proposal, and submitted
> a pull request.
>
>   https://github.com/geotools/geotools/pull/1474
>
> I’ll let this one simmer for a day or so and if I don’t get any more
> feedback I’ll call for the official vote.
>
> Thanks!
>
> -Justin
>
> On Thu, Feb 9, 2017 at 1:07 PM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hey Jody, thanks for the feedback.
>
> Answers inline.
>
> On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
> Thanks Justin,
>
> Some questions:
> - Does your before query and after query methods ... need an indication of
> what the sql query is?
>
> Yeah, we should probably pass in some context about the query being
> executed, as well as with the other callbacks. I will work on that.
>
> - I also note that our GeoTools Query data structure provides a "name"
> that is intended to be used for logging, callbacks, and so on - you may
> wish to make use of it?
>
> Good idea, I think that gets passed all the way down to the reader? If so
> I’ll pass that through as well.
>
> - Why does the factory need a name?
>
>
> So that it can be specified via data store parameter or system property.
> For example if my callback factory is named “foo” i want to enable it via
> “gt2.jdbc.callback=foo”.  Perhaps “id” would be a better property name?
>
>
> --
> Jody Garnett
>
> On 9 February 2017 at 06:39, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
> Hi folks,
>
> A while back I sent some email about adding some code to the jdbc
> datastores to facilitate the idea of capturing metrics for jdbc data
> access. Here is what I have come up with in terms of a proposal.
>
>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
>
> Looking forward to getting some feedback.
>
> Thanks!
>
> -Justin
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia

Re: [Geotools-devel] JDBC Callbacks

[Justin Deoliveira]

Hi folks,

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

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

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

Thanks!

-Justin

On Thu, Feb 9, 2017 at 1:07 PM Justin Deoliveira <jdeol...@gmail.com> wrote:

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

Re: [Geotools-devel] JDBC Callbacks

[Justin Deoliveira]

Hey Jody, thanks for the feedback.

Answers inline.

On Thu, Feb 9, 2017 at 12:47 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> Thanks Justin,
>
> Some questions:
> - Does your before query and after query methods ... need an indication of
> what the sql query is?
>
Yeah, we should probably pass in some context about the query being
executed, as well as with the other callbacks. I will work on that.

- I also note that our GeoTools Query data structure provides a "name" that
> is intended to be used for logging, callbacks, and so on - you may wish to
> make use of it?
>
Good idea, I think that gets passed all the way down to the reader? If so
I’ll pass that through as well.

- Why does the factory need a name?
>

So that it can be specified via data store parameter or system property.
For example if my callback factory is named “foo” i want to enable it via
“gt2.jdbc.callback=foo”.  Perhaps “id” would be a better property name?

>
> --
> Jody Garnett
>
> On 9 February 2017 at 06:39, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
> Hi folks,
>
> A while back I sent some email about adding some code to the jdbc
> datastores to facilitate the idea of capturing metrics for jdbc data
> access. Here is what I have come up with in terms of a proposal.
>
>   https://github.com/geotools/geotools/wiki/JDBC-Callbacks
>
> Looking forward to getting some feedback.
>
> Thanks!
>
> -Justin
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] JDBC Callbacks

[Justin Deoliveira]

Hi folks,

A while back I sent some email about adding some code to the jdbc
datastores to facilitate the idea of capturing metrics for jdbc data
access. Here is what I have come up with in terms of a proposal.

  https://github.com/geotools/geotools/wiki/JDBC-Callbacks

Looking forward to getting some feedback.

Thanks!

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

[Geotools-devel] [JIRA] (GEOT-5639) Add JDBC callback interface to JDBC datastore modules

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5639  
 
 
  Add JDBC callback interface to JDBC datastore modules   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Created: 
 09/Feb/17 3:31 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 As described by this proposal.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v1000.747.0#100028-sha1:6f58f37

Re: [Geotools-devel] web, css, x11, html color names support

[Justin Deoliveira]

On Tue, Feb 7, 2017 at 8:37 AM Jody Garnett  wrote:

> Andrea I shared your hesitations - have a look at
> https://github.com/geotools/geotools/pull/1462
>
> The converters go form String to Color, I required the hint to be set (or
> they won't do anything). So although they will be available to all code
> paths they won't function by default. We can then hunt down which part of
> the code wants to use what hint.
>
> (If all the code wants to use the same names as SVG then it would be fine,
> I expect gt-css wants to use CSS colours though).
>
> Justin my research later answered that the colour names story is confusing
> and that x11 is a bump along the road for what browsers now support. Let me
> ask the question differently - Can I change YSLD to match the SVG
> parameters colours used by SLD?
>

Yeah, by all means, as long as what is provided by SLD gives us a similar
amount of colour names I am all for it.

>
> --
> Jody Garnett
>
> On 6 February 2017 at 23:41, Andrea Aime 
> wrote:
>
> Hi Jody,
> +1 for centralizing.
>
> Two hesitations about using a pluggable Converter implementation:
>
>- Would they convert from String to Color (a converter from String to
>String does not make much sense now does it?) and then eventually going
>back to hex in all implementations?
>- Once plugged in the conversion will be available for all other code
>paths doing conversions... probably not a bit deal, but there is always the
>risk of it end up interacting in some other existing code paths in a random
>way. Normally as long as the conversion is unique there are no big problems
>(also check the Wicket UI in GeoServer, that also falls back on GeoTools
>converters)
>
> Cheers
> Andrea
>
> On Tue, Feb 7, 2017 at 12:21 AM, Jody Garnett 
> wrote:
>
> In looking at gt-mbstyle ran into a common need to convert from "red" to
> Color.RED.
>
> Checking our code base ( using put yellow language:java
> )
> we have:
>
> - css Value.java
> 
> - has a map of names to hex strings
> - ysld Colors.java
> 
> - has a map of X11 colors (why x11 Kevin/Torben/Justin is that a mistake?)
>
> I would like to capture this information in one spot (rather than
> duplicate).
>
> What would you say to creating a couple of ColorConverters and would
> engage based on the following hint:
>
> /**
>  * The color names definition to use when converting from String to
> Color.
>  *
>  * @see CommonFactoryFinder#getStyleFactory
>  *
>  * @since 17
>  */
> public static final OptionKey COLOR_NAMES = new
> OptionKey("WEB","CSS","X11","JAVA","*");
>
> I kind of assume SLD should respect CSS colors (as per GEOT-5633
> )?
> --
> Jody Garnett
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 

Re: [Geotools-devel] Promoting gt-ysld to a supported module

[Justin Deoliveira]

+1. Great work on this Torben.
On Thu, Jan 26, 2017 at 4:17 PM Ben Caradoc-Davies  wrote:

> +1. Thanks, Torben, that is quite thorough.
>
> Jody, do we have a policy for which supported modules are plugins and
> which are extensions? I noticed that Torben used the term "plugin" and
> realised that I do not know if we have rules. Is there a difference, or
> is this just an historical oddity?
>
> Kind regards,
> Ben.
>
> On 27/01/17 07:41, Torben Barsballe wrote:
> > The gt-ysld module is now ready to be considered for a supported module.
> >
> > I would like to request that this module be approved for inclusion as a
> > supported plugin in the upcoming 16.2 / 17-beta releases.
> > The module conforms to the requirements
> > 
> for a
> > supported module, as follows:
> > Visibility / Module Status
> >
> >- Gold Star Quality Assurance Check - Plugin QA Test - 4/5 stars
> >
> > Here is how a plugin (aka hooks into the geotools library) may earn a
> star:
> > ⭐️ Passes IP check, basically has correct headers
> >
> >
> >- See REVIEW.md
> >  <
> https://github.com/geotools/geotools/blob/master/modules/unsupported/ysld/REVIEW.md
> >
> >
> > ⭐️ Releasable - has no non blocking bugs in jira
> >
> >
> >- GEOT-5622  is the
> >  only open bug, not blocking.
> >
> > ⭐️ Used in anger - Used by GeoServer or uDig or Geomajas (ie some kind of
> > large real world datasets)
> >
> >
> >- Used by the gs-ysld extension in geoserver
> >
> >   Optimised - has been tuned to meet hard performance requirements
> (example
> > shapefile)
> >
> >
> >- Not really, but only place where this is really important is
> >  rendering, and at this point we are using the gt-api
> > StyledLayerDescriptor
> >  objects
> >
> > ⭐️ Supported - user docs, module maintainer watches user list, answers
> > email etc.. (example referencing)
> >
> >
> >- User documentation here
> >  <
> http://docs.geotools.org/latest/userguide/unsupported/ysld.html>.
> >  - Module maintainers: Justin Deolivera, Kevin Smith
> >
> > Intellectual Property Check
> >
> >- Passes, See
> https://github.com/geotools/geotools/blob/master/modules
> >/unsupported/ysld/REVIEW.md
> >
> > Follow the Developers Guide
> >
> >- Analysis here:
> https://gist.github.com/mattkrusz/b010eb29aa784025a639
> >c473b768801e
> >- PR here: https://github.com/geotools/geotools/pull/1440 (merged)
> >
> > Test Coverage and Maven Profiles
> >
> >- Test coverage exceeds the required 40%: Line coverage is 85%, Branch
> >coverage is 73%
> >
> > User Documentation
> >
> >- Has user documentation:
> http://docs.geotools.org/latest/userguide/uns
> >upported/ysld.html
> >
> >
> >
> > If the GeoTools PMC is happy with the module, I will put together a PR
> > moving it from unsupported to plugin.
> >
> > Thanks,
> >
> > Torben
> >
> > On Wed, Jan 25, 2017 at 3:24 PM, Torben Barsballe <
> > tbarsba...@boundlessgeo.com> wrote:
> >
> >> Thanks for the feedback. Class javadocs have been updated in the PR.
> >>
> >> Torben
> >>
> >> On Wed, Jan 25, 2017 at 9:56 AM, Jody Garnett 
> >> wrote:
> >>
> >>> Thanks, formatting changes look good. I looked for the null returns -
> and
> >>> the "return null" statements I found were not especially documented.
> >>>
> >>> General feedback is we could take one run at class javadocs (usual
> >>> Class/Responsibility/Collaboration info) and we should be good.
> >>>
> >>> --
> >>> Jody Garnett
> >>>
> >>> On 25 January 2017 at 09:26, Torben Barsballe <
> >>> tbarsba...@boundlessgeo.com> wrote:
> >>>
>  Based on Matt's analysis, we have put together a pull request fixing
> up
>  the outstanding issues in gt-ysld bringing it up to compliance with
> the
>  developers guide: https://github.com/geotools/geotools/pull/1440
> 
>  Null returns are documented, and are used sparingly.
> 
>  Torben
> 
>  On Tue, Jan 24, 2017 at 9:56 PM, Jody Garnett  >
>  wrote:
> 
> > I am not as keen as Martin was, I expect that Optionals will take the
> > place of the idea of null objects long term.
> >
> > What I am keen on is making our developer guide not suck; so if we
> are
> > not being strict about null we should relax the guide (citing
> returning a
> > null collection). I am kind of okay with returning null if it is
> clearly
> > documented in the javadocs (since those show up as a tooltip when
> > developers are working).
> >
> > --
> > Jody Garnett
> >
> > On 24 January 2017 at 10:11, Andrea Aime <
> andrea.a...@geo-solutions.it>
> > wrote:
> >
> >> On Tue, Jan 24, 2017 at 6:57 PM, Matt Kruszewski <
> >> mkruszew...@boundlessgeo.com> wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> 

Re: [Geotools-devel] Promoting gt-ysld to a supported module

[Justin Deoliveira]

Hey Torben,

Thanks for pushing this forward. I am happy to keep my name on as module
maintainer list as long as others see fit. I know I haven’t been the most
active maintainer over the past while but unfortunately my involvement is
driven by requirements from project work. That said if someone else is keen
to maintain I will gladly step aside.

-Justin

On Fri, Jan 20, 2017 at 1:12 PM Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> Hello All,
>
> I am hoping to promote gt-ysld to a supported module.
>
> There are still a number of things that need to be done before this module
> is ready to be promoted; I will be tackling these over the next few weeks,
> with the aim of having gt-ysld be a supported module for GeoTools 16.2 next
> month.
>
>- Add proper YSLD documentation to the GeoTools User Guide
>- gt-ysld depends on gt-process. We need to either remove the
>dependency on gt-process, or promote gt-process to a supported module.
>- Perform an IP-check on the gt-ysld module.
>
>
> Justin and Kevin - You are currently marked as the module maintainers for
> the YSLD module. Are either or both of you willing to continue this
> commitment when YSLD moves to a supported module?
>
> Torben
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] JDBC Metrics

[Justin Deoliveira]

Hi folks,

I'm working on a project where I would like to be able to produce some
metrics around reading data from a database via GeoTools/GeoServer. Some
things like:

   - how long it takes from the initial query to reading the last row
   - the time it takes to run the initial query against the database before
   it starts returning data
   - etc...

To facilitate this what I am proposing is to introduce an interface called
JDBCMetrics (or something along those lines). This interface would simply
be a callback that the JDBC classes (most notably JDBCFeatureReader) would
invoke at various times during its life cycle. Implementations of the
interface would be responsible for gathering timing, counts, etc... as it
needs.

I have a few ideas regarding implementations of the interface but before I
go down that road I just wanted to poll the dev group to see if such a
thing would be welcomed, or if folks would have any concerns about this
approach.

Thanks!

-Justin
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] jts use of Shapefile Reader

[Justin Deoliveira]

+1

On Wed, Nov 9, 2016 at 6:06 AM Andrea Aime 
wrote:

> +1 here too
>
> Cheers
> Andrea
>
> On Wed, Nov 9, 2016 at 9:48 AM, Ian Turton  wrote:
>
> +1 from me
>
> Ian
>
> On 8 November 2016 at 22:06, Jody Garnett  wrote:
>
> dual license: EPL / BSD
>
> donating/relicense same story, different workflow:
> donating = here jts you can update the headers for those files you have
> our permission
> relicense = here jts I released the files with updated headers for you, go
> ahead and copy into your project
>
> --
> Jody Garnett
>
> On 8 November 2016 at 11:25, Ben Caradoc-Davies  wrote:
>
> +1 to approve relicensing (to EPL 1.0 if I recall correctly?).
>
> Is there a distinction between relicensing and donating? I think you are
> asking for the former. Donating might mean more paperwork.
>
> Kind regards,
> Ben.
>
> On 09/11/16 07:49, Jody Garnett wrote:
>
> Got a request from working with Martin on the next JTS release:
>
> As part of relicensing JTS we are hunting down where external contributions
> came from, one such is "ShapefileReader" from an early GeoTools 2 release
> (before the switch to the file io api).
>
> Can I ask for PSC approval to send an email/letter to Martin giving him
> permission to relicense this implementation
> <
> https://github.com/locationtech/jts/tree/master/modules/app/src/main/java/org/locationtech/jtstest/testbuilder/io/shapefile
> >.
> This is similar to how we have donated code to GeoAPI in the past (or how
> we accept code from the GeoServer PSC).
>
> The author in question, James Macgill, has signed a code contribution
> license so we (as a PSC) are in position donate this code to the JTS
> project. I have also emailed James Macgill so he knows what we are up to :)
> --
> Jody Garnett
>
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
>
> ___
> 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
>
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> Ian Turton
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the 

Re: [Geotools-devel] One liner proposal: adding a reloadFeatureType(Name) method to DataStore to clear eventual caches attached to a certain feature type

[Justin Deoliveira]

Sounds like a good idea to me. I do have a comment on naming though
(surprise). To me calling it “reloadFeatureType” implies that it will be
reloaded immediately and is perhaps confusing/misleading? Using a verb like
“flush” or “clear” might be more suitable to it’s actually purpose.

$0.02

On Tue, Nov 8, 2016 at 6:37 AM Ian Turton  wrote:

> sounds reasonable to me
>
> Ian
>
> On 8 November 2016 at 10:14, Andrea Aime 
> wrote:
>
> Hi,
> on the GeoServer devel list we have been discussing the ability to clear a
> feature type cache in ContentDataStore with
> minimal disruption to other ongoing activities:
>
> http://osgeo-org.1560.x6.nabble.com/Exposing-the-ability-to-reload-a-feature-type-in-the-REST-API-td5294306.html
>
> Now, the solution reached there works fine for ContentDataStore
> implementations, but still leaves out
> datastore wrappers and other direct implementation of DataStore/DataAccess.
>
> I still don't have a go to work on this, so this is not a formal proposal,
> instead it's a community check.
> How about we add a new method to the DataAccess interface that allows
> flushing a store cached information
> about a certain feature type?
> E.g., leveraging Java 8 default methods:
>
> /**
>  * Drops caches related to the specified feature type. The implementation
> will rebuild the feature type definition either
>  * immediately, or on a as-needed basis in subsequent method calls.
>  */
> public void reloadFeatureType(Name typeName) {
>   // no op default implementation
> }
>
> ContentDataStore will implement such method by getting the content entry
> and flushing the state attached to
> Transaction.AUTO_COMMIT, other wrappers (there are several) will delegate
> to the underlying store.
>
> Opinions?
>
> As said, at the moment this is an exploration, I'm checking what ought to
> be done in order to avoid surprises
> later, once I get the approval to work on this I'll make a formal proposal
> (right now I can't, since it would be
> un-funded).
>
> Cheers
> Andrea
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> Ian Turton
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based 

Re: [Geotools-devel] Proposing Nuno Oliveira as committer

[Justin Deoliveira]

+1, if nothing else based on his last name alone ;)

On Tue, Nov 1, 2016 at 2:30 AM Ian Turton  wrote:

> +1
>
> Ian
>
> On 1 November 2016 at 04:19, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
> +1
>
> Cheers
>
> On Tue, Nov 1, 2016 at 12:26 AM, Jody Garnett 
> wrote:
>
> Agreed +1, thanks for all the work Nuno.
>
> --
> Jody Garnett
>
> On 31 October 2016 at 11:18, Ben Caradoc-Davies  wrote:
>
> +1. Nuno has a solid record of contributions.
>
> Kind regards,
> Ben.
>
> On 01/11/16 07:11, Andrea Aime wrote:
> > Hi all,
> > I would like to propose Nuno Oliveira for committer status.
> >
> > Nuno has been performing a number of good pull requests against GeoTools
> > and shows good understanding of the dynamics of the community.
> >
> > Cheers
> > Andrea
> >
> >
> >
> >
> --
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> >
> >
> >
> > ___
> > 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
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> 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
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> Ian Turton
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Upgrading xerial-jdbc driver version in geopackage and mbtiles

[Justin Deoliveira]

No suggestion unfortunately.

That spatialite custom build of xerial was a pain to build, and probably
not worth the effort. The intention was to have all of the library loading,
etc… be transparent, in the same way that users of xerial don’t have to
worry about loading the sqlite library. But it required forking the build
chain of the xerial driver, and those changes are probably long past
compatible with the current upstream version. That said I think newer
versions (4+) of spatialite allow for a more dynamic library loading so I
think it is possible to do this without really changing anything upstream.
But I haven’t really investigated that.

For the geopackage and mbtiles drivers we explicitly wanted to avoid this
kind of mess, which we were allowed to do since spatialite was not a
requirement.

As for the conflict between the two… yes that is an issue and I don’t have
any solution there besides changing the spatialite module to use the base
xerial driver and load the spatialite libraries dynamically at runtime.

Not sure if that helps.

-Justin

On Wed, Oct 19, 2016 at 6:48 AM Andrea Aime 
wrote:

> Hi,
> working on the geopackage module I've found a test failing due to a bug in
> the
> xerial driver itself:
>
>
> https://bitbucket.org/xerial/sqlite-jdbc/issues/134/metadatagetindexinfo-throws-exception
>
> The latest version of the driver has this issue fixed, so I wanted to
> propose an upgrade
> from 3.8.6, the currently used version, to 3.14.2.1, the latest version.
>
> I see that mbtiles also uses the same driver, and upgrading it causes no
> issues.
>
> I was worried about the spatialite, but I see it's already using a
> different version (a customized
> 3.7.something) so I guess changing the version of the other two modules is
> hopefully
> not going to cause "new" troubles, in the end, if the two modules are put
> togther in the
> same classpath there is no saying which libsqlitejdbc.so/dll will be
> picked up...
>
> Justin, the spatialite module lists you as the maintainer, any suggestion?
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be 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.
>
> ---
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Fwd: Can/should we activate the github squash commits on merge option?

[Justin Deoliveira]

Hey guys, yup, definitely addressed, I wasn’t sure from the original post
if this was an “always squash” but it’s clearly not. +1 for me.

On Tue, Aug 30, 2016 at 1:46 AM Andrea Aime 
wrote:

> I see no more feedback,
> Justin, were your concerns addressed?
> Anyone else?
>
> Cheers
> Andrea
>
>
> On Sun, Aug 28, 2016 at 8:41 AM, Brad Hards  wrote:
>
>> > Oooh... does that mean we also get rid of the blasted merge commit and
>> > retain
>> > a more linear history? :-)
>> Indeed it does.
>>
>> https://github.com/codice/imaging-nitf/commits/master shows a couple of
>> recent
>> samples.
>>
>> I note that it modifies the commit message "headline" to include a ref to
>> the
>> pull request, so you can still see where it came from.
>>
>> Brad
>>
>>
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
> --
> ___
> 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] Can/should we activate the github squash commits on merge option?

[Justin Deoliveira]

I would be slightly hesitant because it would mean you couldn’t have a pull
request with multiple commits even when it makes sense? Maybe that is an ok
thing to always have a single commit for a pull requests but I know I often
like to break up commits in a change when it makes logical sense. For
instance, when adding some new api and also adding a new implementation of
it I would tend to have one commit for the api change, and then another for
the implementation of it in whatever module.

Just some food for thought. I have no strong opinion.

On Sat, Aug 27, 2016 at 11:14 AM Andrea Aime 
wrote:

> I'd certainly be +1 on that, it would have avoided me quite some
> manual squashing when merging pull requests
>
> Cheers
> Andrea
>
>
> On Sat, Aug 27, 2016 at 6:01 PM, Ian Turton  wrote:
>
>> Following this post https://github.com/blog/2141-squash-your-commits we
>> can set GitHub to offer the option of squashing merges on acceptance.
>>
>> It would save me fighting git every time I need to squash commits.
>>
>> Ian
>>
>> --
>> Ian Turton
>>
>>
>> --
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> 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.
>
> ---
>
> --
> ___
> 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:

[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 <jody.garn...@gmail.com> 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 <jody.garn...@gmail.com> 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
>> <https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy>
>> .
>> --
>> 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]

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 <ijtur...@gmail.com> wrote:

> +1
>
> Ian
> On 31 May 2016 23:57, "Jody Garnett" <jody.garn...@gmail.com> 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
>> <https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy>
>> .
>> --
>> 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

[Justin Deoliveira]

+1.

On Tue, May 31, 2016 at 3:50 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> So far we have:
>
>- Andrea Aime
>- Ben Caradoc-Davies +1
>- Christian Mueller
>- Ian Turton
>    - Jody Garnett +1
>- Justin Deoliveira
>- Simone Giannecchini
>
>
>
> --
> Jody Garnett
>
> On 31 May 2016 at 12:56, Ben Caradoc-Davies <b...@transient.nz> 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 <b...@transient.nz>
>> Director
>> Transient Software Limited <http://transient.nz/>
>> 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
>
--
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] Copyright header policy

[Justin Deoliveira]

While my personal preference is the same as yours Ben (going with no date
in the header) I think this is the best middle ground. And anything that
moves us away from the constant burden on committers and contributors to
update the headers when it has no tangible benefit is a win.

So what is still unclear to me is what changes (if any) will be required if
any to the existing headers. Someone correct me if I am wrong but if we’re
going with just file creation date then we should be good? And the only
remaining work will be to document the practice?

On Fri, May 20, 2016 at 7:06 PM Ben Caradoc-Davies  wrote:

> Jody,
>
> I am happy to proceed with file creation/contribution date despite my
> small reservations. I think that file creation/contribution date is the
> option that has consensus at this time; it will solve the date
> maintenance overhead problem that is the reason for this change.
>
> I move that you ask OSGeo to obtain legal advice on this matter. I see
> this as a low priority but I think it would be nice to get some advice
> for long-term guidance.
>
> And thanks to everyone for their contributions to this thread. It has
> clarified my views on copyright headers and and changed my views on
> @author tags.
>
> Kind regards,
> Ben.
>
> On 21/05/16 12:06, Jody Garnett wrote:
> > OSGeo is able to obtain legal advice, as PMC representative I can make
> that
> > request on behalf of our project. As one of the early projects in OSGeo
> > other projects will be following our lead.
> >
> > To close this one out I would be content to update our policy to be file
> > creation/contribution date - and if you wish to make the motion Ben we
> can
> > formally ask OSGeo to obtain legal advice (they may do so directly or via
> > reaching out to another foundation with legal staff).
> > --
> > Jody Garnett
> >
> > On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
> >
> >> Many stackexchange comments on common law copyright and registration
> >> relate to the US prior its accession to the Berne convention (1989).
> Please
> >> see later comments and this:
> >> https://www.law.cornell.edu/wex/copyright
> >>
> >> Furthermore, and I am not a lawyer, can you copyright an individual
> source
> >> code file? Is it not like the page of a book?
> >>
> >> As this is an OSGeo project, and OSGeo is incorporated in the United
> >> States, we should give consideration to US law.
> >>
> >> Jody, does OSGeo have a policy on whether dates are required in
> copyright
> >> headers? Does copyright reside in a single source code file or GeoTools
> as
> >> a work as a whole? Is OSGeo able to obtain legal advice these matters?
> >>
> >> Kind regards,
> >> Ben.
> >>
> >
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

We keep on going in circles on this one.  No OSGeo doesn’t have any rules
to follow here, if they did we would be following them. If we want to
“follow OSGeo rules” the best thing we can do is look at what the other
established projects do. I looked at both MapServer and GDAL/OGR and they
appear to do the same thing that has been proposed here: they only update
dates in the copyright header when the copyright changes or a file is
created. I gauged this by looking at bunch of recent commits and the
headers in those files. If folks closer to this problem know otherwise
please share.

On Fri, May 20, 2016 at 2:50 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> Many stackexchange comments on common law copyright and registration
> relate to the US prior its accession to the Berne convention (1989).
> Please see later comments and this:
> https://www.law.cornell.edu/wex/copyright
>
> Furthermore, and I am not a lawyer, can you copyright an individual
> source code file? Is it not like the page of a book?
>
> As this is an OSGeo project, and OSGeo is incorporated in the United
> States, we should give consideration to US law.
>
> Jody, does OSGeo have a policy on whether dates are required in
> copyright headers? Does copyright reside in a single source code file or
> GeoTools as a work as a whole? Is OSGeo able to obtain legal advice
> these matters?
>
> Kind regards,
> Ben.
>
> On 21/05/16 04:42, Jonathan Moules wrote:
> > I can see the appeal of having "2011-present" or similar, but I'm not
> sure it is valid.
> > I believe the point of the date is to establish when a version was
> published for copyright law purposes. This means if a file isn't touched
> for several years, it will have an invalid publication date ("present")
> from the perspective of copyright law.
> > This had a few useful insights:
> >
> http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated
> >
> > Being that the copyright on even the oldest part of GeoServer's code is
> probably not going to expire until everyone who reads this has snuffed it
> (unless there are some *very* young GeoTools developers!), I think the
> Google ethos is simplest:
> > "Google doesn't update their copyright dates because they don't care
> whether some page they started in 1999 and updated this year falls into the
> public domain in 2094 or 2109."
> > Cheers,
> > Jonathan
> >
> >  On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira &
> lt;jdeol...@gmail.com wrote 
> >
> > Thanks Ben. I am going to go ahead with this and update the proposal.
> Thanks for the input everyone.
> >
> > On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz
> wrote:
> >
> > A fixed date might imply that this was the last time the file changed.
> >   Could we write this to start with the file creation year but make it an
> >   open date range?
> >
> >   (C) 2011-, Open Source Geospatial Foundation (OSGeo)
> >
> >   or
> >
> >   (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
> >
> >   as the en-dash (open number range) might otherwise be incorrectly
> parsed
> >   as an em-dash (a pause in text).
> >
> >   If the project ever undergoes another copyright ownership change, we
> can
> >   locate all these "-present," elements and rewrite them to the date that
> >   the change occurs, and add a new open-ended copyright line for the new
> >   owner.
> >
> >   Kind regards,
> >   Ben.
> >
> >   On 20/05/16 07:36, Torben Barsballe wrote:
> >Copyright header with file creation date sounds like a good idea,
> although
> >a would assume we would still want aspects of option B here -
> specifically,
> >if there is ever a copyright transfer event, all the headers
> would need
> >updating. I assume we would do something similar to the following:
> >   
> >/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >  * (c) 2001 - 2013 OpenPlans
> >  */
> >   
> >Where 2001 is the file creation date, and 2014 is the copyright
> transfer
> >date (Example taken from GeoServer).
> >   
> >Torben
> >   
> >On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira &
> lt;jdeol...@gmail.com
> >wrote:
> >   
> >To be clear option C is not to drop the copyright header all
> together,
> >just the date that lives in the header.
> >   
> >I am for any option that doesn’t require us to continuously
> change the
> >header for every commit. So I am +1 wit

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Ben. I am going to go ahead with this and update the proposal.
Thanks for the input everyone.

On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> A fixed date might imply that this was the last time the file changed.
> Could we write this to start with the file creation year but make it an
> open date range?
>
> (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>
> or
>
> (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>
> as the en-dash (open number range) might otherwise be incorrectly parsed
> as an em-dash (a pause in text).
>
> If the project ever undergoes another copyright ownership change, we can
> locate all these "-present," elements and rewrite them to the date that
> the change occurs, and add a new open-ended copyright line for the new
> owner.
>
> Kind regards,
> Ben.
>
> On 20/05/16 07:36, Torben Barsballe wrote:
> > Copyright header with file creation date sounds like a good idea,
> although
> > a would assume we would still want aspects of option B here -
> specifically,
> > if there is ever a copyright transfer event, all the headers would need
> > updating. I assume we would do something similar to the following:
> >
> > /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >   * (c) 2001 - 2013 OpenPlans
> >   */
> >
> > Where 2001 is the file creation date, and 2014 is the copyright transfer
> > date (Example taken from GeoServer).
> >
> > Torben
> >
> > On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira <jdeol...@gmail.com>
> > wrote:
> >
> >> To be clear option C is not to drop the copyright header all together,
> >> just the date that lives in the header.
> >>
> >> I am for any option that doesn’t require us to continuously change the
> >> header for every commit. So I am +1 with a copyright header that
> contains
> >> the file creation date.
> >>
> >> On Thu, May 19, 2016 at 11:42 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >> wrote:
> >>
> >>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett <jody.garn...@gmail.com>
> >>> wrote:
> >>>
> >>>> Putting those two tensions together can I recommend a compromise -
> >>>>
> >>>> "Copyright header using file creation date"
> >>>>
> >>>> This compromise provides copyright header and does not require ongoing
> >>>> extra effort to maintain.
> >>>>
> >>>
> >>> I'd second this one too (based on my previous research about
> foundations,
> >>> and finding
> >>> none that recommends having no copyright headers)
> >>>
> >>> Cheers
> >>> Andrea
> >>>
> >>> --
> >>> ==
> >>> GeoServer Professional Services from the experts! Visit
> >>> http://goo.gl/it488V for more information.
> >>> ==
> >>>
> >>> Ing. Andrea Aime
> >>> @geowolf
> >>> Technical Lead
> >>>
> >>> GeoSolutions S.A.S.
> >>> Via di Montramito 3/A
> >>> 55054  Massarosa (LU)
> >>> phone: +39 0584 962313
> >>> fax: +39 0584 1660272
> >>> mob: +39  339 8844549
> >>>
> >>> http://www.geo-solutions.it
> >>> http://twitter.com/geosolutions_it
> >>>
> >>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
> >>>
> >>> Le informazioni contenute in questo messaggio di posta elettronica e/o
> >>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> >>> loro utilizzo è consentito esclusivamente al destinatario del
> messaggio,
> >>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> >>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> >>> darcene notizia via e-mail e di procedere alla distruzione del
> messaggio
> >>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio
> stesso,
> >>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> >>> utilizzarlo per finalità diverse, costituisce comportamento contrario
> ai
> >>> principi dettati dal D.Lgs. 196/2003.
> >>>
> >>>
> >>>
> >>> The information in this message and/or attachments, i

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

To be clear option C is not to drop the copyright header all together, just
the date that lives in the header.

I am for any option that doesn’t require us to continuously change the
header for every commit. So I am +1 with a copyright header that contains
the file creation date.

On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
wrote:

> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> wrote:
>
>> Putting those two tensions together can I recommend a compromise -
>>
>> "Copyright header using file creation date"
>>
>> This compromise provides copyright header and does not require ongoing
>> extra effort to maintain.
>>
>
> I'd second this one too (based on my previous research about foundations,
> and finding
> none that recommends having no copyright headers)
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

All the votes are in. Thanks everyone.

If D is still on the table then it looks like it is the winner… but as
previously discussed I am not sure how feasible that option is. Taking D
out of the equation C (dropping the date from the copyright header all
together) becomes the winner.

So unless someone in the (D) camp can come up with good way to achieve this
I’ll go ahead and update the proposal with a plan to implement C.

On Wed, May 18, 2016 at 5:47 PM Justin Deoliveira <jdeol...@gmail.com>
wrote:

> Thanks Ben. I am agreement about option D. So unless one of the folks who
> made it there first choice wants to put some time into proving it’s
> feasibility I suggest we remove it from the vote.
>
> I’ll also start reaching out directly to Jody and Christian to fill in
> there votes.
>
> On Tue, May 17, 2016 at 1:25 PM Ben Caradoc-Davies <b...@transient.nz>
> wrote:
>
>> I do not think option D can work with a distributed version control
>> system. I think this option is unimplementable with git. If we eliminate
>> D, then C is the winner.
>>
>> Kind regards,
>> Ben.
>>
>> On 18/05/16 07:05, Ben Caradoc-Davies wrote:
>> > Instant runoff voting give a win for D:
>> > https://en.wikipedia.org/wiki/Instant-runoff_voting
>> >
>> > Round 1: A eliminated
>> > Round 2: B eliminated
>> > Round 3: D wins with 3/5 votes
>> >
>> > Kind regards,
>> > Ben.
>> >
>> > On 18/05/16 01:21, Justin Deoliveira wrote:
>> >> Thanks for kicking this one Andrea.
>> >>
>> >> Using a simple weighted scoring where first pick gets 4 points, second
>> 3,
>> >> etc… the current votes come out to:
>> >>
>> >> A: 5
>> >> B: 12
>> >> C: 12
>> >> D: 11
>> >>
>> >> Which means a tie between methods B and C… so ideally the other PSC
>> members
>> >> could get there votes in on this one so things can move forward.
>> >>
>> >> It also looks like D is getting some traction. I am trying to think
>> about
>> >> how that option might work in practice… I understand git post commit
>> hooks
>> >> but I don’t think I’ve ever seen them used to actually modify the
>> contents
>> >> of a file being committed. Questions I have are:
>> >>
>> >> - Is this even possible? And if git does allow it does github support
>> it?
>> >> - Since change you are committing isn’t the actual diff that results
>> in the
>> >> main repository how will this play out when it comes to merging? Since
>> the
>> >> diff you made locally won’t be the same as what gets stored on the
>> server?
>> >> - Does this mean that after every commit you have to remember to pull
>> so
>> >> you can grab the latest version of the file?
>> >>
>> >> It might be worth trying to flesh that option out a bit more if folks
>> are
>> >> going to be voting that way.
>> >>
>> >> On Mon, May 16, 2016 at 11:17 AM Andrea Aime <
>> andrea.a...@geo-solutions.it>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> thanks Ian, updated
>> >>>
>> >>> Cheers
>> >>> Andrea
>> >>>
>> >>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton <ijtur...@gmail.com>
>> wrote:
>> >>>
>> >>>> Github won't let my phone login so I vote. D, c, b, a.
>> >>>>
>> >>>> Ian
>> >>>>
>> >>> On 16 May 2016 17:24, "Andrea Aime" <andrea.a...@geo-solutions.it>
>> wrote:
>> >>>>
>> >>> Hi,
>> >>>>> looked at the proposal, seems it got stuck?
>> >>>>> Could the other PSC members provide a preference list too?
>> >>>>>
>> >>>>>
>> >>>>>
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>> >>>>>
>> >>>>> Cheers
>> >>>>> Andrea
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
>> >>>>> andrea.a...@geo-solutions.it> wrote:
>> >>>>>
>> >>>>>> Hi Justin,
>> >>>>>> I made a bit of research as this is one topic that foundations
>> probably
>> >>>>>> have guidan

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Ben. I am agreement about option D. So unless one of the folks who
made it there first choice wants to put some time into proving it’s
feasibility I suggest we remove it from the vote.

I’ll also start reaching out directly to Jody and Christian to fill in
there votes.

On Tue, May 17, 2016 at 1:25 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> I do not think option D can work with a distributed version control
> system. I think this option is unimplementable with git. If we eliminate
> D, then C is the winner.
>
> Kind regards,
> Ben.
>
> On 18/05/16 07:05, Ben Caradoc-Davies wrote:
> > Instant runoff voting give a win for D:
> > https://en.wikipedia.org/wiki/Instant-runoff_voting
> >
> > Round 1: A eliminated
> > Round 2: B eliminated
> > Round 3: D wins with 3/5 votes
> >
> > Kind regards,
> > Ben.
> >
> > On 18/05/16 01:21, Justin Deoliveira wrote:
> >> Thanks for kicking this one Andrea.
> >>
> >> Using a simple weighted scoring where first pick gets 4 points, second
> 3,
> >> etc… the current votes come out to:
> >>
> >> A: 5
> >> B: 12
> >> C: 12
> >> D: 11
> >>
> >> Which means a tie between methods B and C… so ideally the other PSC
> members
> >> could get there votes in on this one so things can move forward.
> >>
> >> It also looks like D is getting some traction. I am trying to think
> about
> >> how that option might work in practice… I understand git post commit
> hooks
> >> but I don’t think I’ve ever seen them used to actually modify the
> contents
> >> of a file being committed. Questions I have are:
> >>
> >> - Is this even possible? And if git does allow it does github support
> it?
> >> - Since change you are committing isn’t the actual diff that results in
> the
> >> main repository how will this play out when it comes to merging? Since
> the
> >> diff you made locally won’t be the same as what gets stored on the
> server?
> >> - Does this mean that after every commit you have to remember to pull so
> >> you can grab the latest version of the file?
> >>
> >> It might be worth trying to flesh that option out a bit more if folks
> are
> >> going to be voting that way.
> >>
> >> On Mon, May 16, 2016 at 11:17 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >> wrote:
> >>
> >>> Hi,
> >>> thanks Ian, updated
> >>>
> >>> Cheers
> >>> Andrea
> >>>
> >>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton <ijtur...@gmail.com>
> wrote:
> >>>
> >>>> Github won't let my phone login so I vote. D, c, b, a.
> >>>>
> >>>> Ian
> >>>>
> >>> On 16 May 2016 17:24, "Andrea Aime" <andrea.a...@geo-solutions.it>
> wrote:
> >>>>
> >>> Hi,
> >>>>> looked at the proposal, seems it got stuck?
> >>>>> Could the other PSC members provide a preference list too?
> >>>>>
> >>>>>
> >>>>>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
> >>>>>
> >>>>> Cheers
> >>>>> Andrea
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
> >>>>> andrea.a...@geo-solutions.it> wrote:
> >>>>>
> >>>>>> Hi Justin,
> >>>>>> I made a bit of research as this is one topic that foundations
> probably
> >>>>>> have guidance on.
> >>>>>> Found these for the moment:
> >>>>>> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
> >>>>>>
> >>>>>>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
> >>>>>> http://www.apache.org/legal/src-headers.html
> >>>>>>
> >>>>>> The official guidance for these foundations seem to suggest at least
> >>>>>> one year should show up in the headers.
> >>>>>> I found little evidence that our current approach has benefits,
> >>>>>> although some practices seem to imply
> >>>>>> a mass header change per (major) release... which does not make all
> >>>>>> that much sense to me, but
> >>>>>> would at least be easy t

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks for kicking this one Andrea.

Using a simple weighted scoring where first pick gets 4 points, second 3,
etc… the current votes come out to:

A: 5
B: 12
C: 12
D: 11

Which means a tie between methods B and C… so ideally the other PSC members
could get there votes in on this one so things can move forward.

It also looks like D is getting some traction. I am trying to think about
how that option might work in practice… I understand git post commit hooks
but I don’t think I’ve ever seen them used to actually modify the contents
of a file being committed. Questions I have are:

- Is this even possible? And if git does allow it does github support it?
- Since change you are committing isn’t the actual diff that results in the
main repository how will this play out when it comes to merging? Since the
diff you made locally won’t be the same as what gets stored on the server?
- Does this mean that after every commit you have to remember to pull so
you can grab the latest version of the file?

It might be worth trying to flesh that option out a bit more if folks are
going to be voting that way.

On Mon, May 16, 2016 at 11:17 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi,
> thanks Ian, updated
>
> Cheers
> Andrea
>
> On Mon, May 16, 2016 at 7:08 PM, Ian Turton <ijtur...@gmail.com> wrote:
>
>> Github won't let my phone login so I vote. D, c, b, a.
>>
>> Ian
>>
> On 16 May 2016 17:24, "Andrea Aime" <andrea.a...@geo-solutions.it> wrote:
>>
> Hi,
>>> looked at the proposal, seems it got stuck?
>>> Could the other PSC members provide a preference list too?
>>>
>>>
>>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
>>>> Hi Justin,
>>>> I made a bit of research as this is one topic that foundations probably
>>>> have guidance on.
>>>> Found these for the moment:
>>>> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>>>>
>>>> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
>>>> http://www.apache.org/legal/src-headers.html
>>>>
>>>> The official guidance for these foundations seem to suggest at least
>>>> one year should show up in the headers.
>>>> I found little evidence that our current approach has benefits,
>>>> although some practices seem to imply
>>>> a mass header change per (major) release... which does not make all
>>>> that much sense to me, but
>>>> would at least be easy to automate :-p
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>>
>>>>
>>>> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira <jdeol...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for the input everyone. I put together a proposal with all of
>>>>> the options put forth on this thread. Apologies if I missed one, if I did
>>>>> just let me know.
>>>>>
>>>>>
>>>>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>>>>
>>>>> Like I said before this proposal involves listing out in order of
>>>>> preference the various options. Feel free to update the proposal or just
>>>>> reply to this thread and I’ll happily make the update on your behalf.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Justin
>>>>>
>>>>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett <jody.garn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> You asked where I was uncomfortable, not if it made sense :)
>>>>>>
>>>>>> --
>>>>>> Jody Garnett
>>>>>>
>>>>>> On 25 April 2016 at 09:37, Justin Deoliveira <jdeol...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I can see how the original date could be useful for cases like this
>>>>>>> but have you ever seen a situation where something was marked (for 
>>>>>>> example)
>>>>>>> (c) 2010 and from 2010 to the current date of when you were doing the 
>>>>>>> audit
>>>>>>> the copyright changed in some meaningful way? I am of course not 
>>>>>>> counting
>

Re: [Geotools-devel] Avoiding to scan postgreqsql type system in JDBCDataStore

[Justin Deoliveira]

Sounds like a good approach to me.
On Mon, May 16, 2016 at 11:37 AM Andrea Aime 
wrote:

> Hi,
> today I stumbled into a really weird issue, basically JDBCDataStore becomes
> extremely slow (minutes if the db is not co-located) if a database has
> tens of
> thousands of tables in it.
>
> The short version of it, is that to create a table we need to get from the
> java
> classes to the sql type names, using a mapping process that goes from
> "java class" to "jdbc type id" to "native sql type", and the second jump we
> do by first getting the full list of type ids and type names from the
> database
> (nice generic approach).
>
> However in postgresql even the tables we create are types, and for those,
> the jdbc driver has to make a special query for each table. So if you have
> 23k tables, the driver makes 1 + 23k queries, taking forever to return the
> list of id -> type mappings.
>
> More details can be found here:
> https://osgeo-org.atlassian.net/browse/GEOS-7533
>
> I checked if the driver had any knob or tunable to avoid scanning the
> tables, but it seems
> there are none (by code inspection).
>
> The solution I'd like to propose is to register in the postgis driver
> mappings for
> the most known types already, and do not hit JDBCMedata.getTypeInfo()
> unless
> we actually need to do that, that is, only if we end up with a type
> mapping that
> we cannot resolve using the short list (that is, a solution similar to
> what the jruby
> activerecord people applied, the ticket above contains a link).
>
> This would keep the solution for a postgresql specific issue in the postgis
> module.
>
> If you have objections could you please let me know? I'll proceed with
> the above approach otherwise
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks for the input everyone. I put together a proposal with all of the
options put forth on this thread. Apologies if I missed one, if I did just
let me know.


https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

Like I said before this proposal involves listing out in order of
preference the various options. Feel free to update the proposal or just
reply to this thread and I’ll happily make the update on your behalf.

Thanks!

-Justin

On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> You asked where I was uncomfortable, not if it made sense :)
>
> --
> Jody Garnett
>
> On 25 April 2016 at 09:37, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> I can see how the original date could be useful for cases like this but
>> have you ever seen a situation where something was marked (for example) (c)
>> 2010 and from 2010 to the current date of when you were doing the audit the
>> copyright changed in some meaningful way? I am of course not counting any
>> transfer of copyright to OSGeo, etc… since I would expect that to result in
>> a new copyright timestamp.
>>
>> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> The part that is making me uneasy is the few times I have done code
>>> audits on this codebase the headers were very useful. While I did have to
>>> duck out to git history on a few occasions it was a rare occurrence - in
>>> part because the team here has done a good job.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 24 April 2016 at 08:13, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> What is it specifically that is making you uneasy? I thought Ben made a
>>>> pretty strong argument that any dates in the copyright don’t really mean
>>>> anything when it comes to actual legal stuff.
>>>>
>>>> Doing it periodically via a script does seem like a better compromise…
>>>> although from everything I have heard here I still don’t see why initial
>>>> creation date isn’t enough.
>>>>
>>>> Once this thread “quiets down” I’ll summarize all of the options that
>>>> folks have put forth and throw them into the proposal and we can vote for
>>>> the options we like best. Since there are a handful of options on the table
>>>> I think perhaps having people rank options 1,2,3 might work best.
>>>>
>>>>
>>>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett <jody.garn...@gmail.com>
>>>> wrote:
>>>>
>>>>> Yeah the longer I think about this one the more I am made
>>>>> uncomfortable.  We would be back to "significant" changes needing the
>>>>> header updated -
>>>>>
>>>>> As an alternative wow do you feel about updating the headers once each
>>>>> year (via a script) so that individual pull requests are not held up?
>>>>>
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> On 22 April 2016 at 12:05, Justin Deoliveira <jdeol...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Cool. I'll write up a quick one.
>>>>>>
>>>>>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett <jody.garn...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> If you would like to make that proposal we can update the developers
>>>>>>> guide and get it done ...
>>>>>>>
>>>>>>> --
>>>>>>> Jody Garnett
>>>>>>>
>>>>>>> On 22 April 2016 at 11:38, Justin Deoliveira <jdeol...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks Jody. That helps me understand.
>>>>>>>>
>>>>>>>> My thought is that the day to day overhead is not worth being able
>>>>>>>> to rest assured that in 75 years GeoTools will still be in good 
>>>>>>>> standing
>>>>>>>> with regard to copyright ;)
>>>>>>>>
>>>>>>>> My vote would be to change to a process where the copyright is set
>>>>>>>> to the current year that the file is created or undergoes a major
>>>>>>>> overhaul/rewrite. I
>>>>>>>>
>>>>>>>> $0.02
>>>>>>>>
>

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

I can see how the original date could be useful for cases like this but
have you ever seen a situation where something was marked (for example) (c)
2010 and from 2010 to the current date of when you were doing the audit the
copyright changed in some meaningful way? I am of course not counting any
transfer of copyright to OSGeo, etc… since I would expect that to result in
a new copyright timestamp.

On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <jody.garn...@gmail.com>
wrote:

> The part that is making me uneasy is the few times I have done code audits
> on this codebase the headers were very useful. While I did have to duck out
> to git history on a few occasions it was a rare occurrence - in part
> because the team here has done a good job.
>
> --
> Jody Garnett
>
> On 24 April 2016 at 08:13, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> What is it specifically that is making you uneasy? I thought Ben made a
>> pretty strong argument that any dates in the copyright don’t really mean
>> anything when it comes to actual legal stuff.
>>
>> Doing it periodically via a script does seem like a better compromise…
>> although from everything I have heard here I still don’t see why initial
>> creation date isn’t enough.
>>
>> Once this thread “quiets down” I’ll summarize all of the options that
>> folks have put forth and throw them into the proposal and we can vote for
>> the options we like best. Since there are a handful of options on the table
>> I think perhaps having people rank options 1,2,3 might work best.
>>
>>
>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Yeah the longer I think about this one the more I am made
>>> uncomfortable.  We would be back to "significant" changes needing the
>>> header updated -
>>>
>>> As an alternative wow do you feel about updating the headers once each
>>> year (via a script) so that individual pull requests are not held up?
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 12:05, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> Cool. I'll write up a quick one.
>>>>
>>>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett <jody.garn...@gmail.com>
>>>> wrote:
>>>>
>>>>> If you would like to make that proposal we can update the developers
>>>>> guide and get it done ...
>>>>>
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> On 22 April 2016 at 11:38, Justin Deoliveira <jdeol...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks Jody. That helps me understand.
>>>>>>
>>>>>> My thought is that the day to day overhead is not worth being able to
>>>>>> rest assured that in 75 years GeoTools will still be in good standing 
>>>>>> with
>>>>>> regard to copyright ;)
>>>>>>
>>>>>> My vote would be to change to a process where the copyright is set to
>>>>>> the current year that the file is created or undergoes a major
>>>>>> overhaul/rewrite. I
>>>>>>
>>>>>> $0.02
>>>>>>
>>>>>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>>
>>>>>>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
>>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>>
>>>>>>>> If the PMC wants to make this decision I would be -0, I understand
>>>>>>>> that it would assist with github pull requests, but I feel we would do 
>>>>>>>> so
>>>>>>>> by cutting a corner.
>>>>>>>>
>>>>>>>
>>>>>>> I don't feel strongly either way, copyright updates can be automated
>>>>>>> (see Kevin's GeoServer script), but yeah, it's really annoying to 
>>>>>>> require
>>>>>>> every single time a pull request comes in to update the copyright
>>>>>>> headers...
>>>>>>>
>>>>>>> Cheers
>>>>>>> Andrea
>>>>>>>
>>>>>>> --
>>>>>>> ==
>>>>>>> GeoServer Professional Services from the experts! Visit
>>>>>&g

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

What is it specifically that is making you uneasy? I thought Ben made a
pretty strong argument that any dates in the copyright don’t really mean
anything when it comes to actual legal stuff.

Doing it periodically via a script does seem like a better compromise…
although from everything I have heard here I still don’t see why initial
creation date isn’t enough.

Once this thread “quiets down” I’ll summarize all of the options that folks
have put forth and throw them into the proposal and we can vote for the
options we like best. Since there are a handful of options on the table I
think perhaps having people rank options 1,2,3 might work best.

On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> Yeah the longer I think about this one the more I am made uncomfortable.
> We would be back to "significant" changes needing the header updated -
>
> As an alternative wow do you feel about updating the headers once each
> year (via a script) so that individual pull requests are not held up?
>
> --
> Jody Garnett
>
> On 22 April 2016 at 12:05, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Cool. I'll write up a quick one.
>>
>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> If you would like to make that proposal we can update the developers
>>> guide and get it done ...
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 11:38, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> Thanks Jody. That helps me understand.
>>>>
>>>> My thought is that the day to day overhead is not worth being able to
>>>> rest assured that in 75 years GeoTools will still be in good standing with
>>>> regard to copyright ;)
>>>>
>>>> My vote would be to change to a process where the copyright is set to
>>>> the current year that the file is created or undergoes a major
>>>> overhaul/rewrite. I
>>>>
>>>> $0.02
>>>>
>>>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>>>> andrea.a...@geo-solutions.it> wrote:
>>>>
>>>>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <jody.garn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> If the PMC wants to make this decision I would be -0, I understand
>>>>>> that it would assist with github pull requests, but I feel we would do so
>>>>>> by cutting a corner.
>>>>>>
>>>>>
>>>>> I don't feel strongly either way, copyright updates can be automated
>>>>> (see Kevin's GeoServer script), but yeah, it's really annoying to require
>>>>> every single time a pull request comes in to update the copyright
>>>>> headers...
>>>>>
>>>>> Cheers
>>>>> Andrea
>>>>>
>>>>> --
>>>>> ==
>>>>> GeoServer Professional Services from the experts! Visit
>>>>> http://goo.gl/it488V for more information.
>>>>> ==
>>>>>
>>>>> Ing. Andrea Aime
>>>>> @geowolf
>>>>> Technical Lead
>>>>>
>>>>> GeoSolutions S.A.S.
>>>>> Via di Montramito 3/A
>>>>> 55054  Massarosa (LU)
>>>>> phone: +39 0584 962313
>>>>> fax: +39 0584 1660272
>>>>> mob: +39  339 8844549
>>>>>
>>>>> http://www.geo-solutions.it
>>>>> http://twitter.com/geosolutions_it
>>>>>
>>>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>>>
>>>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>>>> principi dettati dal D.Lgs. 196

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Cool. I'll write up a quick one.
On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> If you would like to make that proposal we can update the developers guide
> and get it done ...
>
> --
> Jody Garnett
>
> On 22 April 2016 at 11:38, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Thanks Jody. That helps me understand.
>>
>> My thought is that the day to day overhead is not worth being able to
>> rest assured that in 75 years GeoTools will still be in good standing with
>> regard to copyright ;)
>>
>> My vote would be to change to a process where the copyright is set to the
>> current year that the file is created or undergoes a major
>> overhaul/rewrite. I
>>
>> $0.02
>>
>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> If the PMC wants to make this decision I would be -0, I understand that
>>>> it would assist with github pull requests, but I feel we would do so by
>>>> cutting a corner.
>>>>
>>>
>>> I don't feel strongly either way, copyright updates can be automated
>>> (see Kevin's GeoServer script), but yeah, it's really annoying to require
>>> every single time a pull request comes in to update the copyright
>>> headers...
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility  for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>> ---
>>>
>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Jody. That helps me understand.

My thought is that the day to day overhead is not worth being able to rest
assured that in 75 years GeoTools will still be in good standing with
regard to copyright ;)

My vote would be to change to a process where the copyright is set to the
current year that the file is created or undergoes a major
overhaul/rewrite. I

$0.02

On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime 
wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
> wrote:
>
>> If the PMC wants to make this decision I would be -0, I understand that
>> it would assist with github pull requests, but I feel we would do so by
>> cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be automated (see
> Kevin's GeoServer script), but yeah, it's really annoying to require
> every single time a pull request comes in to update the copyright
> headers...
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Copyright header policy

[Justin Deoliveira]

Hi folks,

Something I’ve been meaning to ask about is a clarification of why we have
to update copyright header dates to the current year for every file change.
As opposed to just having a static copyright header that signifies a
“copyright event” (like the change over to osgeo) and then stands for that
time forward.

The reason I ask is because I think this policy has some negative things in
my opinion. For one it’s a pain for both contributors and reviewers to
enforce. I myself never remember as you probably well know and I would say
I am a pretty regular contributor. It also adds noise to patches and pull
requests, which also makes things harder to review than necessary.


Anyways, just curious as to the rationale behind this decision. My
apologies if this has been covered in previous email.

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

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Great! Thanks for letting me know Ben. Glad it’s fixed!

On Tue, Apr 19, 2016 at 3:41 PM Ben Caradoc-Davies <b...@transient.nz> wrote:

> The online build passed on ares and locally for me against postgis.
> Thanks, Justin!
>
> Kind regards,
> Ben.
>
> On 20/04/16 06:58, Ben Caradoc-Davies wrote:
> > Thanks, Justin, I have kicked to online build to confirm.
> >
> > Kind regards,
> > Ben.
> >
> > On 20/04/16 06:35, Justin Deoliveira wrote:
> >> Should be fixed now
> >> <
> https://github.com/geotools/geotools/commit/ee7d0b749bc6873ec599d50ee938a80f6eb94500
> >
> >> .
> >> On Tue, Apr 19, 2016 at 12:10 PM Justin Deoliveira <jdeol...@gmail.com>
> >> wrote:
> >>
> >>> I’ll take a look.
> >>>
> >>> On Tue, Apr 19, 2016 at 10:57 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >>> wrote:
> >>>
> >>>> Hi guys,
> >>>> it seems this change broke the postgis online tests build?
> >>>>
> >>>>
> >>>>
> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/470/
> >>>>
> >>>>
> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/471/
> >>>>
> >>>> Cheers
> >>>> Andrea
> >>>>
> >>>>
> >>>> On Sat, Apr 16, 2016 at 5:58 AM, Jody Garnett <jody.garn...@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> Thanks Justin, I am happy to fix up a few headers and merge - I like
> how
> >>>>> the date conversion was handled int the filter visitor.
> >>>>>
> >>>>> If I include this in the beta2 can I ask a few of the people tagged
> in
> >>>>> on this thread to help out with the testing :)
> >>>>>
> >>>>> --
> >>>>> Jody Garnett
> >>>>>
> >>>>> On 15 April 2016 at 15:34, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
> >>>>>
> >>>>>> Ok, here is my cut at this one:
> >>>>>>
> >>>>>> https://github.com/geotools/geotools/pull/1173
> >>>>>>
> >>>>>> It leans on the recent conversion from Date to Long added to
> >>>>>> TemporalConverterFactory, and also adds the reverse conversion from
> Long to
> >>>>>> Date.
> >>>>>>
> >>>>>> The test case exercises reading the date values, as well as writing
> >>>>>> them back, along with filtering.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira <
> jdeol...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <
> >>>>>>> andrea.a...@geo-solutions.it> wrote:
> >>>>>>>
> >>>>>>>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <
> >>>>>>>> jdeol...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hey guys. So as I started on this I quickly came to the
> realization
> >>>>>>>>> (which I apologize for not seeing the obvious before) but
> interpreting
> >>>>>>>>> values as seconds won’t really buy us anything if we’re bound by
> the value
> >>>>>>>>> space of long that’s used for java.util.Date.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Re-implementing a new date type based on seconds rather than
> >>>>>>>>> milliseconds is far from a trivial effort as I am sure folks are
> aware so I
> >>>>>>>>> think the best I’ll be able to do is clean up the original
> patch, which
> >>>>>>>>> will still be limited to the +- 290 million year range.
> Apologies for the
> >>>>>>>>> false hope :)
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yep indeed. Also consider that we recently got in a converter
> going
> >>>>>>>> from long -> Date, that might help simplify the original patch.
> >>>>>>&g

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Should be fixed now
<https://github.com/geotools/geotools/commit/ee7d0b749bc6873ec599d50ee938a80f6eb94500>
.
On Tue, Apr 19, 2016 at 12:10 PM Justin Deoliveira <jdeol...@gmail.com>
wrote:

> I’ll take a look.
>
> On Tue, Apr 19, 2016 at 10:57 AM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
>> Hi guys,
>> it seems this change broke the postgis online tests build?
>>
>>
>> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/470/
>>
>> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/471/
>>
>> Cheers
>> Andrea
>>
>>
>> On Sat, Apr 16, 2016 at 5:58 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Thanks Justin, I am happy to fix up a few headers and merge - I like how
>>> the date conversion was handled int the filter visitor.
>>>
>>> If I include this in the beta2 can I ask a few of the people tagged in
>>> on this thread to help out with the testing :)
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 15 April 2016 at 15:34, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>>
>>>> Ok, here is my cut at this one:
>>>>
>>>>   https://github.com/geotools/geotools/pull/1173
>>>>
>>>> It leans on the recent conversion from Date to Long added to
>>>> TemporalConverterFactory, and also adds the reverse conversion from Long to
>>>> Date.
>>>>
>>>> The test case exercises reading the date values, as well as writing
>>>> them back, along with filtering.
>>>>
>>>>
>>>>
>>>> On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira <jdeol...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <
>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>
>>>>>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <
>>>>>> jdeol...@gmail.com> wrote:
>>>>>>
>>>>>>> Hey guys. So as I started on this I quickly came to the realization
>>>>>>> (which I apologize for not seeing the obvious before) but interpreting
>>>>>>> values as seconds won’t really buy us anything if we’re bound by the 
>>>>>>> value
>>>>>>> space of long that’s used for java.util.Date.
>>>>>>>
>>>>>>>
>>>>>> Re-implementing a new date type based on seconds rather than
>>>>>>> milliseconds is far from a trivial effort as I am sure folks are aware 
>>>>>>> so I
>>>>>>> think the best I’ll be able to do is clean up the original patch, which
>>>>>>> will still be limited to the +- 290 million year range. Apologies for 
>>>>>>> the
>>>>>>> false hope :)
>>>>>>>
>>>>>>
>>>>>> Yep indeed. Also consider that we recently got in a converter going
>>>>>> from long -> Date, that might help simplify the original patch.
>>>>>>
>>>>>
>>>>> Potentially, although the conversion is this case is pretty simple…
>>>>> it’s just taking the long value as is and putting that into the date
>>>>> constructor. But if it’s already there in the converter might as well use
>>>>> it.
>>>>>
>>>>>
>>>>>> At risk of being obvious, do you really need a timeline that goes
>>>>>> back eons, and still allows seconds accuracy? Or even a day accuracy?
>>>>>> Normally when going that far back even a year is (insanely) high
>>>>>> granularity, and well, integer numbers we already handle at ease :-p
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> But yeah, if the requisite is to allow a single unified time
>>>>>> representation good for ages ago and at the same time your
>>>>>> yesterday detailed movements list, I guess a new type of Date is
>>>>>> indeed needed. I was wondering if maybe Joda-time
>>>>>> already faced a similar challenge, but I could not find an answer
>>>>>> doing a quick internet search.
>>>>>>
>>>>> I came up short looking for a solution to this one as well.
>>>>>
>>>>>>
>>&g

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

I’ll take a look.

On Tue, Apr 19, 2016 at 10:57 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi guys,
> it seems this change broke the postgis online tests build?
>
>
> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/470/
>
> http://ares.boundlessgeo.com/jenkins/view/geotools/job/geotools-master-online/471/
>
> Cheers
> Andrea
>
>
> On Sat, Apr 16, 2016 at 5:58 AM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Thanks Justin, I am happy to fix up a few headers and merge - I like how
>> the date conversion was handled int the filter visitor.
>>
>> If I include this in the beta2 can I ask a few of the people tagged in on
>> this thread to help out with the testing :)
>>
>> --
>> Jody Garnett
>>
>> On 15 April 2016 at 15:34, Justin Deoliveira <jdeol...@gmail.com> wrote:
>>
>>> Ok, here is my cut at this one:
>>>
>>>   https://github.com/geotools/geotools/pull/1173
>>>
>>> It leans on the recent conversion from Date to Long added to
>>> TemporalConverterFactory, and also adds the reverse conversion from Long to
>>> Date.
>>>
>>> The test case exercises reading the date values, as well as writing them
>>> back, along with filtering.
>>>
>>>
>>>
>>> On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <
>>>> andrea.a...@geo-solutions.it> wrote:
>>>>
>>>>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <jdeol...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hey guys. So as I started on this I quickly came to the realization
>>>>>> (which I apologize for not seeing the obvious before) but interpreting
>>>>>> values as seconds won’t really buy us anything if we’re bound by the 
>>>>>> value
>>>>>> space of long that’s used for java.util.Date.
>>>>>>
>>>>>>
>>>>> Re-implementing a new date type based on seconds rather than
>>>>>> milliseconds is far from a trivial effort as I am sure folks are aware 
>>>>>> so I
>>>>>> think the best I’ll be able to do is clean up the original patch, which
>>>>>> will still be limited to the +- 290 million year range. Apologies for the
>>>>>> false hope :)
>>>>>>
>>>>>
>>>>> Yep indeed. Also consider that we recently got in a converter going
>>>>> from long -> Date, that might help simplify the original patch.
>>>>>
>>>>
>>>> Potentially, although the conversion is this case is pretty simple…
>>>> it’s just taking the long value as is and putting that into the date
>>>> constructor. But if it’s already there in the converter might as well use
>>>> it.
>>>>
>>>>
>>>>> At risk of being obvious, do you really need a timeline that goes back
>>>>> eons, and still allows seconds accuracy? Or even a day accuracy?
>>>>> Normally when going that far back even a year is (insanely) high
>>>>> granularity, and well, integer numbers we already handle at ease :-p
>>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> But yeah, if the requisite is to allow a single unified time
>>>>> representation good for ages ago and at the same time your
>>>>> yesterday detailed movements list, I guess a new type of Date is
>>>>> indeed needed. I was wondering if maybe Joda-time
>>>>> already faced a similar challenge, but I could not find an answer
>>>>> doing a quick internet search.
>>>>>
>>>> I came up short looking for a solution to this one as well.
>>>>
>>>>>
>>>>> One sneaky suggestion... is it that bad to just put a biginteger of
>>>>> sorts in the database, keep it that way up to the
>>>>> UI, and have the UI translate it in an appropriate way to a date?
>>>>>
>>>>
>>>> Good question…  I think having a type that can store as a long and go
>>>> to/from date is general enough… but once you start putting constraints on
>>>> the value like it represents seconds or years it’s starting to get pretty
>>>> custom, and I agree, better to just have GeoTools model it as a

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Ok, here is my cut at this one:

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

It leans on the recent conversion from Date to Long added to
TemporalConverterFactory, and also adds the reverse conversion from Long to
Date.

The test case exercises reading the date values, as well as writing them
back, along with filtering.



On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira <jdeol...@gmail.com>
wrote:

> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <jdeol...@gmail.com>
>> wrote:
>>
>>> Hey guys. So as I started on this I quickly came to the realization
>>> (which I apologize for not seeing the obvious before) but interpreting
>>> values as seconds won’t really buy us anything if we’re bound by the value
>>> space of long that’s used for java.util.Date.
>>>
>>>
>> Re-implementing a new date type based on seconds rather than milliseconds
>>> is far from a trivial effort as I am sure folks are aware so I think the
>>> best I’ll be able to do is clean up the original patch, which will still be
>>> limited to the +- 290 million year range. Apologies for the false hope :)
>>>
>>
>> Yep indeed. Also consider that we recently got in a converter going from
>> long -> Date, that might help simplify the original patch.
>>
>
> Potentially, although the conversion is this case is pretty simple… it’s
> just taking the long value as is and putting that into the date
> constructor. But if it’s already there in the converter might as well use
> it.
>
>
>> At risk of being obvious, do you really need a timeline that goes back
>> eons, and still allows seconds accuracy? Or even a day accuracy?
>> Normally when going that far back even a year is (insanely) high
>> granularity, and well, integer numbers we already handle at ease :-p
>>
>
>
>
>>
>> But yeah, if the requisite is to allow a single unified time
>> representation good for ages ago and at the same time your
>> yesterday detailed movements list, I guess a new type of Date is indeed
>> needed. I was wondering if maybe Joda-time
>> already faced a similar challenge, but I could not find an answer doing a
>> quick internet search.
>>
> I came up short looking for a solution to this one as well.
>
>>
>> One sneaky suggestion... is it that bad to just put a biginteger of sorts
>> in the database, keep it that way up to the
>> UI, and have the UI translate it in an appropriate way to a date?
>>
>
> Good question…  I think having a type that can store as a long and go
> to/from date is general enough… but once you start putting constraints on
> the value like it represents seconds or years it’s starting to get pretty
> custom, and I agree, better to just have GeoTools model it as a number
> directly and have the application deal with the interpretation of that.
>
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, a

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey guys. So as I started on this I quickly came to the realization
>> (which I apologize for not seeing the obvious before) but interpreting
>> values as seconds won’t really buy us anything if we’re bound by the value
>> space of long that’s used for java.util.Date.
>>
>>
> Re-implementing a new date type based on seconds rather than milliseconds
>> is far from a trivial effort as I am sure folks are aware so I think the
>> best I’ll be able to do is clean up the original patch, which will still be
>> limited to the +- 290 million year range. Apologies for the false hope :)
>>
>
> Yep indeed. Also consider that we recently got in a converter going from
> long -> Date, that might help simplify the original patch.
>

Potentially, although the conversion is this case is pretty simple… it’s
just taking the long value as is and putting that into the date
constructor. But if it’s already there in the converter might as well use
it.


> At risk of being obvious, do you really need a timeline that goes back
> eons, and still allows seconds accuracy? Or even a day accuracy?
> Normally when going that far back even a year is (insanely) high
> granularity, and well, integer numbers we already handle at ease :-p
>



>
> But yeah, if the requisite is to allow a single unified time
> representation good for ages ago and at the same time your
> yesterday detailed movements list, I guess a new type of Date is indeed
> needed. I was wondering if maybe Joda-time
> already faced a similar challenge, but I could not find an answer doing a
> quick internet search.
>
I came up short looking for a solution to this one as well.

>
> One sneaky suggestion... is it that bad to just put a biginteger of sorts
> in the database, keep it that way up to the
> UI, and have the UI translate it in an appropriate way to a date?
>

Good question…  I think having a type that can store as a long and go
to/from date is general enough… but once you start putting constraints on
the value like it represents seconds or years it’s starting to get pretty
custom, and I agree, better to just have GeoTools model it as a number
directly and have the application deal with the interpretation of that.

>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Fi

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Where do you see that? Are we looking at the same patch? The only thing I
really see in the patch is converting to/from milliseconds to date and then
some logic to append a “BC” to encoded date literals when the date falls in
the BC era.

On Thu, Apr 14, 2016 at 9:33 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> I think the patch takes the approach of adjusting the calendar time is
> being measured against.
>
> Can we be tricky and produce a calendar for each section of geological
> time :)
> On Thu, Apr 14, 2016 at 8:31 PM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hey guys. So as I started on this I quickly came to the realization
>> (which I apologize for not seeing the obvious before) but interpreting
>> values as seconds won’t really buy us anything if we’re bound by the value
>> space of long that’s used for java.util.Date.
>>
>> Re-implementing a new date type based on seconds rather than milliseconds
>> is far from a trivial effort as I am sure folks are aware so I think the
>> best I’ll be able to do is clean up the original patch, which will still be
>> limited to the +- 290 million year range. Apologies for the false hope :)
>>
>> I did do some searching around for libraries or any code that is able to
>> represent the full of geologic time but didn’t come up with much. If people
>> do know of such a thing out there let us know…
>>
>>
>>
>> On Tue, Apr 12, 2016 at 1:54 PM Jonathan Marino <mar...@mapstory.org>
>> wrote:
>>
>>> Thanks Justin. Much appreciated. Keep us posted if you can. This is an
>>> exciting, and critical piece of making MapStory work the way we've imagined.
>>>
>>>
>>>
>>> On Tue, Apr 12, 2016 at 3:47 PM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Great, thanks for the input Jonathon and David. I think I have enough
>>>> to put together a proposal on how to improve the current patch. Going to
>>>> start that in a new thread.
>>>>
>>>> On Tue, Apr 12, 2016 at 1:38 PM Jonathan Marino <mar...@mapstory.org>
>>>> wrote:
>>>>
>>>>> Just to be clear from the MapStory end, to be honest, we don't really
>>>>> care the time resolution on negative time - milli, seconds, hours. Just
>>>>> whatever is the most viable pathway to go back to geologic (circa 4.5
>>>>> billion). We leave it to you to determine what you prefer.
>>>>>
>>>>> On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira <jdeol...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Perfect, that is what I needed :)
>>>>>>
>>>>>> Ok, so having two types makes sense. One to be able to go back to
>>>>>> time zero but also limited in terms of resolution to seconds, and one 
>>>>>> that
>>>>>> doesn’t go all the way back but gives you down the millisecond.
>>>>>>
>>>>>> Or do you think that two types is overkill and we can get away with
>>>>>> one type interpreted as seconds?
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290
>>>>>>> Million Years Ago, Seconds can get us to ~290 Billion Years Ago. Using
>>>>>>> seconds allows us to encompass the full geologic record but allows for 
>>>>>>> less
>>>>>>> precision than storing milliseconds.
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <
>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks David. I was clear that native postgresql timestamp couldn’t
>>>>>>>> do the job, but my question was whether bigint had a big enough value 
>>>>>>>> space
>>>>>>>> for geologic time? If we interpret the value as milliseconds is it big
>>>>>>>> enough? Or do we need to interpret as seconds in order to go back far
>>>>>>>> enough?
>>>>>>>>
>>>>>>>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>>>>>>>> bit...@dbspatial.com> wrote:
>>>>>>>>
>>>>>>>>> It's about the value space

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Hey guys. So as I started on this I quickly came to the realization (which
I apologize for not seeing the obvious before) but interpreting values as
seconds won’t really buy us anything if we’re bound by the value space of
long that’s used for java.util.Date.

Re-implementing a new date type based on seconds rather than milliseconds
is far from a trivial effort as I am sure folks are aware so I think the
best I’ll be able to do is clean up the original patch, which will still be
limited to the +- 290 million year range. Apologies for the false hope :)

I did do some searching around for libraries or any code that is able to
represent the full of geologic time but didn’t come up with much. If people
do know of such a thing out there let us know…



On Tue, Apr 12, 2016 at 1:54 PM Jonathan Marino <mar...@mapstory.org> wrote:

> Thanks Justin. Much appreciated. Keep us posted if you can. This is an
> exciting, and critical piece of making MapStory work the way we've imagined.
>
>
>
> On Tue, Apr 12, 2016 at 3:47 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Great, thanks for the input Jonathon and David. I think I have enough to
>> put together a proposal on how to improve the current patch. Going to start
>> that in a new thread.
>>
>> On Tue, Apr 12, 2016 at 1:38 PM Jonathan Marino <mar...@mapstory.org>
>> wrote:
>>
>>> Just to be clear from the MapStory end, to be honest, we don't really
>>> care the time resolution on negative time - milli, seconds, hours. Just
>>> whatever is the most viable pathway to go back to geologic (circa 4.5
>>> billion). We leave it to you to determine what you prefer.
>>>
>>> On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Perfect, that is what I needed :)
>>>>
>>>> Ok, so having two types makes sense. One to be able to go back to time
>>>> zero but also limited in terms of resolution to seconds, and one that
>>>> doesn’t go all the way back but gives you down the millisecond.
>>>>
>>>> Or do you think that two types is overkill and we can get away with one
>>>> type interpreted as seconds?
>>>>
>>>> On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <
>>>> bit...@dbspatial.com> wrote:
>>>>
>>>>> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290
>>>>> Million Years Ago, Seconds can get us to ~290 Billion Years Ago. Using
>>>>> seconds allows us to encompass the full geologic record but allows for 
>>>>> less
>>>>> precision than storing milliseconds.
>>>>>
>>>>> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <jdeol...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Thanks David. I was clear that native postgresql timestamp couldn’t
>>>>>> do the job, but my question was whether bigint had a big enough value 
>>>>>> space
>>>>>> for geologic time? If we interpret the value as milliseconds is it big
>>>>>> enough? Or do we need to interpret as seconds in order to go back far
>>>>>> enough?
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> It's about the value space.
>>>>>>>
>>>>>>> Native PostgreSQL Timestamp can cover between 4713 BC to 294276 AD.
>>>>>>>
>>>>>>> BigInt can cover between ~ -9 and +9 Quintillion
>>>>>>>
>>>>>>> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~
>>>>>>> 290 Billion
>>>>>>>
>>>>>>> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290
>>>>>>> Million
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <
>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks for the info guys, You’ll have to bear with me as you walk
>>>>>>>> me through the nuances of representing time in this way.
>>>>>>>>
>>>>>>>> So in order to represent full geologic time do you need more than
>>>>>>>> just a numeric value? Or is that you just need a numeric type with a 
>>>>>>>> bigger
>>>&

Re: [Geotools-devel] Solr heatmap as a grid coverage

[Justin Deoliveira]

Thanks Simone. See below.

On Thu, Apr 14, 2016 at 10:55 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Ciao Justing,
> please, read below
>
>
>
> On Thu, Apr 14, 2016 at 6:18 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
> > Thanks for the input Simone. Comments inline below.
> >
> > On Thu, Apr 14, 2016 at 10:07 AM Simone Giannecchini
> > <simone.giannecch...@geo-solutions.it> wrote:
> >>
> >> See below..
> >>
> >> 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 Thu, Apr 14, 2016 at 4:10 PM, Justin Deoliveira <jdeol...@gmail.com>
> >> wrote:
> >> > Hey folks.
> >> >
> >> > I just pushed a branch into my repo that contains a coverage reader
> for
> >> > solr
> >> > heatmaps:
> >> >
> >> >
> >> >
> >> >
> https://github.com/geotools/geotools/compare/master...jdeolive:solr-heatmap
> >> >
> >> > A few notes.
> >> >
> >> > First, I tried playing around with using simple interpolation for
> >> > smoothing.
> >> > While it provided something nicer looking than the raw heatmap it
> didn’t
> >> > seem to go far enough. Aside from the fact that it doesn’t seem the
> >> > scale
> >> > operations do anything when translate and scale parameters are
> identity?
> >> > Perhaps that was just user error on my part.
> >> >
> >>
> >> Strange, it should do the simple interpolation. It might be worth
> >> investingating further.
> >> (investigation ongoing)
> >>
> >> Ok, had a quick look at the scale class in JAI-EXT ( I am assuming you
> >> are using geoserver master and have this activated)
> >> and apparently there is an overoptimistic optimization that bypasses
> >> the interpolation:
> >>
> >>
> https://github.com/geosolutions-it/jai-ext/blob/

Re: [Geotools-devel] Solr heatmap as a grid coverage

[Justin Deoliveira]

Thanks for the input Simone. Comments inline below.

On Thu, Apr 14, 2016 at 10:07 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> See below..
>
> 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 Thu, Apr 14, 2016 at 4:10 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
> > Hey folks.
> >
> > I just pushed a branch into my repo that contains a coverage reader for
> solr
> > heatmaps:
> >
> >
> >
> https://github.com/geotools/geotools/compare/master...jdeolive:solr-heatmap
> >
> > A few notes.
> >
> > First, I tried playing around with using simple interpolation for
> smoothing.
> > While it provided something nicer looking than the raw heatmap it didn’t
> > seem to go far enough. Aside from the fact that it doesn’t seem the scale
> > operations do anything when translate and scale parameters are identity?
> > Perhaps that was just user error on my part.
> >
>
> Strange, it should do the simple interpolation. It might be worth
> investingating further.
> (investigation ongoing)
>
> Ok, had a quick look at the scale class in JAI-EXT ( I am assuming you
> are using geoserver master and have this activated)
> and apparently there is an overoptimistic optimization that bypasses
> the interpolation:
>
> https://github.com/geosolutions-it/jai-ext/blob/master/jt-scale/src/main/java/it/geosolutions/jaiext/scale/ScaleCRIF.java#L110
>
> I'll talk to daniele to improve this.
>
> Much appreciated!

>
> > That said I didn’t quite like adding any decisions regarding
> visualization
> > into the coverage reader itself, so I decided to take all of that out and
> > instead do it via rendering transformations. I think this gives us and
> the
> > user the most flexibility. And also allows us to try out different
> > visualization techniques quite easily.
> >
> > In support of this idea on that branch there are two new processes:
> >
> > 1. ConvolveCoverageProcess - Exposes the Convolve operation with a few of
> > it’s parameters
>
> Nice idea.
> There should ne no convolve preocess in GT, but there convolve in JAI
> and JAI-Ext (
> https://github.com/geosolutions-it/jai-ext/tree/master/jt-convolve).
>
> > 2. NormalizeCoverageProcess - “Normalizes” (please correct my terminology
> > here) a raster by first calculating the max value, and then running it
> > through DivideByConst to provide a raster whose values 

Re: [Geotools-devel] Solr heatmap as a grid coverage

[Justin Deoliveira]

Hey folks.

I just pushed a branch into my repo that contains a coverage reader for
solr heatmaps:


https://github.com/geotools/geotools/compare/master...jdeolive:solr-heatmap

A few notes.

First, I tried playing around with using simple interpolation for
smoothing. While it provided something nicer looking than the raw heatmap
it didn’t seem to go far enough. Aside from the fact that it doesn’t seem
the scale operations do anything when translate and scale parameters are
identity? Perhaps that was just user error on my part.

That said I didn’t quite like adding any decisions regarding visualization
into the coverage reader itself, so I decided to take all of that out and
instead do it via rendering transformations. I think this gives us and the
user the most flexibility. And also allows us to try out different
visualization techniques quite easily.

In support of this idea on that branch there are two new processes:

1. ConvolveCoverageProcess - Exposes the Convolve operation with a few of
it’s parameters
2. NormalizeCoverageProcess - “Normalizes” (please correct my terminology
here) a raster by first calculating the max value, and then running it
through DivideByConst to provide a raster whose values fall between the
range [0,1].

The rationale for (2) is to have a “stable” value space for the color map,
otherwise you don’t really know what the min / max values are going to be.
If there some existing code in the code base to handle this situation that
doens’t involve adding any new code please let me know.

Feedback welcome!

Thanks.

-Justin


On Fri, Apr 8, 2016 at 8:31 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Let me know how it goes,
> we have some potential work in the pipeline for Solr and this is
> _very_ interesting for us.
>
> 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, Apr 8, 2016 at 4:25 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
> > Thanks a lot for the feedback guys. Simply using interpolation to do the
> > smoothing makes a lot of sense! Thanks Simone. I am going to experiment a
> > bit more and I’ll come back with my findings.
> >
> > On Fri, Apr 8, 2016 at 7:09 AM Simone Giannecchini
> > <simone.giannecch...@geo-solutions.it> wrote:
> >>
> >> Ciao Justin,
> >> adding to Andrea's, please, read below...
> >>
> >> Regards,
> >> Simone Giannecchini
> >> ==
> >> GeoServer Professional Services from the experts!
> >> Visit http://goo.gl/it488V for more information.
> >

[Geotools-devel] Approach to handling negative dates

[Justin Deoliveira]

Hey folks,

I wanted to start a new thread on this topic to talk about implementation
approach, since I think we can all agree that the current patch (which has
been closed) needs to be redone, at least to some extent.

In general I can think of two approaches to this:

1. Follow the path laid down by the existing patch and add a custom class
to represent this “extended date type”. And then add the converter logic,
etc… to handle converting it to/from it’s native “bigint” representation.

2. Try to approach this by shuffling along some extra metadata in the
attribute type for the column. We already store the “native typename” for
attributes… so I wonder if we can use that to drive the special logic for
date handling.

Alternatives very welcome.

Both of these approaches rest of the idea of adding “well known” domain
types that we would handle in the database, the one from the patch is named
“bigdate”. So I guess one open question to the other developers is if we
are ok with the idea to latching onto types that aren’t “standard”.

All in all I’m kind of leaning toward approach (1) as I think it will be
simpler and it doesn’t involve changing any apis. To make (2) work I think
we should have to end up making modifications to the SQLDialect class in
order to pass AttributeType around instead of Class to some methods. But if
folks feel strongly about following (2) I can give it a try.

Thanks folks.

Also happy to write this up in a proposal if devs think that is warranted.

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

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Great, thanks for the input Jonathon and David. I think I have enough to
put together a proposal on how to improve the current patch. Going to start
that in a new thread.

On Tue, Apr 12, 2016 at 1:38 PM Jonathan Marino <mar...@mapstory.org> wrote:

> Just to be clear from the MapStory end, to be honest, we don't really care
> the time resolution on negative time - milli, seconds, hours. Just whatever
> is the most viable pathway to go back to geologic (circa 4.5 billion). We
> leave it to you to determine what you prefer.
>
> On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Perfect, that is what I needed :)
>>
>> Ok, so having two types makes sense. One to be able to go back to time
>> zero but also limited in terms of resolution to seconds, and one that
>> doesn’t go all the way back but gives you down the millisecond.
>>
>> Or do you think that two types is overkill and we can get away with one
>> type interpreted as seconds?
>>
>> On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <
>> bit...@dbspatial.com> wrote:
>>
>>> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290
>>> Million Years Ago, Seconds can get us to ~290 Billion Years Ago. Using
>>> seconds allows us to encompass the full geologic record but allows for less
>>> precision than storing milliseconds.
>>>
>>> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Thanks David. I was clear that native postgresql timestamp couldn’t do
>>>> the job, but my question was whether bigint had a big enough value space
>>>> for geologic time? If we interpret the value as milliseconds is it big
>>>> enough? Or do we need to interpret as seconds in order to go back far
>>>> enough?
>>>>
>>>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>>>> bit...@dbspatial.com> wrote:
>>>>
>>>>> It's about the value space.
>>>>>
>>>>> Native PostgreSQL Timestamp can cover between 4713 BC to 294276 AD.
>>>>>
>>>>> BigInt can cover between ~ -9 and +9 Quintillion
>>>>>
>>>>> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~ 290
>>>>> Billion
>>>>>
>>>>> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290
>>>>> Million
>>>>>
>>>>> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <
>>>>> jdeol...@gmail.com> wrote:
>>>>>
>>>>>> Thanks for the info guys, You’ll have to bear with me as you walk me
>>>>>> through the nuances of representing time in this way.
>>>>>>
>>>>>> So in order to represent full geologic time do you need more than
>>>>>> just a numeric value? Or is that you just need a numeric type with a 
>>>>>> bigger
>>>>>> value space?
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> With the added rub that millis does not allow to go back quite far
>>>>>>> enough to deal with geologic time. If the same mechanism was used
>>>>>>> (Postgresql Domain), It could be possible to create something like
>>>>>>> "bigdate_milli" and "bigdate_sec" or "bigdate" and "reallybigdate".
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <
>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks David, that helps a lot.
>>>>>>>>
>>>>>>>> So to summarize the ask is to be able to store dates as
>>>>>>>> milliseconds from the epoch, and have the geotools datastore map that 
>>>>>>>> to a
>>>>>>>> java date type . With the current patch that logic is triggered is by 
>>>>>>>> using
>>>>>>>> a domain type of “bigdate” in postgres. And because of the way type 
>>>>>>>> mapping
>>>>>>>> works in the data store we need some subclass (called XDate in the 
>>>>>>>> patch)
>>>>>>>> in order to map back to the database.
>>>>>>>

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Perfect, that is what I needed :)

Ok, so having two types makes sense. One to be able to go back to time zero
but also limited in terms of resolution to seconds, and one that doesn’t go
all the way back but gives you down the millisecond.

Or do you think that two types is overkill and we can get away with one
type interpreted as seconds?

On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <bit...@dbspatial.com>
wrote:

> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290 Million
> Years Ago, Seconds can get us to ~290 Billion Years Ago. Using seconds
> allows us to encompass the full geologic record but allows for less
> precision than storing milliseconds.
>
> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Thanks David. I was clear that native postgresql timestamp couldn’t do
>> the job, but my question was whether bigint had a big enough value space
>> for geologic time? If we interpret the value as milliseconds is it big
>> enough? Or do we need to interpret as seconds in order to go back far
>> enough?
>>
>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>> bit...@dbspatial.com> wrote:
>>
>>> It's about the value space.
>>>
>>> Native PostgreSQL Timestamp can cover between 4713 BC to 294276 AD.
>>>
>>> BigInt can cover between ~ -9 and +9 Quintillion
>>>
>>> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~ 290
>>> Billion
>>>
>>> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290
>>> Million
>>>
>>> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for the info guys, You’ll have to bear with me as you walk me
>>>> through the nuances of representing time in this way.
>>>>
>>>> So in order to represent full geologic time do you need more than just
>>>> a numeric value? Or is that you just need a numeric type with a bigger
>>>> value space?
>>>>
>>>> On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <
>>>> bit...@dbspatial.com> wrote:
>>>>
>>>>> With the added rub that millis does not allow to go back quite far
>>>>> enough to deal with geologic time. If the same mechanism was used
>>>>> (Postgresql Domain), It could be possible to create something like
>>>>> "bigdate_milli" and "bigdate_sec" or "bigdate" and "reallybigdate".
>>>>>
>>>>> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <
>>>>> jdeol...@gmail.com> wrote:
>>>>>
>>>>>> Thanks David, that helps a lot.
>>>>>>
>>>>>> So to summarize the ask is to be able to store dates as milliseconds
>>>>>> from the epoch, and have the geotools datastore map that to a java date
>>>>>> type . With the current patch that logic is triggered is by using a 
>>>>>> domain
>>>>>> type of “bigdate” in postgres. And because of the way type mapping works 
>>>>>> in
>>>>>> the data store we need some subclass (called XDate in the patch) in order
>>>>>> to map back to the database.
>>>>>>
>>>>>> Do I have it right?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> The rationale behind this is to be able to store dates beyond the
>>>>>>> PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>>>>>>>
>>>>>>> Ian's patch allows for storage of the datetime as milliseconds from
>>>>>>> the Unix Epoch which gives roughly +/- 290 Million Years by storing as a
>>>>>>> bigint using a PostgreSQL Domain bigdate as a marker. ("CREATE DOMAIN
>>>>>>> bigdate bigint;" is all that means).
>>>>>>>
>>>>>>> The issue that MapStory/Geonode is running into currently is the
>>>>>>> requirement to be able to show the entire geologic record (the Earth is 
>>>>>>> ~
>>>>>>> 4.2 Billion years old), so even this patch doesn't make it all the way
>>>>>>> there (although storing the datetime as seconds from the Unix Epoch 
>>>

Re: [Geotools-devel] proposal: refactor vector mask external footprint generation

[Justin Deoliveira]

Looks good, added my +1

On Tue, Apr 12, 2016 at 12:01 PM Jody Garnett <jody.garn...@gmail.com>
wrote:

> Added my +1 - we are standing at:
>
>- Andrea Aime: +1
>- Ben Caradoc-Davies
>- Christian Mueller
>- Ian Turton: +1
>- Justin Deoliveira
>- Jody Garnett +1
>- Simone Giannecchini: +1
>
> Ben, Justin, Christian are you in position to respond (the proposal is
> here
> <https://github.com/geotools/geotools/wiki/Refactor-vector-mask-external-footprint-generation>
> )?
>
>
> --
> Jody Garnett
>
> On 12 April 2016 at 00:28, Daniele Romagnoli <
> daniele.romagn...@geo-solutions.it> wrote:
>
>> Hi,
>> We have 3 positive and NO negative.
>> Could I consider the proposal accepted and proceed with the merge?
>>
>> Please, let me know.
>> Cheers,
>> Daniele
>>
>>
>> On Fri, Apr 8, 2016 at 1:32 PM, Ian Turton <ijtur...@gmail.com> wrote:
>>
>>> Sorry I've been busy but it looks good to me +1
>>>
>>> Ian
>>>
>>> On 7 April 2016 at 17:04, Daniele Romagnoli <
>>> daniele.romagn...@geo-solutions.it> wrote:
>>>
>>>> Hi List,
>>>> any other vote on the proposal?
>>>> Please, let me know if you need any clarification.
>>>>
>>>> Cheers,
>>>> Daniele
>>>>
>>>> On Tue, Apr 5, 2016 at 2:09 PM, Simone Giannecchini <
>>>> simone.giannecch...@geo-solutions.it> wrote:
>>>>
>>>>> Dear All,
>>>>> I have been involved in the preparation for this work as I asked to
>>>>> generalize this code so that it can be used in other plugin (e.g.
>>>>> GDAL).
>>>>> Hence I am +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, accur

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Thanks David. I was clear that native postgresql timestamp couldn’t do the
job, but my question was whether bigint had a big enough value space for
geologic time? If we interpret the value as milliseconds is it big enough?
Or do we need to interpret as seconds in order to go back far enough?

On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <bit...@dbspatial.com>
wrote:

> It's about the value space.
>
> Native PostgreSQL Timestamp can cover between 4713 BC to 294276 AD.
>
> BigInt can cover between ~ -9 and +9 Quintillion
>
> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~ 290
> Billion
>
> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290 Million
>
> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Thanks for the info guys, You’ll have to bear with me as you walk me
>> through the nuances of representing time in this way.
>>
>> So in order to represent full geologic time do you need more than just a
>> numeric value? Or is that you just need a numeric type with a bigger value
>> space?
>>
>> On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <
>> bit...@dbspatial.com> wrote:
>>
>>> With the added rub that millis does not allow to go back quite far
>>> enough to deal with geologic time. If the same mechanism was used
>>> (Postgresql Domain), It could be possible to create something like
>>> "bigdate_milli" and "bigdate_sec" or "bigdate" and "reallybigdate".
>>>
>>> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Thanks David, that helps a lot.
>>>>
>>>> So to summarize the ask is to be able to store dates as milliseconds
>>>> from the epoch, and have the geotools datastore map that to a java date
>>>> type . With the current patch that logic is triggered is by using a domain
>>>> type of “bigdate” in postgres. And because of the way type mapping works in
>>>> the data store we need some subclass (called XDate in the patch) in order
>>>> to map back to the database.
>>>>
>>>> Do I have it right?
>>>>
>>>>
>>>>
>>>> On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <
>>>> bit...@dbspatial.com> wrote:
>>>>
>>>>> The rationale behind this is to be able to store dates beyond the
>>>>> PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>>>>>
>>>>> Ian's patch allows for storage of the datetime as milliseconds from
>>>>> the Unix Epoch which gives roughly +/- 290 Million Years by storing as a
>>>>> bigint using a PostgreSQL Domain bigdate as a marker. ("CREATE DOMAIN
>>>>> bigdate bigint;" is all that means).
>>>>>
>>>>> The issue that MapStory/Geonode is running into currently is the
>>>>> requirement to be able to show the entire geologic record (the Earth is ~
>>>>> 4.2 Billion years old), so even this patch doesn't make it all the way
>>>>> there (although storing the datetime as seconds from the Unix Epoch would
>>>>> cover roughly +/-290 Billion which WOULD do the job).
>>>>>
>>>>> On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira <jdeol...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> This was my finding as well… couldn’t make up what was going on here…
>>>>>> which makes me think there is perhaps more to this patch on the GeoNode
>>>>>> side?
>>>>>>
>>>>>> Rather than flying blind has anyone tried to reach out to Ian
>>>>>> Schneider, who afaik is the original author of the patch? If not I can 
>>>>>> give
>>>>>> that a shot and hopefully get him to weigh in.
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 1:30 AM Andrea Aime <
>>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 8:59 AM, Jody Garnett <
>>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Near as I can tell the point of this exercise is to provide a
>>>>>>>> mapping for bigdate:
>>>>>>>>
>>>>>>>> mappings.put("bigdate", XDate.class);
>>>>>>>>
>>>>>>>
&g

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Thanks for the info guys, You’ll have to bear with me as you walk me
through the nuances of representing time in this way.

So in order to represent full geologic time do you need more than just a
numeric value? Or is that you just need a numeric type with a bigger value
space?

On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <bit...@dbspatial.com>
wrote:

> With the added rub that millis does not allow to go back quite far enough
> to deal with geologic time. If the same mechanism was used (Postgresql
> Domain), It could be possible to create something like "bigdate_milli" and
> "bigdate_sec" or "bigdate" and "reallybigdate".
>
> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Thanks David, that helps a lot.
>>
>> So to summarize the ask is to be able to store dates as milliseconds from
>> the epoch, and have the geotools datastore map that to a java date type .
>> With the current patch that logic is triggered is by using a domain type of
>> “bigdate” in postgres. And because of the way type mapping works in the
>> data store we need some subclass (called XDate in the patch) in order to
>> map back to the database.
>>
>> Do I have it right?
>>
>>
>>
>> On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <
>> bit...@dbspatial.com> wrote:
>>
>>> The rationale behind this is to be able to store dates beyond the
>>> PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>>>
>>> Ian's patch allows for storage of the datetime as milliseconds from the
>>> Unix Epoch which gives roughly +/- 290 Million Years by storing as a bigint
>>> using a PostgreSQL Domain bigdate as a marker. ("CREATE DOMAIN bigdate
>>> bigint;" is all that means).
>>>
>>> The issue that MapStory/Geonode is running into currently is the
>>> requirement to be able to show the entire geologic record (the Earth is ~
>>> 4.2 Billion years old), so even this patch doesn't make it all the way
>>> there (although storing the datetime as seconds from the Unix Epoch would
>>> cover roughly +/-290 Billion which WOULD do the job).
>>>
>>> On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> This was my finding as well… couldn’t make up what was going on here…
>>>> which makes me think there is perhaps more to this patch on the GeoNode
>>>> side?
>>>>
>>>> Rather than flying blind has anyone tried to reach out to Ian
>>>> Schneider, who afaik is the original author of the patch? If not I can give
>>>> that a shot and hopefully get him to weigh in.
>>>>
>>>> On Tue, Apr 12, 2016 at 1:30 AM Andrea Aime <
>>>> andrea.a...@geo-solutions.it> wrote:
>>>>
>>>>> On Tue, Apr 12, 2016 at 8:59 AM, Jody Garnett <jody.garn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Near as I can tell the point of this exercise is to provide a mapping
>>>>>> for bigdate:
>>>>>>
>>>>>> mappings.put("bigdate", XDate.class);
>>>>>>
>>>>>
>>>>> Err yeah but I'm still lost, I can't see any such type in postgresql,
>>>>> nor
>>>>> I can find one searching the internet:
>>>>> http://www.postgresql.org/docs/9.3/static/datatype-datetime.html
>>>>>
>>>>> And yet it's used in the test table creations... but if I run it
>>>>> locally:
>>>>>
>>>>> > gttest=# CREATE TABLE "bigdates" (id integer PRIMARY KEY,d bigdate);
>>>>> ERROR:  type "bigdate" does not exist
>>>>> LINE 1: CREATE TABLE "bigdates" (id integer PRIMARY KEY,d bigdate);
>>>>>
>>>>> So... I assume bigdate is some extended type in postgresql, installed
>>>>> as an
>>>>> extension? Yet I cannot find one providing this data type.
>>>>>
>>>>> I'm all for helping, would just like to know what it's for instead of
>>>>> getting in
>>>>> a strange patch at face value there might be a cleaner way to
>>>>> solve this,
>>>>> mocking with converters and centralized converters can cause side
>>>>> effects.
>>>>>
>>>>> Cheers
>>>>> Andrea
>>>>>
>>>>> --
>>>>> ==
>>>>

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

Thanks David, that helps a lot.

So to summarize the ask is to be able to store dates as milliseconds from
the epoch, and have the geotools datastore map that to a java date type .
With the current patch that logic is triggered is by using a domain type of
“bigdate” in postgres. And because of the way type mapping works in the
data store we need some subclass (called XDate in the patch) in order to
map back to the database.

Do I have it right?



On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <bit...@dbspatial.com>
wrote:

> The rationale behind this is to be able to store dates beyond the
> PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>
> Ian's patch allows for storage of the datetime as milliseconds from the
> Unix Epoch which gives roughly +/- 290 Million Years by storing as a bigint
> using a PostgreSQL Domain bigdate as a marker. ("CREATE DOMAIN bigdate
> bigint;" is all that means).
>
> The issue that MapStory/Geonode is running into currently is the
> requirement to be able to show the entire geologic record (the Earth is ~
> 4.2 Billion years old), so even this patch doesn't make it all the way
> there (although storing the datetime as seconds from the Unix Epoch would
> cover roughly +/-290 Billion which WOULD do the job).
>
> On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> This was my finding as well… couldn’t make up what was going on here…
>> which makes me think there is perhaps more to this patch on the GeoNode
>> side?
>>
>> Rather than flying blind has anyone tried to reach out to Ian Schneider,
>> who afaik is the original author of the patch? If not I can give that a
>> shot and hopefully get him to weigh in.
>>
>> On Tue, Apr 12, 2016 at 1:30 AM Andrea Aime <andrea.a...@geo-solutions.it>
>> wrote:
>>
>>> On Tue, Apr 12, 2016 at 8:59 AM, Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Near as I can tell the point of this exercise is to provide a mapping
>>>> for bigdate:
>>>>
>>>> mappings.put("bigdate", XDate.class);
>>>>
>>>
>>> Err yeah but I'm still lost, I can't see any such type in postgresql, nor
>>> I can find one searching the internet:
>>> http://www.postgresql.org/docs/9.3/static/datatype-datetime.html
>>>
>>> And yet it's used in the test table creations... but if I run it locally:
>>>
>>> > gttest=# CREATE TABLE "bigdates" (id integer PRIMARY KEY,d bigdate);
>>> ERROR:  type "bigdate" does not exist
>>> LINE 1: CREATE TABLE "bigdates" (id integer PRIMARY KEY,d bigdate);
>>>
>>> So... I assume bigdate is some extended type in postgresql, installed as
>>> an
>>> extension? Yet I cannot find one providing this data type.
>>>
>>> I'm all for helping, would just like to know what it's for instead of
>>> getting in
>>> a strange patch at face value there might be a cleaner way to solve
>>> this,
>>> mocking with converters and centralized converters can cause side
>>> effects.
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>

Re: [Geotools-devel] WFS Transaction XML parsing

[Justin Deoliveira]

Cool, yeah I think the TransactionPlugin could have some interesting uses
for sure, I think it’s kind of under utilized.

Re the user data attributes I think personally think it could be general
enough. The whole user data idea about shuffling attributes along that you
don’t want to model explicitly I think is pretty useful. And extending that
out to exchange formats like GML and JSON I think is just a natural
extension of that. Interested to hear how other devs feel.

On Fri, Apr 8, 2016 at 9:33 AM Jim Hughes <jn...@ccri.com> wrote:

> Hi Justin,
>
> Thanks.  I forgot to mention that I had seen the TransactionPlugin
> extension point; that one is awesome and I see how to use it support my
> second suggestion.
>
> Would changes in the GML2/3ParsingUtils to inject attributes into a
> SimpleFeature's userData be sensible / more broadly useful?  I'm a bit shy
> about pushing hard for such a change since I am not sure about any other
> ramifications.
>
> Thanks,
>
> Jim
>
>
> On 04/08/2016 10:45 AM, Justin Deoliveira wrote:
>
> Hey Jim,
>
> The wfs native element might be the cleanest way to handle this. I’ve seen
> folks use it before for security and validation type stuff with some
> success. In GeoServer you can plug in WFS transactions callbacks pretty
> easily using the TransactionPlugin extension point. It has direct access
> to the transaction object which has the native content on it.
>
> If you do want to go with approach (1): during GML parsing I don’t believe
> there is any way to tag a GML attribute as something you want to store in
> user data. Folks might correct me on that one though. To support it I
> wonder if we could do something simple like a custom attribute on the gml
> attribute element. Something like:
>
>  foo
>
> One potential downside might be validation… however in GeoServer last I
> checked we don’t validate features on the way in… mostly because it’s a
> pain to have to specify all the schema references properly so a parser can
> actually validate. It may also be there in the gml schema there is some
> attribute we might be able to use /abuse for this purpose… I can’t think of
> one off hand though.
>
> As far as I know the feature parsing logic still lives in the
> GML3ParsingUtils and GML2ParsingUtils classes. To add some support for
> putting an attribute in user data rather than a normal attribute I think
> you would be looking at modifying this method.
>
> As you’ll notice this only applies to simple features. If working with
> complex features i am actually not sure where that logic lives anymore. One
> of the app-schema folks can point you at that if need be.
>
> Hope that helps!
>
> -Justin
>
>
> On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jn...@ccri.com> wrote:
>
>> Hi all,
>>
>> Apologies for the cross-post, but my question hits a little of how
>> GeoServer handles WFS transactions and a little bit of how GeoTools may
>> handle WFS/GML parsing.
>>
>> My high-level goal is to find a way to add security info to a WFS
>> transaction.  I can see three big options:  1. add some bits to the GML
>> feature / WFS call which would set a SimpleFeature's userData or
>> otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3.
>> store the security info in the SimpleFeature.
>>
>> I've got a pretty good handle on the last two options.  The first option
>> would provide the greatest flexibility, so I'm wondering if anyone can
>> help point me in the right direction there.  (Or otherwise say that this
>> is impossible without re-writing GT/GS XML handling...)
>>
>> Thanks in advance,
>>
>> Jim
>>
>>
>> --
>> ___
>> 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] WFS Transaction XML parsing

[Justin Deoliveira]

Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve seen
folks use it before for security and validation type stuff with some
success. In GeoServer you can plug in WFS transactions callbacks pretty
easily using the TransactionPlugin
<[https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java](https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java>
extension point. It has direct access to the transaction object which has
the native content on it.

If you do want to go with approach (1): during GML parsing I don’t believe
there is any way to tag a GML attribute as something you want to store in
user data. Folks might correct me on that one though. To support it I
wonder if we could do something simple like a custom attribute on the gml
attribute element. Something like:

 foo

One potential downside might be validation… however in GeoServer last I
checked we don’t validate features on the way in… mostly because it’s a
pain to have to specify all the schema references properly so a parser can
actually validate. It may also be there in the gml schema there is some
attribute we might be able to use /abuse for this purpose… I can’t think of
one off hand though.

As far as I know the feature parsing logic still lives in the
GML3ParsingUtils and GML2ParsingUtils classes. To add some support for
putting an attribute in user data rather than a normal attribute I think
you would be looking at modifying this method
<[https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362](https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362>
.

As you’ll notice this only applies to simple features. If working with
complex features i am actually not sure where that logic lives anymore. One
of the app-schema folks can point you at that if need be.

Hope that helps!

-Justin


On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes  wrote:

> Hi all,
>
> Apologies for the cross-post, but my question hits a little of how
> GeoServer handles WFS transactions and a little bit of how GeoTools may
> handle WFS/GML parsing.
>
> My high-level goal is to find a way to add security info to a WFS
> transaction.  I can see three big options:  1. add some bits to the GML
> feature / WFS call which would set a SimpleFeature's userData or
> otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3.
> store the security info in the SimpleFeature.
>
> I've got a pretty good handle on the last two options.  The first option
> would provide the greatest flexibility, so I'm wondering if anyone can
> help point me in the right direction there.  (Or otherwise say that this
> is impossible without re-writing GT/GS XML handling...)
>
> Thanks in advance,
>
> Jim
>
>
> --
> ___
> 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] Solr heatmap as a grid coverage

[Justin Deoliveira]

Thanks a lot for the feedback guys. Simply using interpolation to do the
smoothing makes a lot of sense! Thanks Simone. I am going to experiment a
bit more and I’ll come back with my findings.

On Fri, Apr 8, 2016 at 7:09 AM Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:

> Ciao Justin,
> adding to Andrea's, please, read below...
>
> 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 Thu, Apr 7, 2016 at 7:56 PM, Andrea Aime
> <andrea.a...@geo-solutions.it> wrote:
> > On Wed, Apr 6, 2016 at 10:02 PM, Justin Deoliveira <jdeol...@gmail.com>
> > wrote:
> >>
> >> Hi folks,
> >>
> >> I’m working on a project to expose Solr’s heatmap capability through
> >> GeoServer. You can find details about Solr heatmaps here:
> >>
> >> https://cwiki.apache.org/confluence/display/solr/Spatial+Search
> >> (search for “Heatmap Faceting”.
> >>
> >> But the gist of it is this: If you have a spatial field that uses the
> >> recursive prefix tree type (ie. geohash) for indexing then it’s easy
> using
> >> Solr’s facetting infrastructure to generate a heatmap grid. What you get
> >> back from Solr is a 2D array representing the geohash grid, where each
> value
> >> is a count of documents that intersect that grid cell. Applying some
> >> symbolization you can get something that looks like this:
> >>
> >>
> >>
> https://raw.githubusercontent.com/voyagersearch/leaflet-solr-heatmap/master/sample.png
> >>
> >> The above screen shot comes from a leaflet plugin that visualizes the
> >> heatmap directly in the browser. I would like to add a similar looking
> >> visualization for GeoTools/GeoServer.
> >>
> >> My first thought was to expose this as a new type of coverage reader,
> >> since the data is simple grid it falls into the model quite easily. The
> >> major benefit of this approach is that becomes trivial to configure in
> >> GeoServer and easy to style using all of the existing raster symbology
> >> support. I’m interested to hear if others think this is a good approach.
> >
> >
> > I believe it is. You might want have a look at how the sde coverage
> reader
> > was setup, to share the same connection
> > info as a vector solr store (downside, you first have to setup a vector
> > store).
> >
> >>
> >>
> >> If that sounds good my pl

Re: [Geotools-devel] Solr heatmap as a grid coverage

[Justin Deoliveira]

Thanks for the info Jim. Indeed that was my first inclination as well but
once I thought about it I started to struggle with how I could fit it into
the vector pipeline cleanly. HeatmapProcess didn’t seem to really apply
since the aggregation needs to be done on the Solr side and not by the
rendering transform. Is that how the GeoMesa heatmaps work?

To make that approach I would need to hack the request to include all the
required facet parameters. I couldn’t really think of a clean way to do
that although thinking about it again I could probably just throw a bunch
of hints into the query that would trigger the Solr datastore to engage all
of the facetting stuff… I think i’ll explore that approach as well, thanks
Jim!

My other thought was that the heatmap coverage could be useful for reasons
other than purely visualizing areas of density. Like for instance using it
as a mask against another coverage to do some processing… I don’t have a
concrete use case there but thought it had potential.


On Wed, Apr 6, 2016 at 2:14 PM Jim Hughes <jn...@ccri.com> wrote:

> Hi Justin,
>
> Since it is somewhat similar, I wanted to share how GeoMesa creates
> heatmaps using GeoServer.  We have a small WPS which riffs on the
> HeatMapProcess (1).  That process is called via an SLD.  By doing that, we
> can have a regular vector layer, but then generate heatmaps for it without
> fiddling with a second coverage, etc.
>
> Potentially, an approach like that could line up more of the rendering
> pipeline to achieve blur, etc.
>
> Cheers,
>
> Jim
>
> 1.
> https://github.com/geotools/geotools/blob/master/modules/unsupported/process-feature/src/main/java/org/geotools/process/vector/HeatmapProcess.java
>
>
> On 04/06/2016 04:02 PM, Justin Deoliveira wrote:
>
> Hi folks,
>
> I’m working on a project to expose Solr’s heatmap capability through
> GeoServer. You can find details about Solr heatmaps here:
>
> https://cwiki.apache.org/confluence/display/solr/Spatial+Search (search
> for “Heatmap Faceting”.
>
> But the gist of it is this: If you have a spatial field that uses the
> recursive prefix tree type (ie. geohash) for indexing then it’s easy using
> Solr’s facetting infrastructure to generate a heatmap grid. What you get
> back from Solr is a 2D array representing the geohash grid, where each
> value is a count of documents that intersect that grid cell. Applying some
> symbolization you can get something that looks like this:
>
>
> https://raw.githubusercontent.com/voyagersearch/leaflet-solr-heatmap/master/sample.png
>
> The above screen shot comes from a leaflet plugin that visualizes the
> heatmap directly in the browser. I would like to add a similar looking
> visualization for GeoTools/GeoServer.
>
> My first thought was to expose this as a new type of coverage reader,
> since the data is simple grid it falls into the model quite easily. The
> major benefit of this approach is that becomes trivial to configure in
> GeoServer and easy to style using all of the existing raster symbology
> support. I’m interested to hear if others think this is a good approach.
>
> If that sounds good my plan was to add this to the existing solr module.
> It won’t add any new dependencies aside from a dependency on the coverage
> module.
>
> @Andrea: you’re listed as the module maintainer… although if I recall
> correctly we agreed to co-maintain the module?
>
> I have a prototype working so if that all sounds good I’ll push up a
> branch for folks to look at. One thing I am particular eager to get some
> feed back on is how to best achieve the blur affect that makes heatmaps
> look “
> pretty”. At the moment what I have done is baked in a parameter to the
> coverage format that specifies a blur radius and then when reading the
> coverage I run it through the Convolve operation to achieve the desired
> affect. It would be ideal if this could be done at symbolization time. I’m
> wondering if we currently have any way to define a blur or some similar
> effect at rendering time with sld? Would a rendering transform work?
>
> Thanks folks.
>
> -Justin
>
>
>
> --
>
>
>
> ___
> GeoTools-Devel mailing 
> listGeoTools-Devel@lists.sourceforge.nethttps://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] Boundless YSLD to GeoTools?

[Justin Deoliveira]

Can we enable it in the default profile? Tests all pass for me locally and
the module builds pretty fast. Are there are any other requirements for it
to be in the default unsupported profile?

On Wed, Apr 6, 2016 at 12:31 PM Jody Garnett  wrote:

> It is a community module, so not included in a build profile yet. Please
> download source and build locally!
>
> --
> Jody Garnett
>
> On 6 April 2016 at 10:49, jerickson  wrote:
>
>> Hi all!
>>
>> I am super excited to see ysld added to geotools.  I plan on adding it to
>> geoscript asap.  I can't seem to find it in any maven repo though.  I
>> don't
>> see it in the snapshot repo:
>>
>> https://repo.boundlessgeo.com/snapshot/org/geotools/
>>
>> Thanks,
>> Jared
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Boundless-YSLD-to-GeoTools-tp5259070p5259995.html
>> Sent from the geotools-devel mailing list archive at Nabble.com.
>>
>>
>> --
>> ___
>> 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] Boundless YSLD to GeoTools?

[Justin Deoliveira]

On Thu, Mar 31, 2016 at 8:41 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> Wonder how you do your git-fu you do so well.
>

Ha. git filter-branch… it’s amazing and scary all at the same time :)

>
> I will review and merge pull request with torben if you would like to
> create, we best merge to respect contributor agreement etc...
>

Will do. How do you want to handle copyright headers? Shall I update the
module to include the GeoTools copyright now?

>
> The draft docs are in the git history if you want to go digging.
>

Cool, I’ll go looking.


> On Thu, Mar 31, 2016 at 6:13 PM Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Thanks guys, great to hear this is still on the table. I took the liberty
>> of preparing two branches that implement the move. I did it in a way that
>> preserves all of the history of the ysld module from it’s old repository.
>> Here is the branch for that.
>>
>>
>> https://github.com/geotools/geotools/compare/master...jdeolive:ysld?expand=1
>>
>> And then the change removing it from the old repo:
>>
>>
>> https://github.com/boundlessgeo/geoserver-exts/compare/master...jdeolive:ysld-geotools?expand=1
>>
>> Just say the word and I’ll submit these as pull requests.
>>
>> And yeah, definitely willing to share module maintainership on this one,
>> and I’ll be happy to port over docs.
>>
>>
>> On Thu, Mar 31, 2016 at 5:39 PM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> If you like I can take your email as a request for a new community
>>> module :)
>>>
>>> To make this happen we will need to ask a boundless staff to move this
>>> over as a community module. Justin can you volunteer to share "module
>>> maintainer" on this one - since it is a bit of your brainchild. In the
>>> interest of eventually seeing this be supported I can dig up some draft
>>> documentation and either email you or attach to a bug ticket.
>>>
>>>
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 31 March 2016 at 16:28, Torben Barsballe <tbarsba...@boundlessgeo.com
>>> > wrote:
>>>
>>>> Hello Justin
>>>>
>>>> Yes, Boundless is still interested in having YSLD move from
>>>> geoserver-exts to GeoTools.
>>>>
>>>>
>>>> As a GeoTools/GeoServer dev, I also want to bring up one other minor
>>>> note - A few months back, I added some support to GeoServer for generating
>>>> styles in any format (including YSLD). This functionality (available from
>>>> the Styles page in the GeoServer UI) should ideally still function after
>>>> YSLD is ported to geotools. See
>>>> https://github.com/geoserver/geoserver/pull/1182 and
>>>> https://github.com/boundlessgeo/geoserver-exts/pull/100 for more
>>>> details on this.
>>>>
>>>> Torben
>>>>
>>>> On Thu, Mar 31, 2016 at 4:11 PM, Justin Deoliveira <jdeol...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hey folks,
>>>>>
>>>>> I heard a while back through the grapevine that the folks at Boundless
>>>>> are interested in moving the YSLD styling modules currently living in the
>>>>> Boundless geoserver-exts
>>>>> <https://github.com/boundlessgeo/geoserver-exts/tree/master/ysld/gt-ysld>
>>>>> repository to GeoTools? I was wondering if that is still the case because 
>>>>> I
>>>>> think it would be an awesome addition to the library.
>>>>>
>>>>> I know this involves work and I don’t expect folks from Boundless to
>>>>> do this on volunteer time. I have stakeholders that are very eager for 
>>>>> this
>>>>> and they have offered to sponsor my time to work on moving the code over 
>>>>> to
>>>>> GeoTools, initially as an unsupported module.
>>>>>
>>>>> So this is the official ask to the Boundless folks for there blessing.
>>>>> It’s also a poll of the GeoTools developers for opinions, etc… to start 
>>>>> the
>>>>> conversation.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Justin
>>>>>
>>>>>
>>>>> --
>>>>> Transform Data into Opportunity.
>>>>> Accelerate data analysis in your applications with
&

Re: [Geotools-devel] Boundless YSLD to GeoTools?

[Justin Deoliveira]

Thanks guys, great to hear this is still on the table. I took the liberty
of preparing two branches that implement the move. I did it in a way that
preserves all of the history of the ysld module from it’s old repository.
Here is the branch for that.


https://github.com/geotools/geotools/compare/master...jdeolive:ysld?expand=1

And then the change removing it from the old repo:


https://github.com/boundlessgeo/geoserver-exts/compare/master...jdeolive:ysld-geotools?expand=1

Just say the word and I’ll submit these as pull requests.

And yeah, definitely willing to share module maintainership on this one,
and I’ll be happy to port over docs.


On Thu, Mar 31, 2016 at 5:39 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> If you like I can take your email as a request for a new community module
> :)
>
> To make this happen we will need to ask a boundless staff to move this
> over as a community module. Justin can you volunteer to share "module
> maintainer" on this one - since it is a bit of your brainchild. In the
> interest of eventually seeing this be supported I can dig up some draft
> documentation and either email you or attach to a bug ticket.
>
>
>
> --
> Jody Garnett
>
> On 31 March 2016 at 16:28, Torben Barsballe <tbarsba...@boundlessgeo.com>
> wrote:
>
>> Hello Justin
>>
>> Yes, Boundless is still interested in having YSLD move from
>> geoserver-exts to GeoTools.
>>
>>
>> As a GeoTools/GeoServer dev, I also want to bring up one other minor note
>> - A few months back, I added some support to GeoServer for generating
>> styles in any format (including YSLD). This functionality (available from
>> the Styles page in the GeoServer UI) should ideally still function after
>> YSLD is ported to geotools. See
>> https://github.com/geoserver/geoserver/pull/1182 and
>> https://github.com/boundlessgeo/geoserver-exts/pull/100 for more details
>> on this.
>>
>> Torben
>>
>> On Thu, Mar 31, 2016 at 4:11 PM, Justin Deoliveira <jdeol...@gmail.com>
>> wrote:
>>
>>> Hey folks,
>>>
>>> I heard a while back through the grapevine that the folks at Boundless
>>> are interested in moving the YSLD styling modules currently living in the
>>> Boundless geoserver-exts
>>> <https://github.com/boundlessgeo/geoserver-exts/tree/master/ysld/gt-ysld>
>>> repository to GeoTools? I was wondering if that is still the case because I
>>> think it would be an awesome addition to the library.
>>>
>>> I know this involves work and I don’t expect folks from Boundless to do
>>> this on volunteer time. I have stakeholders that are very eager for this
>>> and they have offered to sponsor my time to work on moving the code over to
>>> GeoTools, initially as an unsupported module.
>>>
>>> So this is the official ask to the Boundless folks for there blessing.
>>> It’s also a poll of the GeoTools developers for opinions, etc… to start the
>>> conversation.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>>
>>> --
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>>
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Boundless YSLD to GeoTools?

[Justin Deoliveira]

Hey folks,

I heard a while back through the grapevine that the folks at Boundless are
interested in moving the YSLD styling modules currently living in the
Boundless geoserver-exts

repository to GeoTools? I was wondering if that is still the case because I
think it would be an awesome addition to the library.

I know this involves work and I don’t expect folks from Boundless to do
this on volunteer time. I have stakeholders that are very eager for this
and they have offered to sponsor my time to work on moving the code over to
GeoTools, initially as an unsupported module.

So this is the official ask to the Boundless folks for there blessing. It’s
also a poll of the GeoTools developers for opinions, etc… to start the
conversation.

Thanks!

-Justin
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [GEOT-5079] PostGISDialect Error with PostGIS 2.0

[Justin Deoliveira]

I took a quick look and the patch looks good to me. Commented with a +1 on
the pull request.

On Thu, Mar 17, 2016 at 12:29 PM Andrea Aime 
wrote:

> Hi Shane,
> thanks for the pull request, it might take some time to look at it as
> core devs seem to be all super-busy around this time (deliverables,
> geoserver release delayed due to some java 8 troubles, and so on).
> Worst case I'll try to have a look during the weekend.
>
> Cheers
> Andrea
>
>
> On Thu, Mar 17, 2016 at 7:12 PM, Shane StClair  > wrote:
>
>> Pull request with test cases here:
>>
>> https://github.com/geotools/geotools/pull/1130
>>
>> I can backport to 14.x and 13.x when merged.
>>
>> Thanks,
>> Shane
>>
>> On Tue, Mar 15, 2016 at 1:05 PM Shane StClair 
>> wrote:
>>
>>> Hi list,
>>>
>>> I'm running into this issue with GeoServer 2.8.2/GeoTools 14.2:
>>>
>>> https://osgeo-org.atlassian.net/browse/GEOT-5079
>>>
>>> This happens when the Postgres user used in the GS/GT datastore doesn't
>>> have permissions to read from the geography/geometry_columns tables, or if
>>> a record for the geom doesn't exist in those tables. GeoTools falls back to
>>> trying to use a non-existent DIMENSION() function to get the number of
>>> coordinate dimensions from a sample geometry. Testing with GeoServer, every
>>> configured layer throws this error during startup, which causes several
>>> minutes of delay.
>>>
>>> Although this is a database configuration problem, GeoTools should fall
>>> back to using a working function to determine dimensionality. Based on the
>>> contents of geometry_columns.coord_dimension, the function should be
>>> ST_NDims. I can make a quick PR, just following contributor protocol here,
>>> especially since I don't see updates from this JIRA ticket coming through
>>> on the mailing list.
>>>
>>> Also, I can't figure out a good solution for a test case here, and it's
>>> such a small change I'm not sure if it needs one? Any suggestions?
>>>
>>> Thanks,
>>> Shane
>>>
>>>
>>
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> 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.
>
> ---
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn 

Re: [Geotools-devel] Inserting data in the database from GeoServer

[Justin Deoliveira]

This a question better asked on the GeoServer users list. But yes you can
through GeoServer WFS service.

  http://docs.geoserver.org/latest/en/user/services/wfs/



On Tue, Mar 15, 2016 at 11:46 AM Sayon Kumar 
wrote:

> Hello,
>
> This is a doubt from the end-user perspective.
>
> I can create a new empty table in the database from GeoServer using the
> 'Create new feature type'. Is there also an option that I can insert data
> in this empty table from the GeoServer?
>
> Thanks.
>
> Best,
> Sayon
> 
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Justin Deoliveira]

On Sun, Jan 31, 2016 at 2:37 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Fri, Jan 29, 2016 at 4:00 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> These could be added as new methods to the GML facade class:
>>> SimpleFeatureType GML.decodeSchema(InputStream in)
>>> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>>>
>>> I wonder if you could handle both the scan only single feature vs scan
>> full feature collection with a single additional integer argument. The
>> argument would be the number of features to “pre-scan” to compile the
>> schema. This would allow for a bit more control for larger GML collections
>> where you might not want to scan the whole collection but you want to scan
>> more than just the first. Just a thought.
>>
>
> I'm a bit perplexed... like, it seems to me the two significant values
> would be "1", aka "no null values, my collection is fully uniform" and "0",
> aka "no clue, scan till the end", when you don't know
> where the "odd one out" would be.
> I do realize that most of the time scanning the first few features would
> give you the final schema, but there is no reliability regarding the
> number of features where this happens, the odd case out being exactly the
> one where the attribute shows only in the last
> features of the series (which happens if you do a "order by myAtt desc" in
> a sql query, the null values are packed at
> the beginning of the series).
>
> My thought was that for larger GML collections you may want to lookahead
more than one feature, but you may not want to pay the cost of scanning all
features. So the values would be:

< 1 - scan everything
= 1 - scan just the first
> 1 - scan the first n features

If you don’t think that makes sense that is fine, was just an idea.

So, let me show you what I did in my little experiment, this will also
> explain why I was talking about pull
> parsing :-)
>
> My starting point is a desire to parse a feature collection in GML, and
> get back a SimpleFeatureCollection
> (streaming is not a requirement here). So I started using a normal Parser,
> which gives me back the SimpleFeatureCollection.
>
> However, noticed that the FeatureTypeCache was caching the type of the
> first feature... I then injected in the
> pico context a subclass that would not cache, and then
> DefaultFeatureCollection would start complaining in
> the logs that the features being inserted into it are not a match for its
> feature type (determined from
> the first feature).
>
> So ok, I decided to give the pull parser a try, that does not use a
> collection... here is the result:
>
> ---
>
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> import java.io.IOException;
>
> import javax.xml.stream.XMLStreamException;
>
> import org.geotools.gml2.FeatureTypeCache;
> import org.geotools.gml3.GMLConfiguration;
> import org.geotools.xml.PullParser;
> import org.opengis.feature.simple.SimpleFeature;
> import org.opengis.feature.type.FeatureType;
> import org.xml.sax.SAXException;
>
> public class GMLPullParserReader {
>
> /**
>  * Does not cache the feature type, allowing each feature to have its
> own
>  */
> private static final class FeatureTypeCacheNone extends
> FeatureTypeCache {
> @Override
> public void put(FeatureType type) {
> // no op
> }
> }
>
> public static void main(String[] args) throws XMLStreamException,
> IOException, SAXException {
> pullParse(new File("/tmp/GetFeatureResponse1.xml"));
> pullParse(new File("/tmp/GetFeatureResponse2.xml"));
> }
>
> private static void pullParse(File input)
> throws FileNotFoundException, XMLStreamException, IOException,
> SAXException {
> GMLConfiguration configuration = new GMLConfiguration();
> PullParser parser = new PullParser(configuration, new
> FileInputStream(input), SimpleFeature.class);
> parser.setContextCustomizer(context -> {
> Object instance =
> context.getComponentInstanceOfType(FeatureTypeCache.class);
> context.unregisterComponentByInstance(instance);
> context.registerComponentInstance(new FeatureTypeCacheNone());
> });
> SimpleFeature f = null;
> while((f = (SimpleFeature)parser.parse()) != null) {
> System.out.println(f.getFeatureType());
> }
> }
> }
>
> ---
>
> The two collections hav

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Justin Deoliveira]

Hey Andrea,

Some comments/questions inline.

On Fri, Jan 29, 2016 at 4:44 AM Andrea Aime 
wrote:

> Hi,
> I'm looking into improving our ability to parse GML files whose reference
> to the schema is invalid or unreachable, in other words, not usable.
>
> Right now the parser generates a feature collection by reflecting the
> schema
> out of the first feature, which causes issues some cases, like
> missing elements in the first feature (because they are null), which will
> be then not part of the schema, and will be pruned from any subsequent
> feature too.
>
> My first idea would be to mimic what we have in the GeoJSON module and
> allow the client to perform two parses, one that would determine the best
> feature type by scrolling over the GML (see
> FeatureJSON.readFeatureCollectionSchema),
> and a second one that can take the target feature type as a hint (see
> FeatureJSON.setFeatureType).
>
> These could be added as new methods to the GML facade class:
> SimpleFeatureType GML.decodeSchema(InputStream in)
> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>
> I wonder if you could handle both the scan only single feature vs scan
full feature collection with a single additional integer argument. The
argument would be the number of features to “pre-scan” to compile the
schema. This would allow for a bit more control for larger GML collections
where you might not want to scan the whole collection but you want to scan
more than just the first. Just a thought.


> Internally I'd pass a custom FeatureTypeCache that is not caching anything
> in the first
> case, allowing each feature to have its own natural feature type, and the
> second one
> to prime the cache with the target feature type.
>
> However, I was thinking that the same could be done in a single call,
> since we'd
> be getting a in memory feature collection anyways, so we can really just
> figure
> out the best fitting feature type, and then decorate the collection with a
> retyping one that will be returned. This would be best done using a
> PullParser,
> as we could control how the collection gets build (otherwise we end with a
> DefaultFeatureCollection that would spam the logs complaining the feature
> type
> of the last feature added is not the same as the collection one).
>
> I don’t quite follow this part… the features are all going to be pull into
memory?


> This would however incur in a bit of extra cost... but probably negligible
> comparedf
> to the GML parsing itself... at the same time, the PullParser  is not as
> tested as the non pull one.
>
> So, we have two solutions, one safe but slower, based on two methods,
> using the normal
> parser, and doing two scans, one faster but a litter bit more untested,
> using
> the PullParser.
>
> Which avenue would be the preferred one? Mind, I'd also need to backport
> this little
> new feature
>
> 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 Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or 

Re: [Geotools-devel] jts update from locationtech sprint

[Justin Deoliveira]

Not sure if you need a second but I second that!

On Tue, Jan 26, 2016 at 2:43 PM Jody Garnett  wrote:

> Hanging out with Martin at the locationtech sprint ... over time JTS has
> forked a couple classes from GeoTools:
>
> - SDO - oracle STRUCT to Geometry conversion
> - Shapefile - the origional java.File based implementation before java.io
> :)
>
> I, as a GeoTools PMC member, would like to make these available to the JTS
> project (in a similar fashion to how GeoServer code is shared with
> GeoTools).
> --
> Jody Garnett
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Processes for classification

[Justin Deoliveira]

Thanks Jody.

On Tue, Jan 26, 2016 at 4:11 PM Jody Garnett <jody.garn...@gmail.com> wrote:

> That is all really interesting, are any of the other filter functions
> suitable for use as operators?
>

None that come to mind for the purpose of classifying data into ranges. if
someone does come up with another one it should be pretty easy to add
following the pattern of the current 3 algorithms.

>
> These modules are still considered unsupported so procedure is pretty
> light :)
>

Cool. I’ll wait a bit more for other feedback and merge if no-one objects.

>
> --
> Jody Garnett
>
> On 25 January 2016 at 19:55, Justin Deoliveira <jdeol...@gmail.com> wrote:
>
>> Hi folks,
>>
>> Recently I have been given the opportunity to resurrect some code I wrote
>> a long time back. The code in question adds two processes (one vector, one
>> raster) that breaks input data into a number of classes (ranges). For each
>> range a count of features/pixels is calculated, in addition to a variety of
>> statistical values such as mean, standard deviation, etc… Three
>> classification techniques are utilized:
>>
>> 1. Equal Interval
>> 2. Quantile
>> 3. Natural Breaks
>>
>> Cutting right to the chase here is the pull request:
>>
>>   https://github.com/geotools/geotools/pull/1088
>>
>> I thought I would share some additional technical details to assist in
>> the review.
>>
>> The vector side is the least interesting of the two because the process
>> simple calls through to some FilterFunctions that have existed in the
>> codebase for quite some time.
>>
>> The raster side is a bit more interesting. Basically I implemented a jai
>> operation to do the classification. I should also note that this
>> implementation pre-dates jai-ext (more on that below). The classifcation
>> operation does the breaking of the input raster data into ranges. It does
>> so by extending StatisticsOpImage.
>>
>> Once the classification is done the existing ZonalStats process is
>> utilized to calculate the various statistics requested by the caller.  And
>> that is pretty much it. Feedback welcome.
>>
>> A couple of notes about further improvements that I hope to make
>> relatively soon.
>>
>> The first is probably a port of the operation to jai-ext. I started the
>> initial work for this but it’s still a work in progress. I submitted a few
>> patches to the project (which I am happy to report have been merged) so I
>> can continue to make progress.
>>
>> The second which is shorter term will be a GeoServer pull request that
>> adds support for calling the processes via the GeoServer WPS. Basically I
>> just had to add a custom PPIO to serializes the custom results returned by
>> the classification processes.
>>
>> That is about it. Eager to get some feedback.
>>
>> Thanks!
>>
>> -Justin
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Processes for classification

[Justin Deoliveira]

Hi folks,

Recently I have been given the opportunity to resurrect some code I wrote a
long time back. The code in question adds two processes (one vector, one
raster) that breaks input data into a number of classes (ranges). For each
range a count of features/pixels is calculated, in addition to a variety of
statistical values such as mean, standard deviation, etc… Three
classification techniques are utilized:

1. Equal Interval
2. Quantile
3. Natural Breaks

Cutting right to the chase here is the pull request:

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

I thought I would share some additional technical details to assist in the
review.

The vector side is the least interesting of the two because the process
simple calls through to some FilterFunctions that have existed in the
codebase for quite some time.

The raster side is a bit more interesting. Basically I implemented a jai
operation to do the classification. I should also note that this
implementation pre-dates jai-ext (more on that below). The classifcation
operation does the breaking of the input raster data into ranges. It does
so by extending StatisticsOpImage.

Once the classification is done the existing ZonalStats process is utilized
to calculate the various statistics requested by the caller.  And that is
pretty much it. Feedback welcome.

A couple of notes about further improvements that I hope to make relatively
soon.

The first is probably a port of the operation to jai-ext. I started the
initial work for this but it’s still a work in progress. I submitted a few
patches to the project (which I am happy to report have been merged) so I
can continue to make progress.

The second which is shorter term will be a GeoServer pull request that adds
support for calling the processes via the GeoServer WPS. Basically I just
had to add a custom PPIO to serializes the custom results returned by the
classification processes.

That is about it. Eager to get some feedback.

Thanks!

-Justin
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5334) ClassificationFunction.round suffers from overflow with double values greater than max int

[Justin Deoliveira (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Justin Deoliveira created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5334  
 
 
  ClassificationFunction.round suffers from overflow with double values greater than max int   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Justin Deoliveira  
 
 
Components: 
 main  
 
 
Created: 
 06/Jan/16 4:42 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Justin Deoliveira  
 

  
 
 
 
 

 
 The code does an intermediate conversion to long, then to int, then back to double.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.0-OD-03-049#71001-sha1:c7b15e5

Re: [Geotools-devel] GeoTiff mosaic rendering regression?

[Justin Deoliveira]

Thanks for taking a look Andrea! Indeed, a grayscale image with no color
map being applied, just using the default raster style from GeoServer.

I’ll try to cut the dataset down to something easily downloadable so I can
include in the ticket.

Thanks again!

On Thu, Nov 12, 2015 at 11:42 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Justin,
> had a very quick look, it seems like a gray image  and no colormap was
> supplied for it?
> A bug nevertheless, would be nice if you could open a ticket with enough
> data to reproduce the issue.
>
> We are progressively abandoning support for native JAI btw (as we cannot
> do anything about some of its bugs), that might be part of the problem.
>
> Cheers
> Andrea
>
> On Thu, Nov 12, 2015 at 7:33 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> I’m working on a project where GeoServer is serving up a mosaic of
>> Geotiffs and I’m running into some issues.
>>
>> First off, the server is running version 2.8.0 and the mosaic renders but
>> when zooming into higher resolutions ImageWorker starts to throw
>> exceptions. Here is the stack trace, which seems to be a simple index out
>> of bounds exception:
>>
>>
>> https://gist.github.com/jdeolive/21578d8307659ea88d96#file-2-8-0-stack-trace
>>
>> So my first inclination was to upgrade to the latest 2.8.x, and when
>> looking at that line of code I noticed that it had been addressed. But when
>> I deploy the 2.8.x snapshot the mosaic no longer renders at all, with the
>> following exception:
>>
>>
>> https://gist.github.com/jdeolive/21578d8307659ea88d96#file-2-8-x-stack-trace
>>
>> So… for now what I’ve done is reverted back to 2.8.0 but back ported the
>> patch that adds the size check:
>>
>>
>> https://gist.github.com/jdeolive/21578d8307659ea88d96#file-imageworker-java
>>
>> And with that the mosaic renders, at all zooms.
>>
>> Not sure if it is a configuration issue on my end or a bug but thought I
>> would post here first. The raster masters can let me know if they want me
>> to throw this into a bug report.
>>
>> Some additional info:
>>
>> gdalinfo on one of the mosaic tiles:
>>
>>   https://gist.github.com/jdeolive/21578d8307659ea88d96#file-gdalinfo
>>
>> System info:
>>
>> - Linux 64 bit
>> - Oracle Java 7 / Tomcat 7 with native JAI extensions installed
>>
>> Let me know if I can provide any more info.
>>
>> -Justin
>>
>>
>>
>>
>>
>> --
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or pa

Re: [Geotools-devel] can I grab some help update geoscript projects

[Justin Deoliveira]

geoscript-py updated. Sorry, for some reason my github notifications for
that repo were turned off.

On Sat, Oct 10, 2015 at 10:29 AM, jerickson 
wrote:

> Hi Jody!
>
> I updated geoscript groovy and created pull requests for javascript and
> python.
>
> Cheers,
> Jared
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/can-I-grab-some-help-update-geoscript-projects-tp5229051p5229209.html
> Sent from the geotools-devel mailing list archive at Nabble.com.
>
>
> --
> ___
> 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] Simplifying SOLR store and just expose all documents

[Justin Deoliveira]

On Wed, May 20, 2015 at 10:36 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Wed, May 20, 2015 at 6:12 PM, Justin Deoliveira jdeol...@gmail.com
 wrote:

 +1 I like this approach and I think it will generally make more sense to
 people using solr.

 Question re the cql filter. Will this be a datastore parameter? Or
 something configured on the fly?


 Something that GeoServerFeatureSource adds on the fly, based on the
 GeoServer layer configuration (see parallel thread on the geoserver ml,
 where we suggest
 to add a cql filter on _every_ layer config, not just SOLR).


Right, it made more sense after seeing that thread :)



 If the former what about rather than a cql filter specifying a solr q
 (query) or fq (filter query) parameter directly? I think this would give
 much more flexibility as it would:

 - allow the user to specify solr syntax directy, rather than have to go
 through only is mappable from cql
 - allow for use of solr concepts (like query boosting, etc..) that aren't
 really expressible in cql


 A very nice idea... but I don't have enough time/funding to follow this
 direction (would require some custom UI in GeoServer too, and some virtual
 table like setup in the store).
 Is it something you want to help with, even later?


No worries, just bringing it up as a discussion point. Definitely something
that can be done later... shouldn't  be too hard since we already have the
machinery in place to handle direct solr parameters via viewparams.




 Finally one potentially related point while we are talking about a
 redesign is that I think that rather have the user point directly to a url
 that specifies the core, have the main url the base solr url, and have each
 core served as an available layer. I think this would (a) be more
 convenient to create a single store and (b) follow more how our other
 formats like databases work. I have some code on a branch that does this
 with an implementation of the LayerMapper interface. I can work on making
 that available.


 Agreed, it's just that I'm really tight on time (both available, and
 delivery deadline). But if you have time to work on it, now or later, I
 believe it would be a nice win for everybody.
 Also does not look like my little change would be at odds with what you're
 proposing, am I right?


Yup, I don't see any conflict, definitely something we can iterate on. I
hope to have some time I can put into this in a few weeks time after some
other deliverables are out of the way. Anyways, definitely proceed as you
see fit and I'll be happy to review the patch when the time comes.


 Cheers
 Andrea


 --
 ==
 Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
 http://goo.gl/WHKDXT for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions S.A.S.
 Via Poggio alle Viti 1187
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob: +39  339 8844549

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del messaggio,
 per le finalità indicate nel messaggio stesso. Qualora riceviate questo
 messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
 darcene notizia via e-mail e di procedere alla distruzione del messaggio
 stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
 divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
 utilizzarlo per finalità diverse, costituisce comportamento contrario ai
 principi dettati dal D.Lgs. 196/2003.



 The information in this message and/or attachments, is intended solely for
 the attention and use of the named addressee(s) and may be confidential or
 proprietary in nature or covered by the provisions of privacy act
 (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
 Code).Any use not in accord with its purpose, any disclosure, reproduction,
 copying, distribution, or either dissemination, either whole or partial, is
 strictly forbidden except previous formal approval of the named
 addressee(s). If you are not the intended recipient, please contact
 immediately the sender by telephone, fax or e-mail and delete the
 information in this message that has been received in error. The sender
 does not give any warranty or accept liability as the content, accuracy or
 completeness of sent messages and accepts no responsibility  for changes
 made after they were sent or for other risks which arise as a result of
 e-mail transmission, viruses, etc.

 ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50

Re: [Geotools-devel] Simplifying SOLR store and just expose all documents

[Justin Deoliveira]

+1 I like this approach and I think it will generally make more sense to
people using solr.

Question re the cql filter. Will this be a datastore parameter? Or
something configured on the fly? If the former what about rather than a cql
filter specifying a solr q (query) or fq (filter query) parameter
directly? I think this would give much more flexibility as it would:

- allow the user to specify solr syntax directy, rather than have to go
through only is mappable from cql
- allow for use of solr concepts (like query boosting, etc..) that aren't
really expressible in cql

Finally one potentially related point while we are talking about a redesign
is that I think that rather have the user point directly to a url that
specifies the core, have the main url the base solr url, and have each core
served as an available layer. I think this would (a) be more convenient to
create a single store and (b) follow more how our other formats like
databases work. I have some code on a branch that does this with an
implementation of the LayerMapper interface. I can work on making that
available.



On Wed, May 20, 2015 at 3:47 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 Hi,
 I would like to propose we drop the current field mapping approach in
 the SOLR
 store, leaving only the all documents in one layer approach as the only
 user visible option.
 We realized the current functionality is indeed rigid and cumbersome, and
 would like to
 have it removed before the module has a chance to get into to supported
 land.

 By user visible I mean the functionality will remain in the store for
 backwards compatibility,
 but we'll stop advertising it, so new users won't see it.

 As a replacement for it, at least at the GeoServer level, a more general
 functionality of admin
 specified CQL filter will be used instead.
 (At the GeoTools level, writing a filtering feature source wrapper is
 indeed not hard).

 Let me know if this is ok with you.

 Cheers
 Andrea


 --
 ==
 Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
 http://goo.gl/WHKDXT for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions S.A.S.
 Via Poggio alle Viti 1187
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob: +39  339 8844549

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del messaggio,
 per le finalità indicate nel messaggio stesso. Qualora riceviate questo
 messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
 darcene notizia via e-mail e di procedere alla distruzione del messaggio
 stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
 divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
 utilizzarlo per finalità diverse, costituisce comportamento contrario ai
 principi dettati dal D.Lgs. 196/2003.



 The information in this message and/or attachments, is intended solely for
 the attention and use of the named addressee(s) and may be confidential or
 proprietary in nature or covered by the provisions of privacy act
 (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
 Code).Any use not in accord with its purpose, any disclosure, reproduction,
 copying, distribution, or either dissemination, either whole or partial, is
 strictly forbidden except previous formal approval of the named
 addressee(s). If you are not the intended recipient, please contact
 immediately the sender by telephone, fax or e-mail and delete the
 information in this message that has been received in error. The sender
 does not give any warranty or accept liability as the content, accuracy or
 completeness of sent messages and accepts no responsibility  for changes
 made after they were sent or for other risks which arise as a result of
 e-mail transmission, viruses, etc.

 ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Geobuf DataStore

[Justin Deoliveira]

On Thu, Apr 9, 2015 at 11:28 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Wed, Apr 8, 2015 at 4:47 AM, Jared Erickson jared.erick...@gmail.com
 wrote:

 Hi all!

 I would like to contribute a Geobuf DataStore as an unsupported module.
 Geobuf is a protocol buffer based format from the mapbox folks with
 javascript (https://github.com/mapbox/geobuf) and python (
 https://pypi.python.org/pypi/geobuf/1.0.0) implementations.  The
 DataStore I have been working on has read and write support and is based on
 ContentDataStore.  If this sounds like a good idea, I will submit a pull
 request.


 +1 me too


 The only wrinkle is that we will have to get the TravisCI config file to
 make sure the the native protoc executable is installed.


 Hum... this might be a problem, to get stable builds we had to moved to
 the container based infrastructure,
 in which you don't have sudo powers, thus you cannot install packages.

 Afaik the new container based infrastructure still allows for you to
install packages with the apt addon (vs doing it with sudo apt-get
install). Which I think is all that would be needed here.

  http://docs.travis-ci.com/user/apt/


But maybe we could have get it installed on the ares build server? Jody,
 what do you think?
 In any case, the tests should just disable themselves if they are not
 finding the right environment
 to work

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions S.A.S.
 Via Poggio alle Viti 1187
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob: +39  339 8844549

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del messaggio,
 per le finalità indicate nel messaggio stesso. Qualora riceviate questo
 messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
 darcene notizia via e-mail e di procedere alla distruzione del messaggio
 stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
 divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
 utilizzarlo per finalità diverse, costituisce comportamento contrario ai
 principi dettati dal D.Lgs. 196/2003.



 The information in this message and/or attachments, is intended solely for
 the attention and use of the named addressee(s) and may be confidential or
 proprietary in nature or covered by the provisions of privacy act
 (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
 Code).Any use not in accord with its purpose, any disclosure, reproduction,
 copying, distribution, or either dissemination, either whole or partial, is
 strictly forbidden except previous formal approval of the named
 addressee(s). If you are not the intended recipient, please contact
 immediately the sender by telephone, fax or e-mail and delete the
 information in this message that has been received in error. The sender
 does not give any warranty or accept liability as the content, accuracy or
 completeness of sent messages and accepts no responsibility  for changes
 made after they were sent or for other risks which arise as a result of
 e-mail transmission, viruses, etc.

 ---


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Changing FeatureJSON behaviour when parsing 'id' property

[Justin Deoliveira]

I had a question about part of the patch. See pull request for discussion.

On Sun, Feb 22, 2015 at 5:15 AM, Jody Garnett jody.garn...@gmail.com
wrote:

 Pull request looks good.
 On Sun, Feb 22, 2015 at 3:25 AM William Voorsluys williamv...@gmail.com
 wrote:

 Hello,

 We've been experiencing an issue with parsing GeoJSON using
 FeatureJSON, that happens when a feature has a property named 'id'.
 The current behaviour of FeatureJSON is problematic, as it does not
 recognise 'id' as a property, but instead as the feature ID. I believe
 this a bug.

 I would like to propose a fix that when 'id' is inside a 'properties'
 element, it gets parsed as a regular property.

 If this is an OK behaviour, the fix is part of the following PR:

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

 Best regards,

 Will

 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631;
 iu=/4140/ostg.clktrk
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [geotools-devel] gt-render tests failure

[Justin Deoliveira]

On Thu, Feb 12, 2015 at 2:54 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 Yet... I don't see a way out of this, short of having a OSX build server.
 The renderer is still quote under-tested, whixh also makes it diffucult to
 chance/refactor it.


Right. So I think the profile to disable the checks on OS X is a good
compromise. And if one developing on OS X does play with the renderer
(which doesn't seem to be very often) then they should make sure they run
tests on a different platform or run the tests in interactive mode.

 Cheers
 Andrea
 Il 12/feb/2015 21:55 Justin Deoliveira jdeol...@gmail.com ha scritto:

 The last time I brought this up I did this and indeed the images looked
 fine, but the perceptual diff reported many of the pixels were different.
 It was mentioned back then that we could go through the failing tests and
 up the tolerance value but you also mentioned that there were more such
 tests coming and since you don't develop on OS X it didn't seem like the
 most scalable solution.

 On Thu, Feb 12, 2015 at 1:47 PM, Andrea Aime 
 andrea.a...@geo-solutions.it wrote:

 Guys, check the two images running an interactive test (on the phone
 now, do not remember the sysvar) and if the two images do not have
 significante differences, up the tolerance param accordingly.

 Cheers
 Andrea
 Il 12/feb/2015 21:30 Justin Deoliveira jdeol...@gmail.com ha
 scritto:

 I consistently get these exact same failures on OS X so I think this is
 a known issue, although Jody claims to not have this problem, so not sure
 what his secret sauce is.

 That said I think someone recently added a built profile to ignore
 these failures.

 On Thu, Feb 12, 2015 at 12:09 PM, Ben Caradoc-Davies b...@transient.nz
 wrote:

 Francesco,

 a full build of master with -Dall passes for me on debian/sid amd64.
 This could be a Mac-only failure. I think Jody encountered many of
 these
 in the past. (I had to fix many font problems to get gt-render to pass
 on OpenJDK.)

 Jody, are you still on Mac?

 Francesco, are you able to run this test in Eclipse with interactive
 image tests enabled? This may help you diagnose the problem.

 Andrea's work porting image comparison to pure Java will mean more
 people run them and detect platform variations. There is a property to
 skip image tests, but better to fix them on Mac.

 My environment:

 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-15T06:29:23+13:00)
 Maven home: /home/ben/java/maven
 Java version: 1.7.0_75, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
 Default locale: en_GB, platform encoding: UTF-8
 OS name: linux, version: 3.16.0-4-amd64, arch: amd64, family:
 unix

 Kind regards,
 Ben.

 On 13/02/15 06:29, francesco bartoli wrote:
  Is it just me who isn’t able to build currently geotools? I’m facing
 with the failure in the subject that reports the message below:
 
  Results :
 
  Failed tests:
GridCoverageRendererTest.testReprojectGoogleMercator:416 Images
 are visibly different, found 3220 different pixels, against a threshold 
 of 0
GridCoverageRendererTest.testNoProjectionHandlerSet:512 Images are
 visibly different, found 27 different pixels, against a threshold of 0
GridCoverageRendererTest.testNorthPolar:621 Images are visibly
 different, found 40 different pixels, against a threshold of 0
GridCoverageRendererTest.testRenderingBuffer:321 Images are
 visibly different, found 5628 different pixels, against a threshold of 
 1000
 
  Tests run: 378, Failures: 4, Errors: 0, Skipped: 1
 
  Environment is:
 
  Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-14T18:29:23+01:00)
  Maven home: /usr/local/Cellar/maven/3.2.5/libexec
  Java version: 1.7.0_55, vendor: Oracle Corporation
  Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
  Default locale: it_IT, platform encoding: UTF-8
  OS name: mac os x, version: 10.9.5, arch: x86_64, family: mac
 
  Thanks,
  Francesco
 
 
 
 
 
 --
  Dive into the World of Parallel Programming. The Go Parallel Website,
  sponsored by Intel and developed in partnership with Slashdot Media,
 is your
  hub for all things parallel software development, from weekly thought
  leadership blogs to news, videos, case studies, tutorials and more.
 Take a
  look and join the conversation now.
 http://goparallel.sourceforge.net/
 
 
 
  ___
  GeoTools-Devel mailing list
  GeoTools-Devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/geotools-devel
 

 --
 Ben Caradoc-Davies b...@transient.nz
 Software Engineer
 Transient Software http://transient.nz
 New Zealand


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media

Re: [Geotools-devel] [geotools-devel] gt-render tests failure

[Justin Deoliveira]

The last time I brought this up I did this and indeed the images looked
fine, but the perceptual diff reported many of the pixels were different.
It was mentioned back then that we could go through the failing tests and
up the tolerance value but you also mentioned that there were more such
tests coming and since you don't develop on OS X it didn't seem like the
most scalable solution.

On Thu, Feb 12, 2015 at 1:47 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 Guys, check the two images running an interactive test (on the phone now,
 do not remember the sysvar) and if the two images do not have significante
 differences, up the tolerance param accordingly.

 Cheers
 Andrea
 Il 12/feb/2015 21:30 Justin Deoliveira jdeol...@gmail.com ha scritto:

 I consistently get these exact same failures on OS X so I think this is a
 known issue, although Jody claims to not have this problem, so not sure
 what his secret sauce is.

 That said I think someone recently added a built profile to ignore these
 failures.

 On Thu, Feb 12, 2015 at 12:09 PM, Ben Caradoc-Davies b...@transient.nz
 wrote:

 Francesco,

 a full build of master with -Dall passes for me on debian/sid amd64.
 This could be a Mac-only failure. I think Jody encountered many of these
 in the past. (I had to fix many font problems to get gt-render to pass
 on OpenJDK.)

 Jody, are you still on Mac?

 Francesco, are you able to run this test in Eclipse with interactive
 image tests enabled? This may help you diagnose the problem.

 Andrea's work porting image comparison to pure Java will mean more
 people run them and detect platform variations. There is a property to
 skip image tests, but better to fix them on Mac.

 My environment:

 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-15T06:29:23+13:00)
 Maven home: /home/ben/java/maven
 Java version: 1.7.0_75, vendor: Oracle Corporation
 Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
 Default locale: en_GB, platform encoding: UTF-8
 OS name: linux, version: 3.16.0-4-amd64, arch: amd64, family:
 unix

 Kind regards,
 Ben.

 On 13/02/15 06:29, francesco bartoli wrote:
  Is it just me who isn’t able to build currently geotools? I’m facing
 with the failure in the subject that reports the message below:
 
  Results :
 
  Failed tests:
GridCoverageRendererTest.testReprojectGoogleMercator:416 Images are
 visibly different, found 3220 different pixels, against a threshold of 0
GridCoverageRendererTest.testNoProjectionHandlerSet:512 Images are
 visibly different, found 27 different pixels, against a threshold of 0
GridCoverageRendererTest.testNorthPolar:621 Images are visibly
 different, found 40 different pixels, against a threshold of 0
GridCoverageRendererTest.testRenderingBuffer:321 Images are visibly
 different, found 5628 different pixels, against a threshold of 1000
 
  Tests run: 378, Failures: 4, Errors: 0, Skipped: 1
 
  Environment is:
 
  Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
 2014-12-14T18:29:23+01:00)
  Maven home: /usr/local/Cellar/maven/3.2.5/libexec
  Java version: 1.7.0_55, vendor: Oracle Corporation
  Java home:
 /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
  Default locale: it_IT, platform encoding: UTF-8
  OS name: mac os x, version: 10.9.5, arch: x86_64, family: mac
 
  Thanks,
  Francesco
 
 
 
 
 
 --
  Dive into the World of Parallel Programming. The Go Parallel Website,
  sponsored by Intel and developed in partnership with Slashdot Media,
 is your
  hub for all things parallel software development, from weekly thought
  leadership blogs to news, videos, case studies, tutorials and more.
 Take a
  look and join the conversation now. http://goparallel.sourceforge.net/
 
 
 
  ___
  GeoTools-Devel mailing list
  GeoTools-Devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/geotools-devel
 

 --
 Ben Caradoc-Davies b...@transient.nz
 Software Engineer
 Transient Software http://transient.nz
 New Zealand


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take
 a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel




 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub