Re: [Geotools-devel] Could I get more GitHub permissions?

2024-05-29 Thread Ian Turton
+1

Ian

On Wed, 29 May 2024, 05:54 Jody Garnett,  wrote:

> I think you have been a committer previously David,  but we cleaned up
> inactive accounts a couple years back.
>
> I don’t think the project guidelines have changed much:
> https://docs.geotools.org/latest/developer/roles/contributor.html
>
> The key thing is don’t break the build.
>
> +1 from me, but as your friend and coworker I will ask another PMC member
> to speak up also.
> --
> Jody Garnett
>
>
> On Tue, May 28, 2024 at 4:21 PM David Blasby  wrote:
>
>> Hi,
>>
>> I've been working in the GT codebase and I'd like to have a bit more
>> permission.  I cannot re-run failed builds and I cannot ask for PR reviews.
>>
>> Thanks a lot,
>> Dave
>> ___
>> 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] Individual Contributor clarification

2024-04-26 Thread Ian Turton
+1

Ian

On Thu, 25 Apr 2024 at 12:08, Peter Smythe  wrote:

> Following in the footsteps of GeoServer's GSIP-224, here is a similar
> proposal for GeoTools for the PMC to vote on please:
>
>
> https://github.com/geotools/geotools/wiki/Individual-contributor-clarification
>
> Proposed text, updating
> https://docs.geotools.org/latest/developer/procedures/contribution_license.html
> :
>
> All new contributors
>> <https://docs.geotools.org/latest/developer/roles/contributor.html> will
>> be required to grant copyright to the foundation using a Contributor
>> Licenses <https://www.osgeo.org/about/licenses/>:
>
>
>-
>
>individual_contributor
><https://www.osgeo.org/resources/individual-contributor-license/>
>
>-
>
>corporate_contributor
><https://www.osgeo.org/resources/corporate-contributor-license/>
>
>
> GeoTools is grateful that organizations of all shapes and sizes support
> our project with in-kind participation of their employees. Extending commit
> access is made to individuals directly based on their expertise
> demonstrated over time.
>
>
> Voting:
>
>- Andrea Aime:
>- Ian Turton:
>- Jody Garnett:
>- Nuno Oliveira:
>- Simone Giannecchini:
>- Torben Barsballe:
>
>
> Peter
>
> GeoServer PSC
> AWS Solutions Architect
> https://github.com/petersmythe
>
>
> On Wed, 10 Apr 2024 at 06:13, Jody Garnett  wrote:
>
>> Proposal for discussion
>> https://github.com/geoserver/geoserver/wiki/GSIP-224
>>
>> New text proposed for
>> https://docs.geoserver.org/latest/en/developer/policies/committing.html
>>  page:
>>
>> All contributors are asked to provide an assignment agreement for working
>> on the project:
>>
>>
>>- individual_contributor
>>   <https://www.osgeo.org/resources/individual-contributor-license/>
>>   - Individual contributor agreement.
>>
>>
>>
>>- corporate_contributor
>>   <https://www.osgeo.org/resources/individual-contributor-license/>
>>   - Corporate contributor agreement to authorize employees to work
>>   on project. May also be used as a software grant to donate software to 
>> the
>>   project.
>>
>>
>> GeoServer recognizes that organizations of all shapes and sizes support
>> our project with in-kind participation of their employees. Extending commit
>> access is made to individuals directly based on their expertise
>> demonstrated over time.
>>
>>
>> Thanks!
>> --
>> Jody Garnett
>> ___
>> Geoserver-devel mailing list
>> geoserver-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] [Geoserver-users] forwarding GEBCO WMS fails - help needed

2024-04-25 Thread Ian Turton
On Thu, 25 Apr 2024 at 14:02, Roar Brænden 
wrote:

>
> Certainly that first Accept header seems a little out-dated, but as Ian
> mentioned it doesn't explain why we will get a 403 status code.
>
>
>
Because the ESRI devs don't understand how the web works!

Ian

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


Re: [Geotools-devel] [Geoserver-users] forwarding GEBCO WMS fails - help needed

2024-04-22 Thread Ian Turton
It sounds like we (GeoTools) should accept `text/xml` especially when
requesting getCapabilities documents. But I'm really not sure 403 is the
correct response to not accepting the right content type.

Ian

On Mon, 22 Apr 2024 at 14:03, Peter Smythe  wrote:

> With access to Brent's GeoServer, I have managed to reproduce this
> problem, and it appears to be a combination of GeoTools HTTPClient (not
> MultithreadedHttpClient) and the GEBCO *MapServer* not allowing HTTP
> Header "accept": "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2"
> for some reason.
>
> To reproduce:
> In Postman, GET
> https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES=1.3.0=WMS
> works fine, until the Accept header is changed from the default */* to 
> text/html,
> image/gif, image/jpeg, *; q=.2, */*; q=.2
> Returns 403 Unauthorised
>
> This Accept header appears to only be sent by GeoTools HTTPClient and is
> not sent by the GeoTools MultithreadedHttpClient, which is what I had on by
> default, when the cascaded WMS worked for me on my GeoServer (previous
> email):
>
> [image: image.png]
>  (in GeoServer New WMS Connection)
>
> Is this a GeoTools bug?  Or GeoServer?
>
> And then under what circumstances would the WMS data store fall back to
> the Simple HTTPClient rather than using the MultithreadedHttpClient (HTTP
> connection pooling), even if the above is ticked?
>
> Peter
>
> GeoServer PSC
> AWS Solutions Architect
> https://github.com/petersmythe
>
>
> On Sun, 21 Apr 2024 at 15:19, Peter Smythe  wrote:
>
>> Maybe try again, it works for me from GeoServer v2.25.0:
>>
>> [image: image.png]
>>
>> Peter
>>
>> GeoServer PSC
>> AWS Solutions Architect
>> https://github.com/petersmythe
>>
>>
>> On Sun, 21 Apr 2024 at 00:50, Brent Wood via Geoserver-users <
>> geoserver-us...@lists.sourceforge.net> wrote:
>>
>>> Hi,
>>>
>>> I'm looking to install geoserver on a ship.
>>>
>>> I'd like to use the GEBCO WMS service to provide a background map layer,
>>> but cache it locally to avoid internet traffic.
>>>
>>> The capabilities doc is at:
>>>
>>> https://wms.gebco.net/mapserv?REQUEST=GETCAPABILITIES=1.3.0=WMS
>>>
>>> The layer I wish to provide is: GEBCO_LATEST_SUB_ICE_TOPO
>>>
>>> I can connect & get the capabilities doc in a browser. I can select &
>>> open the layer in QGIS.
>>>
>>> When I try to set up a WMS store in Geoserver I enter the required
>>> parameters, but get told the connection test to the URL failed with error
>>> 403.
>>>
>>> I understand this means the Gebco server is refusing to reply with the
>>> doc. I'm not sure why the URL works from a browser but fails when sent from
>>> Geoserver, any suggestions appreciated, as far  as I know it is an
>>> identical request, from the same host.
>>>
>>>
>>> Thanks,
>>>
>>>   Brent Wood.
>>>
>>> ___
>>> Geoserver-users mailing list
>>>
>>> Please make sure you read the following two resources before posting to
>>> this list:
>>> - Earning your support instead of buying it, but Ian Turton:
>>> http://www.ianturton.com/talks/foss4g.html#/
>>> - The GeoServer user list posting guidelines:
>>> http://geoserver.org/comm/userlist-guidelines.html
>>>
>>> If you want to request a feature or an improvement, also see this:
>>> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>>>
>>>
>>> geoserver-us...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>
>> _______
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines:
> http://geoserver.org/comm/userlist-guidelines.html
>
> If you want to request a feature or an improvement, also see this:
> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>
>
> geoserver-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>


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


Re: [Geotools-devel] Running geotools Quickstart without Maven

2024-02-27 Thread Ian Turton
If you use maven it walks the dependency tree and finds all the jars it
needs.

Ian

On Tue, 27 Feb 2024, 14:10 Amirhossein Nikfal,  wrote:

> Yes, the problem was due to the missing of apache.commons.lang3. Thank you
> very much.
>
> But how could I know about this dependency before the compilation? Neither
> in the pom file, nor in the contents of the jar file
> (gt-swing-31-SNAPSHOT.jar), there was no name regarding
> apache.commons.lang3. Also "*mvn dependency:tree
> -Dincludes=org.geotools:gt-swing:**" could not be helpful.
>
> Best,
> Amir
>
> On Fri, Feb 23, 2024 at 4:37 PM Ian Turton  wrote:
>
>> it looks like you haven't added (at least) the apache.commons.lang3 jar.
>> This is what maven excels at so you should probably let it do it's magic
>> rather than trying to muddle along with out it.
>>
>> Ian
>>
>> On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal 
>> wrote:
>>
>>> The short code below can be compiled and run successfully, but *after
>>> loading the shapefile*, shows error in line: FileDataStore store =
>>> FileDataStoreFinder.getDataStore(file);
>>>
>>> This is the way I compile and run it:
>>> java -d . Quickstart.java
>>> java org.geotools.tutorial.quickstart.Quickstart
>>>
>>> Code:
>>> package org.geotools.tutorial.quickstart;
>>>
>>> import java.io.File;
>>> import org.geotools.api.data.FileDataStore;
>>> import org.geotools.api.data.FileDataStoreFinder;
>>> import org.geotools.swing.data.JFileDataStoreChooser;
>>>
>>> public class Quickstart {
>>> public static void main(String[] args) throws Exception {
>>> File file = JFileDataStoreChooser.showOpenFile("shp", null);
>>> if (file == null) {
>>> return;
>>> }
>>> FileDataStore store = FileDataStoreFinder.getDataStore(file);
>>> }
>>> }
>>>
>>> The errors:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder
>>> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles
>>> (*.shp):java.lang.NoClassDefFoundError:
>>> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError:
>>> org/apache/commons/lang3/SystemUtilsat
>>> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189)
>>> at org.geotools.data.shapefile.files.ShpFiles.(ShpFiles.java:147)
>>> at
>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260)
>>>   at
>>> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417)
>>>   at
>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78)
>>>   at
>>> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55)
>>>   at Quickstart.main(Quickstart.java:31)Caused by:
>>> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils
>>>   at
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
>>>   at
>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>>>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
>>> ... 7 more*
>>>
>>> However, it can load the shapefile without problem when it's run by
>>> maven:
>>> mvn exec:java
>>> -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart
>>>
>>>
>>> Any comment would be appreciated.
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>> Ian Turton
>>
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Re: [Geotools-devel] Running geotools Quickstart without Maven

2024-02-23 Thread Ian Turton
it looks like you haven't added (at least) the apache.commons.lang3 jar.
This is what maven excels at so you should probably let it do it's magic
rather than trying to muddle along with out it.

Ian

On Fri, 23 Feb 2024 at 14:49, Amirhossein Nikfal 
wrote:

> The short code below can be compiled and run successfully, but *after
> loading the shapefile*, shows error in line: FileDataStore store =
> FileDataStoreFinder.getDataStore(file);
>
> This is the way I compile and run it:
> java -d . Quickstart.java
> java org.geotools.tutorial.quickstart.Quickstart
>
> Code:
> package org.geotools.tutorial.quickstart;
>
> import java.io.File;
> import org.geotools.api.data.FileDataStore;
> import org.geotools.api.data.FileDataStoreFinder;
> import org.geotools.swing.data.JFileDataStoreChooser;
>
> public class Quickstart {
> public static void main(String[] args) throws Exception {
> File file = JFileDataStoreChooser.showOpenFile("shp", null);
> if (file == null) {
> return;
> }
> FileDataStore store = FileDataStoreFinder.getDataStore(file);
> }
> }
>
> The errors:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Feb 23, 2024 3:31:29 PM org.geotools.api.data.FileDataStoreFinder
> getDataStoreWARNING: Could not aquire ESRI(tm) Shapefiles
> (*.shp):java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/SystemUtilsjava.lang.NoClassDefFoundError:
> org/apache/commons/lang3/SystemUtilsat
> org.geotools.data.shapefile.files.ShpFiles.init(ShpFiles.java:189)
> at org.geotools.data.shapefile.files.ShpFiles.(ShpFiles.java:147)
> at
> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:260)
>   at
> org.geotools.data.shapefile.ShapefileDataStoreFactory.createDataStore(ShapefileDataStoreFactory.java:417)
>   at
> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:78)
>   at
> org.geotools.api.data.FileDataStoreFinder.getDataStore(FileDataStoreFinder.java:55)
>   at Quickstart.main(Quickstart.java:31)Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils
>   at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
>   at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 7 more*
>
> However, it can load the shapefile without problem when it's run by maven:
> mvn exec:java -Dexec.mainClass=org.geotools.tutorial.quickstart.Quickstart
>
>
> Any comment would be appreciated.
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] Pre-proposal discussion: adding alpha to ChannelSelection

2024-02-22 Thread Ian Turton
sounds good to me

Ian

On Thu, 22 Feb 2024 at 10:09, Andrea Aime 
wrote:

> On Wed, Feb 21, 2024 at 7:37 PM Jody Garnett 
> wrote:
>
>> That sounds good .. and surprising it is not there already? Is it just
>> not a feature of SLD?
>>
>
> Indeed, as crazy as it sounds, it's not an SLD feature. This is an excerpt
> from SE 1.1 schemas:
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
>> Default method very much appreciated to be kind to implementations. For a
>> default setter should it log a message, or throw a not implemented
>> exception?
>>
>
> Yes. There is only one implementation, that will be updated, so the
> exception should not be triggered in the practice.
>
>
>> If you are making an API change perhaps attack the channel traversal
>> problem directly with a default method to list all 4 channels...
>>
>
> The existing API is actually going to collaborate for this bit, here is
> what we have in the style visitor:
>
> /**
>  * Called when accept is called on a raster {@link ChannelSelection}
> element
>  *
>  * @param cs the {@link ChannelSelection} to visit.
>  */
> void visit(ChannelSelection cs);
>
> /**
>  * Called when accept is called on a raster {@link
> SelectedChannelType} element
>  *
>  * @param sct the {@link SelectedChannelType} to visit.
>  */
> void visit(SelectedChannelType sct);
>
> So it's up to the implementation to unpack the channel selection and call
> the visit on the single channel selection type.
> All existing implementations will be updated to call also on the new alpha
> channel. No need for a new visit method here.
>
> All in all, existing implementations not using the alpha channel should be
> unaffected, which should help backporting this change.
> Thoughts?
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] Time to upgrade Spotless... and maybe take advantage of the break?

2024-01-02 Thread Ian Turton
Sounds good to me, not too bothered by which one we go with.

Ian

On Tue, 2 Jan 2024, 17:06 Andrea Aime, 
wrote:

> Hi all,
> you probably know that we are formatting the source code with the Spotless
> Maven plugin,
> in combination with the Google Java Format library.
>
> Currently, we are using an older version of both, because they upgraded
> time ago to require Java 11 as the minimum version, and we were still using
> Java 8. But we have been on Java 11 for a while now, and we can update up
> the dependencies.
>
> I've prepared a pure upgrade of GeoTools, as an example, here:
> https://github.com/aaime/geotools/tree/spotless_upgrade
>
> The update touches 2k files, mostly changing the javadoc style for single
> line javadocs, to use three lines instead. Lots of noise, no significant
> gain in my opinion.
>
> One formatting library that I've been keeping an eye on for a while is
> Palantir's fork of Google Java format. They made some significant changes:
>
>- 4 spaces indent by default (we get this by adopting the AOSP style
>of Google's one)
>- 120 columns rather than 100
>- Formatter optimized for streams and functional style to use less
>space.
>
> They have some significant examples in their landing page
> .
> I've tried this out with GeoTools, and linking what I've found, also with
> GeoServer (both are best viewed offline, in a checkout):
>
>- https://github.com/aaime/geotools/tree/spotless_palantir
>- https://github.com/aaime/geoserver/tree/spotless_palantir
>
> In this case, the GeoTools diff is significantly bigger than the pure
> Spotless upgrade, touches 2k files, but in the end, manages to cut down 60k
> lines of code.
>
> What is your opinion? Would you like to go with Palantir?
>
> If we went down that road, I'd recommend to:
>
>- Wait until the Wicket 9 upgrade is done
>- Wholesale reformat all three projects (GeoTools, GeoWebCache,
>GeoServer)
>- Reformat all active branches for ease of backport (if this ends up
>landing after the 2.25.x release, maybe also reformat the 2.23.x series as
>it will likely get some extra fixes in the next few months).
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Re: [Geotools-devel] Fun with wind arrows in polar projections

2023-12-01 Thread Ian Turton
Sounds like a good solution to the issue, what about the existing
SimplifyingVisitor and other simplifiable functions like Add and Subtract,
will you add it to them or is that left as further work?

Ian

On Thu, 30 Nov 2023 at 21:47, Jody Garnett  wrote:

> What a fun problem, I think the suggestion is a good one.
>
> On Fri, Dec 1, 2023 at 2:31 AM Andrea Aime <
> andrea.a...@geosolutionsgroup.com> wrote:
>
>> Hi,
>> I'm working with wind maps, where typically the data contains
>> (some way to compute) magnitude and directions of the wind vectors.
>>
>> Now, the "direction" is an angle that is used to rotate a symbol.
>> The angle has an assumption... that north is up. However, take a non
>> trivial projection, like polar ones, and the assumption goes belly up, the
>> direction of north can change point by point.
>>
>> So my plan is to introduce a function, "northFix", that would provide a
>> correction angle
>> taking as parameters a CRS and the current point. Something like this:
>>
>> 
>>   
>> EPSG:3976
>> theGeom
>> windDirection
>> 
>>  
>>
>> Parameters in order:
>>
>>- The current CRS  (in actual app, coming from an env variable, e.g
>>"wms_crs" in GeoServer)
>>- The current point
>>- The angle to be fixed
>>
>> So far, so good, I'd say... but in a general SLD, that might still eat
>> quite some time, in cases where it's not needed, e.g., web mercator, WGS84.
>> It would be better to recognize the situation right away, and eliminate the
>> function, replacing it with the wind direction property name directly.
>>
>> I have a StyleSimplifier that could do that, but it would also be quite
>> ad-hoc. Could we have maybe an interface that functions could implement to
>> test if they are simplifyable at all, and offer a replacement? E.g.
>>
>> SimplifyableFunction {
>>  Expression simplify(Function function);
>> }
>>
>> Thoughts?
>>
>> Cheers
>> Andrea
>> ==
>>
>> GeoServer Professional Services from the experts!
>>
>> Visit http://bit.ly/gs-services-us for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions Group
>> phone: +39 0584 962313
>>
>> fax: +39 0584 1660272
>>
>> mob:   +39  339 8844549
>>
>> https://www.geosolutionsgroup.com/
>>
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] ShapeFileDataStore should use GeometryFactory of DataStore.

