Re: [Geotools-devel] About the OGR failures

[Andrea Aime]

Hi all,
pull request here:
https://github.com/geotools/geotools/pull/1872

Cheers
Andrea


On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime 
wrote:

> Hi Ben,
> I've already inquired to Even about those failures, looks like signature
> of a few methods changes in OGR 1.11.
> Both JNI and BridJ bindings fail, the difference is that BridJ does not
> need the "bridge" JNI native library so it
> runs most of the time, while the JNI one skip the tests.
>
> Now, with something dynamic as BridJ I guess one could check the OGR
> version, have native bindings for
> the various methods overloads, and call the right ones, but for the JNI
> case I'm not sure what to do.
>
> This notion of "buliding against a knows GDAL version" is not a match for
> the way we do things, GeoTools/GeoServer
> are just dropped on a machine and the find whatever they find, there is no
> notion of packaging against a specific
> version like with the native packages.
>
> All in all I'm tempted to just drop support for the OGR data store, at
> least of the BridJ part, it's getting too much
> work to maintain and there are other things having a higher priority, and
> to be honest, I have never used it
> for a real project (I created the first version of it in my spare time as
> a "good gesture" in the OSGeo familiy,
> but never got traction).
>
> Discussion with Even follows.
>
> Cheers
> Andrea
>
>
> -- Forwarded message --
> From: Andrea Aime 
> Date: Sun, Mar 18, 2018 at 4:27 PM
> Subject: Binary incompatible change in OGR JNI?
> To: Even Rouault 
>
>
> Hi Even,
> recently I have had reports of some failures in the GeoTools bridge to OGR.
> Looking into it I've found this build error:
>
> Warning 1: Field name of width 255 truncated to 254.
> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882 sec
> <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time
> elapsed: 0.014 sec  <<< ERROR!
> java.lang.UnsatisfiedLinkError: org.gdal.ogr.ogrJNI.Layer_SetS
> patialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
> at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
> at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
> at org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOGR.java:257)
> at org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFe
> atureSource.java:128)
> at org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRF
> eatureSource.java:158)
> at org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFe
> atureStore.java:109)
> at org.geotools.data.store.ContentFeatureSource.getCount(Conten
> tFeatureSource.java:507)
> at org.geotools.data.store.ContentFeatureCollection.size(Conten
> tFeatureCollection.java:231)
> at org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(O
> GRDataStoreTest.java:750)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at org.geotools.data.ogr.TestCaseSupport.run(TestCaseSupport.java:113)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
> ssRunner.java:84)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUni
> t4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestS
> et(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit
> 4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProvider
> InSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInPro
> cess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBoo
> ter.java:103)
>
> Are you by any chance aware of such changes in the OGR JNI interface?
> If you have to look, no problem, I'll do it, just wanted to see if it
> rings a bell for you.
>
> Ah, context, the store was developed against 1.9, linux distros are
> currently shipping 1.11(.3)
>
> 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 

Re: [Geotools-devel] About the OGR failures

[Justin Deoliveira]

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

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

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

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

Re: [Geotools-devel] About the OGR failures

[Andrea Aime]

On Sat, Apr 21, 2018 at 12:08 AM, Ben Caradoc-Davies 
wrote:

> On 20/04/18 18:24, Andrea Aime wrote:
>
>> On Fri, Apr 20, 2018 at 1:16 AM, Jody Garnett 
>> wrote:
>>
>>> Andrea, I often often been frustrated with build difficulties on this one
>>> over the years. I understand it is not supported, so just remain
>>> frustrated
>>> - usually removing GDAL when it showed up on my path.
>>>
>> Well, the module is actually in supported land, and cannot stay there in
>> this condition.
>> The JNI part is equally broken, but at least it's not breaking the build.
>> I have too many modules to look after, time to cut some dead branches
>>
>
> +1 to demote modules that we do not support to unsupported status.
>
> Note however that we do have some community interest in GDAL and we should
> give them a chance to assess whether they are willing to support this
> module.
>

Yes, we can move the module down to unsupported and remove it from the
-Dall build.
Question, should I move out only the BridJ module, or also the JNI one?
Is anyone still caring for it? Justin, you're the maintainer right?

Cheers
Andrea

