Re: [gdal-dev] Native library load failed while using gdal maven dependency - UnsatisfiedLinkError
Thanks. Will be looking into that soon. Will report back here if it works. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Native-library-load-failed-while-using-gdal-maven-dependency-UnsatisfiedLinkError-tp5249728p5249772.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Native library load failed while using gdal maven dependency - UnsatisfiedLinkError
Looks like you have everything configured properly. I have seen reports
from users having issue with using a gdal jar compiled on a different
system. I’ve never seen that personally but from what I understand the
solution in that case was to just compile the java (and the rest of the
gdal libs) themselves locally.
On Tue, Feb 9, 2016 at 12:58 PM ssaniev wrote:
> Hi Justin,
>
> Coding in java Windows7/Eclipse/spring/maven.
>
> *As told before, added dependency to pom, and see the gdal-2.0.0.jar in
> maven dependencies and able to import to my java class.*
>
> org.gdal
> gdal
> 2.0.0
>
>
>
> I downloaded the libraries from here:
>
> http://download.gisinternals.com/sdk/downloads/release-1800-x64-gdal-1-11-3-mapserver-6-4-2.zip
>
> unzippped... and added the both paths below to my environment PATH
> variable:
> ..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin
> ..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java
>
> Created another environment variable
>
> GDAL_DATA=..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal-data
>
> Inside Eclipse, added a VM argument to my project runtume:
>
> -Djava.library.path="..\workspace\GISDataDirectory\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java\;${env_var:PATH}"
>
>
>
> *And after all this, I am getting a different related error:*
>
> Native library load failed.
> java.lang.UnsatisfiedLinkError:
>
> ..\workspace\GISDataDirectory\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java\gdaljni.dll:
> The specified procedure could not be found
>
> nested exception is java.lang.UnsatisfiedLinkError:
> org.gdal.gdal.gdalJNI.VersionInfo__SWIG_1()Ljava/lang/String;] with root
> cause
>
>
> What am I missing here?
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Native-library-load-failed-while-using-gdal-maven-dependency-UnsatisfiedLinkError-tp5249728p5249767.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Native library load failed while using gdal maven dependency - UnsatisfiedLinkError
Hi Justin,
Coding in java Windows7/Eclipse/spring/maven.
*As told before, added dependency to pom, and see the gdal-2.0.0.jar in
maven dependencies and able to import to my java class.*
org.gdal
gdal
2.0.0
I downloaded the libraries from here:
http://download.gisinternals.com/sdk/downloads/release-1800-x64-gdal-1-11-3-mapserver-6-4-2.zip
unzippped... and added the both paths below to my environment PATH variable:
..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin
..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java
Created another environment variable
GDAL_DATA=..\Downloads\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal-data
Inside Eclipse, added a VM argument to my project runtume:
-Djava.library.path="..\workspace\GISDataDirectory\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java\;${env_var:PATH}"
*And after all this, I am getting a different related error:*
Native library load failed.
java.lang.UnsatisfiedLinkError:
..\workspace\GISDataDirectory\release-1800-x64-gdal-1-11-3-mapserver-6-4-2\bin\gdal\java\gdaljni.dll:
The specified procedure could not be found
nested exception is java.lang.UnsatisfiedLinkError:
org.gdal.gdal.gdalJNI.VersionInfo__SWIG_1()Ljava/lang/String;] with root
cause
What am I missing here?
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Native-library-load-failed-while-using-gdal-maven-dependency-UnsatisfiedLinkError-tp5249728p5249767.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Native library load failed while using gdal maven dependency - UnsatisfiedLinkError
Hi,
Have you set the java.library.path system property to the location of the
gdal libraries on the system? The gdal jar doesn’t contain any of the
native libraries, just the java parts.
I’ve found that usually I do need to set LD_LIBRARY_PATH to include the
location of the gdal libraries, and the location of any libraries that it
is linked to.
For example if you I had the native GDAL libraries in /usr/local/lib I
would set up my java IDE as follows:
- Set the environment variable LD_LIBRARY_PATH (linux) or DYLD_LIBRARY_PATH
(osx) to /usr/local/lib
- Add the java system property “-Djava.library.path=/usr/local/lib”
And that usually does the trick for me. Hope that helps.
-Justin
On Tue, Feb 9, 2016 at 9:40 AM ssaniev wrote:
> Hey guys,
>
> First time GDAL user here.
>
> We are trying to load shapefiles into postgresql DB, and were able to do so
> with GDAL ogr2ogr CLI utility.
> Following cmd works via cmd:
> ogr2ogr -f PostgreSQL PG:"host='hostName' port='5432' user='userName'
> dbname='dbName' password='aPassword'" shapeFileName.shp
>
>
> *Next step is to accomplish this in java with GDAL bindings. *
>
> There is a maven dependency for gdal which we included in our pom.xml:
>
>org.gdal
>gdal
>2.0.0
>
>
>
> *We import and simply want to output the version of gdal in java: *
>
> import org.gdal.gdal.gdal;
>
> public class ShapeFileWorker {
> public void process(String fileName, String hostAddress) {
> gdal.VersionInfo()
> }
> }
>
>
> *While trying to use gdal library in our java class, we are getting the
> following error: *
> java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
>
>
> The development project is in SPRING, and Eclipse IDE.
>
> After reading many online gdal discussions, I have added GDAL_DATA and
> LD_LIBRARY_PATH variables.
>
> But since we are using gdal maven dependency, we shouldn't need them.
>
> Anyone could point us in the right direction?
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Native-library-load-failed-while-using-gdal-maven-dependency-UnsatisfiedLinkError-tp5249728.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Native library load failed while using gdal maven dependency - UnsatisfiedLinkError
Hey guys,
First time GDAL user here.
We are trying to load shapefiles into postgresql DB, and were able to do so
with GDAL ogr2ogr CLI utility.
Following cmd works via cmd:
ogr2ogr -f PostgreSQL PG:"host='hostName' port='5432' user='userName'
dbname='dbName' password='aPassword'" shapeFileName.shp
*Next step is to accomplish this in java with GDAL bindings. *
There is a maven dependency for gdal which we included in our pom.xml:
org.gdal
gdal
2.0.0
*We import and simply want to output the version of gdal in java: *
import org.gdal.gdal.gdal;
public class ShapeFileWorker {
public void process(String fileName, String hostAddress) {
gdal.VersionInfo()
}
}
*While trying to use gdal library in our java class, we are getting the
following error: *
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
The development project is in SPRING, and Eclipse IDE.
After reading many online gdal discussions, I have added GDAL_DATA and
LD_LIBRARY_PATH variables.
But since we are using gdal maven dependency, we shouldn't need them.
Anyone could point us in the right direction?
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Native-library-load-failed-while-using-gdal-maven-dependency-UnsatisfiedLinkError-tp5249728.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
I declare this motion passed with +1 from Even, Tamas, Jukka and Daniel and no -1. I'll commit soon the changes to the core and then later the drivers: memory, shape and pg. The goal is to keep the travis test build passing. Ari 05.02.2016, 10:04, Ari Jolma kirjoitti: I'd like to ask the PSC and others to vote on adopting RFC 61: Support for measured geometries. The draft RFC is at https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries and a draft implementation is at https://github.com/ajolma/GDAL-XYZM which is tested at https://travis-ci.org/ajolma/GDAL-XYZM (the test #34, which passed, was the so far last one after core changes with unchanged autotests and a rather comprehensive set of WKT tests in the Perl tests directory) This is seemingly a small change but it is at the heart of OGR so it has some important implications. The only backwards incompatibilities that have appeared so far are with some drivers, for example shapefile, which can be lessened with, e.g., open options. Best, Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] shp to raster
Paulo Pires gmail.com> writes: > > Hello > > I try to use: gdal_rasterize -a xxx -burn 255 -burn 0 -ts 3000 3000 -l xxx > aaa.shp bbb.tif for create raster from line shapefile but the output is a > black raster... > > Something is wrong on my command line? Hi, I suppose that the command is planned to take the burn value either from an attribute with -a or from user given values with -burn. Your command has -a and two -burn parameters. You do not have -b parameters for defining the bands. I recommend to read http://www.gdal.org/gdal_rasterize.html again and test with the first example command. Once you see that it works change the parameters one by one to fine tune the result. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
09.02.2016, 11:17, Even Rouault kirjoitti: Tests are not independant from each other, so I suspect the failure in ogr_pg_21 might let a (implicit) transaction non committed. Thus ogr_pg_24 which opens a new connection doesn't see the table created before. Whereas if you quit, the transaction will be committed. That's it. I think it is a bug. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
Le mardi 09 février 2016 09:18:00, Ari Jolma a écrit : > Thanks, > > We now have +1 from Even, Tamas, Jukka and Daniel. Is that formally enough? Yes. at least 2 business days, 2 +1 votes and no -1. > > I have a small change to the draft. I now think that the coordinate > flags should be managed/queried solely through Is3D(), IsMeasured() > (which are standard) and set3D(boolean) and setMeasured(boolean), (which > are extensions to the SF specification). I.e., the getFlags() and > setFlags(int) should be removed. The reason is that there is one flag, > which is used only for points, and thus the API can be easily misused. Sounds good. I had a bit that feeling too when looking at the code but didn't dive enough into the implementation to have a strong opinion on it. > > Similarly the bit #defines for the coordinate flags sh/could be private. > In practice that means to move them to ogr_p.h. > > Even, there are strange errors in the ogr_pg.py tests. > > https://s3.amazonaws.com/archive.travis-ci.org/jobs/107782519/log.txt > > Test 24 fails because the layer is NoneType, i.e., it does not open the > datatypetest table. However, if I run the tests up to 24 but quit before > it, the table exists and seems to be ok. Tests are not independant from each other, so I suspect the failure in ogr_pg_21 might let a (implicit) transaction non committed. Thus ogr_pg_24 which opens a new connection doesn't see the table created before. Whereas if you quit, the transaction will be committed. > I had similar problems with the > shape driver - temporary datasets disappearing midtests. Any idea what's > the reason? This cannot be due to transactions here, but here too steps may have dependencies. > > Ari > > 08.02.2016, 19:06, Daniel Morissette kirjoitti: > > On 2016-02-05 3:04 AM, Ari Jolma wrote: > >> I'd like to ask the PSC and others to vote on adopting RFC 61: Support > >> for measured geometries. > >> > >> The draft RFC is at > >> > >> https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries > > > > +1 > > > > Daniel > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
09.02.2016, 10:18, Ari Jolma kirjoitti: Even, there are strange errors in the ogr_pg.py tests. https://s3.amazonaws.com/archive.travis-ci.org/jobs/107782519/log.txt Test 24 fails because the layer is NoneType, i.e., it does not open the datatypetest table. However, if I run the tests up to 24 but quit before it, the table exists and seems to be ok. I had similar problems with the shape driver - temporary datasets disappearing midtests. Any idea what's the reason? A bit more on this: If I run the tests until 24, i.e., including it, and then quit. The table datatypetest is in the database. If I run the test under gdb just until where test 24 attempts to open the table, the table is not in the database. I can see this also from pgAdmin. The table seems to disappear just for the test. Which is very confusing. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] convert shapefile from California State Plane to EPSG:4326
Am 09.02.2016 um 03:35 schrieb maning sambale: Thanks Daniel and Even, Using following Even's advice, I get better results: https://gist.github.com/maning/093a866fd465ea880032#better-conversion Wondering if it might be appropriate to change proj.4 defaults to the above ? +1 The datum shift between WGS84 and NAD83 is related to the tectonic plate shift, which varies across North America, and over the time. So it makes not much sense to change the proj.4 values, unless it is checked for accuracy at several places across the continent, and bound to a certain time. Locally, you get good fitting vectors and images if you use the same shift as was used for georeferencing the orthoimages. Greetings, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
Thanks, We now have +1 from Even, Tamas, Jukka and Daniel. Is that formally enough? I have a small change to the draft. I now think that the coordinate flags should be managed/queried solely through Is3D(), IsMeasured() (which are standard) and set3D(boolean) and setMeasured(boolean), (which are extensions to the SF specification). I.e., the getFlags() and setFlags(int) should be removed. The reason is that there is one flag, which is used only for points, and thus the API can be easily misused. Similarly the bit #defines for the coordinate flags sh/could be private. In practice that means to move them to ogr_p.h. Even, there are strange errors in the ogr_pg.py tests. https://s3.amazonaws.com/archive.travis-ci.org/jobs/107782519/log.txt Test 24 fails because the layer is NoneType, i.e., it does not open the datatypetest table. However, if I run the tests up to 24 but quit before it, the table exists and seems to be ok. I had similar problems with the shape driver - temporary datasets disappearing midtests. Any idea what's the reason? Ari 08.02.2016, 19:06, Daniel Morissette kirjoitti: On 2016-02-05 3:04 AM, Ari Jolma wrote: I'd like to ask the PSC and others to vote on adopting RFC 61: Support for measured geometries. The draft RFC is at https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries +1 Daniel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