2023-11-13 Thread Ian Turton
That sounds reasonable to me - a Ticket and a PR is always welcome

Ian

On Mon, 13 Nov 2023 at 11:09, Burkhard Strauss 
wrote:

> I noted the following problem with class ShapeFileDataStore:
>
>- Current behaviour: When reading features from a ShapeFileDataStore,
>the GeometryFactory is taken from Hints specified in the Query. If not
>present, a new default-factory is used. The GeometryFactory of the
>ShapeFileDataStore (which is a ContentDataStore) is simply ignored.
>- Expected behaviour: If the Query doesn't carry a GeometryFactory,
>and the DataStore has one, use the latter.
>
> This can be fixed by changing/adding three lines in one method.
>
> What do you think? Would I need to open a Jira issue?
>
> Regards
>
> Burkhard
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] motion: remove-opengis financial support authorization

2023-09-04 Thread Ian Turton
+0 as I have a conflict of interest

Ian

On Tue, 29 Aug 2023 at 18:22, Jody Garnett  wrote:

> I have contacted the treasurer with respect to costs associated with
> "remove-opengis" proposal - started great success / and great effort last
> week.
>
> Motion: Propose GeoTools PMC authorize up-to $2000 USD to put towards
> travel expenses associated with this activity.
>
> This motion allows the osgeo board to retain some budget for affected
> downstream projects which have not paid attention thus far.
>
>
>- Andrea Aime
>- Ian Turton
>- Jody Garnett
>- Nuno Oliveira
>- Simone Giannecchini
>- Torben Barsballe
>
>
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] release failiure - source forge directory structure change

2023-07-19 Thread Ian Turton
I'm fairly sure we ran into this last time too, it seems that the project
directory has moved, looking at the docs (
https://sourceforge.net/p/forge/documentation/rsync/) it seems that aiming
for

/home/frs/project/geotools/29.2/

Is this a fix that needs to go into main and be backported? Or is it
changing everytime?

For this release I can just hand up load but we should really try to fix this

Ian

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


Re: [Geotools-devel] Release artefacts for 29.2 for testing

2023-07-19 Thread Ian Turton
On Tue, 18 Jul 2023 at 18:53, Jody Garnett  wrote:

> Ian, the same test works for me locally. I expect you are mixing up java
> compilers on your local machine when testing.
>

You're right I do seem to be using Javac 17 and Java 11 - no idea why
though.

Ian

>
> The rest of the bin download looks fine, although the footer says ©
> Copyright 2021, Open Source Geospatial Foundation
> --
> Jody Garnett
>
>
> On Jul 18, 2023 at 9:44:34 AM, Jody Garnett 
> wrote:
>
>> Is there chance you compiled Quickstart.java with Java 17 on line one?
>> --
>> Jody Garnett
>>
>>
>> On Jul 18, 2023 at 9:25:48 AM, Ian Turton  wrote:
>>
>>> I've run into the following issue:
>>>
>>> javac -cp "lib/*" -d bin
>>> src/org/geotools/tutorial/quickstart/Quickstart.java
>>> java -cp "lib/*:bin" org.geotools.tutorial.quickstart.Quickstart
>>> Error: LinkageError occurred while loading main class
>>> org.geotools.tutorial.quickstart.Quickstart
>>> java.lang.UnsupportedClassVersionError:
>>> org/geotools/tutorial/quickstart/Quickstart has been compiled by a more
>>> recent version of the Java Runtime (class file version 61.0), this version
>>> of the Java Runtime only recognizes class file versions up to 55.0
>>>
>>> Not sure if I need to update my Java?
>>> java --version
>>> openjdk 11.0.19 2023-04-18
>>> OpenJDK Runtime Environment (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1)
>>> OpenJDK 64-Bit Server VM (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1,
>>> mixed mode, sharing)
>>>
>>> Or the build server is using Java17? the release job config claims to be
>>> using 11.04
>>>
>>> Can anyone throw any light on this?
>>>
>>> Ian
>>>
>>> On Tue, 18 Jul 2023 at 16:44, Jody Garnett 
>>> wrote:
>>>
>>>> Oh hey Ian cool :)
>>>>
>>>> I was not aware we had a volunteer for the release this month. I would
>>>> like to join you to test the geoserver release announcement script , and
>>>> can make the GWC release if needed.
>>>>
>>>> Jody
>>>>
>>>> On Tue, Jul 18, 2023 at 5:57 AM Ian Turton  wrote:
>>>>
>>>>> Goto
>>>>> https://build.geoserver.org/view/release/job/geotools-release/99/artifact/build/release/distribution/29.2/
>>>>>
>>>>> Ian
>>>>>
>>>>> --
>>>>> Ian Turton
>>>>> ___
>>>>> GeoTools-Devel mailing list
>>>>> GeoTools-Devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>
>>>> --
>>>> --
>>>> Jody Garnett
>>>>
>>>
>>>
>>> --
>>> Ian Turton
>>>
>>

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


Re: [Geotools-devel] Release artefacts for 29.2 for testing

2023-07-18 Thread Ian Turton
I've run into the following issue:

javac -cp "lib/*" -d bin
src/org/geotools/tutorial/quickstart/Quickstart.java
java -cp "lib/*:bin" org.geotools.tutorial.quickstart.Quickstart
Error: LinkageError occurred while loading main class
org.geotools.tutorial.quickstart.Quickstart
java.lang.UnsupportedClassVersionError:
org/geotools/tutorial/quickstart/Quickstart has been compiled by a more
recent version of the Java Runtime (class file version 61.0), this version
of the Java Runtime only recognizes class file versions up to 55.0

Not sure if I need to update my Java?
java --version
openjdk 11.0.19 2023-04-18
OpenJDK Runtime Environment (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1)
OpenJDK 64-Bit Server VM (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1,
mixed mode, sharing)

Or the build server is using Java17? the release job config claims to be
using 11.04

Can anyone throw any light on this?

Ian

On Tue, 18 Jul 2023 at 16:44, Jody Garnett  wrote:

> Oh hey Ian cool :)
>
> I was not aware we had a volunteer for the release this month. I would
> like to join you to test the geoserver release announcement script , and
> can make the GWC release if needed.
>
> Jody
>
> On Tue, Jul 18, 2023 at 5:57 AM Ian Turton  wrote:
>
>> Goto
>> https://build.geoserver.org/view/release/job/geotools-release/99/artifact/build/release/distribution/29.2/
>>
>> Ian
>>
>> --
>> Ian Turton
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> --
> --
> Jody Garnett
>


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


[Geotools-devel] Release artefacts for 29.2 for testing

2023-07-18 Thread Ian Turton
Goto
https://build.geoserver.org/view/release/job/geotools-release/99/artifact/build/release/distribution/29.2/

Ian

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


[Geotools-devel] Release day 29.2, 1.23.2, 2.23.2

2023-07-18 Thread Ian Turton
I'm about to kick off the release train for GeoTools 29.2, GeoWebCache
1.23.2 and GeoServer 2.23.2 (Well Andrea is going to do the GWC release)

I'll start around 1pm UTC so if you have any last minute back ports you
want included in the releases now is your chance.

Ian

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


Re: [Geotools-devel] GEOT-6266

2023-06-14 Thread Ian Turton
We always welcome PRs for open issues. This sounds as if there is a general
potential for SQL injection in the layer names that we should be protecting
against,

Ian

On Wed, 14 Jun 2023 at 10:09, Mike Bryant via GeoTools-Devel <
geotools-devel@lists.sourceforge.net> wrote:

> Dear all,
>
> https://osgeo-org.atlassian.net/browse/GEOT-6266
>
> I've recently run into GEOT-6266 attempting to use the GeoPackage export
> plugin with GeoServer 2.23.1, since some of our layer names contain
> hyphens.
>
> Looking at the relevant code in GeoPackage.java this could be resolved
> by quoting the table name in a few SQLite queries, and I'm happy to
> submit PRs for this if that would be welcome. However, perhaps there are
> other considerations here I'm not aware of? I guess there's the larger
> issue of compatibility and best-practices for layer naming but I'm not
> sure where that is supposed to be enforced.
>
> Many thanks,
> Mike
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] (no subject)

2023-05-22 Thread Ian Turton
As Mark suggested please try to use `gt-geojson-core` as we are trying to
deprecate the `gt-geojson` module which relies on an older and unsupported
dependency.

Ian

On Mon, 22 May 2023 at 16:22, pengfei tian  wrote:

> Hi,
> I found GeoJSONUtil.parse(featureCollectionHandler,
> featureCollectionJson,false) cant return FeatureCollection, so I think 
> FeatureCollectionHandler
> should extends DelegatingHandler
>
> GeoJSONUtil: 
> https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java
>
> FeatureCollectionHandler:https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/feature/FeatureCollectionHandler.java
>
> If this need to be fixed , please let me try to do that.
>
> Best wishes!
> Tiandy
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] GeoTools 29.1 release artefacts available for testing

2023-05-22 Thread Ian Turton
On Mon, 22 May 2023 at 10:15, Andrea Aime 
wrote:

> Hi Ian,
> some time go a "build with empty repo" was added to the geotools-release
> job, so if that is green, we're good on that aspect.
>
> I've just made a clean build anyway.


> By the way, I was checking if we need a GWC 1.23.1, but it seems no commit
> has happened since 1.23.0, so I guess
> it's going to be a pass, and GeoServer can be released against 1.23.0:
> https://github.com/GeoWebCache/geowebcache/tree/1.23.x
>
>
Cool, I'll start on GeoServer then

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


[Geotools-devel] GeoTools 29.1 release artefacts available for testing

2023-05-21 Thread Ian Turton
They are at
https://build.geoserver.org/view/release/job/geotools-release/96/artifact/build/release/distribution/29.1/

If no one finds any issues I'll go ahead and release them

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


[Geotools-devel] Release issues

2023-05-20 Thread Ian Turton
I'm seeing an SSH credentials problem with the release job (
https://build.geoserver.org/view/release/job/geotools-release/95/console)

java.io.IOException: [ssh-agent] Could not find specified credentials
at 
com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:209)
at 
jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:75)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:520)
at hudson.model.Run.execute(Run.java:1900)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)
FATAL: [ssh-agent] Could not find specified credentials
java.io.IOException: [ssh-agent] Could not find specified credentials
at 
com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:209)
at 
jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:75)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:520)
at hudson.model.Run.execute(Run.java:1900)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)
Archiving artifacts

I'm not sure where it is trying to connect to, but I suspect it's
related to the new DNS service. Does anyone know what needs fixing?

Ian


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


[Geotools-devel] Release delayed

2023-05-19 Thread Ian Turton
Until the osgeo repo comes back the release is on hold.

Ian

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


[Geotools-devel] 2.23.1 and 29.1 releases train will start this friday

2023-05-18 Thread Ian Turton
If you have any fixes that you want included in the upcoming 2.23.1
GeoServer or 29.1 GeoTools releases please make sure you have backported
them and updated the fix version in the ticket before Friday morning (UTC)
which is when I plan to start the release cycle.

Ian

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


Re: [Geotools-devel] Add mapping for new type

2023-05-16 Thread Ian Turton
You'll need to take a look at the PostGIS JDBC plugin to get you started,
you should be able to extend most of it and just need to work on the
dialect to add in the changes you need.

Ian

On Tue, 16 May 2023 at 12:05, WaZy  wrote:

> I forgot that there exists a MobilityDB-JDBC driver, can  I use it to
> implement those mapping in a simpler way ?
>
> Le mar. 16 mai 2023 à 11:23, WaZy  a écrit :
>
>> I actually have a type implemented in MobilityDB known as tgeompoint, it
>> is a type used to represent points moving in time( trips). For example this
>> is what  a  tgeompoint looks like :
>>
>> tgeompoint '[Point(0 0)@2000-01-01, Point(100 100)@2000-01-02
>>
>> For your 2 first  questions I didn't understand what you were asking so 
>> maybe know that you see what it looks like we have a better idea than me.
>>
>> For your last question I have already taken a look at PostGISDialect but I 
>> don't know what I should do to have the same thing for mobilityDB and how 
>> would I test it?
>>
>> Do I have to extend this class since mobility+DB is built on top of PostGIS? 
>> Or is there a better way  to  do  that?
>>
>> Wassim
>>
>>
>>
>> Le lun. 15 mai 2023 à 22:41, Jody Garnett  a
>> écrit :
>>
>>> There are a number of ways to model locations changing in time. Do you
>>> have a series of time stamped records each Ruth’s location? If so the
>>> existing temporal support should be fine?
>>>
>>> Or do you have a spatial temporal reference burst as some kind of XYZM
>>> geometry with M being some kind of timestamp? If so you probably have
>>> functions to work with your type?
>>>
>>> Have a look at PostGISDialect for type mapping; you can make something
>>> similar for MobilityDB?
>>>
>>> Jody
>>>
>>> On Mon, May 15, 2023 at 6:59 AM WaZy  wrote:
>>>
>>>> Hello I'm new here and I would like to know how I could add the mapping
>>>> for a new type in  GeoTool. I'm actually using MobilityDB  which is an
>>>> extension to the PostgreSQL database system and its spatial extension
>>>> PostGIS. It allows temporal and spatio-temporal objects to be stored in the
>>>> database, that is, objects whose attribute values and/or location evolves
>>>> in time.I want to  visualize data with Geoserver but it do not allow me to
>>>> read the data because those types are unknown to Geotool if I understood
>>>> correctly.
>>>>
>>>> The message I get in  the logs is : No mapping found for "myAttribute"
>>>> set to  read only.
>>>>
>>>>
>>>>  This is why I want to know how I could do  that and if it is a hard
>>>> task.
>>>>
>>>> Best regards.
>>>> ___
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>> --
>>> --
>>> Jody Garnett
>>>
>> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] gt-iau-wkt graduation

2023-05-09 Thread Ian Turton
+1

Ian

On Tue, 9 May 2023, 17:31 Andrea Aime, 
wrote:

> Hi all,
> following up on previous conversation, criterias for gt-iau-wkt
> "graduation" (aka landing straight on supported land):
>
>- Only class has correct headers
>- No known bugs
>- 100% coverage as reported by jacoco (one class, fully covered by
>tests)
>- Reuses existing code, adds basically just a configuration file
>- Has maintainer (me), has docs (see PR)
>
> Can I get a vote on landing the module directly in supported land?
>
> https://github.com/geotools/geotools/pull/4284
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Re: [Geotools-devel] Polygon fill with markers, rotation and margins

2023-05-08 Thread Ian Turton
On Mon, 8 May 2023 at 13:46, Cécile Vuilleumier <
cecile.vuilleum...@camptocamp.com> wrote:

> Hello all,
>
> This is a follow-up to:
> https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/9c182de7-da6d-7ba8-0689-a4ecd29e3381%40camptocamp.com/#msg37788010
> The issue was initially reported to us by a customer for rotated markers
> (ESRI font) with margins. For non-rotated symbols (as in my initial
> message), it seems the problem is visible only for certain resolutions (for
> me: when working with a very large screen, or by adding the parameter
> "_OPTIONS=dpi:96" to the GetMap request).
>
> After locally debugging the code, it appears that the margin between
> symbols is not taken into account when creating the 3x3 grid and when
> clipping the subimage from it (that is, the central symbol that will be
> used for tiling). The margin is added afterwards (outside the
> markToTilableImage() function) thus resulting in broken up symbols.
>
> I have a branch which addresses the issue and hopefully does not introduce
> any regression (the unit tests are passing and I also did some manual
> testing):
>
> https://github.com/vuilleumierc/geotools/commit/e9af35eeaf5984e7f6b6514c5f9c03a6846e5aaa
>
> I am also attaching two images (actual result and result with proposed
> solution) and the corresponding SLD file.
> Would you consider a PR for this, and if yes do we need a JIRA ticket to
> open one? If more info is needed, let me know.
>
>
That looks great, please open a ticket and then push the PR with a
reference to the ticket.

Thanks

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


[Geotools-devel] Security Score Cards?

2023-04-04 Thread Ian Turton
I've just read this article on assessing security risks -
https://opensource.com/article/23/3/open-source-security-scorecard - Might
be worth implementing as a git action for us.

Any thoughts?

Ian

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


Re: [Geotools-devel] Formerly proposing Remove OpenGIS activity

2023-03-21 Thread Ian Turton
+1

Ian

On Tue, 21 Mar 2023 at 06:33, Jody Garnett  wrote:

> +1 from me; I like the proposal as written (and would not be content with
> just a search and replace).
> --
> Jody Garnett
>
>
> On Mon, Mar 20, 2023 at 12:21 PM Jody Garnett 
> wrote:
>
>> This was discussed <https://git.osgeo.org/gitea/osgeo/todo/issues/142> 
>> earlier
>> as part of OSGeo budget allocation
>> <https://wiki.osgeo.org/wiki/OSGeo_Budget_2023#OSGeo_Initiatives>.
>>
>> Before proceeding with fundraising and setting up an osgeo initiative I
>> want to confirm with the GeoTools PMC that this is a good idea and we are
>> okay with doing the work if funding / planning / enthusiasm are in place to
>> complete the activity.
>>
>> The proposal is here, and the approach has been discussed in prior
>> meetings:
>> - https://github.com/geotools/geotools/wiki/Remove-OpenGIS
>> --
>> Jody Garnett
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] DataUtilities.createType with comma in name

2023-01-23 Thread Ian Turton
On Mon, 23 Jan 2023 at 16:29, Matthias Loeks  wrote:

> Hi all,
>
> I've noticed that org.geotools.data.DataUtilities.createType()
> 
> does not properly map attributed if the name of the descriptor contains a
> comma.
>
> Example: Decoding  "the_geom:Point,value,%:Double"
> yields both "value:String" and "%:Double" attributes, instead of only
> "value,%:Double"
>
> Is this behaviour intended for those featureType specs or is this a bug?
>
> Not sure if using commas in attributed is generally discouraged, but
> matter of fact is we're getting customer SHP data with this.
>