==

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

Ing. Andrea Aime
@geowolf
Technical Lead

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

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] About the OGR failures

[Ben Caradoc-Davies]

On 20/04/18 18:24, Andrea Aime wrote:

On Fri, Apr 20, 2018 at 1:16 AM, Jody Garnett 
wrote:

Andrea, I often often been frustrated with build difficulties on this one
over the years. I understand it is not supported, so just remain frustrated
- usually removing GDAL when it showed up on my path.

Well, the module is actually in supported land, and cannot stay there in
this condition.
The JNI part is equally broken, but at least it's not breaking the build.
I have too many modules to look after, time to cut some dead branches


+1 to demote modules that we do not support to unsupported status.

Note however that we do have some community interest in GDAL and we 
should give them a chance to assess whether they are willing to support 
this module.


Kind regards,

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

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

Re: [Geotools-devel] About the OGR failures

[Andrea Aime]

On Fri, Apr 20, 2018 at 1:16 AM, Jody Garnett 
wrote:

> Andrea, I often often been frustrated with build difficulties on this one
> over the years. I understand it is not supported, so just remain frustrated
> - usually removing GDAL when it showed up on my path.
>

Well, the module is actually in supported land, and cannot stay there in
this condition.
The JNI part is equally broken, but at least it's not breaking the build.
I have too many modules to look after, time to cut some dead branches

Cheers
Andrea

==

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

Ing. Andrea Aime
@geowolf
Technical Lead

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

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] About the OGR failures

[Jody Garnett]

Andrea, I often often been frustrated with build difficulties on this one
over the years. I understand it is not supported, so just remain frustrated
- usually removing GDAL when it showed up on my path.




--
Jody Garnett

On 18 April 2018 at 05:30, Andrea Aime  wrote:

> Hi all,
> any feedback? If not, I plan to remove the module sometimes soon.
> (mind, the JNI module will be broken just the same at runtime, but won't
> fail the build unless the JNI native lib is around, which is normally not)
>
> Cheers
> Andrea
>
> On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime 
> wrote:
>
>> Hi Ben,
>> I've already inquired to Even about those failures, looks like signature
>> of a few methods changes in OGR 1.11.
>> Both JNI and BridJ bindings fail, the difference is that BridJ does not
>> need the "bridge" JNI native library so it
>> runs most of the time, while the JNI one skip the tests.
>>
>> Now, with something dynamic as BridJ I guess one could check the OGR
>> version, have native bindings for
>> the various methods overloads, and call the right ones, but for the JNI
>> case I'm not sure what to do.
>>
>> This notion of "buliding against a knows GDAL version" is not a match for
>> the way we do things, GeoTools/GeoServer
>> are just dropped on a machine and the find whatever they find, there is
>> no notion of packaging against a specific
>> version like with the native packages.
>>
>> All in all I'm tempted to just drop support for the OGR data store, at
>> least of the BridJ part, it's getting too much
>> work to maintain and there are other things having a higher priority, and
>> to be honest, I have never used it
>> for a real project (I created the first version of it in my spare time as
>> a "good gesture" in the OSGeo familiy,
>> but never got traction).
>>
>> Discussion with Even follows.
>>
>> Cheers
>> Andrea
>>
>>
>> -- Forwarded message --
>> From: Andrea Aime 
>> Date: Sun, Mar 18, 2018 at 4:27 PM
>> Subject: Binary incompatible change in OGR JNI?
>> To: Even Rouault 
>>
>>
>> Hi Even,
>> recently I have had reports of some failures in the GeoTools bridge to
>> OGR.
>> Looking into it I've found this build error:
>>
>> Warning 1: Field name of width 255 truncated to 254.
>> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882
>> sec <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
>> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time
>> elapsed: 0.014 sec  <<< ERROR!
>> java.lang.UnsatisfiedLinkError: org.gdal.ogr.ogrJNI.Layer_SetS
>> patialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
>> at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
>> at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
>> at org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOG
>> R.java:257)
>> at org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFe
>> atureSource.java:128)
>> at org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRF
>> eatureSource.java:158)
>> at org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFe
>> atureStore.java:109)
>> at org.geotools.data.store.ContentFeatureSource.getCount(Conten
>> tFeatureSource.java:507)
>> at org.geotools.data.store.ContentFeatureCollection.size(Conten
>> tFeatureCollection.java:231)
>> at org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(O
>> GRDataStoreTest.java:750)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at junit.framework.TestCase.runTest(TestCase.java:176)
>> at junit.framework.TestCase.runBare(TestCase.java:141)
>> at junit.framework.TestResult$1.protect(TestResult.java:122)
>> at junit.framework.TestResult.runProtected(TestResult.java:142)
>> at junit.framework.TestResult.run(TestResult.java:125)
>> at junit.framework.TestCase.run(TestCase.java:129)
>> at org.geotools.data.ogr.TestCaseSupport.run(TestCaseSupport.java:113)
>> at junit.framework.TestSuite.runTest(TestSuite.java:255)
>> at junit.framework.TestSuite.run(TestSuite.java:250)
>> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
>> ssRunner.java:84)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUni
>> t4Provider.java:264)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestS
>> et(JUnit4Provider.java:153)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit
>> 4Provider.java:124)
>> at org.apache.maven.surefire.booter.ForkedBooter.invokeProvider
>> InSameClassLoader(ForkedBooter.java:200)
>> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInPro
>> cess(ForkedBooter.java:153)
>> at 

