Re: [Geotools-devel] 31.0 and 2.25.0 releases

[Mark Prins]

On 19-03-2024 09:01, Peter Smythe wrote:
Release artifacts for anyone to verify v31.0: 
https://build.geoserver.org/view/geotools/job/geotools-release/119/ 



The QuickStart works for me.


Upgraded some (Maven) projects to 31.0 without problems, did not check 
any of the funky tracking urls you provided.


- M





Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe 




On Tue, 19 Mar 2024 at 08:49, Peter Smythe > wrote:


Hi developers

I am starting the releases now with:

geoserver version = 2.25-SNAPSHOT
git revision = bf9a61403423f3b635234a09ec023d5617173fe2
git branch = origin/2.25.x
build date = 18-Mar-2024 14:00
geotools version = 31-SNAPSHOT
geotools revision = cb01076a71f53bb47f8e9e481bdddecc94532f8d
geowebcache version = 1.25-SNAPSHOT
geowebcache revision = 9ff2bbbcdde77721a597e83f3ddbad2b73ad3166/9ff2bbb

Peter

GeoServer PSC
AWS Solutions Architect
https://github.com/petersmythe




On Mon, 18 Mar 2024 at 11:19, Peter Smythe mailto:g...@smythe.co.za>> wrote:

Oops, why was this not sent?!?  The releases will be done over
the next 2 days.


Hi developers

I'll be starting the GeoTools 31.0 and GeoServer 2.25.0 releases
on Monday 18 March, so you have the next 48 hours to get those
final fixes in.

If anyone has feedback on the RC testing, please also submit
that ASAP.

Thanks

Peter



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




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

Re: [Geotools-devel] Can anyone figure out the GDAL setup failure in the MAC OS build?

[Mark Prins]

So I've opened a `brew update` PR

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

but that seems to just make the failure reproducible...

-M


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

Re: [Geotools-devel] (no subject)

[Mark Prins]

You are free to try and propose a pull request.
Alternatively you could look into the geojson-core module and
https://github.com/geotools/geotools/blob/48547967e75f2ef841751c3950b01e88cd5683e7/modules/unsupported/geojson-core/src/main/java/org/geotools/data/geojson/GeoJSONReader.java#L300

Op ma 22 mei 2023 om 17:22 schreef pengfei tian :

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


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geotools-gt2-users] GeoTools 29-RC1 released

[Mark Prins]

things work as before after upgrading some of our projects (from 28.2)

thanks, Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] MySQL 5 Github actions not working anymore

[Mark Prins]

On 12-07-2022 10:34, Andrea Aime wrote:

Hi all,
the MySQL 5 docker tests are failing on GitHub... the output does not 


fixed with https://github.com/geotools/geotools/pull/3959


___
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

[Mark Prins]

On 19-05-2022 15: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.


I notice that the bin zip file with artifacts still has the 
gt-jdbc-teradata module which was moved to unsupported with 
https://osgeo-org.atlassian.net/browse/GEOT-7079 / 
https://github.com/geotools/geotools/pull/3801


so that is still being build/packaged, not a big deal though

Mark


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

[Geotools-devel] Informix online testing workflow [PR #3896]

[Mark Prins]

Hi,
Having never run into Informix IRL I'm having trouble with a last thing 
in a PR to bring an Informix online testing workflow.


Basically I have not been able to figure out how to run the simple 
"CREATE DATABASE geotools WITH LOG;" SQL command from the bash script or 
from a shell inside the container for that matter...


If anyone has any ideas please leave them at
https://github.com/geotools/geotools/pull/3896#discussion_r877096403

Mark


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

Re: [Geotools-devel] Informix JDBC datasource plugin - supported or not?

[Mark Prins]

On 24-03-2022 09:37, George Dewar wrote:
IP check - is the dependency on the Informix JDBC driver 
 a 
problem? If so, is there a solution?


The license is probably a problem for redistribution (as in: when the 
the driver jar file is included in a download provided by osgeo - eg. 
when providing this as an extension for geoserver) but is of no concern 
as a dependency.
I don't think that could be resolved afaik there are no open source 
alternatives; informix users would need to download and accept the license.
Note that the driver is available - but without source code - in Maven 
central: https://repo1.maven.org/maven2/com/ibm/informix/jdbc/4.50.7.1/
so it can easily be accessed with Maven; not like eg. the old Oracle 
jdbc drivers.



>   * Ask to be included in the next release - perhaps that could be a
> later step?

if unsupported, it won't be part of the release (as in release artifacts 
that can be downloaded)


> If it /does /go
> in unsupported, does that mean I can’t make the online tests run via
> GitHub actions?

Some other modules in unsupported run online tests eg. elasticsearch 
(that seems the only one though)


-M


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

Re: [Geotools-devel] Should we switch to Java 11 as the minimum version?

[Mark Prins]

There is also the new HTTP client (there is still use of the EOL apache
httpclient 3.x in some places) and new String and Collection methods would
probably make it possible to reduce the number of dependencies as well.
Dropping Java 8 as a runtime makes it possible to upgrade the EE modules to
supported/maintained (Jakarta) versions



Op ma 21 feb. 2022 om 19:25 schreef Jody Garnett :

> I am neutral on this; geocat can make the change for our customers to Java
> 11 (but are presently using Java 8).
>
> It seems odd to limit the geotools build if their is no technical reason
> feature we wish to take advantage of. The key language feature I am looking
> forward to is inline classes (for efficient coordinates lists), sadly Java
> 14 records just implement equals/hashcode.
> —
> Jody
>
>
> On Mon, Feb 21, 2022 at 2:21 AM Andrea Aime <
> andrea.a...@geosolutionsgroup.com> wrote:
>
>> Hi all,
>> recently I've been wondering multiple times if we should just switch to
>> Java 11
>> as the minimum supported versions.
>>
>> Reasons/benefits:
>>
>>- I believe most deployments are on Java 11 anyways
>>- It simplifies our build, one less JDK to handle (we now try to
>>support Java 8, 11 and 17)
>>- google-java-format recent versions require Java 11,
>>errorprone shows some misbehaviors on Java 8 and requires special setup
>>- Among our dependencies, Wicket 9 also requires Java 11, not sure
>>what else.
>>- Can can start using some new API introduced after Java 11, like
>>"var" for type inference, some handy new methods in Optional, a variety of
>>new methods in streams, and support for creating maps, sets and lists with
>>a single call (e..g Map.of(key, value)).
>>
>> Disadvantages:
>>
>>- Java 8 is supported up until 2026 while Java 11 (so far at least)
>>up until October 2024 . Switching
>>now, we'd still get 3.5 years of support ahead of us.
>>
>> I'm afraid that we'll have to get used to short LTSs anyways, Oracle is
>> proposing to go down to 2 years for LTSs:
>> https://www.infoq.com/news/2021/10/oracle-java-two-year-lts/
>>
>> 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
>>
> --
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [Geoserver-devel] Upgrading formatter plugin to the latest version (compatible with Java 8)?

[Mark Prins]

Op za 4 dec. 2021 om 22:23 schreef Andrea Aime <
andrea.a...@geosolutionsgroup.com>:

>
> I like how the streams are formatter in a bit more compact way,
>
>
definitely


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] 26-RC artifacts ready for testing

[Mark Prins]

Ahhh no... I have more technical dept than I thought I had... I stand 
corrected. In tha case my PR does not make much sense anymore


Thanks Andrea

On 13-09-2021 15:04, Andrea Aime wrote:
On Mon, Sep 13, 2021 at 1:43 PM Mark Prins <mailto:mc.pr...@gmail.com>> wrote:


After upgrading one of our projects I noticed that
org.geotools.data.ows.HTTPClient could no longer be found; it seems
to have moved to org.geotools.http.HTTPClient as part of GEOT-6755.
Same thing for org.geotools.data.ows.SimpleHttpClient which was
moved to org.geotools.http.SimpleHttpClient

So after adding the new gt-http module and updating the packages
things worked again, apart from that we had a transitive dependency
on commons-httpclient:3.1 from GeoTools that now emerged and
requires some more work in our code.

A note about this change, or in fact the whole new gt-http module
seems to be missing from the upgrade notes; so I'll start a PR for
that shortly.


The module has been deprecated in 25.x, it's part of the upgrade notes:
https://docs.geotools.org/stable/userguide/welcome/upgrade.html 
<https://docs.geotools.org/stable/userguide/welcome/upgrade.html>


26.x "finished the job" by removing the deprecated module.

Cheers
Andrea
==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us <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/ <https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_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] stop just stop main vs Main vs 26.x

[Mark Prins]

might have been my-bad, though I'm not aware of any mishaps and don't 
have any forks or local branches that have this. I had a windows machine 
on loan for a couple of days that may have caused this...


It ("duplicate_main") does not seem to have any commits that the main 
branch has, so I think it ("duplicate_main") can just be deleted.


Mark

On 11-09-2021 07:24, Jody Garnett wrote:
I have renamed Main as duplicate_main 
(https://github.com/geotools/geotools/tree/duplicate_main 
) and we can 
clean it up another day.

--
Jody Garnett


On Fri, 10 Sept 2021 at 22:21, Jody Garnett > wrote:


Okay not sure how this happened but it is really disrupting my
release process:

  * https://github.com/geotools/geotools/commits/main

default branch - branch I have been tracking and created 26.x from
  * https://github.com/geotools/geotools/commits/Main

Last commit september 2 2021

This is really messing up git on my system, it keeps pulling track
changes against *Main* when working on the *main* branch.
--
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] 26-RC artifacts ready for testing

[Mark Prins]

So it seems that the Jira ticket (
https://osgeo-org.atlassian.net/browse/GEOT-6755) wasn't marked as
resolved/done when https://github.com/geotools/geotools/pull/3256 was
merged for 26

I've started https://github.com/geotools/geotools/pull/3639 but won't have
any thime to work on that this week

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] 26-RC artifacts ready for testing

[Mark Prins]

After upgrading one of our projects I noticed that
org.geotools.data.ows.HTTPClient could no longer be found; it seems to have
moved to org.geotools.http.HTTPClient as part of GEOT-6755.
Same thing for org.geotools.data.ows.SimpleHttpClient which was moved to
org.geotools.http.SimpleHttpClient

So after adding the new gt-http module and updating the packages things
worked again, apart from that we had a transitive dependency on
commons-httpclient:3.1 from GeoTools that now emerged and requires some
more work in our code.

A note about this change, or in fact the whole new gt-http module seems to
be missing from the upgrade notes; so I'll start a PR for that shortly.

Op za 11 sep. 2021 om 17:01 schreef Jody Garnett :

> Available here:
>
> https://build.geoserver.org/view/release/job/geotools-release/lastSuccessfulBuild/artifact/build/release/distribution/26-RC/
>
> Testing welcome; it is worth checking documentation links as this is the
> first branch of a new stable series.
>
> Aside: Downstream build jobs for main are disable while new branches and
> version numbers are created.
>
> Jody
> --
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Making XmlSimpleFeatureParser.parseGeom() a public API

[Mark Prins]

On 06-05-2021 10:55, Matthijs Laan via GeoTools-Devel wrote:


The internal StAX GML parser from the wfs-ng module would be useful as a 
public API as it is much simpler and faster than the GTXML parsers, 
although the latter supports more GML elements.


Beside the GTXML parsers there is also a SAX GML parser in gt-xml, 
package org.geotools.gml.


Would it be a good idea to move the XmlSimpleFeatureParser.parseGeom() 
method to the gt-xml module in a package like org.geotools.gml.stream, 
or better to create a new module like modules/unsupported/gml-streaming?


Moving it to gt-xml would mean no dependencies would change for wfs-ng.
On the other hand gt-xml also contains a SAX based SLD parser but a StAX 
SLD parser is in a separate ysld module.


In addition to making it a public API, it is also a good opportunity to 
reduce code duplication in XmlSimpleFeatureParser and 
XmlComplexFeatureParser. The latter descends from XmlFeatureParser which 
has duplicated parseGeom() methods which have already diverged because 
in GEOT-6835 / #3393 MultiCurve support was added to one but not the 
other. Some more GML support for Arcs etc. could also be added.


Either way is a simple tasks moving some code around, I can make a PR 
for it.




+1 for pulling it up into gt-xml
-M


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

[Geotools-devel] 2.19.0 still in "unreleased" in Jira

[Mark Prins]

Can someone please push the button in Jira to release 2.19.0?

There were 3 open issues in 2.19.0 that I've either moved to a new 
milestone or resolved, assigees/reporters should have received a 
notification about that from Jira.


thanks, Mark


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

[Geotools-devel] backporting "[GEOT-2972] Character set from CPG files" to 25.x

[Mark Prins]

Hi all,

Dmitriy Fedorov added some code to try and "autodetect" the shapefile 
codepage from the CPG sidecar in 
https://github.com/geotools/geotools/pull/3405


I would like to backport this to 25.x and 24.x (preferably before 24.3 
is released)


It is a switch that turns "on" a small change in behaviour, that does't 
affect existing code if it already specifies a codepage and makes life 
much easier IMO. (We are seeing increasing numbers of UTF-8 encoded 
shapefiles that give unexpected results for clients.)


Alternatively; I could update the code in the backports to default to 
false for the "tryCPGFile" property so there is no actual change in 
behavior of the store unless your code changes the property to true 
(though I would prefer not to - keeping behavior the same across versions)


Opinions?

Mark


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

Re: [Geotools-devel] ArcSDE module: how about removing it?

[Mark Prins]

On 09-01-2021 10:45, Andrea Aime wrote:

Hi all,
the ArcSDE module has been in unsupported for a year, without any 
further change.
While working on the PMD fixes on test classes, I've found I'd have to 
fix 120 violations in the sde module:


     [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-pmd-plugin:3.14.0:check (default) on 
project gt-arcsde: You have 120 PMD violations. For more details see: 
/home/aaime/devel/git-gt-clean/modules/unsupported/arcsde/datastore/target/pmd.xml 
-> [Help 1]


Hmm... I'd rather not, honestly :-D
Is it time to simply remove the module? As an alternative, I could 
disable PMD on its test sources.


I don't know anybody using geotools of geoserver icw arcsde - and when 
data is stored in the database native format one can use the regular 
jdbc connector that we have to get at the data. So I have no objections 
to dropping arcsde.


-M


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

Re: [Geotools-devel] Switching JUnit tests from v3 to v4... epic! (part 1)

[Mark Prins]

Heh,
So much for christmas holifdays with the family eh?...
Great job! epic indeed.

-M


On 03-01-2021 09:56, Andrea Aime wrote:

Hi,
in the last few days I've been working on switching our large mass of 
JUnit 3 tests to

JUnit 4.

The original plan was simple: let IntelliJ do most of the job, with its 
automatic migration,

and then fill in the blanks.
Turned out IntelliJ is very good at migrating simple JUnit tests, but 
not tests that inherit
from other base test classes... which is a pattern very widely used in 
GeoTools.


Long story short, IntelliJ migrated some 250 tests, but I had to modify 
more or less
twice as that by "hand"... where hand means, mostly regex replacements 
with extra

actual "by hand" changes. The final PR modifies 870 files:
https://github.com/geotools/geotools/pull/3306

It was an epic endeavour. Some highlights follow:

  * Classes had a lot of needless cruft, like suite methods manually
collecting the test methods, or "main" with runners. Wiped them all out.
  * JUnit3 had an equals between doubles without a tolerance, switching
to JUnit4 all these calls required the tolerance param to be added
(the old method is there, but deprecated)
  * The test compile in Maven complains if a class with JUnit 4
annotations has methods whose name matches ".*test.*", and breaks
the compile. That was pretty useful to locate methods that the
regexes missed. It also meant changing test methods that were
disabled by adding a prefix to "test" (e.g.. xtestMyCase), and
annotating them with both @Test and @Ignore.
  * There was still a risk of having less tests after the migration, so
I've made a sequential build both on the current master and in the
branch, and compared. Found I missed a few test classes and added
them back. The final result is that the build runs a few more tests
than the current master, as there were test methods disabled that
were actually passing!

So all of this is great eh? Hem... nope, not quite as I hoped at least.
My last step was to add PMD checks to ensure no new JUnit3 tests could 
be added. Created a custom PMD rule for it,
based on type matching (sort of a XPath match), and found I had to 
disable it for OnlineTest. Nice!
But then I noticed it would not fail in imagemosaicjdbc, where there is 
a separate base class for online test (why it could not use

OnlineTest, it's beyond me)... why oh why?

And then it dawned on me PMD is actually not running on test 
sources! It needs a dedicated flag 
 
to do so.

So, all the test sources, they have never been gone though the PMD checks.
First, I've tried to set-up the maven build so that different checks are 
run on main sources and tests... and failed.
The attempt tried to use two different executions, linked to different 
phases, giving each a different PMD configuration,
and found it was ignoring my config, solid this is due to an issue 
in the PMD plugin, it only honors the configuration

under plugin, ignoring the eventual one in executions:
https://issues.apache.org/jira/browse/MPMD-132

Long story short, the above PR does not contain any new PMD check, as 
they do nothing on tests anyways.

Plan to move forward:

  * Complete the migration on GWC and GS (should be much quicker, most
GeoServer tests are JUnit 4 already).
  * Go back, and enable PMD on tests as well. That's gonna be epic too,
gt-main alone contains a few hundred failures... but oh well, at
this point I've become decently good at resolving them :-D
  * Finally, take a stab at migrating the OnlineTest family as well.

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 

Re: [Geotools-devel] Failing Github Checks

[Mark Prins]

On 31-12-2020 00:59, Roar Brænden wrote:


Is there a way to restart the check without making a new commit?


there is, but some are limited to committers;
1. on the checks page of the PR, when you got to the failing job (or the 
"details" link in the PR checks) there's a button "Re-run jobs"

2. you can close/reopen the PR, which wil trigger all checks

HTH


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

Re: [Geotools-devel] New library gt-http : Special notice for gt-wps / gt-mbstyle / gt-mongodb

[Mark Prins]

On 09-12-2020 09:47, Roar Brænden wrote:

Hi,

I have started to work on a new library gt-http that tries to collect 
all usage of HTTP clients within Geotools. For the moment there are two 
client implementations. SimpleHttpClient in gt-main and 
MultithreadedHttpClient in gt-wms and gt-wfs-ng. You see there are 
actually three, but the last two are almost identical.


MultithreadedHttpClient have the advantage that it uses a connection 
pool favoring connections to the same host. I see the advantage in using 
this for all the listed projects. The disadvantage is that you would 
have a new dependency on the external library commons-httpclient.


In the near future this dependency will vanish when Geotools is ready 
for JDK 11, and we could use the new HTTP client inside JDK. Before 
going that direction, it would be great to have one place for all HTTP 
clients.


If you really think it's horrible to include this dependency, I could 
turn it into a plugin.


Any opinions?



At the risk of this being out of scope; the commons-httpclient version 3 
.x that is in use by GeoTools is and has been EOL for quite a while. 
upgrades from 3.x to 4.x or 5.x are non trivial because the API is quite 
different if I recall correctly.
So I'm ambivalent with respect to further reliance on an EOL dependency; 
on the one hand the imapct can be quite substantial if something shows 
up awry in that lib (this is ofcourse already a risk), on the otherhand 
you're centralizing in one place, so that could make upgrading an easier 
task.


-M


___
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

[Mark Prins]

On 20-11-2020 16:21, Jody Garnett wrote:
The library used to collect this information was updated in October, 
perhaps we need to test a newer version...


there's one or 2 fixes in the next releases; unlikely to help on a 
warning about getting the size of a disk if it's not allowed to.
(this seems to pop up here and there when docker is involved, but I 
don't know if that is the case here.)




___
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

[Mark Prins]

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

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

[Mark Prins]

On 19-11-2020 18:22, Alessandro Parma wrote:

Hi All, Jody

Artifacts are available for testing here 
 any 
feedback is welcome.


I've upgraded some of our projects to GT 24.1 and all testcases pass / 
no regressions. (BTW this is using the Maven artifact from repo.osgeo.org)


Mark



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

Re: [Geotools-devel] MySQL 8 spatial functions are not supported (GEOT-6690 / GEOT-6692 )

[Mark Prins]

Hi All,

I've managed to make the MySQL module work with both MySQL 5 (5.6/5.7) 
as well as MySQL 8 (8.0) resolving GEOT-6690 / GEOT-6692.


There's some trickery around the "envelope" and "srid" functions involved.
If anyone cares to review PR 3191? I will squash and merge after OK to 
clean up the commit messages.


Thanks, Mark

[0] https://osgeo-org.atlassian.net/browse/GEOT-6690
[1] https://osgeo-org.atlassian.net/browse/GEOT-6692
[2] https://github.com/geotools/geotools/pull/3191



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

[Geotools-devel] Why is the unknown SRID -1 (and not 0)?

[Mark Prins]

Hi,
This question rose while upgrading the MySQL module to version 8 where I 
ran into the database throwing a "MysqlDataTruncation" exception with 
message "Data truncation: SRID value is out of range in 
'st_geomfromtext'" when passing -1 as the SRID value when one of the 
tests inserted a geometry without SRID.


I traced this back to 
JDBCDataStore#getDescriptorSRID(AttributeDescriptor) defaulting to -1 as 
the unknown value:

https://github.com/geotools/geotools/blob/821d9add2f8de1f6649601dc4a67ccd9c64f1719/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCDataStore.java#L4291-L4302

There's actually a default to -1 for srid in setPreparedFilterValues() 
as well.


I found this note on the PostGIS ST_SRID page: 
https://postgis.net/docs/RT_ST_SRID.html


   "From PostGIS 2.0+ the srid of a non-georeferenced raster/geometry 
is 0 instead of the prior -1."


Which might explain why (and it's been like that for at least 10 years), 
but if postgis stopped using -1 maybe we should too?

(postgis seems lenient to using -1 as a srid)

Mark


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

Re: [Geotools-devel] MySQL 8 spatial functions are not supported

[Mark Prins]

O Joy, it gets better.

In MySQL 8 if you store epsg 4326 data you must be wanting to store 
geography and not geometry so let's demand that you flip the axis: 
https://dba.stackexchange.com/a/242004


and then ofcourse things like this fail (on MySQL 8.0.21)...

SELECT ST_Envelope(ST_GeomFromText('POLYGON ((6 12, 8 14, 6 16, 4 16, 4 
14, 6 12))',4326))


with "Nope can't do this"

Seems that in 8 Geography is a new feature and it needs to be shown off...

Mark

On 04-09-2020 15:23, Mark Prins wrote:

Ok, thanks.
I'll get to work on it

Op wo 2 sep. 2020 om 13:57 schreef Nikolaos Pringouris 
mailto:nprig...@gmail.com>>:


Hmm probably I have missed/overlooked these 2 functions when adding
support for ST_... functions in geotools 19.x.
In any case as you already mentioned the flag is direct available
there so you easily add support for the corresponding ST_ functions
at that point.

Concerning Mysql v5.5 I think you are right. IMHO there is no need
to further support them in newer versions of geotools.


Στις Τετ, 2 Σεπ 2020 στις 2:36 μ.μ., ο/η mark mailto:mc.pr...@gmail.com>> έγραψε:

On 2020-09-01 19:24, Nikolaos Pringouris wrote:
 > Hi All,
 >
 > A couple of years ago I worked on jdbc-mysql module and
provided support
 > for the newly introduced ST_ functions in Mysql5.6 & Mysql
5.7. I think
 > these functions are also supported in Mysql8.0 with the same
signature
 > so I do not think there is an issue of incompatibility.

the problem is the code uses old/removed functions in several places

If you check the
 > Data Store factory for Mysql (MySQLDataStoreFactory) you will
see that
 > there is a static function isMySqlVersion56(...) which is
called during
 > creation of the dataStore and if figures out that mysql 5.6
or above is
 > used in enables enhancedSpatialSupport flag automatically and
the use of
 > the corresponding ST_ functions (check also
 > visitBinarySpatialOperatorEnhanced(...) function in
MySQLFilterToSQL
 > class).

this would/my have worked for 5.7, but not 8 as the old
functions have
been removed, this code:


https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialect.java#L225-L238

simply fails with a database error that function asWKB does not
exist

same for


https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialectPrepared.java#L194-L205

I can add the enhanced flag around those as a quick scan of the
code
seems that it's limited to these instances. maybe this was an
oversight
when a different dev worked on the code and didn't know about
that flag,
(suggesting the design could be improved)

 > Of course mysql 8.0 may have additional spatial features (to
be honest I
 > am still using version 5.7.x in my geotools related projects)
and
 > probably the mysql module can still be improved but I am
pretty sure
 > that the module will still be functional when the underline
Mysql DB is
 > v8.0 (in addition to 5.5, 5.6, 5.7).
 >

I don't see any point in supporting 5.5 (EOL December 2018) as
it is no
longer part of the support matrix, if you want to use an
unsupported
database software you can use an old version of
geotools/geoserver as
well IMO.
5.6 will be EOL in a few months (February, 2021)



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



--
Disclaimer;
This message is just a reflection of what I thought at the time of 
sending. The message may contain information that is not intended for 
you or that you don't understand.




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

Re: [Geotools-devel] MySQL 8 spatial functions are not supported

[Mark Prins]

Ok, thanks.
I'll get to work on it

Op wo 2 sep. 2020 om 13:57 schreef Nikolaos Pringouris :

> Hmm probably I have missed/overlooked these 2 functions when adding
> support for ST_... functions in geotools 19.x.
> In any case as you already mentioned the flag is direct available there so
> you easily add support for the corresponding ST_ functions at that point.
>
> Concerning Mysql v5.5 I think you are right. IMHO there is no need to
> further support them in newer versions of geotools.
>
>
> Στις Τετ, 2 Σεπ 2020 στις 2:36 μ.μ., ο/η mark  έγραψε:
>
>> On 2020-09-01 19:24, Nikolaos Pringouris wrote:
>> > Hi All,
>> >
>> > A couple of years ago I worked on jdbc-mysql module and provided
>> support
>> > for the newly introduced ST_ functions in Mysql5.6 & Mysql 5.7. I think
>> > these functions are also supported in Mysql8.0 with the same signature
>> > so I do not think there is an issue of incompatibility.
>>
>> the problem is the code uses old/removed functions in several places
>>
>> If you check the
>> > Data Store factory for Mysql (MySQLDataStoreFactory) you will see that
>> > there is a static function isMySqlVersion56(...) which is called during
>> > creation of the dataStore and if figures out that mysql 5.6 or above is
>> > used in enables enhancedSpatialSupport flag automatically and the use
>> of
>> > the corresponding ST_ functions (check also
>> > visitBinarySpatialOperatorEnhanced(...) function in MySQLFilterToSQL
>> > class).
>>
>> this would/my have worked for 5.7, but not 8 as the old functions have
>> been removed, this code:
>>
>>
>> https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialect.java#L225-L238
>>
>> simply fails with a database error that function asWKB does not exist
>>
>> same for
>>
>>
>> https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialectPrepared.java#L194-L205
>>
>> I can add the enhanced flag around those as a quick scan of the code
>> seems that it's limited to these instances. maybe this was an oversight
>> when a different dev worked on the code and didn't know about that flag,
>> (suggesting the design could be improved)
>>
>> > Of course mysql 8.0 may have additional spatial features (to be honest
>> I
>> > am still using version 5.7.x in my geotools related projects) and
>> > probably the mysql module can still be improved but I am pretty sure
>> > that the module will still be functional when the underline Mysql DB is
>> > v8.0 (in addition to 5.5, 5.6, 5.7).
>> >
>>
>> I don't see any point in supporting 5.5 (EOL December 2018) as it is no
>> longer part of the support matrix, if you want to use an unsupported
>> database software you can use an old version of geotools/geoserver as
>> well IMO.
>> 5.6 will be EOL in a few months (February, 2021)
>>
>>
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] MySQL 8 spatial functions are not supported

[Mark Prins]

Hi,
I've opened [0] which I ran into after setting up online testing with 
MySQL 8 and will be taking a stab at that, but before I take off I'm 
wondering which versions of MySQL we want to support in GeoTools.


The MySQL project is already dropping support for 5.6 on some platforms 
[1] and dropping that in GeoTools (24.x/master) would make the 
migration/upgrade easier as 5.7 is supposed to have both ST_ prefixed 
and plain named (but deprecated) spatial functions.
We could leave 23.x as is (without MySQL 8 support, but with 5.6/5.7 
support)


Mark

[0] https://osgeo-org.atlassian.net/browse/GEOT-6690
[1] https://www.mysql.com/support/supportedplatforms/database.html


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

Re: [Geotools-devel] Windows GitHub CI build failing on 23.x

[Mark Prins]

On 30-07-2020 11:56, Uhrig, Stefan wrote:

Hi all,

I’m currently trying to backport a fix for the HANA JDBC plugin to 
branch 23.x (https://github.com/geotools/geotools/pull/3096). However, 
the Windows GitHub CI build is failing with the following error:


*[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-install-plugin:2.4:install 
(default-install) on project xmlcodegen: Failed to install metadata 
org.geotools.maven/maven-metadata.xml: Error updating group repository 
metadata: in epilog non whitespace content is not allowed but got s 
(position: END_TAG seen ...\ns... **@11:2) -> [Help 1]*


This happens when the maven-metadata.xml file is/gets/has been corrupted 
which can occur when there are multiple threads writing the file during 
the build. It can also happen if the file is downloaded from a remote 
repo and is corrupted.


definitely not related to the changes in that PR.

as an aside I notice that the windows build is not (re-)using the maven 
cache, I'll fix that ASAP.


-M


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

[Geotools-devel] non-compliant file in gt-imagemosaic

[Mark Prins]

seeing this locally in a bugfix I'm working on as well as last Travis-CI
build of master branch:

[ERROR] Failed to execute goal com.coveo:fmt-maven-plugin:2.4.0:check
(default) on project gt-imagemosaic: Found 1 non-complying files,
failing build -> [Help 1]
10873[ERROR]
10874[ERROR] To see the full stack trace of the errors, re-run Maven
with the -e switch.
10875[ERROR] Re-run Maven using the -X switch to enable full debug logging.
10876[ERROR]
10877[ERROR] For more information about the errors and possible
solutions, please read the following articles:
10878[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
10879[ERROR]
10880[ERROR] After correcting the problems, you can resume the build
with the command
10881[ERROR]   mvn  -rf :gt-imagemosaic


-- 


https://travis-ci.org/github/geotools/geotools/builds/698989229
seems that something snuck in...

Mark

Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Maven Release Repository

[Mark Prins]

Hi Frank,

use https://repo.osgeo.org/ (the boudless repo was decommissioned)

hth, Mark


On 28-05-2020 09:18, Frank Gasdorf via GeoTools-Devel wrote:

Hello folks,

recently I got errors downloading artifacts from Boundless repository 
(not available anymore).


https:///repo/./boundlessgeo/.com/main

Where are release artifacts deployed to? Is there another repository I 
can use?


However is Boundless Server down by intention or by mistake?

--
Frank


___
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] GT PMC meeting notes, May 12th 2020

[Mark Prins]

On 12-05-2020 19:50, Andrea Aime wrote:


Q: Long term home for docs?

 *

static webserver, ask osgeo?

 o

moderate amount of space (due to prior builds) 2-10 GBs

 +

Can cut back on archived releases if needed < 1GB

 o

ask via trac?

 o

Mapserver docs hosted by OSGeo
https://download.osgeo.org/mapserver/docs/

 o

Action: Jody to request via trac
https://trac.osgeo.org/osgeo/ticket/2461

I was wondering if hosting at github (aka GitHub Pages) was considered 
for this? I've done some sites with this in the past and was quite 
simple to set up:


1. create a geotools.github.io repository to drop in all the files to
   be hosted
2. add a CNAME file to that repo with "docs.geotools.org"
3. set up GitHub Pages on that repo
4. update DNS for "docs.geotools.org" (essentially change the current
   CNAME record for docs.geotools.org to geotools.github.io

see also 
https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site


Github provides loadbalanced/cloud hosting + https

Mark

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

[Geotools-devel] update of online testing docs

[Mark Prins]

I've started putting together some notes and things I learned in recent 
PRs on running databases (Oracle XE and SQL Server for now) for online 
testing in https://github.com/geotools/geotools/pull/2932


Any comments and additions are welcome, specifically on:

- the location of that prose in "Online Tests"?
- does it need a JIRA?

TIA, Mark


--
Disclaimer;
This message is just a reflection of what I thought at the time of 
sending. The message may contain information that is not intended for 
you or that you don't understand.



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

Re: [Geotools-devel] Online testing for Oracle, some questions on failing test

[Mark Prins]

Fails on master with an old driver, fixed in the PR by adding a getter for
the expected.

Op za 25 apr. 2020 10:31 schreef Andrea Aime :

> But first the question: was it failing before?
> Tests are often added to the base JDBC*Test classes, and tested on a bunch
> of them only... like,
> NOT Oracle :-D
>
> Cheers
> Andrea
>
> On Sat, Apr 25, 2020 at 3:10 AM Jody Garnett 
> wrote:
>
>> My first thought is the previous driver also had to wrestle with Oracle's
>> representation of Numbers and was able to sort things out.
>>
>> * Can we find any logic that handled this previously?
>>
>> * Can we step through the old code with a debugger and see how it made
>> the decision to convert from BigDecimal to Integer? (There is obviously
>> some logic as it managed the conversion from BigDecimal to Double)
>> --
>> Jody Garnett
>>
>>
>> On Thu, 23 Apr 2020 at 02:28, Mark Prins  wrote:
>>
>>>
>>>
>>> Op di 21 apr. 2020 om 17:51 schreef Mark Prins :
>>>
>>>> While working on this PR https://github.com/geotools/geotools/pull/2890
>>>> to have Online testing of the Oracle JDBC module I'm running into some
>>>> failing tests.
>>>>
>>>
>>>> OracleFeatureSourceOnlineTest>OnlineTestCase.run:112->JDBCFeatureSourceOnlineTest.testMixedEncodeIn:680
>>>>
>>>> expected:<[zero, two, 1, 2, 0.0]> but was:<[zero, two, 1, 2, 0.0]>
>>>>
>>>>
>>> debugging shows that this test[1] is failing because:
>>>
>>> literals = {ArrayList@4436}  size = 5
>>>  0 = "zero"
>>>  1 = "two"
>>>  2 = {BigDecimal@4442} "1"
>>>  3 = {BigDecimal@4443} "2"
>>>  4 = {Double@} 0.0
>>>
>>> expected = {Arrays$ArrayList@4451}  size = 5
>>>  0 = "zero"
>>>  1 = "two"
>>>  2 = {Integer@4456} 1
>>>  3 = {Integer@4457} 2
>>>  4 = {Double@4458} 0.0
>>>
>>> [1]
>>> https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L677
>>>
>>> This is because Oracle uses BigDecimal for any Number...
>>>
>>> My initial thought was to copy and overide the test into the Oracle
>>> subclass, but that is basically made impossible becasue the test uses the
>>> package private method "splitFilter" (
>>> https://github.com/geotools/geotools/blob/7925c3f05470aceeab2c2188ea90959466ce0bd2/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L363
>>> )
>>>  so that won't fly..
>>>
>>> My second best option is to extract getting the expected values into a
>>> protected method so dialects can override that, so adding
>>> to JDBCFeatureSourceOnlineTest the following method:
>>>
>>> /**
>>> * @return expected list for {@link #testMixedEncodeIn()}
>>> */
>>> protected List getTestMixedEncodeInExpected (){
>>> return Arrays.asList("zero", "two", 1, 2, 0d);
>>> }
>>>
>>> and adding to OracleFeatureSourceOnlineTest
>>>
>>> /**
>>>  * Because Oracle uses "Bigdecimal" for any number we need to change the 
>>> type of the objects that are in the list of expected objects.
>>>  *
>>>  * @return expected list for {@link #testMixedEncodeIn()}
>>>  */
>>> @Override
>>> protected List getTestMixedEncodeInExpected() {
>>> return Arrays.asList("zero", "two", BigDecimal.valueOf(1), 
>>> BigDecimal.valueOf(2), 0d);
>>> }
>>>
>>>
>>> Any other thoughts / ideas? I don't think it would be too useful to
>>> reduce the test to compare two List instead?
>>>
>>> Mark
>>>
>>> --
>>> Disclaimer;
>>> This message is just a reflection of what I thought at the time of
>>> sending. The message may contain information that is not intended for you
>>> or that you don't understand.
>>> ___
>>> 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] Draft blog post for 23.0 release ready for checking

[Mark Prins]

The published blog post starts off with "We are happy to announce 
GeoServer 2.17.0 release candidate is available for testing."


I think it should be "We are happy to announce GeoServer 2.17.0 release."

Mark

On 21-04-2020 16:28, Ian Turton wrote:

https://www.blogger.com/blogger.g?blogID=116830172286767929#editor/target=post;postID=852854690940286431;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname

Please make sure I've name checked everything you've been upto for the 
23.0 release and mentioned any sponsors etc. I'll hit publish tomorrow 
unless someone screams


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

Re: [Geotools-devel] Add strToLowerCase filter function support to Oracle DataStore

[Mark Prins]

Currently working on a PR to get testing Oracle up to par with other
databases in https://github.com/geotools/geotools/pull/2890  so "not having
an oracle server" will no longer be an excuse ;-)

Mark


Op do 23 apr. 2020 om 08:48 schreef Jody Garnett :

> Welcome to the deep end of the pool, and thank you for starting the email
> thread.
>
> GeoTools is in an odd spot where we like to support new developers
> (including those new to Java) but for this specific issue not many folks
> have an oracle server to test against.
>
> —
> Jody
>
> On Wed, Apr 22, 2020 at 6:06 PM David Jerrard  wrote:
>
>> The Oracle jdbc plugin does not support the "strToLowerCase" filter
>> function - or, indeed, many of the 
>> "org.geotools.filter.function.FilterFunction_"
>> functions.
>>
>> I have a problem whereby application software is sending valid WFS
>> queries to Geoserver which include the "strToLowerCase" function.  For
>> performance reasons (dealing with large datasets) I need to have this
>> filter sent to the underlying Oracle database with a suitable "WHERE"
>> clause:
>>
>> WHERE LOWER(field_name) LIKE 'search_value%'
>>
>> This preferred database filtering is how PostGIS DataStores work when the
>> "Encode functions" option is enabled.
>>
>> *WORKING SOLUTION*
>> I have already confirmed (?) that the code change required to implement
>> this change in the gt-jdbc-oracle extension is minimal:
>>
>>
>> https://github.com/geotools/geotools/compare/22.2...djerrard:djerrard_oracle_filter?expand=1
>>
>> With these code changes in place I have rebuilt gt-jdbc-oracle-22.2.jar.
>> It is currently installed at a test site (Geoserver 2.16.2) where it's
>> getting a good thrashing - so far so good!
>>
>> *WHAT'S NEXT?*
>>
>>- I have never been here before
>>- I am not a java developer, so unable to provide any useful
>>technical contribution in that capacity
>>- I would obviously like to see this change incorporated into the
>>Geotools code base - possibly augmented with other similar Oracle plugin
>>enhancements (are there any others on the "wish list"?)
>>
>> In the spirit of the "Talk first policy" on the Contributions page, I'd
>> be happy to talk further.  (Also, thanks to Jody Garnett for the helpful
>> hints he's provided in that regard already.)
>>
>> Having delved deeper into this space than I've ever been before, I'm now
>> keen to see this through to a happy conclusion.  I also feel like I've got
>> some "skin in the game" and would be pleased to contribute in any way
>> possible.
>>
>> I look forward to the journey!
>>
>> Cheers,
>> David
>> ___
>> 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
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Online testing for Oracle, some questions on failing test

[Mark Prins]

Op di 21 apr. 2020 om 17:51 schreef Mark Prins :

> While working on this PR https://github.com/geotools/geotools/pull/2890
> to have Online testing of the Oracle JDBC module I'm running into some
> failing tests.
>

> OracleFeatureSourceOnlineTest>OnlineTestCase.run:112->JDBCFeatureSourceOnlineTest.testMixedEncodeIn:680
>
> expected:<[zero, two, 1, 2, 0.0]> but was:<[zero, two, 1, 2, 0.0]>
>
>
debugging shows that this test[1] is failing because:

literals = {ArrayList@4436}  size = 5
 0 = "zero"
 1 = "two"
 2 = {BigDecimal@4442} "1"
 3 = {BigDecimal@4443} "2"
 4 = {Double@} 0.0

expected = {Arrays$ArrayList@4451}  size = 5
 0 = "zero"
 1 = "two"
 2 = {Integer@4456} 1
 3 = {Integer@4457} 2
 4 = {Double@4458} 0.0

[1]
https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureSourceOnlineTest.java#L677

This is because Oracle uses BigDecimal for any Number...

My initial thought was to copy and overide the test into the Oracle
subclass, but that is basically made impossible becasue the test uses the
package private method "splitFilter" (
https://github.com/geotools/geotools/blob/7925c3f05470aceeab2c2188ea90959466ce0bd2/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L363
)
 so that won't fly..

My second best option is to extract getting the expected values into a
protected method so dialects can override that, so adding
to JDBCFeatureSourceOnlineTest the following method:

/**
* @return expected list for {@link #testMixedEncodeIn()}
*/
protected List getTestMixedEncodeInExpected (){
return Arrays.asList("zero", "two", 1, 2, 0d);
}

and adding to OracleFeatureSourceOnlineTest

/**
 * Because Oracle uses "Bigdecimal" for any number we need to change
the type of the objects that are in the list of expected objects.
 *
 * @return expected list for {@link #testMixedEncodeIn()}
 */
@Override
protected List getTestMixedEncodeInExpected() {
return Arrays.asList("zero", "two", BigDecimal.valueOf(1),
BigDecimal.valueOf(2), 0d);
}


Any other thoughts / ideas? I don't think it would be too useful to reduce
the test to compare two List instead?

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] geotools-master-owasp and geotools-master-owasp-check builds disabled on jenkins

[Mark Prins]

On 21-04-2020 14:16, Ian Turton wrote:
I'm happy to apply PRs so the build works again - I just felt after 8 
months of it failing continuously there was no real point in running it 
every day


I'll prepare a new PR for master Geotools (the old ones were outdated) 
and you can see if you like; the whole idea is that the job fails the 
build if a threshold is reached; ideally it should be combined with a 
service like Dependabot to automaically create PR's for dependency 
updates, though that wil generate noise as well.


I know some people are not too keen on these kind of notifications / noise.

Mark




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

[Geotools-devel] Online testing for Oracle, some questions on failing test

[Mark Prins]

While working on this PR https://github.com/geotools/geotools/pull/2890 
to have Online testing of the Oracle JDBC module I'm running into some 
failing tests.


Some may have to do with how the user is defined in Oracle, but one of 
the failures definitely isn't and the failure line is slightly cryptic:


OracleFeatureSourceOnlineTest>OnlineTestCase.run:112->JDBCFeatureSourceOnlineTest.testMixedEncodeIn:680 
expected:<[zero, two, 1, 2, 0.0]> but was:<[zero, two, 1, 2, 0.0]>


Basically the test compares 2 List, and as you can see the 
autoboxing to string yields the correct values.


Does anyone have an idea? any chance this is JDK related?
(I'm seeing the fail locally (open jdk 1.8.0_242) as wel as on Travis 
(also openjdk8: 1.8.0_242)


Any insights on the other 2 failing test are also welcome!

Getting unicorns on github, time to go home. Hope I didn't break 
anything there ;-).


Mark



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

Re: [Geotools-devel] geotools-master-owasp and geotools-master-owasp-check builds disabled on jenkins

[Mark Prins]

On 20-04-2020 16:48, Jody Garnett wrote:
Jim because it is a in someways a security check we will not speak on 
the mailing list. 


I find this odd, anyone can run this check on the dependencies used 
because it is open source and we're just talking about a procedure here.


In fact I have a GH action running the check for geoserver here: 
https://github.com/mprins/geoserver/actions?query=workflow%3A%22OWASP+dependency+check%22 
that I run occasionally.


I posted some PR's to update the plugin because it was way out of date; 
the main reason for failing in the first place; but closed them after 
Ian's mail the other day.


Mark




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

Re: [Geotools-devel] Online testing for SQL server

[Mark Prins]

Travis is giving a green light on this PR:
https://travis-ci.org/github/geotools/geotools/jobs/677166629 after I
disabled the failing testBBOX3DOutsideLine() test, there some issues with
the filter geometry loosing the 3-rd dimension in one or two locations in
the code, see https://osgeo-org.atlassian.net/browse/GEOT-6555 for more
details, probably similar to that test failing for Oracle (
https://osgeo-org.atlassian.net/browse/GEOT-6534)

I think this can be backported (I can/will when merged), as the
actual/effective code change is restricted to disabling the above mentioned
test and upgrading the microsoft jdbc driver (
https://osgeo-org.atlassian.net/browse/GEOT-6556)

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Online testing for SQL server

[Mark Prins]

I've just opened https://github.com/geotools/geotools/pull/2880 to bring
SQL server online testing as a job on Travis-CI as currently there seems no
environment that runs those. Right?

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

[Mark Prins]

If time permits could you guys look into the Oracle driver upgrades?
The PR's have been sitting there for a while now.

https://github.com/geotools/geotools/pull/2832
and
https://github.com/geoserver/geoserver/pull/4119

Thanks,
Mark


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Upgrade to ojdbc8 oracle driver?

[Mark Prins]

turns out the failures in "OraclePrimaryKeyFinderOnlineTest" were caused by
me having "schema=geotools" instead of "schema=GEOTOOLS" in my
~/.geotools/oracle.properties. (What was I thinking!...)

PR https://github.com/geotools/geotools/pull/2832 is now ready for review,
I've disabled the Oracle3DOnlineTest>OnlineTestCase.run:112->
JDBCGeneric3DOnlineTest.testBBOX3DOutsideLine testcase; I don't think it
will work / also fails on master. This leaves 435 test passing.

Mark


Op vr 13 mrt. 2020 om 12:38 schreef Mark Prins :

>
> Getting the exact same errors and failures when running with the master
> branch, so I'm going to ignore those for now; I looked at the
> testBBOX3DOutsideLine test and tried running the supposed select in my
> DBeaver, giving the same result, see below.
>
> git checkout master && git pull upstream master
> mvn clean install -Dall -T1.1C
> mvn clean install -Dall -pl :gt-jdbc-oracle -Ponline -T1.1C -Doracle=true
>
> gives me:
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]
> Oracle3DOnlineTest>OnlineTestCase.run:112->JDBCGeneric3DOnlineTest.testBBOX3DOutsideLine:181
> expected:<0> but was:<2>
> [ERROR]
> OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testSequencedPrimaryKey:46
> [ERROR] Errors:
> [ERROR]
> OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testAssignedMultiPKeyView:68
> » ClassCast
> [ERROR]
> OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testAssignedSinglePKeyView:56
> » ClassCast
> [ERROR]
> OracleTypeNamesOnlineTest>OnlineTestCase.run:112->JDBCTypeNamesOnlineTest.testTypeNames:30
> » NullPointer
> [INFO]
> [ERROR] Tests run: 435, Failures: 2, Errors: 3, Skipped: 0
> [INFO]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  11:30 min (Wall Clock)
> [INFO] Finished at: 2020-03-13T12:25:34+01:00
> [INFO]
> 
>
>
> It seems 3D filtering does not work, when I execute
>
> SELECT A.* FROM LINE3D A
> WHERE sdo_filter( A.GEOM, SDO_geometry( 3003, 4326, NULL,
> SDO_elem_info_array( 1, 1003, 3 ), SDO_ordinate_array( 2, 1, 100, 3, 2, 101
> ) ) ) = 'TRUE';
>
> Which is what I think the failing
> Oracle3DOnlineTest>OnlineTestCase.run:112->JDBCGeneric3DOnlineTest.testBBOX3DOutsideLine:181
> should be doing I also get both/all records returned.
>
> btw. I'm using "Oracle Oracle Database 12c Enterprise Edition Release
> 12.2.0.1.0 - 64bit Production" FWIW
>
> -M
>
> Op vr 13 mrt. 2020 om 10:42 schreef Ian Turton :
>
>> The 2nd error is saying that something it expected to write to is read
>> only.
>>
>> Ian
>>
>> On Thu, 12 Mar 2020 at 17:39, Mark Prins  wrote:
>>
>>> I've started factoring out the deprecations and seeing some test
>>> failures that don't seem related.
>>> So I'm curious if anybody ran the oracle online tests recently? and if
>>> there are known failures.
>>>
>>> Notably:
>>>
>>> =1=
>>> a failing test: Oracle3DOnlineTest#testBBOX3DOutsideLine() inherited
>>> from JDBCGeneric3DOnlineTest
>>>
>>> I see some WARNING messages in the output log about "3 dimensioned
>>> geometry provided. This encoder only supports 2D linestring geometries.
>>> The query will be constructed as a 2D query." so I'm wondering if this
>>> is expected because a 2D filter is used instead of a 3D
>>>
>>> =2=
>>> I see some messages "java.lang.ClassCastException:
>>> org.geotools.jdbc.JDBCFeatureSource cannot be cast to
>>> org.geotools.jdbc.JDBCFeatureStore"
>>>
>>> when the OraclePrimaryKeyFinderOnlineTest runs (all cases fail for that
>>> test)
>>>
>>> =3=
>>> I'm getting a NPE on the datastore in
>>> OracleTypeNamesOnlineTest#testTypeNames() that inherits from
>>> JDBCTypeNamesOnlineTest
>>>
>>> any hints or experiences are welcome;
>>> (I have yet to try and see the results with master)
>>>
>>> Mark
>>>
>>>
>>> On 09-03-2020 14:03, Mark Prins wrote:
>>> > Created:
>>> > - https://osgeo-org.atlassian.net/browse/GEOT-6529
>>> > - https://osgeo-org.atlassian.net/browse/GEOS-9535
>>> >
>>> > Will follo

Re: [Geotools-devel] Upgrade to ojdbc8 oracle driver?

[Mark Prins]

Getting the exact same errors and failures when running with the master
branch, so I'm going to ignore those for now; I looked at the
testBBOX3DOutsideLine test and tried running the supposed select in my
DBeaver, giving the same result, see below.

git checkout master && git pull upstream master
mvn clean install -Dall -T1.1C
mvn clean install -Dall -pl :gt-jdbc-oracle -Ponline -T1.1C -Doracle=true

gives me:

[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]
Oracle3DOnlineTest>OnlineTestCase.run:112->JDBCGeneric3DOnlineTest.testBBOX3DOutsideLine:181
expected:<0> but was:<2>
[ERROR]
OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testSequencedPrimaryKey:46
[ERROR] Errors:
[ERROR]
OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testAssignedMultiPKeyView:68
» ClassCast
[ERROR]
OraclePrimaryKeyFinderOnlineTest>OnlineTestCase.run:112->JDBCPrimaryKeyFinderOnlineTest.testAssignedSinglePKeyView:56
» ClassCast
[ERROR]
OracleTypeNamesOnlineTest>OnlineTestCase.run:112->JDBCTypeNamesOnlineTest.testTypeNames:30
» NullPointer
[INFO]
[ERROR] Tests run: 435, Failures: 2, Errors: 3, Skipped: 0
[INFO]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  11:30 min (Wall Clock)
[INFO] Finished at: 2020-03-13T12:25:34+01:00
[INFO]



It seems 3D filtering does not work, when I execute

SELECT A.* FROM LINE3D A
WHERE sdo_filter( A.GEOM, SDO_geometry( 3003, 4326, NULL,
SDO_elem_info_array( 1, 1003, 3 ), SDO_ordinate_array( 2, 1, 100, 3, 2, 101
) ) ) = 'TRUE';

Which is what I think the failing
Oracle3DOnlineTest>OnlineTestCase.run:112->JDBCGeneric3DOnlineTest.testBBOX3DOutsideLine:181
should be doing I also get both/all records returned.

btw. I'm using "Oracle Oracle Database 12c Enterprise Edition Release
12.2.0.1.0 - 64bit Production" FWIW

-M

Op vr 13 mrt. 2020 om 10:42 schreef Ian Turton :

> The 2nd error is saying that something it expected to write to is read
> only.
>
> Ian
>
> On Thu, 12 Mar 2020 at 17:39, Mark Prins  wrote:
>
>> I've started factoring out the deprecations and seeing some test
>> failures that don't seem related.
>> So I'm curious if anybody ran the oracle online tests recently? and if
>> there are known failures.
>>
>> Notably:
>>
>> =1=
>> a failing test: Oracle3DOnlineTest#testBBOX3DOutsideLine() inherited
>> from JDBCGeneric3DOnlineTest
>>
>> I see some WARNING messages in the output log about "3 dimensioned
>> geometry provided. This encoder only supports 2D linestring geometries.
>> The query will be constructed as a 2D query." so I'm wondering if this
>> is expected because a 2D filter is used instead of a 3D
>>
>> =2=
>> I see some messages "java.lang.ClassCastException:
>> org.geotools.jdbc.JDBCFeatureSource cannot be cast to
>> org.geotools.jdbc.JDBCFeatureStore"
>>
>> when the OraclePrimaryKeyFinderOnlineTest runs (all cases fail for that
>> test)
>>
>> =3=
>> I'm getting a NPE on the datastore in
>> OracleTypeNamesOnlineTest#testTypeNames() that inherits from
>> JDBCTypeNamesOnlineTest
>>
>> any hints or experiences are welcome;
>> (I have yet to try and see the results with master)
>>
>> Mark
>>
>>
>> On 09-03-2020 14:03, Mark Prins wrote:
>> > Created:
>> > - https://osgeo-org.atlassian.net/browse/GEOT-6529
>> > - https://osgeo-org.atlassian.net/browse/GEOS-9535
>> >
>> > Will follow up on those issues with PR's ASAP
>> >
>> > Mark
>> >
>> >
>> > On 02-03-2020 19:12, Jody Garnett wrote:
>> >> A PR would be great, and we can include the *Oracle Free Use Terms and
>> >> Conditions (FUTC)* license in the extension if that is what is
>> required.
>> >>
>> >> Also individual extensions can make notices in the server status
>> >> modules tab, if they want to report availability of a library, or link
>> >> to some license notice (if that is required in the running
>> application).
>> >> --
>> >> Jody Garnett
>> >>
>> >>
>> >> On Mon, 2 Mar 2020 at 02:45, Mark Prins > >> <mailto:mc.pr...@gmail.com>> wrote:
>> >>
>> >> On 13-12-2019 11:08, Jody Garnett wrote:
>> >>  > Following up on last meetings discussion on supporting oracle:
>> >> Oracle
>> >>  

Re: [Geotools-devel] Upgrade to ojdbc8 oracle driver?

[Mark Prins]

I've started factoring out the deprecations and seeing some test 
failures that don't seem related.
So I'm curious if anybody ran the oracle online tests recently? and if 
there are known failures.


Notably:

=1=
a failing test: Oracle3DOnlineTest#testBBOX3DOutsideLine() inherited 
from JDBCGeneric3DOnlineTest


I see some WARNING messages in the output log about "3 dimensioned 
geometry provided. This encoder only supports 2D linestring geometries. 
The query will be constructed as a 2D query." so I'm wondering if this 
is expected because a 2D filter is used instead of a 3D


=2=
I see some messages "java.lang.ClassCastException: 
org.geotools.jdbc.JDBCFeatureSource cannot be cast to 
org.geotools.jdbc.JDBCFeatureStore"


when the OraclePrimaryKeyFinderOnlineTest runs (all cases fail for that 
test)


=3=
I'm getting a NPE on the datastore in 
OracleTypeNamesOnlineTest#testTypeNames() that inherits from 
JDBCTypeNamesOnlineTest


any hints or experiences are welcome;
(I have yet to try and see the results with master)

Mark


On 09-03-2020 14:03, Mark Prins wrote:

Created:
- https://osgeo-org.atlassian.net/browse/GEOT-6529
- https://osgeo-org.atlassian.net/browse/GEOS-9535

Will follow up on those issues with PR's ASAP

Mark


On 02-03-2020 19:12, Jody Garnett wrote:

A PR would be great, and we can include the *Oracle Free Use Terms and
Conditions (FUTC)* license in the extension if that is what is required.

Also individual extensions can make notices in the server status 
modules tab, if they want to report availability of a library, or link 
to some license notice (if that is required in the running application).

--
Jody Garnett


On Mon, 2 Mar 2020 at 02:45, Mark Prins <mailto:mc.pr...@gmail.com>> wrote:


    On 13-12-2019 11:08, Jody Garnett wrote:
 > Following up on last meetings discussion on supporting oracle:
    Oracle
 > JDBC drivers on Maven Central
 >

<https://medium.com/oracledevs/oracle-jdbc-drivers-on-maven-central-64fcf724d8b> 


 >
 > Based on the I would like to remove the manual process of 
installing

 > ojdbc7 into your local repo, and replace with something like:
 >
 >      
 >       com.oracle.ojdbc
 >       ojdbc8
 >       19.3.0.0
 >      
 >
 > Can I ask if anyone is using odjbc8 already?

    I don't think this happened yet has it?

    Oracle's first try at using Maven central was nearly succesful;
    advancing insights made them decide to move the drivers to diffent
    groupId's as described in the post om medium [1]

    the TLDR:
    - all versions now available (19.3.0.0, 18.3.0.0, 12.2.0.1 and some
    11.2.0.4)
    - new groupId for production jar's at com.oracle.database.jdbc
    - net groupId for debug jars (postfixed with _g) at
    com.oracle.database.jdbc.debug
    - all have sources + javadoc jar's as required

    so above snippet should be

      
        com.oracle.database.jdbc
        ojdbc8
        19.3.0.0
      

    for production use, or

      
        com.oracle.database.jdbc.debug
        ojdbc8_g
        19.3.0.0
      

    for debugging.

    I can prepare a PR if you like.

    Not sure where to a a note about the license "Oracle Free Use 
Terms and

    Conditions (FUTC)"
    (I think that would only concern geoserver as that would/could
    distribute the driver jar with the extension. Some lawyer should 
decide

    on that I guess.)

    [1]

https://medium.com/@kuassimensah/all-in-and-new-groupids-oracle-jdbc-drivers-on-maven-central-a76d545954c6 






    ___
    GeoTools-Devel mailing list
    GeoTools-Devel@lists.sourceforge.net
    <mailto: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] Upgrade to ojdbc8 oracle driver?

[Mark Prins]

Created:
- https://osgeo-org.atlassian.net/browse/GEOT-6529
- https://osgeo-org.atlassian.net/browse/GEOS-9535

Will follow up on those issues with PR's ASAP

Mark


On 02-03-2020 19:12, Jody Garnett wrote:

A PR would be great, and we can include the *Oracle Free Use Terms and
Conditions (FUTC)* license in the extension if that is what is required.

Also individual extensions can make notices in the server status modules 
tab, if they want to report availability of a library, or link to some 
license notice (if that is required in the running application).

--
Jody Garnett


On Mon, 2 Mar 2020 at 02:45, Mark Prins <mailto:mc.pr...@gmail.com>> wrote:


On 13-12-2019 11:08, Jody Garnett wrote:
 > Following up on last meetings discussion on supporting oracle:
Oracle
 > JDBC drivers on Maven Central
 >

<https://medium.com/oracledevs/oracle-jdbc-drivers-on-maven-central-64fcf724d8b>
 >
 > Based on the I would like to remove the manual process of installing
 > ojdbc7 into your local repo, and replace with something like:
 >
 >      
 >       com.oracle.ojdbc
 >       ojdbc8
 >       19.3.0.0
 >      
 >
 > Can I ask if anyone is using odjbc8 already?

I don't think this happened yet has it?

Oracle's first try at using Maven central was nearly succesful;
advancing insights made them decide to move the drivers to diffent
groupId's as described in the post om medium [1]

the TLDR:
- all versions now available (19.3.0.0, 18.3.0.0, 12.2.0.1 and some
11.2.0.4)
- new groupId for production jar's at com.oracle.database.jdbc
- net groupId for debug jars (postfixed with _g) at
com.oracle.database.jdbc.debug
- all have sources + javadoc jar's as required

so above snippet should be

      
        com.oracle.database.jdbc
        ojdbc8
        19.3.0.0
      

for production use, or

      
        com.oracle.database.jdbc.debug
        ojdbc8_g
        19.3.0.0
      

for debugging.

I can prepare a PR if you like.

Not sure where to a a note about the license "Oracle Free Use Terms and
Conditions (FUTC)"
(I think that would only concern geoserver as that would/could
distribute the driver jar with the extension. Some lawyer should decide
on that I guess.)

[1]

https://medium.com/@kuassimensah/all-in-and-new-groupids-oracle-jdbc-drivers-on-maven-central-a76d545954c6




___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto: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] Upgrade to ojdbc8 oracle driver?

[Mark Prins]

On 13-12-2019 11:08, Jody Garnett wrote:
Following up on last meetings discussion on supporting oracle: Oracle 
JDBC drivers on Maven Central 



Based on the I would like to remove the manual process of installing 
ojdbc7 into your local repo, and replace with something like:


     
      com.oracle.ojdbc
      ojdbc8
      19.3.0.0
     

Can I ask if anyone is using odjbc8 already?


I don't think this happened yet has it?

Oracle's first try at using Maven central was nearly succesful; 
advancing insights made them decide to move the drivers to diffent 
groupId's as described in the post om medium [1]


the TLDR:
- all versions now available (19.3.0.0, 18.3.0.0, 12.2.0.1 and some 
11.2.0.4)

- new groupId for production jar's at com.oracle.database.jdbc
- net groupId for debug jars (postfixed with _g) at 
com.oracle.database.jdbc.debug

- all have sources + javadoc jar's as required

so above snippet should be


  com.oracle.database.jdbc
  ojdbc8
  19.3.0.0


for production use, or


  com.oracle.database.jdbc.debug
  ojdbc8_g
  19.3.0.0


for debugging.

I can prepare a PR if you like.

Not sure where to a a note about the license "Oracle Free Use Terms and 
Conditions (FUTC)"
(I think that would only concern geoserver as that would/could 
distribute the driver jar with the extension. Some lawyer should decide 
on that I guess.)


[1] 
https://medium.com/@kuassimensah/all-in-and-new-groupids-oracle-jdbc-drivers-on-maven-central-a76d545954c6





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

Re: [Geotools-devel] GSIP 189 - Control remote HTTP requests send by GeoTools \ GeoServer

[Mark Prins]

On 28-02-2020 12:20, Imran Rajjad wrote:

Dear All,
I would like to submit the following GSIP : 
https://github.com/geoserver/geoserver/wiki/GSIP-189


*Some Background and Context:*
**
Geotools and Geoserver make a lot of HTTP calls, internally and 
externally for different purposes which include



  * Downloading Schemas
  * Requesting Online Images and Resources
  * Loading remote SLDs
  * Working with remote OGC servers
  * Other Misc calls that involve access resources outside the Data
Directory


In some production environments this can be seen as a potential security 
loop hole where developers/users have no way of controlling what is 
being accessed. Hence a new Interface is proposed to implement URL 
validation before making the HTTP call.


Geoserver will receive its de-facto implementation of this interface in 
which URLs will be validated through Regex expressions configured 
through Web Admin interface. By default Geoserver will have a number of 
known URLs allowed (e.g OGC Schema URls etc)


Complete details are included on the proposal. Looking forward to 
everyone`s feedback




instead of having a whitelist of allowed domains which is prone to fail 
for subdomains I would think about having a default regex that will just 
allow anything, or allow anything by default until a rule is added.


-M



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

Re: [Geotools-devel] GeoTools / GeoServer PMC meeting - 2019-02-04

[Mark Prins]

On 10-02-2020 11:12, Jody Garnett wrote:

Created the following trac tickets:

- artifact manager to replace download.osgeo.org/webdav/geotools 



This is pointing to the wrong ticket, should be 
https://trac.osgeo.org/osgeo/ticket/2410


Also if a choice was made for Nexus, that could also take care of 
https://trac.osgeo.org/osgeo/ticket/2385 (docker regisitry) as that can 
be provided by Nexus


-M


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

Re: [Geotools-devel] GeoTools 22.3 Release - Artifacts ready for testing

[Mark Prins]

Does this mean there will be no 22.2 release?...
(and any 22.2 artifacts should be purged)

tia, Mark


On 20-01-2020 12:57, Alessandro Parma wrote:

Hi all,

Artifacts available here 
, 
please test and report any issues.


--

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.




___
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] jai-codec not compatible with OpenJDK (not directly GeoTools related)

[Mark Prins]

On 10-12-19 10:29, Marco Peters wrote:

Hi,

This is a question not directly related to GeoTools but maybe you can 
help me anyway. If you think this question is not appropriate here, then 
feel free to ignore or delete it.


GeoTools is one of the rare projects who is still using jai. We, the ESA 
SNAP (https://step.esa.int ) project also still 
use it.


Now, we want to migrate to OpenJDK and noticed that JAI uses classes 
from the com.sun.image.codec.* package which is not any longer available 
in OpenJDK.


The usage is for example in the class 
com.sun.media.jai.codecimpl.JPEGImageDecoder.So, we can’t read jpeg files 
anymore.

How have you solved this? Are you reading images differently now? Have 
you patched the JAI library?


there is a replacement from Geosolutions called JAI-ext that was dropped 
into geotools some years ago, in any case geotools now runs just fine on 
both openjdk 8 and 11, afaik without native jai


see: https://github.com/geosolutions-it/jai-ext



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

Re: [Geotools-devel] jars with timestamp in Geotools repo

[Mark Prins]

On 04-12-19 17:58, Jody Garnett wrote:

That is interesting, I added some notes to the ticket...
- the extensions package jars using SNAPSHOT
- the war includes geoserver jars using SNAPSHOT, and geotools jars 
using timestamp


We could experiment with setting false ?


I think that will only work for the "maven-deploy-plugin" plugin and for 
old versions < 3.0.0)


As noted on the plugin page:

Major Version Upgrade to version 3.0.0
Please note that the following parameter has been completely removed 
from the plugin configuration:

  uniqueVersion
As of Maven 3, snapshot artifacts will always be deployed using a 
timestamped version.



The problem is probably caused by having artifacts from both remote 
repository as well as locally built artifacts in the local repo.


-M



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

Re: [Geotools-devel] Build failed in Jenkins: geotools-java11 #476

[Mark Prins]

On 25-09-19 09:16, Andrea Aime wrote:
These errors keep on popping up, anyone has figured out what's going on? 
The file system seems to be extremely unstable
for some reason, files not found, files that are not files maybe 
Amazon is pulling the node away from the fleet and it starts by

unloading the file system?


Perhaps the workspace cleanup that Jenkins does in another job causes this?

I noticed that the job is doing:

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
[WS-CLEANUP] Done

While the Jenkins plugin docs say:


== Disable deferred wipeout method ==

In particular deployment (e.g. cloud) it might be useful to be sure 
deferred wipeout is never selected as a cleanup method. Therefore there 
is a new feature introduced to do this, implemented via regular 
NodeProperty which you can attach to any node via UI or via script like:


https://plugins.jenkins.io/ws-cleanup


Also I never ever use /tmp for storing anything I need to hang on to for 
more than a little while there are unix variants that have a /tmp 
cleanup running at midnight or after resuming from "sleep", so perhaps 
something like that? the builds are running from /tmp/jenkins-xx.../


-M


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

Re: [Geotools-devel] Setting the map background color in the style (small change from OGC Testbed 15)

[Mark Prins]

Op wo 11 sep. 2019 om 19:23 schreef Andrea Aime <
andrea.a...@geo-solutions.it>:

>
> The giant polygon approach has been labelled as clumsy and ineffective,
> and indeed, I have to agree:
>
>- Why expose a dedicated, user visible layer with a massive polygon
>just to set the color of the painting canvas
>
> I thought this would be possible using a /
/?
Though I will readily agree that having a  at some level is much
easier.

Mark
-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] gt-epsg-hsql gets dragged in by gt-wmts through gt-tile-client

[Mark Prins]

Opened https://osgeo-org.atlassian.net/browse/GEOT-6341 , will provde PR
and we'll see how that rolls out

-M

Op do 11 jul. 2019 om 15:00 schreef Andrea Aime <
andrea.a...@geo-solutions.it>:

> I may be wrong, but for other modules normally gt-epsg-hsql is included
> for running tests but any epsg
> factory does the job for runtime.
> I'd just demote the dependency scope to tests (but I'm not the maintainer
> of the module).
>
> Cheers
> Andrea
>
>
> On Thu, Jul 11, 2019 at 2:57 PM Mark Prins  wrote:
>
>> We've got an application where we prefer to use the gt-epsg-wkt artifact,
>> but it is also using the gt-wmts artifact which has dependency
>> on gt-tile-client which has gt-epsg-hsql as a dependency so we end up with
>> both the wkt as well as the hsql version in our final package; it doesn't
>> seem to cause any problems (I don't see any Factory exceptions that the FAQ
>> talks about [1]) but I would think that the tile client should be using a
>> different scope for the epsg library (eg. test like the gt-wms module)
>> because it makes it hard to choose a certain EPSG over the hsql version.
>> (yes I can - as a workaround - add exclusions in my projects pom file)
>>
>> mvn dependency:tree snippet:
>>
>> [INFO] +- org.geotools:gt-wmts:jar:21.2:compile
>> [INFO] |  +- org.geotools:gt-tile-client:jar:21.2:compile
>> [INFO] |  |  +- org.geotools:gt-epsg-hsql:jar:21.2:compile
>> [INFO] |  |  \- commons-httpclient:commons-httpclient:jar:3.1:compile
>>
>> Section  in the tile-client pom:
>>
>>
>> https://github.com/geotools/geotools/blob/22c9e4a80aff47731feb174b97c5dbef3dc373b0/modules/extension/tile-client/pom.xml#L84-L88
>>
>>
>> [1]
>> https://docs.geotools.org/latest/userguide/library/referencing/faq.html#q-how-to-choose-an-epsg-authority
>>
>>
>> Mark
>>
>> --
>> Disclaimer;
>> This message is just a reflection of what I thought at the time of
>> sending. The message may contain information that is not intended for you
>> or that you don't understand.
>> ___
>> 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.*
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] gt-epsg-hsql gets dragged in by gt-wmts through gt-tile-client

[Mark Prins]

We've got an application where we prefer to use the gt-epsg-wkt artifact,
but it is also using the gt-wmts artifact which has dependency
on gt-tile-client which has gt-epsg-hsql as a dependency so we end up with
both the wkt as well as the hsql version in our final package; it doesn't
seem to cause any problems (I don't see any Factory exceptions that the FAQ
talks about [1]) but I would think that the tile client should be using a
different scope for the epsg library (eg. test like the gt-wms module)
because it makes it hard to choose a certain EPSG over the hsql version.
(yes I can - as a workaround - add exclusions in my projects pom file)

mvn dependency:tree snippet:

[INFO] +- org.geotools:gt-wmts:jar:21.2:compile
[INFO] |  +- org.geotools:gt-tile-client:jar:21.2:compile
[INFO] |  |  +- org.geotools:gt-epsg-hsql:jar:21.2:compile
[INFO] |  |  \- commons-httpclient:commons-httpclient:jar:3.1:compile

Section  in the tile-client pom:

https://github.com/geotools/geotools/blob/22c9e4a80aff47731feb174b97c5dbef3dc373b0/modules/extension/tile-client/pom.xml#L84-L88


[1]
https://docs.geotools.org/latest/userguide/library/referencing/faq.html#q-how-to-choose-an-epsg-authority


Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Coordinate Reference System Error

[Mark Prins]

Op vr 29 mrt. 2019 17:53 schreef Zhang, Jack :

> Hi,
>
>
>
> I’m facing an error where I’m trying to create the EPSG:4326 coordinate.
>
>
>
> I’m using the GeoTools 20.3, added all those jar libraries to my build
> path.
>
>
>
> I run the following program and got errors (see below). I suspect
> something about my environment is not set up correctly, any thoughts?
>
>
>
You are probably either missing an implementation of the crs/referencing
store or have more than one in your runtime classpath. Adding all the jar
files is not the way to go.
See:
Referencing FAQ
http://docs.geotools.org/latest/userguide/faq.html#referencing-faq

Thanks,
>
>
>
> *import* org.geotools.referencing.CRS;
>
> *import* org.opengis.referencing.FactoryException;
>
> *import* org.opengis.referencing.crs.CoordinateReferenceSystem;
>
>
>
> *public* *class* Testing
>
> {
>
>
>
>*public* *static* *void* main(String[] args)
>
>{
>
>   *try*
>
>   {
>
>  CoordinateReferenceSystem *crs* = CRS.*decode*("EPSG:4326");
>
>   }
>
>   *catch* (FactoryException e)
>
>   {
>
>  // *TODO* Auto-generated catch block
>
>  e.printStackTrace();
>
>   }
>
>}
>
>
>
> }
>
>
>
> Mar 29, 2019 9:38:12 AM org.geotools.factory.FactoryRegistry scanForPlugins
>
> WARNING: Can't load a service for category "CRSAuthorityFactory". Cause is
> "ServiceConfigurationError:
> org.opengis.referencing.crs.CRSAuthorityFactory: Provider
> org.geotools.referencing.factory.epsg.CartesianAuthorityFactory could not
> be instantiated".
>
> java.util.ServiceConfigurationError:
> org.opengis.referencing.crs.CRSAuthorityFactory: Provider
> org.geotools.referencing.factory.epsg.CartesianAuthorityFactory could not
> be instantiated
>
>at java.util.ServiceLoader.fail(Unknown Source)
>
>at java.util.ServiceLoader.access$100(Unknown Source)
>
>at java.util.ServiceLoader$LazyIterator.nextService(Unknown Source)
>
>at java.util.ServiceLoader$LazyIterator.next(Unknown Source)
>
>at java.util.ServiceLoader$1.next(Unknown Source)
>
>at org.geotools.factory.FactoryRegistry.register(
> *FactoryRegistry.java:1042*)
>
>at org.geotools.factory.FactoryRegistry.scanForPlugins(
> *FactoryRegistry.java:921*)
>
>at org.geotools.factory.FactoryRegistry.scanForPluginsIfNeeded(
> *FactoryRegistry.java:951*)
>
>at org.geotools.factory.FactoryRegistry.getFactories(
> *FactoryRegistry.java:299*)
>
>at org.geotools.referencing.ReferencingFactoryFinder.getFactories(
> *ReferencingFactoryFinder.java:184*)
>
>at
> org.geotools.referencing.ReferencingFactoryFinder.getCRSAuthorityFactories(
> *ReferencingFactoryFinder.java:454*)
>
>at
> org.geotools.referencing.DefaultAuthorityFactory.getBackingFactory(
> *DefaultAuthorityFactory.java:88*)
>
>at org.geotools.referencing.DefaultAuthorityFactory.(
> *DefaultAuthorityFactory.java:68*)
>
>at org.geotools.referencing.CRS.getAuthorityFactory(*CRS.java:246*)
>
>at org.geotools.referencing.CRS.decode(*CRS.java:517*)
>
>at org.geotools.referencing.CRS.decode(*CRS.java:440*)
>
>at ca.airradar.common.formats.rpf.Testing.main(*Testing.java:14*)
>
> Caused by: java.lang.NoSuchFieldError: ONE
>
>at org.geotools.referencing.cs.DefaultCoordinateSystemAxis.(
> *DefaultCoordinateSystemAxis.java:541*)
>
>at org.geotools.referencing.cs.AbstractCS.(
> *AbstractCS.java:80*)
>
>at org.geotools.referencing.crs.DefaultEngineeringCRS.(
> *DefaultEngineeringCRS.java:79*)
>
>at
> org.geotools.referencing.factory.epsg.CartesianAuthorityFactory.(
> *CartesianAuthorityFactory.java:55*)
>
>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(*Native
> Method*)
>
>at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source)
>
>at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
>
>at java.lang.reflect.Constructor.newInstance(Unknown Source)
>
>at java.lang.Class.newInstance(Unknown Source)
>
>... 15 more
>
>
>
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class org.geotools.referencing.cs.DefaultCoordinateSystemAxis
>
>at
> org.geotools.referencing.factory.TransformedAuthorityFactory.(
> *TransformedAuthorityFactory.java:70*)
>
>at org.geotools.referencing.factory.epsg.DirectEpsgFactory.(
> *DirectEpsgFactory.java:533*)
>
>at org.geotools.referencing.factory.epsg.FactoryUsingSQL.(
> *FactoryUsingSQL.java:53*)
>
>at org.geotools.referencing.factory.epsg.FactoryUsingAnsiSQL.(
> *FactoryUsingAnsiSQL.java:122*)
>
>at org.geotools.referencing.factory.epsg.FactoryUsingHSQL.(
> *FactoryUsingHSQL.java:51*)
>
>at
> org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory$1.(
> *ThreadedHsqlEpsgFactory.java:312*)
>
>at
> 

Re: [Geotools-devel] 19-RC1 release starting up

[Mark Prins]

FWIW; I've set up two of our projects to run with 19-RC1 and our
builds/testsuites are passing fine.

Mark


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Trouble using WFS-NG DataStore with https

[Mark Prins]

2017-12-13 6:02 GMT+01:00 Jim Hughes :

> Hi all,
>
> So I'm slow on the uptake tonight...  In the event that the remote server
> is a GeoServer, then the Global settings proxy base url (
> http://docs.geoserver.org/latest/en/user/configuration/glob
> alsettings.html#proxy-base-url) can be set to sort this issue out.
>
> I suppose it might still be worth considering if the GeoTools WFS-NG
> datastore should have a work-around for a 'broken' environment?
>
>
Broken isn't a very well defined state, it's quite a valid use case to have
(valid ofcourse) urls pointing all over the place.

wrt following redirects; as geotools is still on an old version of apache
httpclient which doesn't provide this functionality (see eg.
https://hc.apache.org/httpclient-legacy/redirects.html for a workaround)
I've started porting to the new version, but it will take a while.
Also there are some know issues and vulnerabilities with this apache lib
when used in a TLS environment, see
https://osgeo-org.atlassian.net/browse/GEOT-5859

Mark




-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools PMC meeting, November 14th 2017

[Mark Prins]

Op 14 nov. 2017 18:57 schreef "Andrea Aime"


Q: Can we build with Java 9 on Travis?


You can add "oraclejdk9" to the "jdk" section, until recently the travis
build image had an out-of-date version so it required updating, I have an
example of doing that here:
https://github.com/GeoDienstenCentrum/closure-compiler-maven-plugin/blob/master/.travis.yml

I can cook up a pr for master if you like.

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

[Geotools-devel] upgrading JDom

[Mark Prins]

Hi,
While upgrading and porting some of our legacy applications I noticed
GeoTools 18 is using JDom 1.1.3 which is a fairly old version. (and
dragging it back in)
At some point in time the JDom project decided to rename their packages
(or.jdom -> org.jdom2) which bit me because the old jdom was still around
as a transitive dependency...
JDom itself only has some optional dependencies, so that shouldn't be a big
deal.

I could prepare a PR for upgrading both GeoTools and Geoserver to the
current release which is 2.0.6 [1] if there is an interest.
If so, should that be against master only or 18.x / 2.12.x as well? ( I'm
not sure it would change any public API signatures eg. returning an
org.jdom2.Element instead of an org.jdom.Element)

[1] http://jdom.org/

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Geotools NullPointerException

[Mark Prins]

Op 29 sep. 2017 20:31 schreef "Edgardo Antuna" :


Geoserver version = 2.8.3

Geoserver git revision = 1c8c9ba0f74a465c397d46cf19d3b34b95b2fb6e

Geoserver build date = 22-Mar-2016 21:12

Geotools version = 14.3 (rev 2298d56000bef6f526b521a480316ea544c74571)

Tomcat version = 8.0.30
Java version = 1.8.0.72 64-bit


It would be interesting to see if you can reproduce this with a supported,
current version, as what you are using atm is overdue for upgrading.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] java 8 eol --> java 9 compatibility

[Mark Prins]

Java 8 will be around in a supported form a little longer than Jody
suggests, eg. Redhat will support Java 8 until October 2020 [1], IBM lists
April 2020 as eol [2] for the non z/OS systems.

[1] https://access.redhat.com/articles/1299013
[2] https://developer.ibm.com/javasdk/support/lifecycle/





-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5795) WARNING: java.lang.ClassNotFoundException: org.geotools.data.wfs.v1_0_0.xml.WFSSchema

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5795  
 
 
  WARNING: java.lang.ClassNotFoundException: org.geotools.data.wfs.v1_0_0.xml.WFSSchema   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 18-beta, 17.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 wfs-ng  
 
 
Created: 
 01/Aug/17 2:36 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 When loading a WFS cpas file I'm seeing the following message popup in my logs: {{ Aug 01, 2017 2:05:14 PM org.geotools.xml.SchemaFactory loadSchemas WARNING: java.lang.ClassNotFoundException: org.geotools.data.wfs.v1_0_0.xml.WFSSchema }} supposedly because there is a services file in wfs-ng that lists this class, and only this class. I have tried to find an class WFSSchema, but have been unable to find this, even by any other package, so I guess this sort of slipped in in the past.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] GeoJSON Java version requirement

[Mark Prins]

On 06-07-17 02:46, fragmenter wrote:

​Hello,

I saw that only the version 14.x and below of geotools can be compiled 
in Java 1.7. But GeoJSON is not available in those versions. Is there 
anyway to get just the GeoJSON module compiled to 1.7? (With 14.5 
version of the main library) Due to unfortunate reasons, I cannot use 
JDK 1.8 in my project. Any workarounds with this?


The geojson module is in 14.x 
(https://github.com/geotools/geotools/tree/14.x/modules/unsupported/geojson), 
not sure why you think it isn't.


The geojsonstore module 
(https://github.com/geotools/geotools/tree/15.x/modules/unsupported/geojsonstore) 
didn't appear until 15.x, you may be able to backport that or maybe it 
will just compile against 14.5, the number of dependecies seems limited 
so I can imagine this being quite possible.


that being said, I wouldn't want to be using such an old version of the 
library knowing that there have been quite a number of bugfixes applied.


Mark

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

Re: [Geotools-devel] Still seeing timeouts for 17.X travis builds

[Mark Prins]

On 30-06-17 18:34, Ian Turton wrote:
I notice that we seem to be having more success for master builds now 
but I'm still seeing timeouts for the 17.x builds. Is there something 
that was done to the master repo that needs repeating for 17.x?


See 
https://travis-ci.org/geotools/geotools/builds/246378917?utm_source=github_status_medium=notification


Ian


It may be an idea to split the build and test like we do here: 
https://github.com/flamingo-geocms/flamingo/blob/master/.travis.yml


basically do a full build/install during travis "install" without 
testing and then in the "script" stage execute the unit tests


something like:

install:
  - mvn -B -fae -T4.2C -Dall clean install -DskipTests -q

script:
  - mvn -B -fae -T1C -Dall test

YMMV, Mark

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

[Geotools-devel] Adding Oracle hints eg. /* + APPEND_VALUES */ to PS

[Mark Prins]

Hi,
According to an oracle admin eg. inserts could benefit from adding (oracle
specific) hints to the sql statements.

At this time I don't have funding/assignment to work on this, so this
message is to check if it would be something people would like to see/have.

I've looked at the private
org.geotools.jdbc.JDBCDataStore#buildInsertPS(InsertionClassifier kind,
SimpleFeatureType featureType, KeysFetcher keysFetcher,
PreparedStatementSQLDialect dialect) method [0] which generates the insert
prepared statement.

My idea would be to add some way eg. a Hints object maybe? or perhaps
the OracleDialect could be changed to provide the hint to add the /*+
APPEND_VALUES*/ hint to the sql statement so that:

   INSERT INTO RSGBBGTITEST.OVERBRUGGINGSDEEL (
DAT_BEG_GELDH,DATUM_EINDE_GELDH,RELVE_HOOGTELIGGING,...) VALUES ( ?,?,?,...)
would become
   INSERT /*+ APPEND_VALUES */ INTO RSGBBGTITEST.OVERBRUGGINGSDEEL (
DAT_BEG_GELDH,DATUM_EINDE_GELDH,RELVE_HOOGTELIGGING,...) VALUES ( ?,?,?,...)

more about direct-path insert hints in the oracle docs:
https://docs.oracle.com/cd/E11882_01/server.112/e25494/tables.htm#ADMIN01509

[0]
https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCDataStore.java#L1802


Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] XML Binding Generation?

[Mark Prins]

Op 7 apr. 2017 11:03 schreef "Ian Turton" :



Personally I'd lean towards JAXB as it is built in and the OGC provide
prebuilt jars (https://repo1.maven.org/maven2/org/jvnet/ogc/) for most of
their standards. But as JABX is currently the only XML technology we don't
use I'm wary of adding yet another XML technology to our stack.



The sources can be found at https://github.com/highsource/ogc-schemas

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

Re: [Geotools-devel] A quick question on GEOT-724 (PR 1228)

[Mark Prins]

On 16-09-16 10:53, Mark Prins wrote:

> I can prep backport pull requests for the branches if there is interest
> so it can be included in 15.2

I've gone ahead and prepared backport PR's since 15.2 release is planned 
shortly

https://github.com/geotools/geotools/pull/1312
https://github.com/geotools/geotools/pull/1313

Mark

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

[Geotools-devel] A quick question on GEOT-724 (PR 1228)

[Mark Prins]

Hi,
Ian prepared/merged a fix for empty/null geometries in Oracle in PR 1228 [
https://github.com/geotools/geotools/pull/1228], closing Jira GEOT-724 [
https://osgeo-org.atlassian.net/browse/GEOT-724]. Jira tells me that this
was fixed for 16-M0
I'm trying to find out is this was backported to 15.x and/or 14.x

As far as I can tell it's not on the 14-branch (looking at the history:
https://github.com/geotools/geotools/compare/14.3...14.x) and not on the
15.x branch either (https://github.com/geotools/geotools/compare/15.0...15.x
)

Also I noticed the tag for 16-M0 seems to be missing on Github (while the
artifacts have been published), someone may still need to "git push --tags"

I can prep backport pull requests for the branches if there is interest so
it can be included in 15.2

Mark


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [JIRA] (GEOT-5512) inserting CompoundCurve w/ Arc part (circularstring) fails in mssql

[Mark Prins]

I can probably have a crack at this over the week; but might need some help.
it's a bummer not at least supporting those possible curve types (ie
COMPOUNDCURVE
and CURVEPOLYGON)

Mark


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5512) inserting CompoundCurve w/ Arc part (circularstring) fails in mssql

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5512  
 
 
  inserting CompoundCurve w/ Arc part (circularstring) fails in mssql   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Affects Versions: 
 14.5  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 jdbc-sqlserver plugin  
 
 
Created: 
 05/Sep/16 4:52 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 Transforming the below feature and trying to insert into a mssqlserver database (on both mssql2012 and mssql2016) fails on the "kruinlijn" geometry (the polygon seems to be fine) (same feature inserts just fine on postgresql/postgis and oracle) GML 

 

"1.0" encoding="UTF-8"?>
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:imgeo-s="http://www.geostandaarden.nl/imgeo/2.1/simple/gml31" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gml="http://www.opengis.net/gml" xsi:schemaLocation="http://www.geostandaarden.nl/imgeo/2.1/simple/gml31 imgeo-simple-2.1-gml31.xsd http://www.opengis.net/gml http://schemas.opengis.net/gml/3.1.1/base/gml.xsd">
  
"b64a9a08a-031a-11e6-b420-2bdcc4ab5d7f">
  2016-03-08
  NL.IMGeo
  G1699.2d8ccd18a08f7da5e05332a1e90adfb4
  2016-03-08T18:21:50.000
  2016-04-13T09:22:32.000
  G1699
  false
  0
  bestaand
  true
  transitie
  
xmlns:gml="http://www.opengis.net/gml">
  

  

  

  226080.978 573035.586 226076.665 573034.943 226072.730 573033.058
 

Re: [Geotools-devel] [JIRA] (GEOT-5508) A NPE can occur when calling CompoundCurve.isRectangle()

[Mark Prins]

I have prepared PR's to fix this this:
https://github.com/geotools/geotools/pull/1297 (master)
and backports:  https://github.com/geotools/geotools/pull/1298 (15.x) and
https://github.com/geotools/geotools/pull/1299 (14.x)


Mark


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5508) A NPE can occur when calling CompoundCurve.isRectangle()

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5508  
 
 
  A NPE can occur when calling CompoundCurve.isRectangle()   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Affects Versions: 
 15.1, 14.5, 16-M0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 api  
 
 
Created: 
 05/Sep/16 9:13 AM  
 
 
Priority: 
  High  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 When calling the isRectangle() method on a CompoundCurve it can throw a NullPointerException because the linearized member has not been initialized. A typical stacktrace looks like:  


 java.lang.NullPointerException
	at org.geotools.geometry.jts.CompoundCurve.isRectangle(CompoundCurve.java:377)
	at org.geotools.geometry.jts.CompoundRing.isRectangle(CompoundRing.java:158)
	at org.geotools.data.oracle.sdo.GeometryConverter.toSDO(GeometryConverter.java:172)
	at org.geotools.data.oracle.OracleDialect.setGeometryValue(OracleDialect.java:596)
	at org.geotools.jdbc.JDBCDataStore.insertSQLPS(JDBCDataStore.java:4161)
	at org.geotools.jdbc.JDBCDataStore.insert(JDBCDataStore.java:1675)
	at org.geotools.jdbc.JDBCDataStore.insert(JDBCDataStore.java:1638)
	at org.geotools.jdbc.JDBCInsertFeatureWriter.write(JDBCInsertFeatureWriter.java:76)
	at org.geotools.data.InProcessLockingManager$1.write(InProcessLockingManager.java:337)
	at org.geotools.data.store.ContentFeatureStore.addFeature(ContentFeatureStore.java:309)
	at org.geotools.data.store.ContentFeatureStore.addFeatures(ContentFeatureStore.java:263)
	at nl.b3p.brmo.loader.gml.BGTGMLLightLoader.storeFeatureCollection(BGTGMLLightLoader.java:404

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Mark Prins]

thank you Niels!
This sounds really good, tied up in other work for 6 weeks or so, so will
have to wait to give this a shot.

Mark



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5486) dependency convergence commons-collections

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5486  
 
 
  dependency convergence commons-collections   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Affects Versions: 
 14.5  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 jdbc, xsd-gml  
 
 
Created: 
 12/Aug/16 5:41 PM  
 
 
Priority: 
  Low  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 I have just created a rrelease and noted in the maven Reactor Dependency Convergence report that org.geotools.xsd:gt-xsd-core:jar:14.5 has a dependency on commons-collections:commons-collections:jar:3.1 while org.geotools:gt-jdbc:jar:14.5 has a dependency on commons-collections:commons-collections:jar:3.2.2 It would be nice to use the same (latest) version 

 

nl.b3p:bgt-gml-loader:jar:1.3.5-SNAPSHOT
\- org.geotools:gt-xml:jar:14.5:compile
   \- org.geotools.xsd:gt-xsd-wfs:jar:14.5:compile
  \- org.geotools.xsd:gt-xsd-filter:jar:14.5:compile
 \- org.geotools.xsd:gt-xsd-core:jar:14.5:compile
\- (commons-collections:commons-collections:jar:3.1:compile - omitted for conflict with 3.2.2)

nl.b3p:bgt-gml-loader:jar:1.3.5-SNAPSHOT
\- org.geotools:gt-jdbc:jar:14.5:compile
   \- commons-collections:commons-collections:jar:3.2.2:compile

[Geotools-devel] close GEOT-5388

[Mark Prins]

can someone with appropriate authorizations close
https://osgeo-org.atlassian.net/browse/GEOT-5388
fixes were merged into 14.x and master in april

Thanx, Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [JIRA] (GEOT-5422) jndi fails with jTDS driver

[Mark Prins]

Anyone care to comment on my proposed solution in PR
https://github.com/geotools/geotools/pull/1198
Right now we have to unwrap the connection and use reflection to get at the
user password [1] which is a little nasty...
Would be nice to get this into 14.4 if possible

[1]
https://github.com/B3Partners/brmo/commit/a6e931b5eaa6162a8ea7a4c299a4f8927688de70#diff-aa551afb3bfb750ef0adc717215a4436L103

Thanx, Mark



2016-05-19 14:09 GMT+02:00 Mark Prins (JIRA) <j...@osgeo-org.atlassian.net>:

> Mark Prins
> <https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?name=mprins>
> *created* an issue
>
> GeoTools <https://osgeo-org.atlassian.net/browse/GEOT> / [image: Bug]
> <https://osgeo-org.atlassian.net/browse/GEOT-5422> GEOT-5422
> <https://osgeo-org.atlassian.net/browse/GEOT-5422>
> jndi fails with jTDS driver
> <https://osgeo-org.atlassian.net/browse/GEOT-5422>
> Issue Type: [image: Bug] Bug
> Affects Versions: 15-RC1, 14.3, 16-beta
> Assignee: Unassigned
> Components: jdbc-sqlserver plugin
> Created: 19/May/16 2:08 PM
> Environment:
>
> no specific environment; off-line test will be provided in PR
> Labels: jndi jtds
> Priority: [image: High] High
> Reporter: Mark Prins
> <https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?name=mprins>
>
> When specifying the jtds *dbtype* in combination with a *schema* and a
> *jndiReferenceName* it will return null instead of a datastore:
>
> jndiProps.put("jndiReferenceName", JNDINAME);
> jndiProps.put("schema", "dbo");
> jndiProps.put("dbtype", "jtds-sqlserver");
> JDBCDataStore dataStore = (JDBCDataStore) 
> DataStoreFinder.getDataStore(jndiProps);
>
> specifying sqlserver as *dbtype* you do get a datastore.
>
> some talk about this on the user ML:
> https://sourceforge.net/p/geotools/mailman/message/35089310/
> [image: Add Comment]
> <https://osgeo-org.atlassian.net/browse/GEOT-5422#add-comment> Add Comment
> <https://osgeo-org.atlassian.net/browse/GEOT-5422#add-comment>
>
> This message was sent by Atlassian JIRA (v1000.5.2#72002-sha1:b4422fe)
> [image: Atlassian logo]
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] [JIRA] (GEOT-5422) jndi fails with jTDS driver

[Mark Prins]

2016-05-19 14:31 GMT+02:00 Mark Prins <mc.pr...@gmail.com>:

> I'm looking into solving this but would like to hear opinion; my initial
> thought is to code a JDTSSQLServerJNDIDataStoreFactory + spi that
> extends SQLServerJNDIDataStoreFactory and that
> wraps JTDSSqlServerDataStoreFactory... any other opions?
>
>
I've gone ahead and implemented this in PR:
https://github.com/geotools/geotools/pull/1198

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5422) jndi fails with jTDS driver

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5422  
 
 
  jndi fails with jTDS driver   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-RC1, 14.3, 16-beta  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 jdbc-sqlserver plugin  
 
 
Created: 
 19/May/16 2:08 PM  
 
 
Environment: 
 no specific environment; off-line test will be provided in PR  
 
 
Labels: 
 jndi jtds  
 
 
Priority: 
  High  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 When specifying the jtds dbtype in combination with a schema and a jndiReferenceName it will return null instead of a datastore: 

 

jndiProps.put("jndiReferenceName", JNDINAME);
jndiProps.put("schema", "dbo");
jndiProps.put("dbtype", "jtds-sqlserver");
JDBCDataStore dataStore = (JDBCDataStore) DataStoreFinder.getDataStore(jndiProps);
 

 specifying sqlserver as dbtype you do get a datastore. some talk about this on the user ML: https://s

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Mark Prins]

On 26-04-16 14:21, Andrea Aime wrote:
> Thanks Niels,
> Mark, I believe this opens the road for you to re-open that ticket (or
> create a new one) and
> possibly present a pull request to create an upgrade path for yourself
> (and everybody
> else using the wfs store directly).
>

It will take some time before I get around to this, but while we're at 
it the solution would IMO basically comprise:

  - adding a hint or connection param "use_wfs_legacy_naming"
  - making WFSDataStore#createTypeNames() [1] work with the hint while 
cooking up the names
  - some tests
  - some docs

I may have missed something here and something might break...
Currently the connection param looks easier to implement

[1] 
https://github.com/geotools/geotools/blob/42c4cc0c3d850b1dea50c07108f171aace35a798/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/WFSDataStore.java#L108





> Cheers
> Andrea
>
>
> On Sat, Apr 23, 2016 at 12:18 AM, Niels Charlier  > wrote:
>
> Andre,
>
> The reason I closed it as "not a bug" was because I knew it was done
> by intentional design (not by me, but by the initial developer of
> wfs-ng) for a particular purpose and therefore I did not consider it
> a bug. You do make good points to criticise this choice, which does
> affect backwards compatibility. I do not personally oppose your
> alternative suggestion.
>
> Regards
> Niels
>
>
> On 04/22/2016 07:48 PM, Andrea Aime wrote:
>> On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett
>> > wrote:
>>
>>
>> > Hum... wfs-ng was supposed to be a drop-in
>> replacement, not having a upgrade
>> > path seems to be a serious issue to me.
>> > Where is it documented?
>>
>> Quick search got us this:
>> https://osgeo-org.atlassian.net/browse/GEOT-4883
>> and we googled some more messages on it.
>>
>> A backwards incompable change blocking upgrades presented
>> as a GeoServer requirement and resolved as "not a bug"...
>>
>>
>> Reading this issue, and I agree it is not a bug - the new
>> datastore is behaving as designed in order to preserve valid
>> names for GML generation.
>>
>>
>> Jody I believe we have a problem here, in terms of
>> responsibilities. Is it really the job of the stores to decide
>> what is valid, and what is not?
>> Not all usage is WFS cascading, stores are used for a number of
>> other cases, which might have different naming limitations.
>>
>> Also from a consistency point of view, did you know that you can
>> create a typename like "a:b" using a postgis store?
>>
>> > create table "a:b" (id serial, geom geometry(POLYGON, 4326));
>> CREATE TABLE
>>
>> And then the datastore is happily returning a:b as the typename,
>> And of course we also have shapefiles, on linux a file name like
>> a:b.shp is also completely valid.
>>
>> With you and Niels claiming that is not a bug, we have a difficult
>> situation, as nobody else can just jump in and make
>> the upgrade path easier, since according to your evaluation, we'd
>> be introducing a bug... (and from that same point of view,
>> then jdbc store and shapefile store are buggy too...).
>>
>> Unless of course your position is a bit more relaxed, as in, you
>> don't consider that a bug, but the behavior returning the native
>> name is valid too.
>>
>>
>> For this specific case the old datastore would of required a
>> similar fix (to prevent type names being of the form
>> "local_namespace:remote_namespace:typename").
>>
>> As far as I know GeoServer was already handling the ":" in
>> the name, and the admin is able to rename layers as they
>> see fit.
>> Yep, there is code stripping the prefix:
>> 
>> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java#L1212
>>
>>
>> GeoServer may have work arounds, but I do not mind if the new
>> DataStore is taking more care to produce consistent type names.
>>
>>
>> See Mark's situation though. I'm also aware of other situations
>> like this one that will be broken by an upgrade (systems configured
>> to work against well known type names in remote servers).
>>
>> Mind, I checked, GeoServer is not affected, because internally we
>> have this little thing that hides from GeoServer the columns and
>> guess what, replaces them with underscores. See here:
>>
>> 
>> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/vfny/geoserver/util/DataStoreUtils.java#L74
>>
>> and then the retyper does this:
>>
>> 
>> 

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Mark Prins]

2016-04-22 9:18 GMT+02:00 Andrea Aime <andrea.a...@geo-solutions.it>:

> On Thu, Apr 21, 2016 at 2:27 PM, Mark Prins <mc.pr...@gmail.com> wrote:
>
>> > Where is it documented?
>>
>> Quick search got us this:
>> https://osgeo-org.atlassian.net/browse/GEOT-4883
>> and we googled some more messages on it.
>>
>> This happened over christmas so it's gone a bit hazy by now, we upgraded
>> from 9.x to 14.x during that period, (late yes, but we were tied to
>> supporting Java 6)
>>
>
> Could you share with us a bit more about how the change affected your
> application?
> Your request of keeping support for the old wfs store seems to imply
> switching
> to wfs-ng would be a significant rework of your application
>
>
Sure,

In our application we have an admin define a view/map service (eg. WMS),
while the capabilities are retrieved we also try to discover a WFS (to use
for attribute info, tables, graphs etc.), if not discoverable the admin may
specify one himself (even a different service).

We store the WFS typenames in a table in our backend like so:

id;  description;geom-attr; type_name;
;writable; source id
"68";"Bedrijventerrein_kavels"; "geom";"Economie:Bedrijventerrein_kavels";
FALSE;14
"70";"EcMo_Wonen_regios";   "geom";"Economie:EcMo_Wonen_regios";
FALSE;14
"79";"BeschikbarePandenOpBedrijventerreinen";"geom";"IBIS_BeschikbarePandenOpBedrijventerreinen";FALSE;16
"80";"";"geom";"bedrijvenkavels_tijdelijk";
 TRUE;11


"Economie:Bedrijventerrein_kavels" being the typename reported by the WFS,
a test case illustrating this [0]. We use this typename to request features
from the WFS [1],

If I recall correctly wfs-ng reports "Economie_EcMo_Wonen_regios" as a
typename (instead of "Economie:EcMo_Wonen_regios") which breaks when just
using that in a getfeatures request also because the underscore is a
legitimate character in both layer name and namespace name (contrary to the
colon) it becomes impossible to determine which part is which (not possible
to use a simple split on ':' anymore). Our stored type_name is used in
various places in our application.

We can/should probably expand our model to store typename and namespace
separately to use this new naming convention and update the code to use
that. And cook up a migration script for our users.


[0]
https://github.com/flamingo-geocms/flamingo/blob/master/viewer-admin/src/test/java/nl/b3p/viewer/admin/stripes/WFSTypeNamingTest.java#L199
[1] eg.
https://github.com/flamingo-geocms/flamingo/blob/master/viewer-config-persistence/src/main/java/nl/b3p/viewer/config/services/WFSFeatureSource.java#L246



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Mark Prins]

On 19-04-16 20:29, Andrea Aime wrote:
> Hi Mark,
> comments inline
>
> We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the
> naming convention change, we cache/store the namespace:typename of
> featuretypes in our software and our things broke down all over the
> place. Though documented, this really bit me in the ass, I expected our
> upgrade to go a bit smoother.
>
>
> Hum... wfs-ng was supposed to be a drop-in replacement, not having a upgrade
> path seems to be a serious issue to me.
> Where is it documented?

Quick search got us this:
https://osgeo-org.atlassian.net/browse/GEOT-4883
and we googled some more messages on it.

This happened over christmas so it's gone a bit hazy by now, we upgraded 
from 9.x to 14.x during that period, (late yes, but we were tied to 
supporting Java 6)

  Mark

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

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Mark Prins]

On 19-04-16 00:32, Jody Garnett wrote:
> I have been monitoring GEOT-5128
>  looking to delete
> AbstractDataStore and friends - currently in use by the gt-wfs module.
> We have a "new" wfs-ng implementation based on ContentDataStore - that
> is waiting on a firm thumbs up (or a series of bug reports) in order to
> take over duties.

We've had to revert the upgrading of gt-wfs -> gt-wfs-ng due to the 
naming convention change, we cache/store the namespace:typename of 
featuretypes in our software and our things broke down all over the 
place. Though documented, this really bit me in the ass, I expected our 
upgrade to go a bit smoother.

A big plus for the gt-wfs-ng is the updated http library which fixes 
some issues.

I'm assuming this question bubbles up from the wish to drop gt-wfs from 
the library, I for one would like for it to be still around in 15.x

Mark


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

Re: [Geotools-devel] beta2 planning

[Mark Prins]

On 12-04-16 08:45, Jody Garnett wrote:
> I am looking to make a beta2 release this week, I notice Ben and Maciej
> working away on a pull request.
>
> Are there any other pull requests that are a priority to get into the beta?

Any chance for [GEOT-5388] 
(https://github.com/geotools/geotools/pull/1146 / 
https://github.com/geotools/geotools/pull/1147)

--
Mark

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

[Geotools-devel] [JIRA] (GEOT-5400) FeatureTypeFactory SPI in main module fails

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5400  
 
 
  FeatureTypeFactory SPI in main module fails   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 15-beta, 14.3, 13.6  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 main  
 
 
Created: 
 05/Apr/16 9:27 AM  
 
 
Priority: 
  High  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 .../main/src/main/resources/META-INF/services/org.geotools.feature.FeatureTypeFactory lists org.geotools.feature.DefaultFeatureTypeFactory which existed in 2.x (but not anymore) and also the SPI file should be named {{ ...ary/main/src/main/resources/META-INF/services/org.opengis.feature.type.FeatureTypeFactory}} and point to org.geotools.feature.type.FeatureTypeFactoryImpl Jody already prepared a PR: https://github.com/geotools/geotools/pull/1163  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Re: [Geotools-devel] [JIRA] (GEOT-5388) Let TemporalConverterFactory provide for conversion from Long to Date

[Mark Prins]

I've created PR's for master [1] and 14.x [2], I can create a 13.x PR as
well if required.
Not sure if this qualifies as a new feature or a fix, but it fixes the
parsing of ArcGIS REST JSON responses where dates of features are written
out as epoch stamps

[1] https://github.com/geotools/geotools/pull/1146
[2] https://github.com/geotools/geotools/pull/1147


Mark

2016-03-25 18:17 GMT+01:00 Mark Prins (JIRA) <j...@osgeo-org.atlassian.net>:

> Mark Prins
> <https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?name=mprins>
> *created* an issue
>
> GeoTools <https://osgeo-org.atlassian.net/browse/GEOT> / [image:
> Improvement] <https://osgeo-org.atlassian.net/browse/GEOT-5388> GEOT-5388
> <https://osgeo-org.atlassian.net/browse/GEOT-5388>
> Let TemporalConverterFactory provide for conversion from Long to Date
> <https://osgeo-org.atlassian.net/browse/GEOT-5388>
> Issue Type: [image: Improvement] Improvement
> Affects Versions: 15-beta, 14.3
> Assignee: Unassigned
> Components: main
> Created: 25/Mar/16 6:16 PM
> Priority: [image: Medium] Medium
> Reporter: Mark Prins
> <https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?name=mprins>
>
> Currently org.geotools.util.TemporalConverterFactory fails to convert from
> Long to Date, this is an issue while converting features from ArcGIS server
> REST/json responses that have a date as the esriFieldTypeDate is
> communicated as a long value representing epoch milliseconds since 1-1-1970
> in GMT
> [image: Add Comment]
> <https://osgeo-org.atlassian.net/browse/GEOT-5388#add-comment> Add Comment
> <https://osgeo-org.atlassian.net/browse/GEOT-5388#add-comment>
>
> This message was sent by Atlassian JIRA (v7.2.0-OD-04-029#72002-
> sha1:f50e4de)
> [image: Atlassian logo]
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5388) Let TemporalConverterFactory provide for conversion from Long to Date

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5388  
 
 
  Let TemporalConverterFactory provide for conversion from Long to Date   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 15-beta, 14.3  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 main  
 
 
Created: 
 25/Mar/16 6:16 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Mark Prins  
 

  
 
 
 
 

 
 Currently org.geotools.util.TemporalConverterFactory fails to convert from Long to Date, this is an issue while converting features from ArcGIS server REST/json responses that have a date as the esriFieldTypeDate is communicated as a long value representing epoch milliseconds since 1-1-1970 in GMT  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[Geotools-devel] [JIRA] (GEOT-5349) MetadataTablePrimaryKeyFinder fails to quote schema name, PK lookup fails on views in gt_pk_metadata

[Mark Prins (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Prins created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5349  
 
 
  MetadataTablePrimaryKeyFinder fails to quote schema name, PK lookup fails on views in gt_pk_metadata   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 14.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 jdbc  
 
 
Created: 
 02/Feb/16 10:41 AM  
 
 
Environment: 
 postgresql 9.4 / postgis 2.1.7 and a schema named IBIS (CREATE SCHEMA "IBIS" AUTHORIZATION ibis  
 
 
Labels: 
 jdbc postgis  
 
 
Priority: 
  Medium  
 
 
Reporter: 
     Mark Prins  
 
 
Original Estimate: 
1 hour 
 
 
Remaining Estimate:  
1 hour 
 

  
 
 
 
 

 
 MetadataTablePrimaryKeyFinder fails to find the primary key of a view event though that has an entry in the GT_PK_METADATA table, log keeps reporting "No primary key or unique index found for v_grootste_10_bedrijven_op_terrein." Stepping through in the debugger I can see the statement "SELECT * FROM IBIS.GT_PK_METADATA WHERE 1 = 0" being prepared and executed and consequently failing with an exception: e = (org

[Geotools-devel] problems finding PK metadata table in a schema (postgis)

[Mark Prins]

Hi,
I have a postgis schema ("IBIS") with some views that have an entry in the
GT_PK_METADATA table but I keep seeing the message "No primary key or
unique index found for v_grootste_10_bedrijven_op_terrein." in my logs.

Stepping through in the debugger I can see the statement "SELECT * FROM
IBIS.GT_PK_METADATA WHERE 1 = 0" being prepared and executed and
consequently failing with an exception

e = (org.postgresql.util.PSQLException) org.postgresql.util.PSQLException:
ERROR: relation "ibis.gt_pk_metadata" does not exist
  Position: 15

Because the sql is invalid for postgis, the schema name should be quoted..

HeuristicPrimaryKeyFinder seems to be using the encodeTableName() of the
store to circumvent that.

I've filed an issue: https://osgeo-org.atlassian.net/browse/GEOT-5349 and
can probably prepare a PR with a fix

I've just submitted https://github.com/geotools/geotools/pull/1096 for
https://osgeo-org.atlassian.net/browse/GEOT-4886, so I would include that.

Mark



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Any plans dropping deprecated CQL syntax for 'ID IN'?

[Mark Prins]

On 15-12-15 19:44, Jody Garnett wrote:
> Reading the page ...
>
> Deprecated Syntax
>
>   ::= [ "NOT" ] "IN" "("  {","  } ")"
>   ::=  
>
> New Syntax (since 2.7.rc1)
>
>   ::= [ "NOT" ] "IN" "("  {","  } ")"
>   ::=   | 
>
> Am I missing something? It looks like the new syntax just allows
> integers or character strings?

No, Yes, misunderstanding on my side, driven by sleep deprivation and 
wishful thinking of having id treated as a regular attribute field

Mark


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

Re: [Geotools-devel] Any plans dropping deprecated CQL syntax for 'ID IN'?

[Mark Prins]

yes; I think it would cause some grief.  I'm not pushing for this but
having one syntax flagged as something one should not use doesn't really
make much sense to me if there are no ill side-effects nor plans to drop it.
Mark

2015-12-15 12:27 GMT+01:00 Andrea Aime <andrea.a...@geo-solutions.it>:

> Hmm... that would be a backwards compatibility breach, I'm not so eager to
> remove that support
>
> Cheers
> Andrea
>
> On Tue, Dec 15, 2015 at 12:13 PM, Mark Prins <mc.pr...@gmail.com> wrote:
>
>> Out of curiosity (and because I'm running into some trouble having tables
>> with an id column that's not the primary key) what is the plan (if any) for
>> dropping the deprecated "id in" syntax from CQL? (So that "id" will be
>> handled as an ordinary attribute)
>>
>> From the docs [1] it seems that it was deprecated in the 2.7 release
>>
>> [1]
>> https://github.com/geotools/geotools/blob/master/modules/library/cql/ECQL.md
>>
>> --
>> Disclaimer;
>> This message is just a reflection of what I thought at the time of
>> sending. The message may contain information that is not intended for you
>> or that you don't understand.
>>
>>
>> --
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> *Geosolutions' Winter Holidays from 24/12 to 6/1*
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>



-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Any plans dropping deprecated CQL syntax for 'ID IN'?

[Mark Prins]

Out of curiosity (and because I'm running into some trouble having tables
with an id column that's not the primary key) what is the plan (if any) for
dropping the deprecated "id in" syntax from CQL? (So that "id" will be
handled as an ordinary attribute)

>From the docs [1] it seems that it was deprecated in the 2.7 release

[1]
https://github.com/geotools/geotools/blob/master/modules/library/cql/ECQL.md

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Travis build on OSX available

[Mark Prins]

I have a one-liner in a before-install to export that;

before_install:
   - if [ $TRAVIS_OS_NAME == osx ]; then export
JAVA_HOME=$(/usr/libexec/java_home); fi

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

Re: [Geotools-devel] Travis build on OSX available

[Mark Prins]

Hey Andrea,
I just saw your changes to the .travis.yml, currently the jvm switcher is
not supported on osx causing those builds to fail.

You'll want to remove the jdk section and then add an include to build with
the non default JDK's in the matix. It will crat a build matrix with the
two default JDK's on osx and linux and the add two more builds


It would then look something like this for geotools:

sudo: false
cache:
  directories:
- $HOME/.m2
language: java
script:
  - mvn -B -T2 -fae -Djava.awt.headless=true -Dall clean install
notifications:
  email: false
  on_failure: never
env: GDAL_LIBRARY_NAME=disabled_see_geot-4733
os:
  - linux
  - osx
matrix:
  allow_failures:
- os: osx
  include:
  # additional builds on linux w/ openjdk7 and oraclejdk8
- os: linux
 jdk: openjdk7
   - os: linux
 jdk: oraclejdk8

I just spent some time figuring this out for an entirely different project.
see:
- https://github.com/GeoDienstenCentrum/sass-maven-plugin/pull/65
- https://travis-ci.org/GeoDienstenCentrum/sass-maven-plugin/builds/75738242


HTH, Mark


2015-08-14 9:00 GMT+02:00 Andrea Aime andrea.a...@geo-solutions.it:

 HI,
 a few months ago I logged a request at Travis to get a OSX build
 machine. It has now arrived, activated for the GeoTools and GeoServer
 projects.

 Here is the mail from the Travis people:


 -

 Hi Andrea!

 Just enabled the multi-os feature for both:
 https://github.com/geotools/geotools and
 https://github.com/geoserver/geoserver.

 Please note that this feature is currently in beta, so do let us know if
 there is anything you feel can be improved or anything you miss.

 Here's what you need to add in your .travis.yml: http://docs.travis
 -ci.com/user/multi-os/#Setting-.travis.yml

 -

 Activation is repo specific, and back then I queued a request for those
 two repos. I don't have time right now to
 activate them, but instructions are above, if anyone wants to try

 Cheers
 Andrea

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

 Ing. Andrea Aime
 @geowolf
 Technical Lead

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

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

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

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



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

 ---


 --

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




-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] GeoTools / GeoServer Meeting 2015-06-23

[Mark Prins]

2015-06-23 22:52 GMT+02:00 Ben Caradoc-Davies b...@transient.nz:
 GeoTools / GeoServer Meeting 2015-06-23


 Preventing vulnerability with build checks
 --

 Jenkins plugin may allow us to run automated vunerability check:

 * https://www.blackducksoftware.com/vulnerability-plugin

 Can we make a build profile for this similar to database tests...

You may also want to look into the OWASP Dependency-Check [1] [2]
tools which has plugins for Maven, Jenkins and other tools/plugins.
I've used this before and was impressed with the results, it uses the
NIST CVE database to check all project dependencies.

The problem with this kind of tool is that it is a static analysis
which generally doesn't catch things like SQL injection, XSS or ENTITY
expansion that occur at runtime (it will ofcourse raise a flag if it's
a known bad dependency). That would still require a pen test with
something like the Zed Attack Proxy [3]

Also, there are false positives to handle and investigate.

I have an example, running as part of the site phase, setup here [4],
report here [5]

[1] https://www.owasp.org/index.php/OWASP_Dependency_Check
[2] https://github.com/jeremylong/DependencyCheck
[3] https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
[4] https://github.com/MinELenI/CBSviewer/blob/master/pom.xml#L801
[5] http://mineleni.github.io/CBSviewer/dependency-check-report.html

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of
sending. The message may contain information that is not intended for
you or that you don't understand.

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5135) unexpected results using setMaxFeatures on RELATE query w/ DE9IM filter

[Mark Prins (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Mark Prins created an issue 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 GeoTools /  GEOT-5135 
 
 
 
  unexpected results using setMaxFeatures on RELATE query w/ DE9IM filter  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14-M0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 jdbc-postgis plugin 
 
 
 

Created:
 

 29/May/15 9:44 AM 
 
 
 

Environment:
 
 
postgis 2.1.3 on postgres 9.4 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Mark Prins 
 
 
 
 
 
 
 
 
 
 
RELATE + DE-9IM matrix query and the setMaxFeatures method on postgis and it appears that setting the max features prevents returning proper results because the query to the database sets a limit, but the filter is executed locally...(so only run on the retrieved features) which leads to some unexpected results, eg. no features returned, but count says there should be. 
I think the postgis filter should just pass the sql to he database, postgis has supported ST_relate since 1.5, but is not it shouldn't set a limit 
some code (full code including data at: https://github.com/mprins/geotools

[Geotools-devel] geotools.org down?

[Mark Prins]

geotools.org appears to be down or refusing connections[1] atm and
last night as well. Is any of the devs available to push a button to
get it going again?

thanx, Mark

[1] http://isitup.org/www.geotools.org

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of
sending. The message may contain information that is not intended for
you or that you don't understand.

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