If it isn't outright forbidden to use commas in variable names (it really
should be)  it will be in that function - as explained at
https://github.com/geotools/geotools/blob/a4b65151f993702f05b4e4a0e9f053c71243a14e/modules/library/main/src/main/java/org/geotools/data/DataUtilities.java#L1818
the comma separates the feature descriptors. I'm not at all sure that % is
a valid name either. But in general you shouldn't be using those simple
create functions in anything except unit tests. Use a proper
FeatureTypeBuilder and I suspect all your problems will disappear.

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


[Geotools-devel] Release artefacts available for testing

2023-01-19 Thread Ian Turton
Please try out the new 28.1 release -
https://build.geoserver.org/view/release/job/geotools-release/73/artifact/build/release/distribution/28.1/geotools-28.1-bin.zip

Ian

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


[Geotools-devel] 2.22.1 /1.22.1/28.1 Release train is starting

2023-01-19 Thread Ian Turton
Heads up, I'm going to kick off the 28.1 release of GeoTools this morning,
depending on how this goes Andrea will do GWC 1.22.1 (assuming there have
been changes) and then I will probably finish up GeoServer tomorrow morning.

Ian

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


Re: [Geotools-devel] [Geowebcache-devel] osgeo budget request

2023-01-05 Thread Ian Turton
+0 on the org.opengis - I might have capacity to do that work later this
year but I can think of better things to do with the money.

+1 on the security issues fund (might be able to tap the EU for funds for
that)

Ian

On Wed, 4 Jan 2023 at 20:06, Jody Garnett  wrote:

> Good morning folks,
>
> OSGeo board put out their call for budget request; separately they have
> "todo" ticket for removing the org.opengis
> <https://git.osgeo.org/gitea/osgeo/todo/issues/142> package from the
> GeoTools codebase. And it is on the agenda for the next board meeting
> <https://wiki.osgeo.org/wiki/Board_Meeting_2023-01-30>.
>
> I have provided a technical debt wiki page on refactoring org.opengis
> packages (reversing the work we did to provide the interfaces to start the
> project) in order to get an idea on the work required and costs involved:
> https://github.com/geotools/geotools/wiki/Remove-OpenGIS
>
> Since this change provides no value to the geotools codebase I have no
> real interest in fundraising for the activity. I would expect a similar
> effort to the Java 11 split-package refactoring where the work can be done,
> and a script created and tested against downstream GeoWebCache and
> GeoServer codebases.
>
> For that activity sponsorship raised around $5k for a cross-project
> sprint. The in-kind contributions were 10-25k (staff time / travel / venue
> / fundraising).
>
> I am going to recommend putting in a budget request of 10k for geotools,
> and 5k for geowebcache, and 5k for geoserver to cover a similar
> undertaking. If successful we will still need to ask for in-kind
> participation for individuals and organizations (even if just to cover
> their risk).
>
> I do not think we have a meeting before their budget deadline; so if I can
> get a few +1 replies to this email I will make the request on our behalf.
>
> Also after last year I am going to separately suggest an OSGeo budget for
> "security issues" (as a cross project initiative similar to code sprints).
> Because 2022 sucked.
> --
> Jody Garnett
> ___
> Geowebcache-devel mailing list
> geowebcache-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geowebcache-devel
>


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


Re: [Geotools-devel] Proposing Joseph Miller for commit rights

2022-11-28 Thread Ian Turton
+1

Ian

On Mon, 28 Nov 2022 at 17:07, Andrea Aime 
wrote:

> Hi all,
> Joseph has been working on a number of PRs lately, on a variety of
> different topics (vector mosaicking data store, geojson reader
> improvements, read and expose database column comments, CQL-JSON
> parser/encoder, and more).
> He has patiently been applying all review feedback received.
>
> I'd like to propose Joseph for commit rights on the GeoTools project.
>
> What do you think?
>
> Cheers
> Andrea
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


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

2022-10-29 Thread Ian Turton
+1

Ian

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

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


Re: [Geotools-devel] Problems with shape marks

2022-08-11 Thread Ian Turton
Mika,

can you atleast create a ticket for this (
https://osgeo-org.atlassian.net/jira/software/c/projects/GEOT/issues) and
add the information that you've found so far.

Thanks

Ian

On Thu, 11 Aug 2022 at 10:31,  wrote:

> Jody,
> I understand that. I still feel that this "bug" is something that needs
> particular dev experience on Geotools or Java. I haven't been an active
> developer for five years now and I have very limited time to investigate
> things but..
>
> I did what you asked and I can confirm and repeat this malfunction.
> First of all Javas:
> - java-11-openjdk-11.0.16.0.8-1.el7_9.x86_64
> - java-1.8.0-openjdk-1.8.0.342.b07-1.el7_9.x86_64
> and the code (Geotools):
>
> ExplicitBoundsShape dotShape =
>  new ExplicitBoundsShape(
>  new Ellipse2D.Double(-0.01, -0.01,
> 0.01, 0.01));
>  dotShape.setBounds(new Rectangle2D.Double(-0.5, 0.5, 1.0, 1.0));
>  shapes.put("dot", dotShape);
>
> and especially this:
>
> new Ellipse2D.Double(-0.01, -0.01, 0.01, 0.01)
>
> Doesn't work (in Geoserver) with OpenJDK 11
>
> This one does (almost the same functioning):
>
> new Ellipse2D.Double(-0.1, -0.1, 0.1, 0.1)
>
> And even this one (of course the dots are squares, not circles):
>
> new Rectangle2D.Double(-0.01, -0.01, 0.01, 0.01)
>
> I have no idea why this kind of behaviour, API should be 100% same. What
> might have changed are the definitions of doubles and floats and maybe
> some locale issues between 8 and 11, but I didn't find any that would
> suite into this problem. So some kind of cul-de-sac for me, can't spend
> any time on this without help.
>
> - mika -
>
> P.S. There's no unit test for this and probably some bugs or mix ups on
> tests named as
>
> https://github.com/geotools/geotools/blob/main/modules/library/render/src/test/java/org/geotools/renderer/style/markwkt/ShapeMarkFactoryTest.java
> Any way they wouldn't find this problem because no exceptions found even
> though function is not what wanted.
>
>
>
> On 2022-08-09 16:46, Jody Garnett wrote:
> > This list is for the developer side of the street; we can help you
> > here when you submit a bug and start working on a patch.
> >
> > There should be some existing test cases for mark factory you can
> > copy; or if you run a build in that environment they should *fail* if
> > there is indeed a regression in OpenJDK11.
> >
> > As far as I know we are running all tests on OpenJDK8 and OpenJDK11
> > (both on build server and pull requests).
> >
> > Can you grab the source code and build in your environment? Perhaps
> > you have a new OpenJDK11 with a problem; or are on a system such as
> > windows that is not often used by developers.
> >
> > Jody
> >
> > On Tue, Aug 9, 2022 at 5:21 AM  wrote:
> >
> >> Hello,
> >> maybe not the best platform to ask (spam..), but anyone having any
> >> idea
> >> of ShapeMarkfactory
> >>
> > (
> https://github.com/geotools/geotools/blob/26.5/modules/library/render/src/main/java/org/geotools/renderer/style/ShapeMarkFactory.java
> )
> >> ..does it work with OpenJDK11 as planned? Or can someone debug that?
> >> My problem is in Geoserver, loosing dot hatch if using OpenJDK11,
> >> with 8
> >> it works. I found these lines, which I believe do the dots:
> >>
> >> ExplicitBoundsShape dotShape =
> >> new ExplicitBoundsShape(
> >> new Ellipse2D.Double(-0.01, -0.01,
> >> 0.01, 0.01));
> >> dotShape.setBounds(new Rectangle2D.Double(-0.5, 0.5, 1.0,
> >> 1.0));
> >> shapes.put("dot", dotShape);
> >>
> >> According to Javadoc that seems to be ok also with 11, but for some
> >> reason dots disappear (SLD below). With for example shape://plus,
> >> hatch
> >> works, with dot, nothing.
> >>
> >> Thanks,
> >> - mika -
> >>
> >>  >> xmlns="http://www.opengis.net/sld;
> >> xmlns:sld="http://www.opengis.net/sld;
> >> xmlns:gml="http://www.opengis.net/gml;
> >> xmlns:ogc="http://www.opengis.net/ogc; version="1.0.0">
> >> 
> >> Default Styler
> >> 
> >> Default Styler
> >> 
> >> name
> >> 
> >> Name something
> >> 
> >> 
> >> 
> >> 
> >> 
> >>
> >> shape://dot
> >> 
> >>  >> name="stroke">#646464
> >>  >> name="stroke-width">2
> >> 
> >> 
> >> 5
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>
> >> ___
> >> GeoTools-Devel mailing list
> >> GeoTools-Devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >  --
> >
> > --
> > Jody Garnett
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] New community module: STAC datastore

2022-07-13 Thread Ian Turton
+1

Ian

On Wed, 13 Jul 2022 at 13:38, Andrea Aime
 wrote:
>
> Hi all,
> I'm writing to ask permission for a new community module, a datastore that 
> would
> talk to a STAC API, and return features accordingly.
>
> The module would be used as a simple vector store, to display where assets 
> (images) are located, but it's also meant to be used as a image mosaic index, 
> so that we can display and mosaic images referenced from the STAC server (as 
> COGs, typically).
>
> The features returned would be the usual SimpleFeatures, with the usual small 
> departures from the model, with attributes occasionally containing arrays, 
> maps or more complex structures
> (complex features support, as it stands today, it's not particularly useful, 
> too expensive to use both at development time and at run time).
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa 
> che ogni circostanza inerente alla presente email (il suo contenuto, gli 
> eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i 
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per 
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei 
> comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is addressed 
> and may contain information that is privileged, confidential or otherwise 
> protected from disclosure. We remind that - as provided by European 
> Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or 
> the information herein by anyone other than the intended recipient is 
> prohibited. If you have received this email by mistake, please notify us 
> immediately by telephone or e-mail
> _______
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel



-- 
Ian Turton


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


Re: [Geotools-devel] Proposed MF-JSON unsupported module

2022-07-13 Thread Ian Turton
+1 - looks like fun

Ian

On Wed, 13 Jul 2022 at 02:21, Brad Hards  wrote:
>
> As flagged in gitter, I am (virtually) attending the OGC Vector API code
> sprint. There is interest in an OGC Moving Features JSON implementation for
> GeoTools.  Moving Features is (simplistically) like OGC Simple Features with a
> time attribute, except the time attribute is really a temporal geometry.
>
> There are two encodings, as described in https://docs.opengeospatial.org/is/
> 19-045r3/19-045r3.html#_overview_of_moving_features_json_encodings_informative
>
> The goal (possibly not within this sprint) is to support both as a Store.
>
> I request approval to create a new unsupported module for this work, under
> geotools/modules/unsupported/mfjson
>
> Brad
>
>
>
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel



-- 
Ian Turton


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


Re: [Geotools-devel] Odd JDBC test failure in Oracle and Infomix only?

2022-06-12 Thread Ian Turton
On Sat, 11 Jun 2022 at 18:40, Andrea Aime 
wrote:

> Hi Ian,
> I don't know, but the code change I'm seeing in JDBCDataStore is not where
> I expected it... maybe it bears some relation.
> The check on whether a visitor can be optimized out or not is normally
> made at the beginning of this method:
>
> https://github.com/geotools/geotools/blob/7c49932f89472db7bfd76b42b137c5392f1661c2/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCDataStore.java#L1395
>
>
Ah, that's a much better place to check


> That said, the check you're proposing is way more nested, other stuff
> already happened, and it's throwing an exception ...
> maybe in some databases that leaves a dirty state somewhere?
>
>
Hmm even with the new code those 2 fail - I can either pull that test (it
isn't actually relevant to this fix) or ignore it in the Infomix and Oracle
for the time being.

Ian

> Cheers
> Andrea
>
> On Sat, Jun 11, 2022 at 3:10 PM Ian Turton  wrote:
>
>> While experimenting with function handling in JDBC datastores I added a
>> new test as a just in case test - it should already pass on all databases.
>> I was just checking strMatches functions didn't get passed to the database
>> and all seemed fine with H2 and Postgis locally, when I pushed it to gtihub
>> I get failures from Oracle and Infomix.
>>
>> The test is
>> https://github.com/ianturton/geotools/blob/6693a5ec64aee6766821c6b8a8e9d29adccfc7c1/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L755
>> which (I think) is functionally the same as
>> https://github.com/ianturton/geotools/blob/6693a5ec64aee6766821c6b8a8e9d29adccfc7c1/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L739
>> which does pass.
>>
>> The failed CI runs are at
>> https://github.com/geotools/geotools/runs/6842365526?check_suite_focus=true
>> and
>> https://github.com/geotools/geotools/runs/6842365461?check_suite_focus=true
>>
>> Can anyone think why two databases are failing but the rest are fine?
>>
>> cheers
>>
>> Ian
>>
>> --
>> Ian Turton
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>


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


[Geotools-devel] Odd JDBC test failure in Oracle and Infomix only?

2022-06-11 Thread Ian Turton
While experimenting with function handling in JDBC datastores I added a new
test as a just in case test - it should already pass on all databases. I
was just checking strMatches functions didn't get passed to the database
and all seemed fine with H2 and Postgis locally, when I pushed it to gtihub
I get failures from Oracle and Infomix.

The test is
https://github.com/ianturton/geotools/blob/6693a5ec64aee6766821c6b8a8e9d29adccfc7c1/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L755
which (I think) is functionally the same as
https://github.com/ianturton/geotools/blob/6693a5ec64aee6766821c6b8a8e9d29adccfc7c1/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L739
which does pass.

The failed CI runs are at
https://github.com/geotools/geotools/runs/6842365526?check_suite_focus=true
and
https://github.com/geotools/geotools/runs/6842365461?check_suite_focus=true

Can anyone think why two databases are failing but the rest are fine?

cheers

Ian

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


[Geotools-devel] SQL Aggregate functions?

2022-06-09 Thread Ian Turton
While taking a quick look at
https://osgeo-org.atlassian.net/browse/GEOT-7161 I can't find any tests for
the org.geotools.jdbc.JDBCDataStore.doSelectAggregateSQL(String,
List, List, SimpleFeatureType, Query,
LimitingVisitor, StringBuffer)
or org.geotools.jdbc.JDBCDataStore.selectAggregateSQL(String,
List, List, SimpleFeatureType, Query,
LimitingVisitor) methods?


- am I missing something obvious?or did this functionality sneak in without
any tests?

Ian

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


[Geotools-devel] Request body logging settings on the global settings page?

2022-06-03 Thread Ian Turton
According to the manual -
https://docs.geoserver.org/main/en/user/configuration/globalsettings.html#enable-request-logging
and
https://docs.geoserver.org/main/en/user/production/troubleshooting.html#troubleshooting-requests
you can turn request body logging on via the global settings page. But you
can't - the only setting left from that is the size of the request body to
saved.

Before I have a go at rewriting those sections to point to the web.xml file
I thought I'd check that we actually intended to remove the controls from
the global settings page or should I look instead at where they've gone to?

Ian

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


Re: [Geotools-devel] Build failures in gt-imageio-ext-gdal

2022-06-02 Thread Ian Turton
For anyone else who runs into this issue its a version mismatch problem, As
gdal-config was saying my system has moved on to GDAL 3.3.2 but looking at
the output of the failing tests showed that GeoTools was still picking up
version 3.0.4 somehow.

ldconfig -p | grep gdal
libgdalalljni.so.29 (libc6,x86-64) => /usr/local/lib/libgdalalljni.so.29
libgdal.so.29 (libc6,x86-64) => /usr/local/lib/libgdal.so.29
libgdal.so.29 (libc6,x86-64) => /usr/lib/libgdal.so.29
libgdal.so.26 (libc6,x86-64) => /usr/lib/libgdal.so.26
libgdal.so (libc6,x86-64) => /usr/local/lib/libgdal.so
libgdal.so (libc6,x86-64) => /usr/lib/libgdal.so

so the 26 shared library was being picked up first.

The solution was to set /usr/local/lib ahead of /usr/lib in LD_LIBRARY_PATH
- I didn't want to just delete the 26 version of the library as something
else might need it.

Ian

On Fri, 27 May 2022 at 12:08, Ian Turton  wrote:

> I'm seeing a persistent failure when I try to build main locally, it's in
> gt-imageio-ext-gdal.
>
> There's a dumpstream in the surefire-reports folder that says:
>
> # Created at 2022-05-27T11:57:21.448
> free(): invalid pointer
>
> # Created at 2022-05-27T11:57:21.456
> Aborted
>
> And the failing tests seems to be VRTTest, RPFTOCTest & SRPTest with this
> error:
>
>
> ---
> Test set: org.geotools.coverageio.gdal.vrt.VRTTest
>
> ---
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 s <<<
> FAILURE! - in org.geotools.coverageio.gdal.vrt.VRTTest
> test(org.geotools.coverageio.gdal.vrt.VRTTest)  Time elapsed: 0 s  <<<
> ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class
> org.gdal.gdalconst.gdalconstConstants
> at
> it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:703)
> at javax.imageio.ImageReader.setInput(ImageReader.java:380)
> at
> org.geotools.coverageio.BaseGridCoverage2DReader.(BaseGridCoverage2DReader.java:161)
> at
> org.geotools.coverageio.gdal.BaseGDALGridCoverage2DReader.(BaseGDALGridCoverage2DReader.java:74)
> at
> org.geotools.coverageio.gdal.vrt.VRTReader.(VRTReader.java:54)
> at org.geotools.coverageio.gdal.vrt.VRTTest.test(VRTTest.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> While DTEDTest fails with:
>
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.049 s
> <<< FAILURE! - in org.geotools.coverageio.gdal.dted.DTEDTest
> test(org.geotools.coverageio.gdal.dted.DTEDTest)  Time elapsed: 0.047 s
>  <<< ERROR!
> java.lang.UnsatisfiedLinkError:
> org.gdal.gdalconst.gdalconstJNI.OF_MULTIDIM_RASTER_get()I
> at org.gdal.gdalconst.gdalconstJNI.OF_MULTIDIM_RASTER_get(Native
> Method)
> at
> org.gdal.gdalconst.gdalconstConstants.(gdalconstConstants.java:101)
> at
> it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:703)
> at javax.imageio.ImageReader.setInput(ImageReader.java:380)
> at
> org.geotools.coverageio.BaseGridCoverage2DReader.(BaseGridCoverage2DReader.java:161)
> at
> org.geotools.coverageio.gdal.BaseGDALGridCoverage2DReader.(BaseGDALGridCoverage2DReader.java:74)
> at
> org.geotools.coverageio.gdal.dted.DTEDReader.(DTEDReader.java:53)
> at
> org.geotools.coverageio.gdal.dted.DTEDTest.test(DTEDTest.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> gdal-config --version reports 3.3.2 and I'm running Ubuntu 20.04 LTS.
>
> Can anyone see what might be up?
>
> Ian
>
> --
> Ian Turton
>


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


[Geotools-devel] Build failures in gt-imageio-ext-gdal

2022-05-27 Thread Ian Turton
I'm seeing a persistent failure when I try to build main locally, it's in
gt-imageio-ext-gdal.

There's a dumpstream in the surefire-reports folder that says:

# Created at 2022-05-27T11:57:21.448
free(): invalid pointer

# Created at 2022-05-27T11:57:21.456
Aborted

And the failing tests seems to be VRTTest, RPFTOCTest & SRPTest with this
error:

---
Test set: org.geotools.coverageio.gdal.vrt.VRTTest
---
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 s <<<
FAILURE! - in org.geotools.coverageio.gdal.vrt.VRTTest
test(org.geotools.coverageio.gdal.vrt.VRTTest)  Time elapsed: 0 s  <<<
ERROR!
java.lang.NoClassDefFoundError: Could not initialize class
org.gdal.gdalconst.gdalconstConstants
at
it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:703)
at javax.imageio.ImageReader.setInput(ImageReader.java:380)
at
org.geotools.coverageio.BaseGridCoverage2DReader.(BaseGridCoverage2DReader.java:161)
at
org.geotools.coverageio.gdal.BaseGDALGridCoverage2DReader.(BaseGDALGridCoverage2DReader.java:74)
at
org.geotools.coverageio.gdal.vrt.VRTReader.(VRTReader.java:54)
at org.geotools.coverageio.gdal.vrt.VRTTest.test(VRTTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)

While DTEDTest fails with:

Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.049 s <<<
FAILURE! - in org.geotools.coverageio.gdal.dted.DTEDTest
test(org.geotools.coverageio.gdal.dted.DTEDTest)  Time elapsed: 0.047 s
 <<< ERROR!
java.lang.UnsatisfiedLinkError:
org.gdal.gdalconst.gdalconstJNI.OF_MULTIDIM_RASTER_get()I
at org.gdal.gdalconst.gdalconstJNI.OF_MULTIDIM_RASTER_get(Native
Method)
at
org.gdal.gdalconst.gdalconstConstants.(gdalconstConstants.java:101)
at
it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:703)
at javax.imageio.ImageReader.setInput(ImageReader.java:380)
at
org.geotools.coverageio.BaseGridCoverage2DReader.(BaseGridCoverage2DReader.java:161)
at
org.geotools.coverageio.gdal.BaseGDALGridCoverage2DReader.(BaseGDALGridCoverage2DReader.java:74)
at
org.geotools.coverageio.gdal.dted.DTEDReader.(DTEDReader.java:53)
at org.geotools.coverageio.gdal.dted.DTEDTest.test(DTEDTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)