Re: [Geotools-devel] About the OGR failures

[Jesper Steen Møller]

Thanks for clarifying - I suppose it would be possible to segment the level of 
support to levels:

Level 1 would be is reading and writing the geometry, crs and tabular data, 
level 2 would be the styling - I'm currently examining the MITAB source to see 
how big a task this should be.

-Jesper

> On 18 Apr 2018, at 15.30, Ian Turton  wrote:
> 
> As I recall just importing the basic geometries from a MapInfo file wasn't 
> too hard but there is a whole bunch of styling and other junk in there too 
> that people wanted to read in. 
> 
> Plus whoever was doing it would need a MapInfo licence to generate/check 
> input files.
> 
> So not impossible but not cheap either.
> 
> Ian
> 
> On 18 April 2018 at 13:56, Andrea Aime  > wrote:
> Hi Jesper,
> you can take over maintainership of the BridJ module and fix the build, or 
> sponsor
> someone to do it for you.
> 
> Writing mapinfo support in java would be best of course, but also believe 
> it's a sizable effort
> (take a look at the OGR mapinfo source code, something similar would have to 
> be built
> for GeoTools, along with a good amount of tests).
> 
> Cheers
> Andrea
> 
> 
> On Wed, Apr 18, 2018 at 2:50 PM, Jesper Steen Møller  > wrote:
> Hi list
> 
> Ugh - removing OGR support will make it impossible for Java tools to access 
> MapInfo files. We're using BridJ for now, as it's easier to get the GDAL bits 
> without the corresponding JNI shared object.
> 
> Is there anything I could do to help? How big a job is building MapInfo 
> support in Java?
> 
> -Jesper
> 
>> On 18 Apr 2018, at 14.30, Andrea Aime > > wrote:
>> 
>> Hi all,
>> any feedback? If not, I plan to remove the module sometimes soon.
>> (mind, the JNI module will be broken just the same at runtime, but won't 
>> fail the build unless the JNI native lib is around, which is normally not)
>> 
>> Cheers
>> Andrea
>> 
>> On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime > > wrote:
>> Hi Ben,
>> I've already inquired to Even about those failures, looks like signature of 
>> a few methods changes in OGR 1.11.
>> Both JNI and BridJ bindings fail, the difference is that BridJ does not need 
>> the "bridge" JNI native library so it
>> runs most of the time, while the JNI one skip the tests.
>> 
>> Now, with something dynamic as BridJ I guess one could check the OGR 
>> version, have native bindings for
>> the various methods overloads, and call the right ones, but for the JNI case 
>> I'm not sure what to do.
>> 
>> This notion of "buliding against a knows GDAL version" is not a match for 
>> the way we do things, GeoTools/GeoServer
>> are just dropped on a machine and the find whatever they find, there is no 
>> notion of packaging against a specific
>> version like with the native packages.
>> 
>> All in all I'm tempted to just drop support for the OGR data store, at least 
>> of the BridJ part, it's getting too much
>> work to maintain and there are other things having a higher priority, and to 
>> be honest, I have never used it
>> for a real project (I created the first version of it in my spare time as a 
>> "good gesture" in the OSGeo familiy,
>> but never got traction).
>> 
>> Discussion with Even follows.
>> 
>> Cheers
>> Andrea
>> 
>> 
>> -- Forwarded message --
>> From: Andrea Aime > >
>> Date: Sun, Mar 18, 2018 at 4:27 PM
>> Subject: Binary incompatible change in OGR JNI?
>> To: Even Rouault > >
>> 
>> 
>> Hi Even,
>> recently I have had reports of some failures in the GeoTools bridge to OGR.
>> Looking into it I've found this build error:
>> 
>> Warning 1: Field name of width 255 truncated to 254.
>> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882 sec 
>> <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
>> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time 
>> elapsed: 0.014 sec  <<< ERROR!
>> java.lang.UnsatisfiedLinkError: 
>> org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
>>  at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
>>  at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
>>  at 
>> org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOGR.java:257)
>>  at 
>> org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFeatureSource.java:128)
>>  at 
>> org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRFeatureSource.java:158)
>>  at 
>> org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFeatureStore.java:109)
>>  at 
>> 

