Re: [gdal-dev] GDAL 2.0.2 & gpkg woes
> The libspatialite code where the failure occurs is only executed when > spatialite is built with LOADABLE_EXTENSION undefined. Is there any > possibility that the new gpkg code depends on this being defined? > LOADABLE_EXTENSION does not appear anywhere in the GDAL source. Are you trying to link to mod_spatialite or libspatialite ? Brad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unable to get multi-platform JAR working for GDAL 2.x
Even,
That does seem to be the problem; I had already compiled the bindings using
SWIG 3.x and the make clean command wasn't clearing everything out completely.
I verified the new jar made after running the veryclean command now has the
appropriate SWIGDatasetUpcast method just like the windows one does.
This should fix the issue. I really appreciate your help!
Steven D. Lander, Software Engineer
Reinventing Geospatial, Inc
From: Even Rouault
Sent: Tuesday, May 3, 2016 1:19:54 PM
To: gdal-dev@lists.osgeo.org
Cc: Lander, Steven
Subject: Re: [gdal-dev] Unable to get multi-platform JAR working for GDAL 2.x
> * Linux builds make
> Dataset_SWIGUpcast no matter what SWIG version I compile with. I have
> verified this by compiling the java swig project, unzipping the Jars, and
> running the GNU strings command on the gdalJNI.class file to see the
> method names in that file.
Here with SWIG 1.3.40 on Linux, I see :
gdal_wrap.cpp:SWIGEXPORT jlong JNICALL
Java_org_gdal_gdal_gdalJNI_SWIGDatasetUpcast(JNIEnv *jenv, jclass jcls, jlong
jarg1) {
org/gdal/gdal/gdalJNI.java: public final static native long
SWIGDriverUpcast(long jarg1);
And with SWIG 2.0.12:
gdal_wrap.cpp:SWIGEXPORT jlong JNICALL
Java_org_gdal_gdal_gdalJNI_Dataset_1SWIGUpcast(JNIEnv *jenv, jclass jcls, jlong
jarg1) {
org/gdal/gdal/gdalJNI.java: public final static native long
Dataset_SWIGUpcast(long jarg1);
Are you sure you generate the bindings with the swig version you think to ?
You can check this by looking at the header of the generated
swig/java/gdal_wrap.cpp for example.
If you switch between swig versions, make sure to do a "make veryclean" in
swig/java so that bindings get regenerated at the next build attempt.
Even
--
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] GDAL 2.1 and Norwegian SOSI
Hei Even, Thanks for the incredibly quick fix. I shall test at once. Cheers Stefan -Original Message- From: Even Rouault [mailto:even.roua...@spatialys.com] Sent: 3. mai 2016 21:33 To: gdal-dev@lists.osgeo.org Cc: Blumentrath, Stefan Subject: Re: [gdal-dev] GDAL 2.1 and Norwegian SOSI Le mardi 03 mai 2016 21:06:14, Blumentrath, Stefan a écrit : > Dear GDAL-devs, > > I just tried to open a Norwegian SOSI file with ogrinfo from GDAL > 2.1dev but get: FAILURE: > Unable to open datasource `./ADM_kommune_2018_Masoy.sos' with the > following drivers. > > 'ogrinfo --formats' does not list the SOSI driver either. But I am > sure I did compile with '--with-sosi' and gdal-config --dep-libs lists > the openfyba libs used for the driver. Hum, I see this is actually a 2.1.0 regression. Fix available in https://trac.osgeo.org/gdal/ticket/6500 > > So my question is,: were there any changes from 1.11 to 2.x which may > affect the driver? Any chance someone will make that working again? > Unfortunately our mapping authority does not seem to be maintaining > the OpenFYBA lib any more (SOSI version 4.5 not yet supported), so I > can understand if you are not too keen on fixing the issue (if it is > not local). > > Thanks for any help. > > Kind regards, > Stefan -- 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] GDAL 2.1 and Norwegian SOSI
Le mardi 03 mai 2016 21:06:14, Blumentrath, Stefan a écrit : > Dear GDAL-devs, > > I just tried to open a Norwegian SOSI file with ogrinfo from GDAL 2.1dev > but get: FAILURE: > Unable to open datasource `./ADM_kommune_2018_Masoy.sos' with the following > drivers. > > 'ogrinfo --formats' does not list the SOSI driver either. But I am sure I > did compile with '--with-sosi' and gdal-config --dep-libs lists the > openfyba libs used for the driver. Hum, I see this is actually a 2.1.0 regression. Fix available in https://trac.osgeo.org/gdal/ticket/6500 > > So my question is,: were there any changes from 1.11 to 2.x which may > affect the driver? Any chance someone will make that working again? > Unfortunately our mapping authority does not seem to be maintaining the > OpenFYBA lib any more (SOSI version 4.5 not yet supported), so I can > understand if you are not too keen on fixing the issue (if it is not > local). > > Thanks for any help. > > Kind regards, > Stefan -- 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
[gdal-dev] GDAL 2.1 and Norwegian SOSI
Dear GDAL-devs, I just tried to open a Norwegian SOSI file with ogrinfo from GDAL 2.1dev but get: FAILURE: Unable to open datasource `./ADM_kommune_2018_Masoy.sos' with the following drivers. 'ogrinfo --formats' does not list the SOSI driver either. But I am sure I did compile with '--with-sosi' and gdal-config --dep-libs lists the openfyba libs used for the driver. So my question is,: were there any changes from 1.11 to 2.x which may affect the driver? Any chance someone will make that working again? Unfortunately our mapping authority does not seem to be maintaining the OpenFYBA lib any more (SOSI version 4.5 not yet supported), so I can understand if you are not too keen on fixing the issue (if it is not local). Thanks for any help. Kind regards, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?
Le mardi 03 mai 2016 20:23:49, jramm a écrit : > Hi > > When writing geotiffs, if I dont write blocks they will automatically be > filled on close by the FillEmptyTiles. > It appears that this will only fill with zeros - is it possible to make it > fill with the no data value instead? You can also avoid the blocks to be written at all with the SPARSE_OK=TRUE creation option. On reading, missing blocks will be returned filled with the nodata value. But sparse geotiffs are a bit non-standard. We'd welcome a patch to modify FillEmptyTiles to use the nodata value > > This is potentially a huge time saver when processing a large, fairly > sparse geotiff using python as relying on gdal to fill in 'null' blocks > appears far quicker than calling the python write method. > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-va > lue-tp5264310.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 -- 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
[gdal-dev] Geotiff FillEmptyTiles with no data value?
Hi When writing geotiffs, if I dont write blocks they will automatically be filled on close by the FillEmptyTiles. It appears that this will only fill with zeros - is it possible to make it fill with the no data value instead? This is potentially a huge time saver when processing a large, fairly sparse geotiff using python as relying on gdal to fill in 'null' blocks appears far quicker than calling the python write method. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Geotiff-FillEmptyTiles-with-no-data-value-tp5264310.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] GDAL 2.0.2 & gpkg woes
Le mardi 03 mai 2016 19:50:11, Alan Stewart a écrit : > Even, > > The libspatialite code where the failure occurs is only executed when > spatialite is built with LOADABLE_EXTENSION undefined. Is there any > possibility that the new gpkg code depends on this being defined? > LOADABLE_EXTENSION does not appear anywhere in the GDAL source. Alan, From what I see from spatialite code, spatialite_init_ex() is only defined if LOADABLE_EXTENSION is undefined (by spatialite own makefiles). LOADABLE_EXTENSION is undefined when libspatialite.so/.dll is built, and defined when mod_spatialite is built ( https://www.gaia- gis.it/fossil/libspatialite/wiki?name=mod_spatialite ). And GDAL needs spatialite_init_ex() to be defined when linking against new (>= 4.1.2) spatialite versions. I'm not sure what's wrong/particular with your sqlite and/or spatialite build, but there are several builds in the wild that work (MS4W, OSGeo4W, gisinternals). If you don't need spatialite, you can disable it when building GDAL. The GPKG driver doesn't absolutely require it. Spatialite provides processing functions, but for simple read/write scenarios, they are not needed. You can also dynamically disable spatialite loading by defining SPATIALITE_LOAD=NO as environmenet variable. Even > > Alan Stewart > Senior Software Engineer > TerraGo Technologies > 3200 Windy Hill Road, Suite 1550W > Atlanta, GA 30339 USA > O. +1 678.391.9615 > > www.terragotech.com > > -Original Message- > From: Even Rouault [mailto:even.roua...@spatialys.com] > Sent: Saturday, April 30, 2016 11:00 AM > To: gdal-dev@lists.osgeo.org > Cc: Alan Stewart > Subject: Re: [gdal-dev] GDAL 2.0.2 & gpkg woes > > On Friday 29 April 2016 14:07:52 Alan Stewart wrote: > > My debug build of ogr2ogr.exe fails in exactly the same way as my > > application code fails. Apparently there's some difference in how the > > new GPKG code uses spatialite or expects spatialite to be built? The > > same libspatialite DLL works with our GDAL 1.11.0 DLL, but fails with > > the new GDAL 2.0.2 DLL. > > Alan, > > Never heard of similar issues. But you could probably try to upgrade to the > latest version of sqlite in the 3.8.X series. And/or upgrade your > spatialite version to the latest stable 4.3.0a. Might be possible that the > changes between GDAL 1.11 and 2.0 have triggered an integration issue with > one of the sqlite/spatialite versions you use. > > Even > > > Alan Stewart > > Senior Software Engineer > > TerraGo Technologies > > 3200 Windy Hill Road, Suite 1550W > > Atlanta, GA 30339 USA > > O. +1 678.391.9615 > > > > www.terragotech.com > > > > ___ > > 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 -- 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] compile error on windows
On 2016-05-03 3:11 PM, Even Rouault wrote: Le mardi 03 mai 2016 19:57:45, Jeff McKenna a écrit : I'm also very ok with changing the default to set H5_BUILT_AS_DYNAMIC_LIB only - I'll just edit the makefile before building. Not an issue for me. I'm not keen to modify things without a clear understanding of what is required in which context. Well if I go back and build the dynamic HDf5 lib, and then set H5_BUILT_AS_DYNAMIC_LIB, then of course my resulting gdal.dll is smaller in size, which I could live with. So making this the default setting 'going forward' in GDAL makes sense. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compile error on windows
Le mardi 03 mai 2016 19:57:45, Jeff McKenna a écrit : > I'm also very ok with changing the default to set > H5_BUILT_AS_DYNAMIC_LIB only - I'll just edit the makefile before > building. Not an issue for me. I'm not keen to modify things without a clear understanding of what is required in which context. > > Since no one is recording these notes from this long discussion in the > buildhints wiki, I'm +1 to change to this new setting in makefile.vc; > then I'll make a note on the buildhints wiki and make sure the MS4W > process is updated. I agree. Ideally we would need a table : HDF5 version | HDF5 cmake build options | GDAL required compilation flags > > -jeff > > > On 2016-05-03 1:36 PM, Even Rouault wrote: > >> If you have the opportunity, it would be good if you could check if > >> defining > >> both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB doesn't affect > >> negatively your > >> builds. Ideally, we'd like to have a default set of compilation flags > >> that > >> works out of the box for (almost) everybody. > > > > It will depend how HDF5 was compiled (the cmake settings). For example, > > I build the static lib of HDF5, and therefore in GDAL's nmake.opt I > > point to "libhdf5.lib". In my case I therefore do not need to set > > H5_BUILT_AS_DYNAMIC_LIB > > > > If I try to set both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB I get 61 > > unresolved symbols in the linker. > > > > Now are you understanding my grey hair comment Even? :) > > > > I feel these notes are important to document in the buildhints wiki. > > > > -jeff > > ___ > 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] compile error on windows
I'm also very ok with changing the default to set H5_BUILT_AS_DYNAMIC_LIB only - I'll just edit the makefile before building. Not an issue for me. Since no one is recording these notes from this long discussion in the buildhints wiki, I'm +1 to change to this new setting in makefile.vc; then I'll make a note on the buildhints wiki and make sure the MS4W process is updated. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 2016-05-03 2:42 PM, Jeff McKenna wrote: On 2016-05-03 1:36 PM, Even Rouault wrote: If you have the opportunity, it would be good if you could check if defining both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB doesn't affect negatively your builds. Ideally, we'd like to have a default set of compilation flags that works out of the box for (almost) everybody. It will depend how HDF5 was compiled (the cmake settings). For example, I build the static lib of HDF5, and therefore in GDAL's nmake.opt I point to "libhdf5.lib". In my case I therefore do not need to set H5_BUILT_AS_DYNAMIC_LIB If I try to set both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB I get 61 unresolved symbols in the linker. Now are you understanding my grey hair comment Even? :) I feel these notes are important to document in the buildhints wiki. -jeff ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.0.2 & gpkg woes
Even, The libspatialite code where the failure occurs is only executed when spatialite is built with LOADABLE_EXTENSION undefined. Is there any possibility that the new gpkg code depends on this being defined? LOADABLE_EXTENSION does not appear anywhere in the GDAL source. Alan Stewart Senior Software Engineer TerraGo Technologies 3200 Windy Hill Road, Suite 1550W Atlanta, GA 30339 USA O. +1 678.391.9615 www.terragotech.com -Original Message- From: Even Rouault [mailto:even.roua...@spatialys.com] Sent: Saturday, April 30, 2016 11:00 AM To: gdal-dev@lists.osgeo.org Cc: Alan Stewart Subject: Re: [gdal-dev] GDAL 2.0.2 & gpkg woes On Friday 29 April 2016 14:07:52 Alan Stewart wrote: > My debug build of ogr2ogr.exe fails in exactly the same way as my > application code fails. Apparently there's some difference in how the > new GPKG code uses spatialite or expects spatialite to be built? The > same libspatialite DLL works with our GDAL 1.11.0 DLL, but fails with > the new GDAL 2.0.2 DLL. Alan, Never heard of similar issues. But you could probably try to upgrade to the latest version of sqlite in the 3.8.X series. And/or upgrade your spatialite version to the latest stable 4.3.0a. Might be possible that the changes between GDAL 1.11 and 2.0 have triggered an integration issue with one of the sqlite/spatialite versions you use. Even > Alan Stewart > Senior Software Engineer > TerraGo Technologies > 3200 Windy Hill Road, Suite 1550W > Atlanta, GA 30339 USA > O. +1 678.391.9615 > > www.terragotech.com > > ___ > 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] compile error on windows
On 2016-05-03 1:36 PM, Even Rouault wrote: If you have the opportunity, it would be good if you could check if defining both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB doesn't affect negatively your builds. Ideally, we'd like to have a default set of compilation flags that works out of the box for (almost) everybody. It will depend how HDF5 was compiled (the cmake settings). For example, I build the static lib of HDF5, and therefore in GDAL's nmake.opt I point to "libhdf5.lib". In my case I therefore do not need to set H5_BUILT_AS_DYNAMIC_LIB If I try to set both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB I get 61 unresolved symbols in the linker. Now are you understanding my grey hair comment Even? :) I feel these notes are important to document in the buildhints wiki. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unable to get multi-platform JAR working for GDAL 2.x
> * Linux builds make
> Dataset_SWIGUpcast no matter what SWIG version I compile with. I have
> verified this by compiling the java swig project, unzipping the Jars, and
> running the GNU strings command on the gdalJNI.class file to see the
> method names in that file.
Here with SWIG 1.3.40 on Linux, I see :
gdal_wrap.cpp:SWIGEXPORT jlong JNICALL
Java_org_gdal_gdal_gdalJNI_SWIGDatasetUpcast(JNIEnv *jenv, jclass jcls, jlong
jarg1) {
org/gdal/gdal/gdalJNI.java: public final static native long
SWIGDriverUpcast(long jarg1);
And with SWIG 2.0.12:
gdal_wrap.cpp:SWIGEXPORT jlong JNICALL
Java_org_gdal_gdal_gdalJNI_Dataset_1SWIGUpcast(JNIEnv *jenv, jclass jcls, jlong
jarg1) {
org/gdal/gdal/gdalJNI.java: public final static native long
Dataset_SWIGUpcast(long jarg1);
Are you sure you generate the bindings with the swig version you think to ?
You can check this by looking at the header of the generated
swig/java/gdal_wrap.cpp for example.
If you switch between swig versions, make sure to do a "make veryclean" in
swig/java so that bindings get regenerated at the next build attempt.
Even
--
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
[gdal-dev] Unable to get multi-platform JAR working for GDAL 2.x
I have been struggling to get a working gdal.jar for both Windows and Linux for a few days/weeks now. A previous issue reported to the mailing list outlines the issue: http://lists.osgeo.org/pipermail/gdal-dev/2016-January/043357.html For windows, I am using Windows 10 64 bit, along with the 64-bit GDAL dev release which reports to be 2.1.0beta1 when I run gdalinfo --version. This is also confirmed by the information page for the release: http://www.gisinternals.com/packageinfo.php?file=release-1800-x64-gdal-mapserver.zip. They also state that it was compiled with SWIG 2.0.4 but I have no way to independently verify that. On Linux, I get the stable release of 2.1.0 and compile it just fine, using SWIG 2.0.4 as stated in the earlier thread. I make the GDAL java bindings with no issue. The problem seems to be Windows will NOT use the jar compiled on Linux and vice versa. Whenever I try to use the Jar from one platform on another platform, I get an UnsatisfiedLink exception pointing to either Dataset_SWIGUpcast or SWIGDatasetUpcast being the problem. On each platform I have the location of the GDAL JNI files in the PATH (Windows) or LD_LIBRARY_PATH (Linux). I use Gradle to build and run my software on each platform, and the GDAL jar is being imported in the gradle file from a lib folder. As mentioned in the thread Even Roualt responded to, I have tried numerous times on Linux to build the bindings for SWIG using version 1.3.40, 2.0.4, and even 3.0.x. Nothing I do can get this Upcast issue to go away. * Is this just not possible? Do I absolutely have to use the same jar compiled for my platform? * All GISInternals releases seem to use SWIGDatasetUpcast to register GDAL drivers * Linux builds make Dataset_SWIGUpcast no matter what SWIG version I compile with. I have verified this by compiling the java swig project, unzipping the Jars, and running the GNU strings command on the gdalJNI.class file to see the method names in that file. * Are the CPP files for gdalJNI not the same for each platform? How is it I am getting two different scenarios where Windows will only work if SWIGDatasetUpcast is present and Linux will only work if Dataset_SWIGUpcast is present in gdalJNI.class? * Ultimately I just want to be able to use 1 gdal.jar in my project so that IntelliJ does not have to worry about which version to load. IntelliJ names the Jar explicitly in it's module folder structure and those files are supposed to be in source. If that file is different for Windows and Linux users, then that creates version headaches for my devs. * I can easily make this issue moot by having gradle detect my platform and load the appropriate jar by unique name at test/compile time, but that will not work for my IntelliJ/source control issue Any ideas? I am struggling to think of other ways to troubleshoot this issue.. Steven D. Lander, Software Engineer Reinventing Geospatial, Inc Steven.Lander AT rgi-corp DOT com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compile error on windows
Le mardi 03 mai 2016 18:23:47, Jeff McKenna a écrit : > On 2016-05-03 4:54 AM, Even Rouault wrote: > >> -EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 -D_HDF5USEDLL_ > >> +EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 > >> -DH5_BUILT_AS_DYNAMIC_LIB > > > > Jeff, > > > > does the above match your experience ? We could probably define both > > _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB to address different versions. > > > > I see in https://www.hdfgroup.org/windows/faq.html that _HDF5USEDLL_ is > > still advised. > > Hi Even, > > I only set -D_HDF5USEDLL in /frmts/hdf5/makefile.vc and I don't have any > issues compiling GDAL against HDF5-1.8.16 If you have the opportunity, it would be good if you could check if defining both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB doesn't affect negatively your builds. Ideally, we'd like to have a default set of compilation flags that works out of the box for (almost) everybody. > > It likely comes down to how HDf5 is compiled (the cmake settings), which > again calls for everyone to be sure to make sure these notes are > recorded on the buildhints page (which by all the discussion here > lately, that page should be getting lots and lots of edits lately - > that's a strong nudge from me to everyone). > https://trac.osgeo.org/gdal/wiki/HDF > > -jeff -- 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] compile error on windows
On 2016-05-03 4:54 AM, Even Rouault wrote: -EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 -D_HDF5USEDLL_ +EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 -DH5_BUILT_AS_DYNAMIC_LIB Jeff, does the above match your experience ? We could probably define both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB to address different versions. I see in https://www.hdfgroup.org/windows/faq.html that _HDF5USEDLL_ is still advised. Hi Even, I only set -D_HDF5USEDLL in /frmts/hdf5/makefile.vc and I don't have any issues compiling GDAL against HDF5-1.8.16 It likely comes down to how HDf5 is compiled (the cmake settings), which again calls for everyone to be sure to make sure these notes are recorded on the buildhints page (which by all the discussion here lately, that page should be getting lots and lots of edits lately - that's a strong nudge from me to everyone). https://trac.osgeo.org/gdal/wiki/HDF -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compile error on windows
an see thers) I'm working on a new build for the MS4W community with the new 2015 compiler, which seems to work better managing these 4 libraries (huge knock on wood!). In terms of building HDF5, one of the important notes is during cmake be sure to set "-DBUILD_SHARED_LIBS:BOOL:ON" I'm not sure if that helps you case or not. All this to say, you're not alone in this battle! -jeff Jeff I can contribute to this effort (already built a couple of GDAL dependencies: HDFs, netCDF and others) but there is one capcha, and that is really an head tearing for me but I insist on it. All my builds have renamed DLLs. That is, I don't want version numbers in it (no gdal2.0.1.dll) and 32 & 64 bits are encoded in name as well. For example gdal will be: gdal_w32.dll & gdal_w64.dll Don't know if this condition is too restrictive for you. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GSoC 2016
Hello GSoC students! I created the section about GSoC 2016 (https://trac.osgeo.org/gdal/wiki/SoCProjects) in GDAL wiki. Please write your project texts as was done previous years and provide them to your mentors to publish them at appropriate wiki pages. Don't afraid some duplication the OSGeo wiki. -- Best regards, Dmitry ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about MBTiles write support @ GDAL 2.1 RC4
GDALBuildOverviews() seems to works fine now, my bad. Thanks for the responses. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Questions-about-MBTiles-write-support-GDAL-2-1-RC4-tp5263684p5264135.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] Question on mbtiles format
I saw the code on gdal-2.1.0\frmts\mbtiles\mbtilesdataset.cpp I want know where a blob is written into mbtiles. I don't see any INSERT SQL statement for inserting a tile blob Gane ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compile error on windows
Le lundi 02 mai 2016 23:21:04, Ryan Grout a écrit : > Thanks, again Christoph. You're a lifesaver. > > For the benefit of the gdal-dev list. > Applying the below patch to GDAL fixed my build issues with HDF5 1.8.16 > --- > -- diff --git frmts/hdf5/makefile.vc frmts/hdf5/makefile.vc > index e2e695d..02f006f 100644 > --- frmts/hdf5/makefile.vc > +++ frmts/hdf5/makefile.vc > @@ -7,7 +7,7 @@ OBJ=hdf5dataset.obj hdf5imagedataset.obj \ > > PLUGIN_DLL =gdal_HDF5.dll > > -EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 -D_HDF5USEDLL_ > +EXTRAFLAGS = -I$(HDF5_DIR)\include -DWIN32 > -DH5_BUILT_AS_DYNAMIC_LIB Jeff, does the above match your experience ? We could probably define both _HDF5USEDLL_ and H5_BUILT_AS_DYNAMIC_LIB to address different versions. I see in https://www.hdfgroup.org/windows/faq.html that _HDF5USEDLL_ is still advised. Ryan, could you try with both -D_HDF5USEDLL_ and -DH5_BUILT_AS_DYNAMIC_LIB defined ? (make sure to clean the frmts/hdf5 directory before rebuilding) Even -- 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