gdal-config --version reports 3.3.2 and I'm running Ubuntu 20.04 LTS.

Can anyone see what might be up?

Ian

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


[Geotools-devel] 27.0 release blog post

2022-05-27 Thread Ian Turton
There is a bare bones draft blog post if people want to add to it at
https://www.blogger.com/blog/post/edit/116830172286767929/6325240602047814947

I'll see if I can flesh it out over the weekend, but if there is anything
you would like to highlight then now is your chance.

Ian

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


Re: [Geotools-devel] 27.0 release artefacts available for testing now

2022-05-19 Thread Ian Turton
I'm seeing the following failures (both in the generated artifacts and on
main) in gt-imageio-ext-gdal:

[ERROR] Errors:
[ERROR]   DTEDTest.test:75 » UnsatisfiedLink 'int
org.gdal.gdalconst.gdalconstJNI.OF_MUL...
[ERROR]   EsriHdrTest.test:89 » NoClassDefFound Could not initialize class
org.gdal.gdal...
[ERROR]   EnviHdrTest.test:85 » NoClassDefFound Could not initialize class
org.gdal.gdal...
[ERROR]   EnviHdrTest.testDimensionNames:194 » NoClassDefFound Could not
initialize clas...
[ERROR]   ErdasImgTest.test:111 » NoClassDefFound Could not initialize
class org.gdal.gd...
[ERROR]   IDRISIImgTest.test:111 » NoClassDefFound Could not initialize
class org.gdal.g...
[ERROR]   RPFTOCTest.test:74 » NoClassDefFound Could not initialize class
org.gdal.gdalc...
[ERROR]   SRPTest.testFile:92->checkSource:114 » NoClassDefFound Could not
initialize cl...
[ERROR]   SRPTest.testPath:98->checkSource:114 » NoClassDefFound Could not
initialize cl...
[ERROR]   VRTTest.test:102 » NoClassDefFound Could not initialize class
org.gdal.gdalcon...
[INFO]
[ERROR] Tests run: 31, Failures: 0, Errors: 10, Skipped: 1
[INFO]

My guess is I don't have the correct version of GDAL now but shouldn't the
tests check for that somehow?

Ian


On Thu, 19 May 2022 at 14:49, Ian Turton  wrote:

> https://build.geoserver.org/view/release/job/geotools-release/63/
>
> Please let me know if there are any issues and then I can pass the baton
> to Jody for the GWC release during his day time and my night time.
>
> Ian
>
> --
> Ian Turton
>


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


[Geotools-devel] 27.0 release artefacts available for testing now

2022-05-19 Thread Ian Turton
https://build.geoserver.org/view/release/job/geotools-release/63/

Please let me know if there are any issues and then I can pass the baton to
Jody for the GWC release during his day time and my night time.

Ian

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


Re: [Geotools-devel] gt-geojsondatastore GeoJSONReader parseFeature does not report actual feature ids?

2022-05-12 Thread Ian Turton
On Thu, 12 May 2022, 17:36 Tobias Gerdin, 
wrote:

> Right, I’ll see if I can come up with that (don’t have a dev environment
> for GeoTools set up yet)
>
>
>
> I also noticed that feature ids do not seem to be returned correctly, i.e.
> mySimpleFeature.getID() always returns “feature.”,
> even though the GeoJSON feature object contains an “id” property. I assume
> this is not by design?
>
>
>
No, that is by design. There is no guarantee that there will be an I'd
attribute for each feature in the schemaless json without reading the whole
file twice. Again if you'd like to add code to take an attribute and use
that as the ID then I'm happy to review it.

Ian

>
> [image: Havochvatten]
>
> *Tobias Gerdin*
>
> Systemutvecklare, Konsult
>
> Enheten för systemutveckling
>
>
>
> *Från:* Ian Turton 
> *Skickat:* den 10 maj 2022 19:58
> *Till:* Tobias Gerdin 
> *Kopia:* Geotools-Devel list 
> *Ämne:* Re: [Geotools-devel] gt-geojsondatastore GeoJSONReader should
> specify encoding as UTF-8?
>
>
>
> I just assumed that everything was going to be utf8. Happy to review a
> pull request with a test.
>
>
>
> Ian
>
>
>
> On Tue, 10 May 2022, 13:41 Tobias Gerdin, 
> wrote:
>
> Hello,
>
>
>
> I was puzzled by the behaviour of org.geotools.data.geojson.GeoJSONReader 
> when I was using it to read a feature collection containing non-ascii 
> strings. It complains that the JSON string contains invalid UTF-8 data.
>
>
>
> Due to client mandate I need to develop on a Windows 11 machine. The
> default platform encoding is windows-1252 (for archeological reasons, I
> guess), not UTF8. I noticed that GeoJSONReader uses plain String.getBytes()
> to read the JSON data (
> https://github.com/geotools/geotools/blob/f416fcc3763b2db020c54a9323601fbdd49388e7/modules/unsupported/geojson-core/src/main/java/org/geotools/data/geojson/GeoJSONReader.java#L179
> <https://url11.mailanyone.net/v1/?m=1noU7V-0005wd-6C=57e1b682=nd0BHN18lI5vvZyhJeZSul8QCsK7EjzqVxFVLS2HSnuWzQCPdExUmmZjNsftJZCHkAw3hTGWYgnnba9mYVF9T5M448udpKgER6NJW5_vcJ_JidCPAKNOxNbTcXoxMOLph80MgSLX4zYdDI2dDTAyWQe8kvVM4seqem0owGeUgtjFOhBMYXOEMCx0TF2tE2MId438iJ0CQM-5D-PsvptlbdX_WOR1OXabMtUzfAlZpiwiD8Q28DHoj52O6Xd7ejb2RGDXkGwTD1OZJL6r7595YAl3MsrjK1v4vBuK_NQ3UCqrbGuoJFYtZOgOEO1oDRDEkjyFsyVvf872aCYSh89sJaV3w191WBq3wmwWO_jqmEdluG5Z3hVXiy9aL7Fxpxa0vsziD2_7TSjc2uvk2kOUVe_Q4WtG8IrXoYa2vfo_CZk>
> ).
>
>
>
> When I change the JVM charset encoding (which needs to be done at startup) 
> using -Dfile.encoding=”UTF-8” my code works, but I rather not have to do 
> this. I am not an expert on JSON but I recall the spec mandates that JSON 
> data is encoded in UTF-8. So I believe that the above linked line should do 
> jsonString.getBytes(StandardCharsets.*UTF_8*) (and in all other locations 
> where JSON data is read).
>
>
>
> Apparently Java is slated to go UTF-8 by default in the future, but until
> then we need to deal with this mess I guess.
>
>
> *Tobias Gerdin*
>
> Systemutvecklare, Konsult
>
> Enheten för systemutveckling
>
>
>
> Gullbergs Strandgata 15, 411 04 Göteborg
>
> Box 11930, SE-404 39 Göteborg
>
> tobias.ger...@havochvatten.se
>
> www.havochvatten.se
>
> Havs- och vattenmyndigheten behandlar dina personuppgifter i enlighet med
> dataskyddsförordningen och myndighetens dataskyddspolicy, läs mer på
> www.havochvatten.se/sa-behandlar-hav-dina-personuppgifter
>
> SwAM processes your personal data in accordance with the General Data
> Protection Regulation (GDPR) and our Data Protection Policy, see
> www.havochvatten.se/sa-behandlar-hav-dina-personuppgifter
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> <https://url11.mailanyone.net/v1/?m=1noU7V-0005wd-6C=57e1b682=eSColVShyw2qqIHmNo0FJvvRFmDXQHdhDf1owtnjIFXQKG7glkWUMrZgvan3f0c4bPu23ihiJwC5ZMsGoyGFBismOfkDR-DkQsgwKVFsYfVq4RHbS6tBLsmqndc6kAzOTS5OEmZKJgFdK-UFwuPilR1H89mjHHbePQ7hfx_mwuUHMk2gclP8D2wI6gBKItdEz8_suRy-IvZcW7G9Qnj06AdYxGUfU0sNWmKZfvqqMcfLtS0qZ6yUEmGt11OtvuCD>
>
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Re: [Geotools-devel] gt-geojsondatastore GeoJSONReader should specify encoding as UTF-8?

2022-05-10 Thread Ian Turton
I just assumed that everything was going to be utf8. Happy to review a pull
request with a test.

Ian

On Tue, 10 May 2022, 13:41 Tobias Gerdin, 
wrote:

> Hello,
>
>
>
> I was puzzled by the behaviour of org.geotools.data.geojson.GeoJSONReader 
> when I was using it to read a feature collection containing non-ascii 
> strings. It complains that the JSON string contains invalid UTF-8 data.
>
>
>
> Due to client mandate I need to develop on a Windows 11 machine. The
> default platform encoding is windows-1252 (for archeological reasons, I
> guess), not UTF8. I noticed that GeoJSONReader uses plain String.getBytes()
> to read the JSON data (
> https://github.com/geotools/geotools/blob/f416fcc3763b2db020c54a9323601fbdd49388e7/modules/unsupported/geojson-core/src/main/java/org/geotools/data/geojson/GeoJSONReader.java#L179
> ).
>
>
>
> When I change the JVM charset encoding (which needs to be done at startup) 
> using -Dfile.encoding=”UTF-8” my code works, but I rather not have to do 
> this. I am not an expert on JSON but I recall the spec mandates that JSON 
> data is encoded in UTF-8. So I believe that the above linked line should do 
> jsonString.getBytes(StandardCharsets.*UTF_8*) (and in all other locations 
> where JSON data is read).
>
>
>
> Apparently Java is slated to go UTF-8 by default in the future, but until
> then we need to deal with this mess I guess.
>
>
> [image: Havochvatten]
>
> *Tobias Gerdin*
>
> Systemutvecklare, Konsult
>
> Enheten för systemutveckling
>
>
>
> Gullbergs Strandgata 15, 411 04 Göteborg
>
> Box 11930, SE-404 39 Göteborg
>
> tobias.ger...@havochvatten.se
>
> www.havochvatten.se
> [image: Havochvatten]
> Havs- och vattenmyndigheten behandlar dina personuppgifter i enlighet med
> dataskyddsförordningen och myndighetens dataskyddspolicy, läs mer på
> www.havochvatten.se/sa-behandlar-hav-dina-personuppgifter
> SwAM processes your personal data in accordance with the General Data
> Protection Regulation (GDPR) and our Data Protection Policy, see
> www.havochvatten.se/sa-behandlar-hav-dina-personuppgifter
> ___
> 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] PostGIS axis order

2022-05-03 Thread Ian Turton
On Tue, 3 May 2022 at 09:07, Andrea Aime 
wrote:

> The report is legit, the CRS attached from a GeoTools out of the box has a
> lat and lon order, while ordinates
> in the database are indeed always stored in lon/lat.
> In GeoServer we never see the issue because we use the sysvar to force the
> lon/lat order system wide.
>

So this only applies to 4326? that may explain why I've never seen it as I
rarely map using that CRS.

Ian


>
> From a practical application point of view using GeoTools, usage might be
> fine due to other bits also using flipped axis
> and seeing no need for reprojection, but I'd guess a stand alone viewer
> reprojecting from 4326 in UTM or web mercator
> might end up showing a flipped map.
>
> There is a very old ticket about it, still open:
> https://osgeo-org.atlassian.net/browse/GEOT-2063
>
> Cheers
> Andrea
>
>
> On Tue, May 3, 2022 at 9:46 AM Ian Turton  wrote:
>
>> I'd always assumed that the order the axes are stored in the database was
>> irrelevant to the end user and the datastore should honour the CRS
>> requested. I've certainly never needed to force an axis order when using
>> PostGIS stores.
>>
>> Do you have a specific case where this isn't working that we can see?
>>
>> Ian
>>
>> On Tue, 3 May 2022 at 05:07, Glenn Walbran via GeoTools-Devel <
>> geotools-devel@lists.sourceforge.net> wrote:
>>
>>> Hello Geotools developers
>>>
>>> I've recently noticed that when reading data from PostGIS with
>>> PostgisNGDataStoreFactory the feature source has a CRS with a YX axis order.
>>>
>>> My understanding is that PostGIS uses an XY axis order.
>>>
>>> This is of course having a bad affect on the location of those features.
>>>
>>> My plan was to override createCRS() in PostGISDialect and call
>>> CRS.decode with forceXY set. This is a simple enough fix but I thought I'd
>>> canvas views from the developer group first. It looks like there would be
>>> quite a bit of churn in the tests go along with this change.
>>>
>>> My assumption is that other users of PostgisNGDataStoreFactory get the
>>> right result by setting the global forceXY properties, but sadly that isn't
>>> an option in my case.
>>>
>>> Regards
>>>
>>> Glenn
>>> --
>>> *Glenn Walbran*
>>> Software Developer
>>>
>>> Catalyst IT - Expert Open Source Solutions
>>> Mob: +64 21 211 1301 | Tel: +64 4 499 2267 | www.catalyst.net.nz
>>>
>>> [image: Catalyst Logo]
>>>
>>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients
>>> only. It may contain privileged, confidential or copyright information. If
>>> you are not the named recipient, any use, reliance upon, disclosure or
>>> copying of this email or its attachments is unauthorised. If you have
>>> received this email in error, please reply via email or call +64 4 499 2267.
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>> Ian Turton
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>


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


Re: [Geotools-devel] PostGIS axis order

2022-05-03 Thread Ian Turton
I'd always assumed that the order the axes are stored in the database was
irrelevant to the end user and the datastore should honour the CRS
requested. I've certainly never needed to force an axis order when using
PostGIS stores.

Do you have a specific case where this isn't working that we can see?

Ian

On Tue, 3 May 2022 at 05:07, Glenn Walbran via GeoTools-Devel <
geotools-devel@lists.sourceforge.net> wrote:

> Hello Geotools developers
>
> I've recently noticed that when reading data from PostGIS with
> PostgisNGDataStoreFactory the feature source has a CRS with a YX axis order.
>
> My understanding is that PostGIS uses an XY axis order.
>
> This is of course having a bad affect on the location of those features.
>
> My plan was to override createCRS() in PostGISDialect and call CRS.decode
> with forceXY set. This is a simple enough fix but I thought I'd canvas
> views from the developer group first. It looks like there would be quite a
> bit of churn in the tests go along with this change.
>
> My assumption is that other users of PostgisNGDataStoreFactory get the
> right result by setting the global forceXY properties, but sadly that isn't
> an option in my case.
>
> Regards
>
> Glenn
> --
> *Glenn Walbran*
> Software Developer
>
> Catalyst IT - Expert Open Source Solutions
> Mob: +64 21 211 1301 | Tel: +64 4 499 2267 | www.catalyst.net.nz
>
> [image: Catalyst Logo]
>
> CONFIDENTIALITY NOTICE: This email is intended for the named recipients
> only. It may contain privileged, confidential or copyright information. If
> you are not the named recipient, any use, reliance upon, disclosure or
> copying of this email or its attachments is unauthorised. If you have
> received this email in error, please reply via email or call +64 4 499 2267.
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] gt-swt issues

2022-04-01 Thread Ian Turton
I don't seem to be an admin on jira and I'm not sure who is.

Does anyone know?

Ian

On Fri, 1 Apr 2022 at 10:35, andrea antonello 
wrote:

> Hello,
> I am refreshing the gt-swt module and browsing through its main issues.
>
> I see there are some that have already been solved and wanted to
> transition them to resolved, but I do not have the permission to do so.
>
> I signed the contributor agreement many years ago, so I wonder if it kind
> of expired.
> I couldn't find anything in the contributor docs to explain that.
>
> Would love for a hint :-)
>
> Thanks,
> Andrea
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] Test failures in ImageMosaic/PostGIS online tests

2022-03-22 Thread Ian Turton
It's an online test, though why only PostGIS triggers it I couldn't say

Ian

On Mon, 21 Mar 2022 at 17:25, Jody Garnett  wrote:

> But .. .why is this only getting the PostGIS online tests?
>
> On Mon, Mar 21, 2022 at 10:15 AM Daniele Romagnoli <
> daniele.romagn...@geosolutionsgroup.com> wrote:
>
>> Hi Ian,
>> I'm currently investigating that.
>> It seems like the Landsat8 S3 free datasets are no longer available or
>> they changed something on their S3 data.
>> https://docs.opendata.aws/landsat-pds/readme.html
>>
>> I'm investigating a Sentinel2 replacement.
>>
>> Regards.
>> Daniele
>>
>>
>>
>>
>>
>> Regards,
>>
>> Daniele Romagnoli
>>
>> ==
>> GeoServer Professional Services from the experts!
>>
>> Visit http://bit.ly/gs-services-us for more information.
>> ==
>>
>> Daniele Romagnoli
>> Senior Software Engineer
>>
>> GeoSolutions Group
>> phone: +39 0584 962313
>> fax:  +39 0584 1660272
>>
>> https://www.geosolutionsgroup.com/
>> http://twitter.com/geosolutions_it
>> ---
>>
>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail.
>>
>>
>> On Mon, Mar 21, 2022 at 6:10 PM Ian Turton  wrote:
>>
>>> I'm seeing the following failures on both GitHub and locally:
>>> https://github.com/geotools/geotools/runs/5606477900?check_suite_focus=true
>>>
>>> Error: Failures:
>>>Error: ImageMosaicCogOnlineTest.testCogMosaicOverview:133
>>>Error: ImageMosaicCogOnlineTest.testFSDateCollect:321
>>> expected:<2019> but was:<2022>
>>>Error: ImageMosaicCogOnlineTest.testHarvestSingleURL:200
>>> expected:<2> but was:<1>
>>> Error: Errors:
>>>Error: ImageMosaicCogOnlineTest.testEmptyMosaic:227 » NullPointer
>>>Error: ImageMosaicCogOnlineTest.testTimeDimensionMosaic:288 »
>>> NullPointer
>>>
>>> Has anyone changed something that might be causing this issue?
>>>
>>> Ian
>>>
>>> --
>>> Ian Turton
>>> ___
>>> 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
>>
> --
> --
> Jody Garnett
>


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


Re: [Geotools-devel] Test failures in ImageMosaic/PostGIS online tests

2022-03-21 Thread Ian Turton
Ok, thanks for the update.

Ian

On Mon, 21 Mar 2022 at 17:14, Daniele Romagnoli <
daniele.romagn...@geosolutionsgroup.com> wrote:

> Hi Ian,
> I'm currently investigating that.
> It seems like the Landsat8 S3 free datasets are no longer available or
> they changed something on their S3 data.
> https://docs.opendata.aws/landsat-pds/readme.html
>
> I'm investigating a Sentinel2 replacement.
>
> Regards.
> Daniele
>
>
>
>
>
> Regards,
>
> Daniele Romagnoli
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions Group
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> https://www.geosolutionsgroup.com/
> http://twitter.com/geosolutions_it
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
> On Mon, Mar 21, 2022 at 6:10 PM Ian Turton  wrote:
>
>> I'm seeing the following failures on both GitHub and locally:
>> https://github.com/geotools/geotools/runs/5606477900?check_suite_focus=true
>>
>> Error: Failures:
>>Error: ImageMosaicCogOnlineTest.testCogMosaicOverview:133
>>Error: ImageMosaicCogOnlineTest.testFSDateCollect:321 expected:<2019>
>> but was:<2022>
>>Error: ImageMosaicCogOnlineTest.testHarvestSingleURL:200 expected:<2>
>> but was:<1>
>> Error: Errors:
>>Error: ImageMosaicCogOnlineTest.testEmptyMosaic:227 » NullPointer
>>Error: ImageMosaicCogOnlineTest.testTimeDimensionMosaic:288 »
>> NullPointer
>>
>> Has anyone changed something that might be causing this issue?
>>
>> Ian
>>
>> --
>> Ian Turton
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>

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


[Geotools-devel] Test failures in ImageMosaic/PostGIS online tests

2022-03-21 Thread Ian Turton
I'm seeing the following failures on both GitHub and locally:
https://github.com/geotools/geotools/runs/5606477900?check_suite_focus=true

Error: Failures:
   Error: ImageMosaicCogOnlineTest.testCogMosaicOverview:133
   Error: ImageMosaicCogOnlineTest.testFSDateCollect:321 expected:<2019>
but was:<2022>
   Error: ImageMosaicCogOnlineTest.testHarvestSingleURL:200 expected:<2>
but was:<1>
Error: Errors:
   Error: ImageMosaicCogOnlineTest.testEmptyMosaic:227 » NullPointer
   Error: ImageMosaicCogOnlineTest.testTimeDimensionMosaic:288 » NullPointer

Has anyone changed something that might be causing this issue?

Ian

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


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

2022-03-19 Thread Ian Turton
+1

Ian

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

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


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


[Geotools-devel] Non English users please test GEOT-7087

2022-03-04 Thread Ian Turton
If you run a computer with a non english locale I would be grateful if you
could test https://github.com/geotools/geotools/pull/3810 for me. The
NumberFormat used to default to English rather than the locale of the
machine and I've changed that, however since my locale is English I can't
be 100% sure it will work for other people.

Cheers
Ian

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


[Geotools-devel] Draft blog post for 25.5 release available

2022-02-19 Thread Ian Turton
If there is anything that you think should be highlighted in this release,
please let me know or edit it directly
https://www.blogger.com/blog/post/edit/116830172286767929/7915724522870083949

Ian

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


[Geotools-devel] Release artefacts for GeoTools 25.5 available for testing

2022-02-18 Thread Ian Turton
https://build.geoserver.org/view/release/job/geotools-release/53/artifact/

Please let me know if there are any issues

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


Re: [Geotools-devel] Request for a gt-cql2-text unsupported module

2022-02-01 Thread Ian Turton
Sounds like a good idea to me. Might be worth raising an issue on
refactoring the package name so we don't forget to fix it at some point.

Ian

On Tue, 1 Feb 2022, 11:51 Andrea Aime,  wrote:

> Hi,
> I have a very narrow opportunity to start implementing a CQL2 parser, but
> need to deliver
> some results in a matter of a few days.
>
> CQL2-text has some significant differences compared to CQL and ECQL, a
> quick check shows:
> - spatial and temporal operator names differ
> - identifiers can have column and period inside without requiring quoting
> (in ECQL period is used to refer to nested properties, we won't be able to
> do that anymore)
> - DATE/TIMESTAMP functions working off a string, rather than the string
> directly (e..g, DATE('2020-10-10'))
> - INTERVAL function for date range construction rather than D1/D2
> - ENVELOPE has same syntax but different axis order, used to be
> west/east/north/south (weird!!) now it's
> - CASEI and ACCENTI are new functions to deal with cases insensitive
> comparison, can be used in text comparisons but also in LIKE (where a fixed
> string used to have to be specified)
>
> Given the (very) tight window my plan is to copy over the ECQL parser and
> adapt it in a gt-cql2-text community module,
> and then make the results available for usage in OGC APIs (STAC in
> particular, at least in the next few days).
>
> Longer term, we might decide to merge gt-cql2-text back into gt-cql, but I
> would not go there until "pens are down" on the
> CQL2 standard (seems like we are close though).
>
> Ah, by the way... I'll have to use a weird package name, because for some
> reason, the implementation of CQL (yes, the original CQL)
> lives in a "org.geotools.filter.text.cql2" package... wow that's quite
> confusing!! Seems like it has been like that since
> before we switched to git... oh well... I'll go for
> "org.geotools.filter.text.cql_2" for the time being, if you have a better
> suggestion I'm all ears.
>
> Cheers
> Andrea
>
> ___
> 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] DOI for the GeoTools project / Springer Handbook of Geoinformatics

2022-01-15 Thread Ian Turton
I think I've solved all the wrinkles and created
https://zenodo.org/record/5854676 which gives our base as
doi://10.5281/zenodo.5854676 - and I've added the .zenodo.json file to the
repository so I think it should get picked up in subsequent releases when I
backport it.