Re: [Geotools-devel] About the OGR failures

[Ian Turton]

As I recall just importing the basic geometries from a MapInfo file wasn't
too hard but there is a whole bunch of styling and other junk in there too
that people wanted to read in.

Plus whoever was doing it would need a MapInfo licence to generate/check
input files.

So not impossible but not cheap either.

Ian

On 18 April 2018 at 13:56, Andrea Aime  wrote:

> Hi Jesper,
> you can take over maintainership of the BridJ module and fix the build, or
> sponsor
> someone to do it for you.
>
> Writing mapinfo support in java would be best of course, but also believe
> it's a sizable effort
> (take a look at the OGR mapinfo source code, something similar would have
> to be built
> for GeoTools, along with a good amount of tests).
>
> Cheers
> Andrea
>
>
> On Wed, Apr 18, 2018 at 2:50 PM, Jesper Steen Møller  > wrote:
>
>> Hi list
>>
>> Ugh - removing OGR support will make it impossible for Java tools to
>> access MapInfo files. We're using BridJ for now, as it's easier to get the
>> GDAL bits without the corresponding JNI shared object.
>>
>> Is there anything I could do to help? How big a job is building MapInfo
>> support in Java?
>>
>> -Jesper
>>
>> On 18 Apr 2018, at 14.30, Andrea Aime 
>> wrote:
>>
>> Hi all,
>> any feedback? If not, I plan to remove the module sometimes soon.
>> (mind, the JNI module will be broken just the same at runtime, but won't
>> fail the build unless the JNI native lib is around, which is normally not)
>>
>> Cheers
>> Andrea
>>
>> On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime > > wrote:
>>
>>> Hi Ben,
>>> I've already inquired to Even about those failures, looks like signature
>>> of a few methods changes in OGR 1.11.
>>> Both JNI and BridJ bindings fail, the difference is that BridJ does not
>>> need the "bridge" JNI native library so it
>>> runs most of the time, while the JNI one skip the tests.
>>>
>>> Now, with something dynamic as BridJ I guess one could check the OGR
>>> version, have native bindings for
>>> the various methods overloads, and call the right ones, but for the JNI
>>> case I'm not sure what to do.
>>>
>>> This notion of "buliding against a knows GDAL version" is not a match
>>> for the way we do things, GeoTools/GeoServer
>>> are just dropped on a machine and the find whatever they find, there is
>>> no notion of packaging against a specific
>>> version like with the native packages.
>>>
>>> All in all I'm tempted to just drop support for the OGR data store, at
>>> least of the BridJ part, it's getting too much
>>> work to maintain and there are other things having a higher priority,
>>> and to be honest, I have never used it
>>> for a real project (I created the first version of it in my spare time
>>> as a "good gesture" in the OSGeo familiy,
>>> but never got traction).
>>>
>>> Discussion with Even follows.
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> -- Forwarded message --
>>> From: Andrea Aime 
>>> Date: Sun, Mar 18, 2018 at 4:27 PM
>>> Subject: Binary incompatible change in OGR JNI?
>>> To: Even Rouault 
>>>
>>>
>>> Hi Even,
>>> recently I have had reports of some failures in the GeoTools bridge to
>>> OGR.
>>> Looking into it I've found this build error:
>>>
>>> Warning 1: Field name of width 255 truncated to 254.
>>> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882
>>> sec <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
>>> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)
>>> Time elapsed: 0.014 sec  <<< ERROR!
>>> java.lang.UnsatisfiedLinkError: org.gdal.ogr.ogrJNI.Layer_SetS
>>> patialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
>>> at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
>>> at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
>>> at org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOG
>>> R.java:257)
>>> at org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFe
>>> atureSource.java:128)
>>> at org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRF
>>> eatureSource.java:158)
>>> at org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFe
>>> atureStore.java:109)
>>> at org.geotools.data.store.ContentFeatureSource.getCount(Conten
>>> tFeatureSource.java:507)
>>> at org.geotools.data.store.ContentFeatureCollection.size(Conten
>>> tFeatureCollection.java:231)
>>> at org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(O
>>> GRDataStoreTest.java:750)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at junit.framework.TestCase.runTest(TestCase.java:176)
>>> at 

Re: [Geotools-devel] About the OGR failures

[Jesper Steen Møller]

Hi list

Ugh - removing OGR support will make it impossible for Java tools to access 
MapInfo files. We're using BridJ for now, as it's easier to get the GDAL bits 
without the corresponding JNI shared object.

Is there anything I could do to help? How big a job is building MapInfo support 
in Java?

-Jesper

> On 18 Apr 2018, at 14.30, Andrea Aime  wrote:
> 
> Hi all,
> any feedback? If not, I plan to remove the module sometimes soon.
> (mind, the JNI module will be broken just the same at runtime, but won't fail 
> the build unless the JNI native lib is around, which is normally not)
> 
> Cheers
> Andrea
> 
> On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime  > wrote:
> Hi Ben,
> I've already inquired to Even about those failures, looks like signature of a 
> few methods changes in OGR 1.11.
> Both JNI and BridJ bindings fail, the difference is that BridJ does not need 
> the "bridge" JNI native library so it
> runs most of the time, while the JNI one skip the tests.
> 
> Now, with something dynamic as BridJ I guess one could check the OGR version, 
> have native bindings for
> the various methods overloads, and call the right ones, but for the JNI case 
> I'm not sure what to do.
> 
> This notion of "buliding against a knows GDAL version" is not a match for the 
> way we do things, GeoTools/GeoServer
> are just dropped on a machine and the find whatever they find, there is no 
> notion of packaging against a specific
> version like with the native packages.
> 
> All in all I'm tempted to just drop support for the OGR data store, at least 
> of the BridJ part, it's getting too much
> work to maintain and there are other things having a higher priority, and to 
> be honest, I have never used it
> for a real project (I created the first version of it in my spare time as a 
> "good gesture" in the OSGeo familiy,
> but never got traction).
> 
> Discussion with Even follows.
> 
> Cheers
> Andrea
> 
> 
> -- Forwarded message --
> From: Andrea Aime  >
> Date: Sun, Mar 18, 2018 at 4:27 PM
> Subject: Binary incompatible change in OGR JNI?
> To: Even Rouault  >
> 
> 
> Hi Even,
> recently I have had reports of some failures in the GeoTools bridge to OGR.
> Looking into it I've found this build error:
> 
> Warning 1: Field name of width 255 truncated to 254.
> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882 sec 
> <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time 
> elapsed: 0.014 sec  <<< ERROR!
> java.lang.UnsatisfiedLinkError: 
> org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
>   at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
>   at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
>   at 
> org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOGR.java:257)
>   at 
> org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFeatureSource.java:128)
>   at 
> org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRFeatureSource.java:158)
>   at 
> org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFeatureStore.java:109)
>   at 
> org.geotools.data.store.ContentFeatureSource.getCount(ContentFeatureSource.java:507)
>   at 
> org.geotools.data.store.ContentFeatureCollection.size(ContentFeatureCollection.java:231)
>   at 
> org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(OGRDataStoreTest.java:750)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at org.geotools.data.ogr.TestCaseSupport.run(TestCaseSupport.java:113)
>   at junit.framework.TestSuite.runTest(TestSuite.java:255)
>   at junit.framework.TestSuite.run(TestSuite.java:250)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> 