Fetching all the contributors from github was a little weird (I'm not sure
I got the number it showed me) plus some of you don't have names - where I
knew who you worked for I've added affiliations but feel free to edit the
file to add affiliations and orcids (https://orcid.org/) if you have them

Peter, please let me know if I've messed this up somehow?

Ian

On Wed, 12 Jan 2022 at 16:33, Peter Löwe  wrote:

> Dear GeoTools developers,
>
> I'm reaching out to you because of an opportunity for the GeoTools
> community, which surfaced recently:
> The upcoming second edition of the Springer Handbook of Geoinformatics (
> https://link.springer.com/book/10.1007/978-3-540-72680-7) will cover the
> GeoTools project. The Handbook project has been delayed due to the
> Pandemic, but will be completed in a few weeks. I am serving as the editor
> of the Handbook chapter about Open Source Geoinformatics.
>
> Recently, new workflows for scientific citation of software projects have
> emerged and are becoming state of the art. This includes references by
> persistent digital object identifiers (DOI) to software projects instead of
> URLs. DOI-based references allow to give due credit to the whole project
> team, including first authors, developers, but also maintainers and people
> in other roles.
>
> The OSGeo projects GRASS GIS, GMT, MapServer, MOSS and rasdaman have
> already registered their own DOI, OSGeoLive, pygeoapi and pycsw will follow
> soon.
> As an example, this is the DOI for GRASS GIS:
> https://doi.org/10.5281/zenodo.5810537
> Hands on information how to register a DOI for a OSGeo project are
> available here: https://wiki.osgeo.org/wiki/Persistent_identifiers(pid).
>
> The Editors of the Springer Handbook agree that including DOI references
> for Open Source projects is a win-win-scenario for the upcoming book and
> also the OSGeo project communities. They have extended the production
> deadline until January 20 to give additional software projects the
> opportunity to register a DOI to be included in the book chapter.
>
> If the GeoTools project reserves or registers a DOI (takes only a few
> minutes) before the deadline of January 20, I would gladly include it in
> the Open Source Geoinformatics chapter reference section.
>
>
> Please let me know if you have any questions.
>
> Best,
> Peter
>
> 
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] [Geoserver-devel] DOI for the Geoserver project / Springer Handbook of Geoinformatics

2022-01-13 Thread Ian Turton
I think this is useful (maybe because I'm an ex-academic) so I'll go ahead
and register both GeoServer and GeoTools tomorrow.

Ian

On Thu, 13 Jan 2022 at 15:44, Peter Löwe  wrote:

> Hello Brad, all,
>
> unlike a URL, a DOI (
> https://en.wikipedia.org/wiki/Digital_object_identifier) will never break
> (no 404 error ever).
>
> The authors and editors for the Handbook project work without financial
> compensation by Springer and will not benefit from the number of volumes
> sold.
> The Open Source chapter aims to expose audiences, which still might
> believe that only facts are relevant when stated in cost intense non open
> access publications, to open source, open access, and open science.
>
> The Handbook will be around for at least five, maybe ten years. One reason
> for DOI (which will keep pointing to the latest Geoserver release, and
> maybe more up to date content (see #5 below) is to give added value to the
> readers and not to  bog them down with obsolete information.
>
> The Geoserver community can of course register a DOI whenever they agree
> to do so. I just want to make sure that all software projects covered in
> the Open Source chapter can make an informed decision whether they want to
> have their DOI referenced in the Handbook. Otherwise, the project URL will
> be used for reference.
>
> Some reasons for DOI for the Geoserver community are IMHO:
>
>  1) Little effort, no cost and significant benefits for everybody who's
> involved in GeoServer and can use scientific credit for their careers (->
> students, early career scientists, people on tenure track).
>  2) preservation of all code releases in an open access long term
> repository (https://en.wikipedia.org/wiki/Zenodo), free of charge and
> effortless for the project community
>  3) Reference by DOI is the way to go when citing anything with a long
> list of authors/committers: Geoserver has about _547_ committers according
> to GitHub, that's a lot.
>  4) When ORCIDs (https://orcid.org/) for persons serving as developers,
> maintainers, etc. are included into the committer - metadata
> (GitHub-sided), the DOI workflows will pick this up and will add due credit
> by reference to their citation lists.
>  5) DOI can be used to link information. This includes DOI for video
> recordings and presentations. Videos from FOSS4G events can now be linked
> to software project DOI and vice versa (and also linked to ORCIDs of real
> people), like this one: https://doi.org/10.5446/40822 :-)
>
> Does this help ?
>
> Cheers,
> Peter
> https://orcid.org/-0003-2257-0517
>
> 
>
>
> > Gesendet: Donnerstag, 13. Januar 2022 um 04:01 Uhr
> > Von: "Brad Hards" 
> > An: geoserver-de...@lists.sourceforge.net, "Peter Löwe" <
> peter.lo...@gmx.de>
> > Betreff: Re: [Geoserver-devel] DOI for the Geoserver project / Springer
> Handbook of Geoinformatics
> >
> > On Thursday, 13 January 2022 2:26:01 AM AEDT Peter Löwe wrote:
> > > Recently, new workflows for scientific citation of software projects
> have
> > > emerged and are becoming state of the art. This includes references by
> > > persistent digital object identifiers (DOI) to software projects
> instead of
> > > URLs. DOI-based references allow to give due credit to the whole
> project
> > > team, including first authors, developers, but also maintainers and
> people
> > > in other roles.
> > >
> > > The Editors of the Springer Handbook agree that including DOI
> references for
> > > Open Source projects is a win-win-scenario for the upcoming book and
> also
> > > the OSGeo project communities.
> > I'm not sure I understand what the advantage for geoserver is. I get
> that
> > Springer will sell more books. I don't see how having a DOI provides
> credit to
> > developers, maintainers or other people. How does it do that, and how
> does it
> > differ from a URL link in that respect.
> >
> > Can you clarify?
> >
> > Brad
> >
> >
> >
>
>
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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


Re: [Geotools-devel] gitattribute and fixing newline chars

2021-12-18 Thread Ian Turton
+1

Ian

On Sat, 18 Dec 2021 at 08:26, Andrea Aime 
wrote:

> Hi,
> following the last PSC meeting, and after attempting to use spotless,
> I've realized we have a mix of line endings in our git checkouts, mostly
> due to people forgetting to set the autocrlf setting in git.
>
> This pull request tries to fix them, and adds a .gitattributes file that
> should
> avoid having funny line endings in the repo, in the future.
> https://github.com/geotools/geotools/pull/3702
>
> Feedback I'm looking for:
>
>- Are people ok with this?
>- Can anyone on windows/osx try it out and see if anything strange
>happens? (I believe after checkout it out, a "git reset --hard" will be
>needed to fix files newlines
>
> If I don't get negative feedback, I plan to apply the PR to GeoTools and
> the backport on the stable and maintenance branches, and then apply the
> same process to GWC and GS as well.
> I'll do it over the Christmas break, hopefully less people are making
> changes that could be affected by the PRs then.
>
> Cheers
> Andrea
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] Blog post for 25.3 ready for review

2021-10-22 Thread Ian Turton
See
https://www.blogger.com/blog/post/edit/116830172286767929/7670018785860007515

Ian

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


[Geotools-devel] Please test the 25.3 artifacts

2021-10-21 Thread Ian Turton
They are at
https://build.geoserver.org/view/release/job/geotools-release/47/artifact/build/release/distribution/25.3/
- I've tested a quick Java 8 and 11 build and that looks good.

Ian

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


[Geotools-devel] GT 25.3, GS 2.19.3 & GWC1.19.3 releases

2021-10-20 Thread Ian Turton
I plan to kick these releases off tomorrow (I completely forgot last week
:-)) - so if you have any last minute back ports now is a good time to hit
merge.

Ian

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


Re: [Geotools-devel] [Geoserver-devel] Rendering pre process Mark Factories extension point proposal

2021-08-09 Thread Ian Turton
Sounds good to me +1

Ian

On Sun, 8 Aug 2021 at 19:10, Fernando Mino <
fernando.m...@geosolutionsgroup.com> wrote:

> Hi community,
>
> I would like to start a proposal to allow GeoServer and other applications
> using GeoTools to order and filter Mark factories when using render and
> styling.
>
> Since this involves code additions/changes on GeoTools and GeoServer, I
> created a proposal on each side.
>
> GeoTools proposal:
>
> https://github.com/geotools/geotools/wiki/Rendering-pre-process-Mark-Factories-extension-point
>
> GeoServer Proposal:
> https://github.com/geoserver/geoserver/wiki/GSIP-204
>
> Of course, any discussion, feedback or extra clarification request is
> welcome, I expect the proposal contains all the details we need to start
> the idea evolution and brainstorm.
>
> Regards,
>
> Fernando Mino
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
>
> ==
>
> Fernando Mino
>
> Software Engineer
>
> @fmy2kec
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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


Re: [Geotools-devel] Simple patch for mongodb plugin

2021-07-29 Thread Ian Turton
We prefer pull requests (against the main branch) as described here (
https://docs.geotools.org/latest/developer/procedures/pull_requests.html)
and an accompanying issue on the tracker (
https://osgeo-org.atlassian.net/jira/software/c/projects/GEOT/issues/)

Thanks
Ian

On Thu, 29 Jul 2021 at 00:59, Kuntz, Karl A 
wrote:

> Hey all,
>
>
>
> I’m new here.  We’re planning on running GeoServer on top of MongoDB
> Atlas.  We’re successfully doing it with the addition of a patch, attached
> and shown below.  It’s very basic, just adds support for the URI scheme
> that starts with mongodb+srv:// in addition to the mongodb:// prefix.  I’m
> hoping someone with commit access would be willing to add it to main for
> others as well.  I’m happy to write tests for it (probably in
>  MongoSchemaDBStoreTest.java), but didn’t see any tests specifically
> focused on the prefix(s), so I haven’t up to this point.
>
>
>
> Thanks!
>
> -Karl
>
>
>
> diff --git
> a/modules/plugin/mongodb/src/main/java/org/geotools/data/mongodb/MongoDataStore.java
> b/modules/plugin/mongodb/src/main/java/org/geotools/data/mongodb/MongoDataStore.java
>
> index 5c710b4233..299194e5c5 100644
>
> ---
> a/modules/plugin/mongodb/src/main/java/org/geotools/data/mongodb/MongoDataStore.java
>
> +++
> b/modules/plugin/mongodb/src/main/java/org/geotools/data/mongodb/MongoDataStore.java
>
> @@ -185,9 +185,10 @@ public class MongoDataStore extends ContentDataStore {
>
>  if (dataStoreURI == null) {
>
>  throw new IllegalArgumentException("dataStoreURI may not be
> null");
>
>  }
>
> -if (!dataStoreURI.startsWith("mongodb://")) {
>
> +if (!dataStoreURI.startsWith("mongodb://")
>
> + && !dataStoreURI.startsWith("mongodb+srv://")) {
>
>  throw new IllegalArgumentException(
>
> -"incorrect scheme for URI, expected to begin with
> \"mongodb://\", found URI of \""
>
> +"incorrect scheme for URI, expected to begin with
> \"mongodb://\" or \"mongodb+srv://\", found URI of \""
>
>  + dataStoreURI
>
>  + "\"");
>
>  }
>
> @@ -223,7 +224,8 @@ public class MongoDataStore extends ContentDataStore {
>
>  + "\"",
>
>  e);
>
>  }
>
> -} else if (schemaStoreURI.startsWith("mongodb:")) {
>
> +} else if (schemaStoreURI.startsWith("mongodb:")
>
> +    || schemaStoreURI.startsWith("mongodb+srv:")) {
>
>  try {
>
>  return new MongoSchemaDBStore(schemaStoreURI);
>
>  } catch (IOException e) {
>
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] I need an image mosaic expert

2021-07-01 Thread Ian Turton
I'm trying to bump the version of commons-io from 2.6 to 2.10 (or any other
value for now) and all is fine except for
`org.geotools.coverage.io.netcdf.NetCDFMosaicReaderTest.testReHarvest()` on
a Windows machine which fails by not reading the 2 new granules added to
the NC file. I've checked the obvious things like files being held open or
not overwritten etc and it isn't anything obvious that I can see (I'm sure
it will be obvious once someone points it out :-) ). I've compared the log
files of a linux and windows run but nothing jumps out at me.


16c16
< INFO: ACCEPTED: /tmp/junit8062632297122653609/nc_harvest4/
polyphemus_20130301_test.nc
---
> INFO: ACCEPTED:
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\
polyphemus_20130301_test.nc
24c24
< INFO: found /tmp/junit8062632297122653609/nc_harvest4/datastore.properties
---
> INFO: found
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\datastore.properties

the file names are different!

36a37,38
> org.geotools.gce.imagemosaic.Utils loadMosaicProperties
> INFO: Required key Levels not found.

Windows seems to loop through this one more time (I suspect it is just a
timing thing as my windows VM is slower)

38c40
< INFO: found /tmp/junit8062632297122653609/nc_harvest4/datastore.properties
---
> INFO: found
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\datastore.properties
45c47
< target /tmp/junit8062632297122653609/nc_harvest4/
polyphemus_20130301_test.nc
---
> target
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\
polyphemus_20130301_test.nc
47,48c49,50
< /tmp/junit8062632297122653609/nc_harvest4/polyphemus_20130301_test.nc.bak
exists? true
< nc2
/home/ian/code/geotools/modules/plugin/coverage-multidim/netcdf/target/test-classes/org/geotools/coverage/io/netcdf/test-data/
polyphemus_20130301_test_more_times.nc
---
>
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\polyphemus_20130301_test.nc.bak
exists? true
> nc2
X:\geotools\modules\plugin\coverage-multidim\netcdf\target\test-classes\org\geotools\coverage\io\netcdf\test-data\
polyphemus_20130301_test_more_times.nc
51,52d52
< org.geotools.jdbc.JDBCDataStore getSQLTypeNames
< WARNING: Fetching fields from Database

Linux makes an extra (?) call to get the SQLTypeNames

54c54
< INFO: ACCEPTED: /tmp/junit8062632297122653609/nc_harvest4/
polyphemus_20130301_test.nc
---
> INFO: ACCEPTED:
C:\Users\ian\AppData\Local\Temp\junit17289880738954782938\nc_harvest4\
polyphemus_20130301_test.nc

Linux has 4 granules rather than windows 2:

59,60d58
< SimpleFeatureImpl:O3=[SimpleFeatureImpl.Attribute: the_geom=POLYGON ((4.9375 44.96875, 4.9375 50.96875, 14.9375 50.96875,
14.9375 44.96875, 4.9375 44.96875)), SimpleFeatureImpl.Attribute:
location=polyphemus_20130301_test.nc,
SimpleFeatureImpl.Attribute: imageindex=2,
SimpleFeatureImpl.Attribute: time=2013-03-01 02:00:00.0]
< SimpleFeatureImpl:O3=[SimpleFeatureImpl.Attribute: the_geom=POLYGON ((4.9375 44.96875, 4.9375 50.96875, 14.9375 50.96875,
14.9375 44.96875, 4.9375 44.96875)), SimpleFeatureImpl.Attribute:
location=polyphemus_20130301_test.nc,
SimpleFeatureImpl.Attribute: imageindex=3,
SimpleFeatureImpl.Attribute: time=2013-03-01 03:00:00.0]

I've attached the full logs if anyone else wants to look. I'm completely
stumped by this but I don't really understand what the test is doing or
what subtle failures it could have?

Ian
-- 
Ian Turton
org.geotools.gce.imagemosaic.Utils loadMosaicProperties
INFO: Required key Levels not found.
log4j:WARN No appenders could be found for logger (org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
org.geotools.gce.imagemosaic.ImageMosaicEventHandlers fireEvent
INFO: Now indexing file indexer.properties
org.geotools.imageio.netcdf.utilities.NetCDFUtilities 
INFO: Value of Check Coordinate Plugins:null
org.geotools.imageio.netcdf.utilities.NetCDFUtilities 
INFO: Should check for coordinate handler plugins:false
org.geotools.gce.imagemosaic.ImageMosaicEventHandlers fireEvent
INFO: Now indexing file polyphemus_20130301_test.nc
org.geotools.jdbc.JDBCDataStore getSQLTypeNames
WARNING: Fetching fields from Database
org.geotools.coverage.io.netcdf.NetCDFReader 
INFO: ACCEPTED: /tmp/junit8062632297122653609/nc_harvest4/polyphemus_20130301_test.nc
org.geotools.jdbc.JDBCDataStore getSQLTypeNames
WARNING: Fetching fields from Database
org.geotools.gce.imagemosaic.ImageMosaicEventHandlers fireEvent
INFO: Creating final properties file 
org.geotools.gce.imagemosaic.Utils loadMosaicProperties
INFO: Required key Levels not found.
org.geotools.gce.imagemosaic.ImageMosaicReader initReaderFromURL
INFO: found /tmp/junit8062632297122653609/nc_harvest4/datastore.properties
org.geotools.gce.imagemosaic.Utils loadMosaicProperties
INFO: Required key Levels not found.
org.geotools.gce.imagemosaic.ImageMosaicReader initReaderFr

Re: [Geotools-devel] Is there an easy way to choose the transformation used in a coordinate transformation?

2021-06-18 Thread Ian Turton
On Fri, 18 Jun 2021, 16:50 Andrea Aime, 
wrote:

> On Fri, Jun 18, 2021 at 5:44 PM Ian Turton  wrote:
>
>> I've got some code to handle the look up, the hard bit is finding
>> somewhere to test it as I need a EPSG authority to test against so I can
>> put the test in gt-referencing but gt-epsg-hsql has no depedency on gt-main
>> where JTS.transform lives and I can't directly inspect a coordinate
>> transform to see what the parameters are!
>>
>
> But you can test that it's transforming well known points with a given
> accuracy, shouldn't that be enough?
>
> If not, can't you cast the transformation to the expect type, take apart
> the bits of ConcatenatedTransform (it has public fields!)
> until you reach the MolondeskyTransform, gets its parameter group, and
> check they are the expected ones?
> Just thinking out loud, don't know if it's doable.
>

Turns out the real problem is that the latest version of the code or the
database does not include the transform ID while 22.4 did. Not sure why,
will have to continue to search tomorrow.

Ian

>
> 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] Is there an easy way to choose the transformation used in a coordinate transformation?

2021-06-18 Thread Ian Turton
On Fri, 18 Jun 2021 at 15:53, Andrea Aime 
wrote:

> Hi Ian,
> the code can only handle one transformation right now, but I don't think
> it's random, it should
> be picking one with good accuracy and wide area coverage, see the sorting
> here:
>
> https://github.com/geotools/geotools/blob/73051a745a647c134ae7c2be26978e0968bfbb03/modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/DirectEpsgFactory.java#L1542
>
> That makes (some) sense - but I just found this warning (
https://github.com/geotools/geotools/blob/73051a745a647c134ae7c2be26978e0968bfbb03/modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/DirectEpsgFactory.java#L3051
):

* @todo The ordering is not consistent among all database software, because
the "accuracy"
 * column may contains null values. When used in an "ORDER BY"
clause, PostgreSQL put null
 * values last, while Access and HSQL put them first. The
PostgreSQL's behavior is better
 * for what we want (put operations with unknow accuracy last).
Unfortunatly, I don't know
 * yet how to instruct Access to put null values last using
standard SQL ("IIF" is not
 * standard, and Access doesn't seem to understand "CASE ... THEN"
clauses).


There is also some handling of transformations superceding others a few
> lines below.
> That said, there is no way to specify the preferred one in GeoTools,
> indeed. GeoServer has a
> custom config file to force a preferred transformation, Jody referred to
> it in his message,
> code is here:
>
> https://github.com/geoserver/geoserver/blob/9e40cbbccb9626b8d08516c8eacaf5a8f168189b/src/main/src/main/java/org/vfny/geoserver/crs/GeoserverWKTOperationFactory.java#L26
>
>
That requires them to copy the WKT out of the database and maintain it
across versions which seems like a hassle when the data is in there.

I've got some code to handle the look up, the hard bit is finding somewhere
to test it as I need a EPSG authority to test against so I can put the test
in gt-referencing but gt-epsg-hsql has no depedency on gt-main where
JTS.transform lives and I can't directly inspect a coordinate transform to
see what the parameters are!

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


[Geotools-devel] Is there an easy way to choose the transformation used in a coordinate transformation?

2021-06-13 Thread Ian Turton
I'm looking at how to pick out a specific transform for a coordinate
reference system (e.g. https://epsg.io/21036) EPSG:21036 has 4 transforms
defined in the EPSG database and currently GeoTools picks the Kenyan
onshore one (https://epsg.io/21036-1284) presumably because it has the best
accuracy. Now I happen to be looking at data in Tanzania so I would prefer
to pick that transform (https://epsg.io/21036-1285)  - so far as I can see
the only way to do this is to use the WKT and define a new CRS object from
that which is OK but a bit fiddly.

I would prefer to be able to say something like:

CoordinateReferenceSystem arc1960SRS = CRS.decode("EPSG:21036-1285");

>From the look of the code it would involve modifying
org.geotools.referencing.operation.DefaultCoordinateOperationFactory.createOperation(CoordinateReferenceSystem,
CoordinateReferenceSystem) to check for the preferred transform rather than
returning the first one it finds in the database. So would probably need to
make sure that CRS decode found the correct transform and made a note of
that transform for later.

Or am I missing an easier way of doing this and the documentation needs
updating?

Ian

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


Re: [Geotools-devel] PMD complexity checks... "cognitive complexity"

2021-06-12 Thread Ian Turton
On Sat, 12 Jun 2021 at 10:54, Andrea Aime 
wrote:

> Hi all,
> PMD recently released version 6.35, with a new check borrowed from the
> Sonar family called
> "Cognitive complexity".
>
> In short, it's an improvement over cyclomatic complexity that accounts for
> the difficulty in understanding
> code rather than just counting the decision points in a method.
> You can read a short paper about it here:
> https://www.sonarsource.com/docs/CognitiveComplexity.pdf
> (10 pages excluding the appendixes, well worth it IMHO).
>
> I took this new check for a spin... it measures the cognitive complexity
> of methods, with a threshold
> of 15. That's a non-starter, we have way too many methods above that
> threshold.
> I've then tried out 50 and 100, still way too many (oh my gosh!).
>
> Pumping it up to 200 (!!!) provides a list of candidates that seems a bit
> more reasonable to attack.
> For example, gt-main only has two methods above that threshold. Here they
> are (brace for cognitive impact!)
>
>- "Conditionals hurricane with love for chained property calls" in
>DefaultTemporalPrimitive
>
> 
>- "Gonna fit my entire program in a single method" in FilterDOMParser
>
> 
>
>
I think I recognise that method :-) but in my defence I've learned a lot in
the last 20 years!

This is different from considering just method length, for example, some
> time ago Gabriel was proposing
> to look PMD maximum method length check, which flagged only a few methods,
> including "reproject" which
> is a 400 lines long method... but only has a cognitive complexity of
> little above 100, I believe thanks to
> its flatter structure.
>
> So, what do you think? Do you mind having this kind of check as part of
> the ones performed by PMD?
> We can start with a score of 200 and go down little by little, until time
> and interest are exhausted.
>
>
+1

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


Re: [Geotools-devel] Proposing commit rights for Fernando Mino

2021-05-11 Thread Ian Turton
+1

(I thought he already had commit access)

Ian

On Mon, 10 May 2021 at 22:32, Nuno Oliveira 
wrote:

> Dear all,
> Fernando contributed several fixes and new functionalities to GeoTools
> [1], he also acts as one of the module maintainers for App-Schema and
> MongoDB.
>
> What do you think?
>
> Kind regards,
> Nuno Oliveira
>
> [1]
> https://github.com/geotools/geotool/pulls?q=is%3Apr+author%3Afernandor777+is%3Aclosed
>
> --
> Regards,
> Nuno Oliveira
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
>
> Nuno Miguel Carvalho Oliveira
> @nmcoliveira
> Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati
> personali (Reg. UE 2016/679 - Regolamento generale sulla
> protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto,
> gli eventuali allegati, etc.) è un dato la cui conoscenza
> è riservata al/i solo/i destinatario/i indicati dallo
> scrivente. Se il messaggio Le è giunto per errore, è
> tenuta/o a cancellarlo, ogni altra operazione è illecita.
> Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to
> which it is addressed and may contain information that
> is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European
> Regulation 2016/679 “GDPR” - copying, dissemination or
> use of this e-mail or the information herein by anyone
> other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify
> us immediately by telephone or e-mail.
> _______
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] Maven repo caching does not seem to be hitting often: are we playing with too many caches?

2021-05-03 Thread Ian Turton
On Mon, 3 May 2021 at 10:09, Andrea Aime 
wrote:

> Hi,
> I was looking at GitHub action checks, that often fail on network
> transfers related to Maven repo.
> One thing that caught my eye is that I keep on see messages like:
>
> Cache not found for input keys:
> Windows-maven-74f70cf8a20d59d956161298093365c04c4b0a04756953eb29b4484f007f9432,
> Windows-maven-.
> Cache not found for input keys:
> oracle-Linux-maven-5a57ae570a1ce6d4a0c33eee5d829ff7cc2577cc9c15722a328d339e4c6fa082,
> oracle-Linux-maven-
>
> Thing is, these builds that I pulled from did not change the pom files, so
> the hash should not have changed... and a cache
> should have been found. There are builds that have a cache hit, but seem
> to be few.
>
> Looking at the documentation for the cache action, there is a limit of 5GB
> per repository:
> https://github.com/actions/cache#cache-limits
>
> Looking at the workflows, maybe we are using too many cache keys, and
> getting close to the cache limits:
>
> > cat *.yml | grep key | grep runner | sort | uniq
> key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
> key: geopkg-${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
> key: integration-${{ runner.os }}-maven-${{
> hashFiles('**/pom.xml') }}
> key: mssql-${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
> key: oracle-${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
> key: postgis-${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
>
> That's 6 unique keys, plus osx and windows being two different operating
> systems, that's 8 separate caches... per branch!
> Yes, because different branches lead to different pom hash, at least due
> to the different version names in the pom files.
> Those 5GB should thus be split into 24 different caches, leaving 200MB for
> each.
>
> Any objection to removing all the prefixes from the database QA builds?
> That should reduce the cache count significantly.
> It's true that this could cause a cache to start small, due to a database
> build not hitting all modules, but in a few rounds
> of builds it should grow to handle everything (it's not like we change the
> pom files every other day).
>

That sounds fine to me

>
> Another angle to look at this would be, do we really need per OS caches?
> Again, I don't think we need OS specific
> caches, do we?
>

I can't think of any reason to have an OS specific cache.

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


Re: [Geotools-devel] early backport of GEOT-6874 Add support for count distinct aggregations in gt-jdbc

2021-04-29 Thread Ian Turton
+1

Ian

On Wed, 28 Apr 2021 at 16:15, Marco Volpini 
wrote:

> Dear all,
> I'm writing to ask permission for early backport of GEOT-6874 Add support
> for count distinct aggregations in gt-jdbc.
> The new functionalities create a new FeatureVisitor to have an
> optimization path for count distinct queries on JDBCDataStore.
> No backward compatibility issue is foreseen. Details on the Jira ticket
> https://osgeo-org.atlassian.net/browse/GEOT-6874.
> Best regards,
> Marco Volpini
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] Release artefacts for 24.3 are ready to test

2021-04-20 Thread Ian Turton
https://build.geoserver.org/view/release/job/geotools-release/26/artifact/

let me know if you see any issues

Ian

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


Re: [Geotools-devel] PMC Meeting Time Change

2021-03-17 Thread Ian Turton
+0 for me (17:30 local time continues to be a problem for me as it clashes
with making dinner)

Ian

On Tue, 16 Mar 2021 at 18:39, Torben Barsballe 
wrote:

> In today's PMC meeting, we proposed moving the PMC meeting time back one
> hour (To 16:30 UTC) starting with next meeting, to match up with the Europe
> DST change on March 28 (as we usually do this time of year).
>
>
> We've got 4 votes so far:
>
> Andrea: +1
>
> Torben: +1
>
> Kevin: +1
>
> Jody +1
>
>
> If you have any objection to this change, please respond. Otherwise, a +1
> would be appreciated.
>
>
> Cheers,
>
> Torben
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] Jenkins failures in main

2021-03-08 Thread Ian Turton
I'm seeing apparently random failures on Jenkins

First it was a problem in gt-imagemosaic:

[INFO] Running org.geotools.geopkg.GeoPkgSchemaTest
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
25.592 s <<< FAILURE! - in
org.geotools.gce.imagemosaic.ImageMosaicReaderTest
[ERROR]
testConcurrentHarvestAndRemoveH2(org.geotools.gce.imagemosaic.ImageMosaicReaderTest)
 Time elapsed: 4.027 s  <<< FAILURE!
java.lang.AssertionError: Terminating test due to previus failures
at
org.geotools.gce.imagemosaic.ImageMosaicReaderTest.checkConcurrentHarvestAndRemove(ImageMosaicReaderTest.java:5562)
at
org.geotools.gce.imagemosaic.ImageMosaicReaderTest.testConcurrentHarvestAndRemoveH2(ImageMosaicReaderTest.java:5449)

So I restarted and then got a problem in jdbc-h2:

[INFO] Running org.geotools.data.h2.H2DataStoreFactoryTest
[ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.15 s <<< FAILURE! - in org.geotools.data.h2.H2DataStoreFactoryTest
[ERROR] testTCP(org.geotools.data.h2.H2DataStoreFactoryTest)  Time elapsed:
0.123 s  <<< FAILURE!
java.lang.AssertionError: Should not have made a connection.
at
org.geotools.data.h2.H2DataStoreFactoryTest.testTCP(H2DataStoreFactoryTest.java:109)

Neither of the problems are related to the actual code changes that have
gone in recently, that I can see.

Anyone else got an idea as to what's going on?

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


Re: [Geotools-devel] rename master to main

2021-03-02 Thread Ian Turton
If we do one, then we should definitely do all three.

Ian

On Tue, 2 Mar 2021, 17:45 Jody Garnett,  wrote:

> In today's meeting geoServer is renaming master to main branch.
>
> I would like to do the same for geotools also.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


[Geotools-devel] Should we install a CLA bot to help manage CLAs in PRs?

2021-01-16 Thread Ian Turton
I noticed GeoNode runs a CLA Bot that automatically checks if people
providing PRs have signed the CLA, is it worth us trying something like it?
Other than keeping the list of signers uptodate it doesn't look too
burdensome.

See https://github.com/apps/cla-bot for more info

Ian

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


Re: [Geotools-devel] GeoTiffReader / Writer different bounds

2021-01-08 Thread Ian Turton
On Thu, 7 Jan 2021 at 18:54, Lorenzo Di Giacomo  wrote:

> Thanks Ian, yeah i removed the print on the awt rectangles that i get
> from ( getGridGeometry().getGridRange2D().getBounds() ).
> Also, that difference is visible in plannarImage.
> I was wondering if that difference in data after serialization /
> deserialization is "normal" and could affect the writing operation.
> Because basically what happens is:
> 1) Read an image in GridCoverage2D
> 2) Cut in N parts using Crop operation ( getting N GridCoverage2D )
> 3) Serialize each part and send it
> 4) Deserialize each part
> 5) Merge them back (with the result of 1 GridCoverage2D)
> 6) Write the GridCoverage2D in file.tiff
>
> Now all this works just fine and is also really fast even with a lot
> of cuts, since i merge them back in multithreading using the MapReduce
> paradigm with ForkJoin.
> But ... When there are few cuts (< 200/300) it's fine, but with 2000
> cuts, for examples, it's stuck on writing.
> Doing the steps above (without points 3,4) write the file well. So i
> was wondering if it could be that difference on X and Y, if it could
> affect the write operation.
> I also tried on a powerful server ( octa-core and 24gb RAM ), thinking
> could be of a memory issue, but i get the same result.
> Thanks for your suggestions!
>