Re: [Geotools-devel] About the OGR failures

[Andrea Aime]

Hi Jesper,
you can take over maintainership of the BridJ module and fix the build, or
sponsor
someone to do it for you.

Writing mapinfo support in java would be best of course, but also believe
it's a sizable effort
(take a look at the OGR mapinfo source code, something similar would have
to be built
for GeoTools, along with a good amount of tests).

Cheers
Andrea


On Wed, Apr 18, 2018 at 2:50 PM, Jesper Steen Møller 
wrote:

> Hi list
>
> Ugh - removing OGR support will make it impossible for Java tools to
> access MapInfo files. We're using BridJ for now, as it's easier to get the
> GDAL bits without the corresponding JNI shared object.
>
> Is there anything I could do to help? How big a job is building MapInfo
> support in Java?
>
> -Jesper
>
> On 18 Apr 2018, at 14.30, Andrea Aime 
> wrote:
>
> Hi all,
> any feedback? If not, I plan to remove the module sometimes soon.
> (mind, the JNI module will be broken just the same at runtime, but won't
> fail the build unless the JNI native lib is around, which is normally not)
>
> Cheers
> Andrea
>
> On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime 
> wrote:
>
>> Hi Ben,
>> I've already inquired to Even about those failures, looks like signature
>> of a few methods changes in OGR 1.11.
>> Both JNI and BridJ bindings fail, the difference is that BridJ does not
>> need the "bridge" JNI native library so it
>> runs most of the time, while the JNI one skip the tests.
>>
>> Now, with something dynamic as BridJ I guess one could check the OGR
>> version, have native bindings for
>> the various methods overloads, and call the right ones, but for the JNI
>> case I'm not sure what to do.
>>
>> This notion of "buliding against a knows GDAL version" is not a match for
>> the way we do things, GeoTools/GeoServer
>> are just dropped on a machine and the find whatever they find, there is
>> no notion of packaging against a specific
>> version like with the native packages.
>>
>> All in all I'm tempted to just drop support for the OGR data store, at
>> least of the BridJ part, it's getting too much
>> work to maintain and there are other things having a higher priority, and
>> to be honest, I have never used it
>> for a real project (I created the first version of it in my spare time as
>> a "good gesture" in the OSGeo familiy,
>> but never got traction).
>>
>> Discussion with Even follows.
>>
>> Cheers
>> Andrea
>>
>>
>> -- Forwarded message --
>> From: Andrea Aime 
>> Date: Sun, Mar 18, 2018 at 4:27 PM
>> Subject: Binary incompatible change in OGR JNI?
>> To: Even Rouault 
>>
>>
>> Hi Even,
>> recently I have had reports of some failures in the GeoTools bridge to
>> OGR.
>> Looking into it I've found this build error:
>>
>> Warning 1: Field name of width 255 truncated to 254.
>> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882
>> sec <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
>> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time
>> elapsed: 0.014 sec  <<< ERROR!
>> java.lang.UnsatisfiedLinkError: org.gdal.ogr.ogrJNI.Layer_SetS
>> patialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
>> at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
>> at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
>> at org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOG
>> R.java:257)
>> at org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFe
>> atureSource.java:128)
>> at org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRF
>> eatureSource.java:158)
>> at org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFe
>> atureStore.java:109)
>> at org.geotools.data.store.ContentFeatureSource.getCount(Conten
>> tFeatureSource.java:507)
>> at org.geotools.data.store.ContentFeatureCollection.size(Conten
>> tFeatureCollection.java:231)
>> at org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(O
>> GRDataStoreTest.java:750)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at junit.framework.TestCase.runTest(TestCase.java:176)
>> at junit.framework.TestCase.runBare(TestCase.java:141)
>> at junit.framework.TestResult$1.protect(TestResult.java:122)
>> at junit.framework.TestResult.runProtected(TestResult.java:142)
>> at junit.framework.TestResult.run(TestResult.java:125)
>> at junit.framework.TestCase.run(TestCase.java:129)
>> at org.geotools.data.ogr.TestCaseSupport.run(TestCaseSupport.java:113)
>> at junit.framework.TestSuite.runTest(TestSuite.java:255)
>> at junit.framework.TestSuite.run(TestSuite.java:250)
>> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
>> 

Re: [Geotools-devel] About the OGR failures

[Andrea Aime]

Hi all,
any feedback? If not, I plan to remove the module sometimes soon.
(mind, the JNI module will be broken just the same at runtime, but won't
fail the build unless the JNI native lib is around, which is normally not)

Cheers
Andrea

On Wed, Apr 4, 2018 at 2:07 PM, Andrea Aime 
wrote:

> Hi Ben,
> I've already inquired to Even about those failures, looks like signature
> of a few methods changes in OGR 1.11.
> Both JNI and BridJ bindings fail, the difference is that BridJ does not
> need the "bridge" JNI native library so it
> runs most of the time, while the JNI one skip the tests.
>
> Now, with something dynamic as BridJ I guess one could check the OGR
> version, have native bindings for
> the various methods overloads, and call the right ones, but for the JNI
> case I'm not sure what to do.
>
> This notion of "buliding against a knows GDAL version" is not a match for
> the way we do things, GeoTools/GeoServer
> are just dropped on a machine and the find whatever they find, there is no
> notion of packaging against a specific
> version like with the native packages.
>
> All in all I'm tempted to just drop support for the OGR data store, at
> least of the BridJ part, it's getting too much
> work to maintain and there are other things having a higher priority, and
> to be honest, I have never used it
> for a real project (I created the first version of it in my spare time as
> a "good gesture" in the OSGeo familiy,
> but never got traction).
>
> Discussion with Even follows.
>
> Cheers
> Andrea
>
>
> -- Forwarded message --
> From: Andrea Aime 
> Date: Sun, Mar 18, 2018 at 4:27 PM
> Subject: Binary incompatible change in OGR JNI?
> To: Even Rouault 
>
>
> Hi Even,
> recently I have had reports of some failures in the GeoTools bridge to OGR.
> Looking into it I've found this build error:
>
> Warning 1: Field name of width 255 truncated to 254.
> Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.882 sec
> <<< FAILURE! - in org.geotools.data.ogr.jni.JniOGRDataStoreTest
> testGeometryFilters(org.geotools.data.ogr.jni.JniOGRDataStoreTest)  Time
> elapsed: 0.014 sec  <<< ERROR!
> java.lang.UnsatisfiedLinkError: org.gdal.ogr.ogrJNI.Layer_SetS
> patialFilter(JLorg/gdal/ogr/Layer;JLorg/gdal/ogr/Geometry;)V
> at org.gdal.ogr.ogrJNI.Layer_SetSpatialFilter(Native Method)
> at org.gdal.ogr.Layer.SetSpatialFilter(Layer.java:89)
> at org.geotools.data.ogr.jni.JniOGR.LayerSetSpatialFilter(JniOGR.java:257)
> at org.geotools.data.ogr.OGRFeatureSource.setLayerFilters(OGRFe
> atureSource.java:128)
> at org.geotools.data.ogr.OGRFeatureSource.getCountInternal(OGRF
> eatureSource.java:158)
> at org.geotools.data.ogr.OGRFeatureStore.getCountInternal(OGRFe
> atureStore.java:109)
> at org.geotools.data.store.ContentFeatureSource.getCount(Conten
> tFeatureSource.java:507)
> at org.geotools.data.store.ContentFeatureCollection.size(Conten
> tFeatureCollection.java:231)
> at org.geotools.data.ogr.OGRDataStoreTest.testGeometryFilters(O
> GRDataStoreTest.java:750)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at org.geotools.data.ogr.TestCaseSupport.run(TestCaseSupport.java:113)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
> ssRunner.java:84)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUni
> t4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestS
> et(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit
> 4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProvider
> InSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInPro
> cess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBoo
> ter.java:103)
>
> Are you by any chance aware of such changes in the OGR JNI interface?
> If you have to look, no problem, I'll do it, just wanted to see if it
> rings a bell for you.
>
> Ah, context, the store was developed against 1.9, linux distros are
> currently shipping 1.11(.3)
>
> Cheers
> Andrea
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.