I think this makes sense, when you have a subset of a larger image the
gridGeometry "knows" it position relative to the origin of the full image,
but when you read it back in it has no larger context so it's origin has to
be 0,0 - I think the solution is to make the merge in geographic space not
pixel space or encode the pixel image origin in with the image data.

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


Re: [Geotools-devel] GeoTiffReader / Writer different bounds

2021-01-07 Thread Ian Turton
and now without a zip file!

Ian

On Thu, 7 Jan 2021 at 17:05, Ian Turton  wrote:

> and here are my input png files (you'll need to add gt-image to read them)
>
> Ian
>
> On Thu, 7 Jan 2021 at 17:02, Ian Turton  wrote:
>
>> It seems odd that you are dealing with java.awt.Rectangles - I'm not sure
>> where you are getting them from as there is no mention in the code. I
>> modified your code to this:
>>
>> public static void main(String[] args) throws IOException {
>> File input = new 
>> File("/home/ian/code/geotools-cookbook/code/modules/spike/test.png");
>> AbstractGridFormat format = GridFormatFinder.findFormat(input);
>> Hints hints = null;
>> if (format instanceof GeoTiffFormat) {
>> hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, 
>> Boolean.TRUE);
>> }
>> AbstractGridCoverage2DReader reader = format.getReader(input, hints);
>> GridCoverage2D grid = reader.read(null);
>> System.out.println( grid.getEnvelope2D());
>> System.out.println( grid.getEnvelope());
>> reader.dispose();
>> ByteArrayOutputStream baos = new ByteArrayOutputStream();
>> GeoTiffWriter writer = new GeoTiffWriter(baos, null);
>> GeoTiffWriteParams wp = new GeoTiffWriteParams();
>> 
>> //wp.setSourceRegion(grid.getGridGeometry().getGridRange2D().getBounds());
>> final ParameterValueGroup params = new 
>> GeoTiffFormat().getWriteParameters();
>> 
>> params.parameter(AbstractGridFormat.GEOTOOLS_WRITE_PARAMS.getName().toString()).setValue(wp);
>> writer.write(grid, null/*params.values().toArray(new 
>> GeneralParameterValue[1])*/);
>> writer.dispose();
>> byte[] bytes = baos.toByteArray();
>>
>> //Deserialization:
>>
>> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
>> GeoTiffReader reader2 = null;
>> hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.TRUE);
>> reader2 = new GeoTiffReader(bais, hints);
>> GridCoverage2D coverage = reader2.read(null);
>> bais.close();
>> System.out.println( coverage.getEnvelope2D());
>> System.out.println( coverage.getEnvelope());
>> }
>>
>>
>> which gives me
>>
>> Envelope2D[(833207.8127810268, 9785025.96070077), (833286.9776217749, 
>> 9785090.075567605)]
>> GeneralEnvelope[(833207.8127810268, 9785025.96070077), (833286.9776217749, 
>> 9785090.075567605)]
>>
>> Envelope2D[(833207.8127810268, 9785025.96070077), (833286.9776217749, 
>> 9785090.075567605)]
>> GeneralEnvelope[(833207.8127810268, 9785025.96070077), (833286.9776217749, 
>> 9785090.075567605)]
>>
>> Where the bounds of the output and input grid match exactly.
>>
>> Ian
>>
>> On Thu, 7 Jan 2021 at 16:28, Lorenzo Di Giacomo 
>> wrote:
>>
>>> Both X and Y are set to 0, in every GridCoverage2D deserialized.
>>> I think that maybe some READ_GRIDCOVERAGE2D parameters are needed (?)
>>> Original: java.awt.Rectangle[x=209,y=333,width=334,height=148]
>>> After serialization / deserialization:
>>> java.awt.Rectangle[x=0,y=0,width=334,height=148]
>>>
>>> Serialization:
>>>
>>> ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> GeoTiffWriter writer = new GeoTiffWriter(baos, null);
>>> GeoTiffWriteParams wp = new GeoTiffWriteParams();
>>> wp.setSourceRegion(grid.getGridGeometry().getGridRange2D().getBounds());
>>> final ParameterValueGroup params = new
>>> GeoTiffFormat().getWriteParameters();
>>>
>>> params.parameter(AbstractGridFormat.GEOTOOLS_WRITE_PARAMS.getName().toString()).setValue(wp);
>>> writer.write(grid, params.values().toArray(new
>>> GeneralParameterValue[1]));
>>> writer.dispose();
>>> byte[] bytes = baos.toByteArray();
>>>
>>> Deserialization:
>>>
>>> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
>>> GeoTiffReader reader = null;
>>> Hints hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER,
>>> Boolean.TRUE);
>>> reader = new GeoTiffReader(bais, hints);
>>> GridCoverage2D grid = reader.read(null);
>>> bais.close();
>>> return grid;
>>>
>>> Il giorno gio 7 gen 2021 alle ore 15:06 Ian Turton
>>>  ha scritto:
>>> >
>>> > How different are we talking about here? You'll probably need to share
>>> some code and example data to allow anyone to look into this.
>>> >
>>> >
>>> > Ian
>

Re: [Geotools-devel] GeoTiffReader / Writer different bounds

2021-01-07 Thread Ian Turton
It seems odd that you are dealing with java.awt.Rectangles - I'm not sure
where you are getting them from as there is no mention in the code. I
modified your code to this:

public static void main(String[] args) throws IOException {
File input = new
File("/home/ian/code/geotools-cookbook/code/modules/spike/test.png");
AbstractGridFormat format = GridFormatFinder.findFormat(input);
Hints hints = null;
if (format instanceof GeoTiffFormat) {
hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.TRUE);
}
AbstractGridCoverage2DReader reader = format.getReader(input, hints);
GridCoverage2D grid = reader.read(null);
System.out.println( grid.getEnvelope2D());
System.out.println( grid.getEnvelope());
reader.dispose();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
GeoTiffWriter writer = new GeoTiffWriter(baos, null);
GeoTiffWriteParams wp = new GeoTiffWriteParams();
//wp.setSourceRegion(grid.getGridGeometry().getGridRange2D().getBounds());
final ParameterValueGroup params = new GeoTiffFormat().getWriteParameters();

params.parameter(AbstractGridFormat.GEOTOOLS_WRITE_PARAMS.getName().toString()).setValue(wp);
writer.write(grid, null/*params.values().toArray(new
GeneralParameterValue[1])*/);
writer.dispose();
byte[] bytes = baos.toByteArray();

//Deserialization:

ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
GeoTiffReader reader2 = null;
hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.TRUE);
reader2 = new GeoTiffReader(bais, hints);
GridCoverage2D coverage = reader2.read(null);
bais.close();
System.out.println( coverage.getEnvelope2D());
System.out.println( coverage.getEnvelope());
}


which gives me

Envelope2D[(833207.8127810268, 9785025.96070077), (833286.9776217749,
9785090.075567605)]
GeneralEnvelope[(833207.8127810268, 9785025.96070077),
(833286.9776217749, 9785090.075567605)]

Envelope2D[(833207.8127810268, 9785025.96070077), (833286.9776217749,
9785090.075567605)]
GeneralEnvelope[(833207.8127810268, 9785025.96070077),
(833286.9776217749, 9785090.075567605)]

Where the bounds of the output and input grid match exactly.

Ian

On Thu, 7 Jan 2021 at 16:28, Lorenzo Di Giacomo  wrote:

> Both X and Y are set to 0, in every GridCoverage2D deserialized.
> I think that maybe some READ_GRIDCOVERAGE2D parameters are needed (?)
> Original: java.awt.Rectangle[x=209,y=333,width=334,height=148]
> After serialization / deserialization:
> java.awt.Rectangle[x=0,y=0,width=334,height=148]
>
> Serialization:
>
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> GeoTiffWriter writer = new GeoTiffWriter(baos, null);
> GeoTiffWriteParams wp = new GeoTiffWriteParams();
> wp.setSourceRegion(grid.getGridGeometry().getGridRange2D().getBounds());
> final ParameterValueGroup params = new
> GeoTiffFormat().getWriteParameters();
>
> params.parameter(AbstractGridFormat.GEOTOOLS_WRITE_PARAMS.getName().toString()).setValue(wp);
> writer.write(grid, params.values().toArray(new GeneralParameterValue[1]));
> writer.dispose();
> byte[] bytes = baos.toByteArray();
>
> Deserialization:
>
> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
> GeoTiffReader reader = null;
> Hints hints = new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER,
> Boolean.TRUE);
> reader = new GeoTiffReader(bais, hints);
> GridCoverage2D grid = reader.read(null);
> bais.close();
> return grid;
>
> Il giorno gio 7 gen 2021 alle ore 15:06 Ian Turton
>  ha scritto:
> >
> > How different are we talking about here? You'll probably need to share
> some code and example data to allow anyone to look into this.
> >
> >
> > Ian
> >
> > On Thu, 7 Jan 2021 at 11:58, Lorenzo Di Giacomo 
> wrote:
> >>
> >> Hello, i'm try to serialize a GridCoverage2D using GeoTiffWriter
> >> writing in a ByteArrayOutputStream and deserializing using
> >> GeoTiffReader from the ByteArrayInputStream... The problem is that the
> >> Bounds (Rectangle object) of the deserialized GridCoverage2D has
> >> different X,Y then the original (the width and height are the same)
> >> ... I also tried to use GeoTiffWriteParams setSourceRegion method but
> >> nothing. Do you know if that's a problem or some other params must be
> >> set in order to have the same bounds from the 2 grid? Thanks again!!
> >>
> >>
> >> ___
> >> GeoTools-Devel mailing list
> >> GeoTools-Devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
> >
> >
> > --
> > Ian Turton
>


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


Re: [Geotools-devel] GeoTiffReader / Writer different bounds

2021-01-07 Thread Ian Turton
How different are we talking about here? You'll probably need to share some
code and example data to allow anyone to look into this.


Ian

On Thu, 7 Jan 2021 at 11:58, Lorenzo Di Giacomo  wrote:

> Hello, i'm try to serialize a GridCoverage2D using GeoTiffWriter
> writing in a ByteArrayOutputStream and deserializing using
> GeoTiffReader from the ByteArrayInputStream... The problem is that the
> Bounds (Rectangle object) of the deserialized GridCoverage2D has
> different X,Y then the original (the width and height are the same)
> ... I also tried to use GeoTiffWriteParams setSourceRegion method but
> nothing. Do you know if that's a problem or some other params must be
> set in order to have the same bounds from the 2 grid? Thanks again!!
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] GeoTools 23.4 release artifacts available for testing

2020-12-18 Thread Ian Turton
https://build.geoserver.org/view/release/job/geotools-release/21/artifact/

If windows and mac users especially can test that would be great.

Cheers

Ian

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


[Geotools-devel] Reminder release tomorrow

2020-12-17 Thread Ian Turton
If you have changes that you would like in GeoTools 23.4, GeoServer 2.17.4
or GeoWebCache 1.17.4 releases please make sure that they are merged today
as tomorrow (18th Dec) Jody and I will be making what is probably the final
release of those branches.

Ian

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


Re: [Geotools-devel] Wrong e-mail address in pom.xml

2020-12-09 Thread Ian Turton
I'm not sure that that list is for anything except historical interest. I
occasionally update my organisation if I happen to be in there making other
changes. From a quick scan it seems that many of the entries are old (in
some cases very old) and the PMC membership list is also very out of date.

In general asking on this list is preferable to contacting module
maintainers directly.

Ian

On Wed, 9 Dec 2020 at 07:44, Roar Brænden  wrote:

> Hi,
>
> I was asked to contact the maintainers of certain libraries of Geotools.
> When doing so I discovered one e-mail address being out of use (
> gda...@refractions.net). How should that be reported? As an issue in Jira?
>
> Another question that arose when looking at the POM is the use of
> x under the . Are there a  register for these, or
> is it up to each and everyone to choose an id. I see that some are using
> this id for @author in comments. Is this a wanted practice in Geotools?
>
> Kind regards,
>
> Roar Brænden
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


[Geotools-devel] Looks like there are some issues on the new github builds

2020-11-29 Thread Ian Turton
I'm seeing failures on both linux builds
https://github.com/geotools/geotools/pull/3251 neither of which have
anything to do with the change (which is unsupported so is probably not
tested in anyway)

JDK-8 issue:

Error: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
(default-compile) on project gt-sample-data: Execution default-compile of
goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
Plugin org.apache.maven.plugins:maven-compiler-plugin:3.8.0 or one of its
dependencies could not be resolved: Could not transfer artifact
org.codehaus.plexus:plexus-java:jar:0.9.10 from/to central (
https://repo.maven.apache.org/maven2): Transfer failed for
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.10/plexus-java-0.9.10.jar:
Connection reset -> [Help 1]
2059Error: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
(default-compile) on project gt-opengis: Execution default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: Plugin
org.apache.maven.plugins:maven-compiler-plugin:3.8.0 or one of its
dependencies could not be resolved: Failure to transfer
org.codehaus.plexus:plexus-java:jar:0.9.10 from
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced. Original error: Could not transfer artifact
org.codehaus.plexus:plexus-java:jar:0.9.10 from/to central (
https://repo.maven.apache.org/maven2): Transfer failed for
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-java/0.9.10/plexus-java-0.9.10.jar
-> [Help 1]

JDK-11 is something to do with gt-jdbc-h2 but I can't see the actual
problem in the log

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


Re: [Geotools-devel] [Geowebcache-devel] Volunteers for GeoTools 23.4, GeoWebCache 1.17.4 and GeoServer 2.17.4 need (December 18th)

2020-11-27 Thread Ian Turton
On Fri, 27 Nov 2020 at 09:39, Andrea Aime 
wrote:

> Hi all,
> we are looking for a volunteer to cut the above releases . Any takers?
>

I can do that if someone can help me with the GWC release.

BTW how much work would it be to make the GWC release work like the others?

Ian


>
> 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.*
> ___
> Geowebcache-devel mailing list
> geowebcache-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geowebcache-devel
>


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


Re: [Geotools-devel] Starting the Release for GeoServer 2.18.1 / GeoTools 24.1

2020-11-20 Thread Ian Turton
2020-11-20 17:13:04,434 WARN [linux.LinuxFileSystem] - Failed to get
information to use statvfs. path: /media/ian/windows10vm, Error code: 13

looks like OSHI so we should be able to just ignore it in the properties
files I guess

Ian

On Fri, 20 Nov 2020 at 16:49, Andrea Aime 
wrote:

> Anyone knows if the logging happens at GeoServer level, or inside OSHI?
>
> Cheers
> Andrea
>
> On Fri, Nov 20, 2020 at 5:47 PM Ian Turton  wrote:
>
>> It's the disk with my windows VM on it but I'm running on Linux. So I
>> suspect it is correct it can't fstat it but it doesn't need to log the fact
>> 40+ times
>>
>> Ian
>>
>> On Fri, 20 Nov 2020 at 16:22, Mark Prins  wrote:
>>
>>> On 20-11-2020 15:30, Ian Turton wrote:
>>> > I'm seeing a lot of warnings about "2020-11-20 14:27:16,927 WARN
>>> > [linux.LinuxFileSystem] - Failed to get information to use statvfs.
>>> > path: /media/ian/windows10vm, Error code: 13" when looking at the
>>> system
>>> > status pages but nothing else obviously wrong.
>>>
>>> is it detecting the OS properly? (just because I'm seeing "windows10vm"
>>> there, but it's using statvfs... )
>>>
>>> I think errno 13 means "Permission denied"
>>>
>>> -M
>>>
>>>
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>> --
>> Ian Turton
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards, Andrea Aime
>
> == GeoServer Professional Services from the experts! Visit
> http://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.*
>


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


Re: [Geotools-devel] Starting the Release for GeoServer 2.18.1 / GeoTools 24.1

2020-11-20 Thread Ian Turton
It's the disk with my windows VM on it but I'm running on Linux. So I
suspect it is correct it can't fstat it but it doesn't need to log the fact
40+ times

Ian

On Fri, 20 Nov 2020 at 16:22, Mark Prins  wrote:

> On 20-11-2020 15:30, Ian Turton wrote:
> > I'm seeing a lot of warnings about "2020-11-20 14:27:16,927 WARN
> > [linux.LinuxFileSystem] - Failed to get information to use statvfs.
> > path: /media/ian/windows10vm, Error code: 13" when looking at the system
> > status pages but nothing else obviously wrong.
>
> is it detecting the OS properly? (just because I'm seeing "windows10vm"
> there, but it's using statvfs... )
>
> I think errno 13 means "Permission denied"
>
> -M
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] [Geoserver-devel] Starting the Release for GeoServer 2.18.1 / GeoTools 24.1

2020-11-20 Thread Ian Turton
sandro.pa...@geo-solutions.it> wrote:
>
> Hi All,
>
>
>
> Just to let you know that I'm starting the release procedure for
>
> - GeoServer 2.18.1
>
> - GeoWebCache 1.18.1
>
> - GeoTools 24.1
>
>
>
> I'll keep you posted on the progress
>
> --
>
> Regards,
>
> Alessandro Parma
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Alessandro Parma
> DevOps Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
>
> *Con riferimento alla normativa sul trattamento dei dati personali (Reg.
> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.*
>
>
>
>
> --
>
> Regards,
>
> Alessandro Parma
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Alessandro Parma
> DevOps Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
>
> *Con riferimento alla normativa sul trattamento dei dati personali (Reg.
> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.*
>
>
>
>
> --
>
> 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.*
> ___
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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


Re: [Geotools-devel] Starting the Release for GeoServer 2.18.1 / GeoTools 24.1

2020-11-20 Thread Ian Turton
lla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail.
>>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] Build failed in Jenkins: geoserver-2.18.x-java11 #39

2020-11-09 Thread Ian Turton
Yes, it does but that just means it received an error message (as XML)
instead of some data as (GML)

Ian

On Mon, 9 Nov 2020 at 14:17, Uhrig, Stefan  wrote:

> Doesn’t it say comparison failure?
>
>
>
> org.junit.ComparisonFailure: expected: but
> was:
>
>
>
>
>
> *From:* Ian Turton 
> *Sent:* Monday, November 9, 2020 3:13 PM
> *To:* Geotools-Devel list 
> *Cc:* geoserver-bui...@lists.sourceforge.net
> *Subject:* Re: [Geotools-devel] Build failed in Jenkins:
> geoserver-2.18.x-java11 #39
>
>
>
> Looking further it's throwing an error on what looks like a timing error?
>
>
>
> [INFO] Running org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest
>
> org.geoserver.platform.ServiceException: Failed to run GetFeatureInfo on 
> layer sf:TimeElevationStacked
>
> at org.geoserver.wms.GetFeatureInfo.execute(GetFeatureInfo.java:88)
>
> at org.geoserver.wms.GetFeatureInfo.run(GetFeatureInfo.java:38)
>
> at 
> org.geoserver.wms.DefaultWebMapService.getFeatureInfo(DefaultWebMapService.java:260)
>
> at jdk.internal.reflect.GeneratedMethodAccessor661.invoke(Unknown 
> Source)
>
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>
> at 
> org.geoserver.ows.util.RequestObjectLogger.invoke(RequestObjectLogger.java:28)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
>
> at com.sun.proxy.$Proxy60.getFeatureInfo(Unknown Source)
>
> at jdk.internal.reflect.GeneratedMethodAccessor660.invoke(Unknown 
> Source)
>
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>
> at org.geoserver.ows.Dispatcher.execute(Dispatcher.java:877)
>
> at 
> org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:265)
>
> at 
> org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:177)
>
> at 
> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:52)
>
> at 
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1040)
>
> at 
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
>
> at 
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
>
> at 
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>
> at 
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
>
> at 
> org.geoserver.test.GeoServerSystemTestSupport$2.service(GeoServerSystemTestSupport.java:1633)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
>
> at 
> org.springframework.mock.web.MockFilterChain$ServletFilterProxy.doFilter(MockFilterChain.java:167)
>
> at 
> org.springframework.mock.web.MockFilterChain.doFilter(MockFilterChain.java:134)
>
> at 
> org.geoserver.test.GeoServerSystemTestSupport.dispatch(GeoServerSystemTestSupport.java:1662)
>
> at 
> org.geoserver.test.GeoServerSystemTestSupport.dispatch(GeoServerSystemTestSupport.java:1575)
>
> at 
> org.geoserver.test.GeoServerSystemTestSupport.getAsServletResponse(GeoServerSystemTestSupport.java:1041)
>
> at 
> org.geoserver.test.GeoServerSystemTestSupport.getAsServletResponse(GeoServerSystemTestSupport.java:1024)
>
> at 
> org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.getFeatureAt(DimensionsVectorGetFeatureInfoTest.java:79)
>
> at 
> org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.testSortTimeElevationDescending(DimensionsVect

Re: [Geotools-devel] Build failed in Jenkins: geoserver-2.18.x-java11 #39

2020-11-09 Thread Ian Turton
)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.IllegalStateException: [] are layers that started
rendering but have not completed, stop() or endLayer() must be called
before clear is called
at 
org.geotools.renderer.label.LabelCacheImpl.clear(LabelCacheImpl.java:221)
at 
org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:959)
at 
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:587)
at 
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:261)
at 
org.geoserver.wms.map.RenderedImageMapOutputFormat.produceMap(RenderedImageMapOutputFormat.java:127)
at 
org.geoserver.wms.featureinfo.VectorRenderingLayerIdentifier.identify(VectorRenderingLayerIdentifier.java:219)
at org.geoserver.wms.GetFeatureInfo.execute(GetFeatureInfo.java:73)
... 66 more
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
11.972 s - in org.geoserver.security.jdbc.H2JNDIRoleServiceTest
[INFO] Running org.geoserver.security.jdbc.H2JNDIUserDetailsServiceTest[ERROR]
Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.542
s <<< FAILURE! - in
org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest[ERROR]
testSortTimeElevationDescending(org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest)
 Time elapsed: 0.722 s  <<< FAILURE!org.junit.ComparisonFailure:
expected: but
was:
at 
org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.getFeatureAt(DimensionsVectorGetFeatureInfoTest.java:85)
at 
org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.testSortTimeElevationDescending(DimensionsVectorGetFeatureInfoTest.java:467)


While the next run failed in rest-config


09 Nov 11:10:09 WARN [core.DefaultDirectoryService] - ApacheDS
shutdown hook has NOT been registered with the runtime.  This default
setting for standalone operation has been overriden.[ERROR] Tests run:
2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.699 s <<<
FAILURE! - in org.geoserver.rest.security.UserRoleRestControllerTest[ERROR]
testRolesAndUsers(org.geoserver.rest.security.UserRoleRestControllerTest)
 Time elapsed: 6.261 s  <<<
ERROR!java.util.ConcurrentModificationException
at 
org.geoserver.rest.security.UserRoleRestControllerTest.testRolesAndUsers(UserRoleRestControllerTest.java:85)


I've kicked off another run to see what is happening


Ian


On Mon, 9 Nov 2020 at 14:07, Ian Turton  wrote:

> This is caused by
>
> [ERROR] 
> testSortTimeElevationDescending(org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest)
>   Time elapsed: 0.722 s  <<< FAILURE!org.junit.ComparisonFailure: 
> expected: but was:
>   at 
> org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.getFeatureAt(DimensionsVectorGetFeatureInfoTest.java:85)
>   at 
> org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.testSortTimeElevationDescending(DimensionsVectorGetFeatureInfoTest.java:467)
>
>
> which is a bit odd as I didn't change anything near there (I think) and
> travis was happy.
>
> Any one know what's happening here?
>
> On Mon, 9 Nov 2020 at 11:51, Jenkins  wrote:
>
>> See <
>> https://build.geoserver.org/job/geoserver-2.18.x-java11/39/display/redirect?page=cha

Re: [Geotools-devel] Build failed in Jenkins: geoserver-2.18.x-java11 #39

2020-11-09 Thread Ian Turton
This is caused by

[ERROR] 
testSortTimeElevationDescending(org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest)
 Time elapsed: 0.722 s  <<< FAILURE!org.junit.ComparisonFailure:
expected: but
was:
at 
org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.getFeatureAt(DimensionsVectorGetFeatureInfoTest.java:85)
at 
org.geoserver.wms.wms_1_1_1.DimensionsVectorGetFeatureInfoTest.testSortTimeElevationDescending(DimensionsVectorGetFeatureInfoTest.java:467)


which is a bit odd as I didn't change anything near there (I think) and
travis was happy.

Any one know what's happening here?

On Mon, 9 Nov 2020 at 11:51, Jenkins  wrote:

> See <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/39/display/redirect?page=changes
> >
>
> Changes:
>
> [Ian Turton] [GEOS-9765] Add IP Address range to GeoFence UI
>
> [Ian Turton] update screenshot in docs
>
> [Ian Turton] update screenshot in docs
>
> [Ian Turton] address comments
>
> [Ian Turton] update to latest GF version
>
> [Ian Turton] formatting?
>
>
> --
> [...truncated 1.17 MB...]
> [INFO] Skipping GeoServer Web Application
> [INFO] This project has been banned from the build due to previous
> failures.
> [INFO]
> 
> [INFO]
> [INFO] ---< org.geoserver.security:gs-web-sec-cas
> >
> [INFO] Building GeoServer CAS Security Web Module 2.18-SNAPSHOT
> [82/101]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ gs-web-sec-cas
> ---
> [INFO] Deleting <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/target
> >
> [INFO]
> [INFO] --- git-commit-id-plugin:2.1.15:revision (default) @ gs-web-sec-cas
> ---
> [INFO]
> [INFO] --- directory-maven-plugin:0.3.1:highest-basedir (directories) @
> gs-web-sec-cas ---
> [INFO] Highest basedir set to: <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> gs-web-sec-cas ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] skip non existing resourceDirectory <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/src/main/resources
> >
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> gs-web-sec-cas ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/target/classes
> >
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ gs-web-sec-cas ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/src/test/java
> >
> [INFO] skip non existing resourceDirectory <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/src/test/resources
> >
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> gs-web-sec-cas ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @
> gs-web-sec-cas ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ gs-web-sec-cas ---
> [INFO] Building jar: <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/target/gs-web-sec-cas-2.18-SNAPSHOT.jar
> >
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:test-jar (default) @ gs-web-sec-cas ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar: <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/target/gs-web-sec-cas-2.18-SNAPSHOT-tests.jar
> >
> [INFO]
> [INFO] --- maven-source-plugin:2.2.1:jar-no-fork (attach-sources) @
> gs-web-sec-cas ---
> [INFO] Building jar: <
> https://build.geoserver.org/job/geoserver-2.18.x-java11/ws/src/extension/security/web/web-cas/target/gs-web-sec-cas-2.18-SNAPSHOT-sources.jar
> >
> [INFO]
> [INFO] --- maven-source-plugin:2.2.1:test-jar-no-fork (attach-sources) @
> gs-web-sec-cas ---
> [INFO] No sources in project. Archive not created.
> [INFO]
> [INFO] --- fmt-maven-plugin:2.4.0:check (default) @ gs-web-sec-cas ---
> [warn] Te

Re: [Geotools-devel] RFC: Transform DataStore

2020-11-03 Thread Ian Turton
Currently, it's a WPS process - the code is at
https://github.com/ianturton/tablejoin

It's built around a FilterVisitor that replaces join values with literals I
think.



Ian

On Tue, 3 Nov 2020 at 19:25, Jim Hughes  wrote:

> Hi Ian,
>
> Interesting.  Is the Joining datastore somewhere online already?
>
> I'll admit to having written similar datastores previously.  One of my
> ideas for using this kind of DataStore would be to leverage functions like
> those in the GS Query Layer extension to pull attributes from other
> layers.  Similarly, it ought to be trivial to pull a column from a CSV on
> disk.
>
> As one starts down that path, there are syntactical annoyances  (I cannot
> see an easy way to say "get a bunch of columns from other there" without
> having a function call per column), and performance considerations (reading
> from a file/database repeated for the same information among separate
> queries is less than ideal, so caching would be nice).  That said, in a
> pinch, this approach may provide a really, really quick solution.
>
> Cheers,
>
> Jim
> On 11/3/20 1:53 PM, Ian Turton wrote:
>
> This looks interesting, I wonder how hard it would be to merge in the work
> I did on Joining datastores that could create "views" across non-jdbc
> datastores so you could add a CSV to a geometry in another store, I should
> dig that code out and look at it again. Maybe a christmas lockdown project?
>
> Ian
>
> On Tue, 3 Nov 2020 at 18:19, Jim Hughes  wrote:
>
>> Hi all,
>>
>> At various times, Jody and I have chatted about having a "CQL View" in
>> GeoServer (or something similar akin to the SQL Views) that'd leverage
>> the Transform module and allow one to add columns to a FeatureSource
>> based on expressions.  Such expressions could use existing or custom CQL
>> functions and that'd open a world of possibilities.
>>
>> Last week, I asked Jody about this idea again and he indicated that one
>> would really just need to write a DataStoreFactory.  I banged out an
>> initial implementation as a starting place for the conversation.  This
>> implementation provides a way to project down to a subset of attributes
>> as well as add new columns/attributes to a FeatureStore.
>>
>> If folks like it as-is, I'd be happy to add unit tests, and
>> documentation wherever we see fit.  Thanks in advance for some feedback
>> on this idea!
>>
>> https://github.com/geotools/geotools/pull/3196/files
>>
>> Cheers,
>>
>> Jim
>>
>>
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
> Ian Turton
>
>
>

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


Re: [Geotools-devel] RFC: Transform DataStore

2020-11-03 Thread Ian Turton
This looks interesting, I wonder how hard it would be to merge in the work
I did on Joining datastores that could create "views" across non-jdbc
datastores so you could add a CSV to a geometry in another store, I should
dig that code out and look at it again. Maybe a christmas lockdown project?

Ian

On Tue, 3 Nov 2020 at 18:19, Jim Hughes  wrote:

> Hi all,
>
> At various times, Jody and I have chatted about having a "CQL View" in
> GeoServer (or something similar akin to the SQL Views) that'd leverage
> the Transform module and allow one to add columns to a FeatureSource
> based on expressions.  Such expressions could use existing or custom CQL
> functions and that'd open a world of possibilities.
>
> Last week, I asked Jody about this idea again and he indicated that one
> would really just need to write a DataStoreFactory.  I banged out an
> initial implementation as a starting place for the conversation.  This
> implementation provides a way to project down to a subset of attributes
> as well as add new columns/attributes to a FeatureStore.
>
> If folks like it as-is, I'd be happy to add unit tests, and
> documentation wherever we see fit.  Thanks in advance for some feedback
> on this idea!
>
> https://github.com/geotools/geotools/pull/3196/files
>
> Cheers,
>
> Jim
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


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

2020-10-31 Thread Ian Turton
+1

Ian

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

> Looks like Github wiki does not like "<" and ">" in the page titles...
> updated proposal reference here:
>
> https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-map-values-from-String-to-generic-object
>
> Cheers
> Andrea
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


Re: [Geotools-devel] GeoServer/GeoTools PMC Meeting at 16:30 UTC tomorrow

2020-10-27 Thread Ian Turton
same here, I forgot the clocks wouldn't have changed over there.

Ian

On Tue, 27 Oct 2020 at 16:59, Andrea Aime 
wrote:

> Whoops, my bad, forgot that this week we switched back to standard time.
> Has everyone done so already? I guess everyone will by the next meeting
> right?
>
> Any objection to move the meeting one hour later?
>
> Cheers
> Andrea
>
> On Tue, Oct 27, 2020 at 5:44 PM Torben Barsballe <
> torbenbarsba...@gmail.com> wrote:
>
>> There were not enough people for a useful meeting this week (just myself
>> and Jody), so no meeting this week. The actions from last meeting are still
>> pending, as far as I know:
>>
>>- Jody to check the the GeoTools bin assembly
>>- Andrea marching on in the unchecked branch
>>
>> The next meeting will be in two weeks, as usual.
>>
>> Cheers,
>> Torben
>>
>>
>> On Mon, Oct 26, 2020 at 3:45 PM Torben Barsballe <
>> torbenbarsba...@gmail.com> wrote:
>>
>>> Reminder that the next PMC meeting is scheduled for tomorrow, October
>>> 27, at 16:30
>>> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting=2020=10=27=16=30=0=1>
>>> UTC.
>>>
>>> You can join the meeting via Jitsi: https://meet.jit.si/GeoServerMeeting
>>>
>>> Cheers,
>>> --
>>> Torben Barsballe
>>> Professional Services Engineer
>>> Planet
>>> torben.barsba...@planet.com
>>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards, Andrea Aime
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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


  1   2   3   4   5   6   7   >