Re: [gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

[Nik Sands]

Hi again,

I have now resolved this issue by rebuilding SQLite with the 
SQLITE_OMIT_PROGRESS_CALLBACK=OFF

GDAL 3.6.0 will now build successfully with my updated buiild of SQLite.

Sorry to have troubled you with this one.

NB:  This may still be worth pursuing within GDAL, since SQLite explicitly 
recommend building with this omitted, as per:  
https://www.sqlite.org/compile.html

If you still wished to pursue a GDAL fix for possibility of missing 
sqlite3_progress_handler, then it’s worth noting that it’s not an iOS issue, as 
far as I know, since I was not using iOS default SQLite.

Cheers,
Nik.


> On 12 Nov 2022, at 1:51 pm, Nik Sands  wrote:
> 
> Hi Even,
> 
> Sorry, I should have mentioned that I’m not using the standard iOS/macOS 
> SQLite (because it does not include RTREE extension which seems to be 
> required for GDAL).
> 
> I’m using a CMAKE compatible SQLite from:  
> https://github.com/azadkuh/sqlite-amalgamation (which was working fine with 
> GDAL 3.5.2)
> 
> I tried building SQLite with:
>   -DSQLITE_OMIT_PROGRESS_CALLBACK=OFF
> but it logged that it was ignoring this (not sure why, when it works OK when 
> I specify other options similarly, such as -DSQLITE_OMIT_DECLTYPE=OFF)
> 
> Anyhow…
> 
> The patch build of GDAL did not resolve the problem, although the output is 
> slightly different.  I still got this error (re-pasted from current build, 
> below).
> 
> I’m also trying to figure out how to get SQLITE_OMIT_PROGRESS_CALLBACK 
> disabled in my SQLite build, which may be a better way to go?  Got to figure 
> out the right CMakeLists.txt changes (in SQLite) for this.
> 
> Cheers,
> Nik.
> 
> 
> Consolidate compiler generated dependencies of target gdal_unit_test
> [ 94%] Linking CXX executable gdal_unit_test.app/gdal_unit_test
> Undefined symbols for architecture arm64:
>   "_sqlite3_progress_handler", referenced from:
>   OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int 
> (*)(double, char const*, void*), void*) in 
> libgdal.a(ogrgeopackagetablelayer.cpp.o)
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[2]: *** [autotest/cpp/gdal_unit_test.app/gdal_unit_test] Error 1
> make[1]: *** [autotest/cpp/CMakeFiles/gdal_unit_test.dir/all] Error 2
> make: *** [all] Error 2
> 
> 
>> On 12 Nov 2022, at 12:45 pm, Even Rouault  wrote:
>> 
>> Weird. So it would seem the SQLite3 build on iOS lacks 
>> sqlite3_progress_handler()
>> 
>> As this is not critical for operations, I've added a CMake configure check 
>> for the presence of this function to conditionally enable it.
>> 
>> Can you try https://github.com/OSGeo/gdal/pull/6675 ?
>> 
>> Even
>> 
>> Le 12/11/2022 à 02:32, Nik Sands a écrit :
>>> After patching GDAL 3.6.0 for ‘pread64’ issue when building for iOS (see 
>>> previous email), the build now progresses to the 100% mark, but then fails 
>>> with the _sqlite3_progress_handler error below.
>>> 
>>> I’m afraid that I don’t even know where to start with this one.  How should 
>>> I proceed?
>>> 
>>> Cheers,
>>> Nik.
>>> 
>>> 
>>> 
>>> [100%] Built target check_swq_parser_md5
>>> Consolidate compiler generated dependencies of target my_test_sqlite3_ext
>>> [100%] Built target my_test_sqlite3_ext
>>> [100%] Built target check_ods_formula_parser_md5
>>> Consolidate compiler generated dependencies of target test_gdal_fuzzer
>>> [100%] Linking CXX executable test_gdal_fuzzer.app/test_gdal_fuzzer
>>> Undefined symbols for architecture arm64:
>>>   "_sqlite3_progress_handler", referenced from:
>>>   OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int 
>>> (*)(double, char const*, void*), void*) in 
>>> libgdal.a(ogrgeopackagetablelayer.cpp.o)
>>> ld: symbol(s) not found for architecture arm64
>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)
>>> make[2]: *** [fuzzers/tests/test_gdal_fuzzer.app/test_gdal_fuzzer] Error 1
>>> make[1]: *** [fuzzers/tests/CMakeFiles/test_gdal_fuzzer.dir/all] Error 2
>>> make: *** [all] Error 2
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>> 
>> -- 
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>> 
>> ___
>> gdal-dev mailing list
>&

Re: [gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

[Nik Sands]

Hi Even,

This patch worked fine to resolve the ‘pread64’ error on iOS and Mac Catalyst.

Thank you.
-Nik

> On 12 Nov 2022, at 12:12 pm, Even Rouault  wrote:
> 
> Nik,
> 
> actually I've just modified it to the following that still tries to detect 
> pread(). Can you test and report?
> 
> diff --git a/cmake/helpers/configure.cmake b/cmake/helpers/configure.cmake
> index f52ea47db3..0939ffadda 100644
> --- a/cmake/helpers/configure.cmake
> +++ b/cmake/helpers/configure.cmake
> @@ -241,16 +241,6 @@ else ()
>check_type_size("off_t" SIZEOF_OFF_T)
> 
>check_function_exists(pread64 HAVE_PREAD64)
> -  if( NOT HAVE_PREAD64 )
> -check_c_source_compiles(
> -  "
> - #include 
> - #include 
> - #include 
> - int main() { pread(0, NULL, 0, 0); return 0; }
> -"
> -  HAVE_PREAD_BSD)
> -  endif()
> 
>check_function_exists(ftruncate64 HAVE_FTRUNCATE64)
>if (HAVE_FTRUNCATE64)
> @@ -280,6 +270,19 @@ else ()
>  unset(HAVE_FSEEK64 CACHE)
>  unset(HAVE_STATVFS64)
>  unset(HAVE_STATVFS64 CACHE)
> +unset(HAVE_PREAD64)
> +unset(HAVE_PREAD64 CACHE)
> +  endif()
> +
> +  if( NOT HAVE_PREAD64 )
> +check_c_source_compiles(
> +  "
> + #include 
> + #include 
> + #include 
> + int main() { pread(0, NULL, 0, 0); return 0; }
> +    "
> +  HAVE_PREAD_BSD)
>endif()
> 
>set(UNIX_STDIO_64 TRUE)
> 
> Le 12/11/2022 à 02:07, Even Rouault a écrit :
>> 
>> Le 12/11/2022 à 02:00, Nik Sands a écrit :
>>> Hi GDAL devs
>>> 
>>> It appears as though ‘pread64’, introduced in 3.6.0, has broken building on 
>>> iOS in the same way that other ‘…64’ errors used to occur on version 3.5.0 
>>> before being patched for 3.5.2.
>>> 
>>> The attached patch (text content also pasted below) allows the build to 
>>> continue past that point for iOS (and Mac Catalyst). I’m just an ignorant 
>>> hobbyist who doesn’t really understand a lot of this stuff, so please check 
>>> that what I’ve done here is correct!  :-)  If it’s all OK, then please 
>>> apply this (or similar) patch for the next release.
>> 
>> Patch queued in https://github.com/OSGeo/gdal/pull/6673
>> 
>> Thanks
>> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 



NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

[Nik Sands]

Hi Even,

Sorry, I should have mentioned that I’m not using the standard iOS/macOS SQLite 
(because it does not include RTREE extension which seems to be required for 
GDAL).

I’m using a CMAKE compatible SQLite from:  
https://github.com/azadkuh/sqlite-amalgamation (which was working fine with 
GDAL 3.5.2)

I tried building SQLite with:
-DSQLITE_OMIT_PROGRESS_CALLBACK=OFF
but it logged that it was ignoring this (not sure why, when it works OK when I 
specify other options similarly, such as -DSQLITE_OMIT_DECLTYPE=OFF)

Anyhow…

The patch build of GDAL did not resolve the problem, although the output is 
slightly different.  I still got this error (re-pasted from current build, 
below).

I’m also trying to figure out how to get SQLITE_OMIT_PROGRESS_CALLBACK disabled 
in my SQLite build, which may be a better way to go?  Got to figure out the 
right CMakeLists.txt changes (in SQLite) for this.

Cheers,
Nik.


Consolidate compiler generated dependencies of target gdal_unit_test
[ 94%] Linking CXX executable gdal_unit_test.app/gdal_unit_test
Undefined symbols for architecture arm64:
  "_sqlite3_progress_handler", referenced from:
  OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int (*)(double, 
char const*, void*), void*) in libgdal.a(ogrgeopackagetablelayer.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [autotest/cpp/gdal_unit_test.app/gdal_unit_test] Error 1
make[1]: *** [autotest/cpp/CMakeFiles/gdal_unit_test.dir/all] Error 2
make: *** [all] Error 2


> On 12 Nov 2022, at 12:45 pm, Even Rouault  wrote:
> 
> Weird. So it would seem the SQLite3 build on iOS lacks 
> sqlite3_progress_handler()
> 
> As this is not critical for operations, I've added a CMake configure check 
> for the presence of this function to conditionally enable it.
> 
> Can you try https://github.com/OSGeo/gdal/pull/6675 ?
> 
> Even
> 
> Le 12/11/2022 à 02:32, Nik Sands a écrit :
>> After patching GDAL 3.6.0 for ‘pread64’ issue when building for iOS (see 
>> previous email), the build now progresses to the 100% mark, but then fails 
>> with the _sqlite3_progress_handler error below.
>> 
>> I’m afraid that I don’t even know where to start with this one.  How should 
>> I proceed?
>> 
>> Cheers,
>> Nik.
>> 
>> 
>> 
>> [100%] Built target check_swq_parser_md5
>> Consolidate compiler generated dependencies of target my_test_sqlite3_ext
>> [100%] Built target my_test_sqlite3_ext
>> [100%] Built target check_ods_formula_parser_md5
>> Consolidate compiler generated dependencies of target test_gdal_fuzzer
>> [100%] Linking CXX executable test_gdal_fuzzer.app/test_gdal_fuzzer
>> Undefined symbols for architecture arm64:
>>   "_sqlite3_progress_handler", referenced from:
>>   OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int 
>> (*)(double, char const*, void*), void*) in 
>> libgdal.a(ogrgeopackagetablelayer.cpp.o)
>> ld: symbol(s) not found for architecture arm64
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> make[2]: *** [fuzzers/tests/test_gdal_fuzzer.app/test_gdal_fuzzer] Error 1
>> make[1]: *** [fuzzers/tests/CMakeFiles/test_gdal_fuzzer.dir/all] Error 2
>> make: *** [all] Error 2
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Build 3.6.0 for iOS fails - _sqlite3_progress_handler error

[Nik Sands]

After patching GDAL 3.6.0 for ‘pread64’ issue when building for iOS (see 
previous email), the build now progresses to the 100% mark, but then fails with 
the _sqlite3_progress_handler error below.

I’m afraid that I don’t even know where to start with this one.  How should I 
proceed?

Cheers,
Nik.



[100%] Built target check_swq_parser_md5
Consolidate compiler generated dependencies of target my_test_sqlite3_ext
[100%] Built target my_test_sqlite3_ext
[100%] Built target check_ods_formula_parser_md5
Consolidate compiler generated dependencies of target test_gdal_fuzzer
[100%] Linking CXX executable test_gdal_fuzzer.app/test_gdal_fuzzer
Undefined symbols for architecture arm64:
  "_sqlite3_progress_handler", referenced from:
  OGRGeoPackageTableLayer::GetGeometryTypes(int, int, int&, int (*)(double, 
char const*, void*), void*) in libgdal.a(ogrgeopackagetablelayer.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [fuzzers/tests/test_gdal_fuzzer.app/test_gdal_fuzzer] Error 1
make[1]: *** [fuzzers/tests/CMakeFiles/test_gdal_fuzzer.dir/all] Error 2
make: *** [all] Error 2
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.6.0 patch for building on iOS (and Mac Catalyst)

[Nik Sands]

Hi GDAL devs

It appears as though ‘pread64’, introduced in 3.6.0, has broken building on iOS 
in the same way that other ‘…64’ errors used to occur on version 3.5.0 before 
being patched for 3.5.2.

The attached patch (text content also pasted below) allows the build to 
continue past that point for iOS (and Mac Catalyst).  I’m just an ignorant 
hobbyist who doesn’t really understand a lot of this stuff, so please check 
that what I’ve done here is correct!  :-)  If it’s all OK, then please apply 
this (or similar) patch for the next release.

(I’ll post my next error in a seperate email, shortly.)

(PS.  I’m VERY excited to be able to create/update fGDBs with 3.6.0!!!  Thanks 
so much for all the work you guys do on this.)

Cheers,
Nik.


--- configure.cmake.orig2022-11-07 07:09:20
+++ configure.cmake 2022-11-12 11:39:42
@@ -280,6 +280,7 @@
 unset(HAVE_FSEEK64 CACHE)
 unset(HAVE_STATVFS64)
 unset(HAVE_STATVFS64 CACHE)
+unset(HAVE_PREAD64 CACHE)
   endif()
 
   set(UNIX_STDIO_64 TRUE)




configure.cmake.PATCH
Description: Binary data
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] iOS patch for GDAL 3.5 requires modification for Mac Catalyst

[Nik Sands]

Hi GDAL devs,

A few months ago, a patch to GDAL 3.5 was developed so that building with CMAKE 
would run correctly for iOS builds.  The patch is below.

I am now extending my iOS app to use Mac Catalyst (for those who don’t know, 
this is an Apple technology to enable apps developed for iOS to also run on 
macOS (both ARM and Intel), and for the Mac version to also be extended to 
include macOS-only functionality, such as menu bars, etc).

I have found that when building for Mac Catalyst, the build failed in exactly 
the same way that it used to fail for iOS before applying the patch (below).  
The errors are due to (as the patch comment says):  tests detect 64 symbols 
for iOS, which are not available at build time.

So I modified the patched file further to replace this line:

if (${CMAKE_SYSTEM_NAME} MATCHES "iOS”)

...with this:

if (${CMAKE_SYSTEM_NAME} MATCHES “iOS” OR ${CMAKE_SYSTEM_NAME} MATCHES “Darwin”)

...and now the Mac Catalyst build works correctly (for both Mac Catalyst x86_64 
AND Mac Catalyst arm64).

HOWEVER, I do not know if this might adversely affect direct (non-catalyst) 
“normal” macOS builds (as I am not doing any such builds myself).  Is anybody 
able to verify if this change would be a problem for macOS.  If not, can this 
change be included in future builds of GDAL, or if it would be problematic for 
“normal” macOS, is there some way to modify the cmake config to check 
explicitly for Mac Catalyst, as opposed to “normal” macOS?

Cheers,
Nik.


START OF PATCH
——

--- orig/configure.cmake2022-05-11 00:03:37.0 +1000
+++ patched/configure.cmake 2022-07-06 18:54:48.0 +1000
@@ -41,6 +41,7 @@
 check_type_size("int" SIZEOF_INT)
 check_type_size("unsigned long" SIZEOF_UNSIGNED_LONG)
 check_type_size("void*" SIZEOF_VOIDP)
+check_type_size("size_t" SIZEOF_SIZE_T)
 
 if (MSVC)
   set(HAVE_VSNPRINTF 1)
@@ -116,6 +117,13 @@
 "
 HAVE_5ARGS_MREMAP)
 
+  check_c_source_compiles(
+"
+#include 
+int main() { pthread_atfork(0,0,0); 0; }
+"
+HAVE_PTHREAD_ATFORK)
+
   check_include_file("sys/stat.h" HAVE_SYS_STAT_H)
   if (${CMAKE_SYSTEM} MATCHES "Linux")
   check_include_file("linux/fs.h" HAVE_LINUX_FS_H)
@@ -233,6 +241,27 @@
 set(VSI_FTRUNCATE64 "ftruncate")
   endif ()
 
+  # For some reason, above tests detect 64 symbols for iOS, which are not
+  # available at build time.
+  if (${CMAKE_SYSTEM_NAME} MATCHES "iOS")
+set(VSI_FOPEN64 "fopen")
+set(VSI_FTRUNCATE64 "ftruncate")
+set(VSI_FTELL64 "ftell")
+set(VSI_FSEEK64 "fseek")
+set(VSI_STAT64 "stat")
+set(VSI_STAT64_T "stat")
+unset(HAVE_FOPEN64)
+unset(HAVE_FOPEN64 CACHE)
+unset(HAVE_FTRUNCATE64)
+unset(HAVE_FTRUNCATE64 CACHE)
+unset(HAVE_FTELL64)
+unset(HAVE_FTELL64 CACHE)
+unset(HAVE_FSEEK64)
+unset(HAVE_FSEEK64 CACHE)
+unset(HAVE_STATVFS64)
+unset(HAVE_STATVFS64 CACHE)
+  endif()
+
   set(UNIX_STDIO_64 TRUE)
 
   set(INCLUDE_XLOCALE_H)
@@ -313,4 +342,4 @@
   set(MACOSX_FRAMEWORK OFF)
 endif ()
 
-# vim: ts=4 sw=4 sts=4 et
+# vim: ts=4 sw=4 sts=4 et
\ No newline at end of file


——
END OF PATCH


NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] How to obtain list of all available SRS in GDAL 3.5?

[Nik Sands]

My app must provide the user with a comprehensive list of Spatial Reference 
Systems to select from.

With GDAL 2.2.2, I did this by querying both 'gcs.csv’ and ‘pcs.csv’ from the 
GDAL_DATA directory.

These files are no longer available in GDAL 3.5.  So what’s the correct way to 
get a list of all the available SRSs now?

Cheers,
Nik.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake ignores EXPAT_INCLUDE_DIR & EXPAT_LIBRARY

[Nik Sands]

Hi Gaige,

Doh!  It was libxml2, not libexpat.  Thanks for pointing me in this direction.

Somehow, I hadn’t noticed the need for libxm2l in GDAL 3.x, as it was not in my 
iOS project which was working fine with GDAL 2.2.2 (or otherwise, it has 
somehow been removed from the project - perhaps when I did a clean up of 
unnecessary libraries).

The the libexpat guess was completely wrong.  It was all libxml2.

Now that I’ve added libxml2.tbd to the project, it builds fine.

Just FYI, as requested, the list of symbols is below (as reported by XCode when 
attempting to replace my old GDAL 2.2.2 library with my new GDAL 3.5 library).

I will remove my custom libexpat (attempt) from my GDAL cmake build process 
again.

Cheers,
Nik.

Undefined symbol: _xmlCatalogResolveSystem
Undefined symbol: _xmlNewStringInputStream
Undefined symbol: _xmlGetLastError
Undefined symbol: _xmlGetExternalEntityLoader
Undefined symbol: _xmlFree
Undefined symbol: _xmlSchemaNewMemParserCtxt
Undefined symbol: _xmlSchemaSetParserErrors
Undefined symbol: _xmlCatalogResolveURI
Undefined symbol: _xmlSetExternalEntityLoader
Undefined symbol: _xmlSchemaFreeParserCtxt
Undefined symbol: _xmlSchemaNewValidCtxt
Undefined symbol: _xmlSchemaValidateFile
Undefined symbol: _xmlSchemaSetValidErrors
Undefined symbol: _xmlSchemaParse
Undefined symbol: _xmlParseDoc
Undefined symbol: _xmlSchemaValidateDoc
Undefined symbol: _xmlFreeDoc
Undefined symbol: _xmlSchemaFreeValidCtxt
Undefined symbol: _xmlSchemaFree

> On 8 Jul 2022, at 8:59 pm, Gaige B. Paulsen  wrote:
> 
> Nik,
> 
> Which symbols is the linker complaining about? I build regularly for iOS 
> (although not using CMake directly), linking with the system copy of libxpat 
> and libxml2 and I haven’t noticed any link or operational failures in 3.5.0. 
> Admittedly, I use a subset of the drivers, but if you can send the linker 
> errors, I can check to see why I'm not having the problem you are, maybe 
> it'll give us a clue.
> 
> Cheers,
> -Gaige
> 
> 
> On 2022-07-07 20:38, Nik Sands wrote:
>> Hi GDAL devs,
>> I’ve built GDAL 3.5 for iOS (device and simulator) but I’ve found that
>> when incorporating libgdal into my iOS app, there are several errors
>> related to undefined symbols, all of which are XML related.
>> My guess is that the libexpat included in Apple’s SDK is missing some
>> symbols that GDAL requires, therefore I’ve now built my own libexpat.
>> Now I’m attempting to rebuild GDAL using my own libexpat, using the
>> cmake configuration command:
>> ==
>> cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN \
>>  -DPLATFORM=$OS \
>>  -DENABLE_BITCODE=OFF \
>>  -DCMAKE_INSTALL_PREFIX=$PREFIX \
>>  -DBUILD_APPS=OFF \
>>  -DBUILD_SHARED_LIBS=OFF \
>>  -DBUILD_PYTHON_BINDINGS=OFF \
>>  -DPROJ_ROOT=$PREFIX \
>>  -DEXPAT_INCLUDE_DIR=$PREFIX/include \
>>  -DEXPAT_LIBRARY=$PREFIX/lib/libexpat.dylib \
>>  -DSQLITE3_INCLUDE_DIR=$PREFIX/include \
>>  -DSQLITE3_LIBRARY=$PREFIX/lib/libsqlite3.a \
>>  -DIconv_INCLUDE_DIR=$SDKPATH/usr \
>>  -DIconv_LIBRARY=$SDKPATH/usr/lib/libiconv.tbd \
>>  -DCMAKE_BUILD_TYPE=Release \
>>  ..
>> ==
>> However, when this completes, it tells me that it has ignored the two
>> libexpat arguments that I supplied to it:
>> ==
>> -- Configuring done
>> -- Generating done
>> CMake Warning:
>>  Manually-specified variables were not used by the project:
>>EXPAT_INCLUDE_DIR
>>EXPAT_LIBRARY
>> -- Build files have been written to: ...
>> ==
>> Why would it be ignoring these arguments and how can I get it to use
>> my own libexpat instead of the default SDK libexpat?
>> Cheers,
>> Nik.
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] cmake ignores EXPAT_INCLUDE_DIR & EXPAT_LIBRARY

[Nik Sands]

Hi GDAL devs,

I’ve built GDAL 3.5 for iOS (device and simulator) but I’ve found that when 
incorporating libgdal into my iOS app, there are several errors related to 
undefined symbols, all of which are XML related.

My guess is that the libexpat included in Apple’s SDK is missing some symbols 
that GDAL requires, therefore I’ve now built my own libexpat.

Now I’m attempting to rebuild GDAL using my own libexpat, using the cmake 
configuration command:

==
cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN \
-DPLATFORM=$OS \
-DENABLE_BITCODE=OFF \
-DCMAKE_INSTALL_PREFIX=$PREFIX \
-DBUILD_APPS=OFF \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_PYTHON_BINDINGS=OFF \
-DPROJ_ROOT=$PREFIX \
-DEXPAT_INCLUDE_DIR=$PREFIX/include \
-DEXPAT_LIBRARY=$PREFIX/lib/libexpat.dylib \
-DSQLITE3_INCLUDE_DIR=$PREFIX/include \
-DSQLITE3_LIBRARY=$PREFIX/lib/libsqlite3.a \
-DIconv_INCLUDE_DIR=$SDKPATH/usr \
-DIconv_LIBRARY=$SDKPATH/usr/lib/libiconv.tbd \
-DCMAKE_BUILD_TYPE=Release \
..
==

However, when this completes, it tells me that it has ignored the two libexpat 
arguments that I supplied to it:

==
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

EXPAT_INCLUDE_DIR
EXPAT_LIBRARY


-- Build files have been written to: ...
==

Why would it be ignoring these arguments and how can I get it to use my own 
libexpat instead of the default SDK libexpat?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.5 successfully built for iOS with cmake

[Nik Sands]

Hi Even,

Yes, you’re updated patch has worked on a (clean) distribution of version 3.5.  
It has built for iOS successfully now, without my second dodgy work-around 
patch.

Thanks again.

Nik.


> On 6 Jul 2022, at 6:28 pm, Even Rouault  wrote:
> 
> Nik,
> 
> can you revert your patches and just try the one at 
> https://github.com/OSGeo/gdal/pull/6024 ?
> 
> The difference with my previous one is that it also unset variables in the 
> cache. Testing locally on Linux (by running it unconditionnaly), I now see 
> that the generated port/cpl_config.h in the build directory no longer define 
> HAVE_STATVFS64, which should avoid the need for your patch in the .cpp file
> 
> Even
> 
> Le 06/07/2022 à 08:41, Nik Sands a écrit :
>> Hello again,
>> 
>> This is just a quick note to follow up on my many questions over the past 
>> few days.
>> 
>> I have successfully built GDAL 3.5 for iOS, and I have fully documented the 
>> procedure I used at:
>> 
>>  
>> https://gis.stackexchange.com/questions/434514/build-gdal-3-x-for-ios/435316#435316
>> 
>> Note that it includes two patches.  The second patch is a very dodgy kludge. 
>>  I hope that people who know better than I do will be able to come up with a 
>> better solution and that both patches will be incorporated into future 
>> distributions of GDAL.
>> 
>> Thanks to Even and the many other people who replied and offered advice and 
>> suggestions (and a patch).
>> 
>> Cheers,
>> Nik.
>> 
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 



NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.5 successfully built for iOS with cmake

[Nik Sands]

Hello again,

This is just a quick note to follow up on my many questions over the past few 
days.

I have successfully built GDAL 3.5 for iOS, and I have fully documented the 
procedure I used at:


https://gis.stackexchange.com/questions/434514/build-gdal-3-x-for-ios/435316#435316

Note that it includes two patches.  The second patch is a very dodgy kludge.  I 
hope that people who know better than I do will be able to come up with a 
better solution and that both patches will be incorporated into future 
distributions of GDAL.

Thanks to Even and the many other people who replied and offered advice and 
suggestions (and a patch).

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build GDAL 3.5 for iOS error: forward declaration of 'stat64'

[Nik Sands]

Thanks Even,

After applying the patch and then running the ‘cmake' and 'cmake —build' again, 
it stops at the same point but produces much fewer errors (and I have found a 
dodgy work-around those - see below).  Only two errors this time, both for the 
same file:

==
[  6%] Building CXX object port/CMakeFiles/cpl.dir/cpl_compressor.cpp.o
[  7%] Building CXX object port/CMakeFiles/cpl.dir/cpl_float.cpp.o
[  7%] Building CXX object port/CMakeFiles/cpl.dir/cpl_vsil_unix_stdio_64.cpp.o
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/port/cpl_vsil_unix_stdio_64.cpp:793:22:
 error: variable has incomplete type 'struct statvfs64'
struct statvfs64 buf;
 ^
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/port/cpl_vsil_unix_stdio_64.cpp:793:12:
 note: forward declaration of 'statvfs64'
struct statvfs64 buf;
   ^
1 error generated.
make[2]: *** [port/CMakeFiles/cpl.dir/cpl_vsil_unix_stdio_64.cpp.o] Error 1
make[1]: *** [port/CMakeFiles/cpl.dir/all] Error 2
make: *** [all] Error 2
==

So the patch has fixed the vast majority of the errors, but this one still 
persists.

DODGY WORK AROUND:

I then modified the file 'port/cpl_vsil_unix_stdio_64.cpp’ and deleted the ‘if' 
section for ‘HAVE_STATVFS64', forcing it to run the stavfs ‘else’ part instead, 
and this time the build continued on (as far as the “98%” mark before producing 
another error which I might post seperately if I can’t resolve it).  Obviously 
this is not the ‘correct’ way to fix the issue, but I hope that it demonstrates 
(part of) where the issue lies and hopefully might help to identify the correct 
solution?

So for some reason, when the 'port/cpl_vsil_unix_stdio_64.cpp’ file is used, it 
appears that HAVE_STATVFS64 is defined, despite the patch having been applied.

Following the patch, my cmake/helpers/configure.cmake file shows that the patch 
has been applied.  The relevent portion of that file now looks like this:

==
  check_function_exists(ftruncate64 HAVE_FTRUNCATE64)
  if (HAVE_FTRUNCATE64)
set(VSI_FTRUNCATE64 "ftruncate64")
  else ()
set(VSI_FTRUNCATE64 "ftruncate")
  endif ()

  if (${CMAKE_SYSTEM_NAME} MATCHES "iOS")
set(VSI_FOPEN64 "fopen")
set(VSI_FTRUNCATE64 "ftruncate")
set(VSI_FTELL64 "ftell")
set(VSI_FSEEK64 "fseek")
set(VSI_STAT64 stat)
set(VSI_STAT64_T stat)
unset(HAVE_FOPEN64)
unset(HAVE_FTRUNCATE64)
unset(HAVE_FTELL64)
unset(HAVE_FSEEK64)
unset(HAVE_STATVFS64)
  endif()

  set(UNIX_STDIO_64 TRUE)

  set(INCLUDE_XLOCALE_H)
  if(HAVE_XLOCALE_H)
set(INCLUDE_XLOCALE_H "#include ")
  endif()
==

Cheers,
Nik.


> On 5 Jul 2022, at 9:23 pm, Even Rouault  wrote:
> 
> (re-adding the list)
> 
> ok, it's a bit weird CMake detects symbols that are not available at build 
> time, but there might be some subtelties in iOS SDK
> 
> Can you try the following patch which basically forces to remap all "foo64" 
> functions to "foo". I assume that iOS Unix I/O is 64-bit enabled by default...
> 
> diff --git a/cmake/helpers/configure.cmake b/cmake/helpers/configure.cmake
> index c38604e23e..e5be264bf9 100644
> --- a/cmake/helpers/configure.cmake
> +++ b/cmake/helpers/configure.cmake
> @@ -241,6 +241,20 @@ else ()
>  set(VSI_FTRUNCATE64 "ftruncate")
>endif ()
>  
> +  if (${CMAKE_SYSTEM_NAME} MATCHES "iOS")
> +set(VSI_FOPEN64 "fopen")
> +set(VSI_FTRUNCATE64 "ftruncate")
> +set(VSI_FTELL64 "ftell")
> +set(VSI_FSEEK64 "fseek")
> +set(VSI_STAT64 stat)
> +set(VSI_STAT64_T stat)
> +unset(HAVE_FOPEN64)
> +unset(HAVE_FTRUNCATE64)
> +unset(HAVE_FTELL64)
> +unset(HAVE_FSEEK64)
> +unset(HAVE_STATVFS64)
> +  endif()
> +
>set(UNIX_STDIO_64 TRUE)
>  
>set(INCLUDE_XLOCALE_H)
> 
> 
> 
> 
> Le 05/07/2022 à 13:07, Nik Sands a écrit :
>> Hi Even,
>> 
>> Thanks again for your advice.  The debug  message did produce what I believe 
>> was the expected output as follows:
>> 
>> CMake Warning at cmake/helpers/configure.cmake:175 (message):
>>   CMAKE_SYSTEM_NAME=iOS
>> 
>> Making the suggested change to the configure.cmake file (line 175 in the 
>> version 3.5 distribution I have) and re-building certainly progresses 
>> further than my previous build attempt.  I now get the errors in the ouput 
>> listed below.  Note that I found one other location in the same 
>> configure.cmake file where it was checking for “Darwin” and I made the same 
>> change to that line, but it made no difference to these errors below.
>> 
>> Cheers,
>> Nik.
>> 
>> 
>> ==
>> …
>

Re: [gdal-dev] Build GDAL 3.5 for iOS error: forward declaration of 'stat64'

[Nik Sands]

/cpl_vsil_unix_stdio_64.cpp:793:12:
 note: forward declaration of 'statvfs64'
struct statvfs64 buf;
   ^
9 errors generated.
make[2]: *** [port/CMakeFiles/cpl.dir/cpl_vsil_unix_stdio_64.cpp.o] Error 1
make[1]: *** [port/CMakeFiles/cpl.dir/all] Error 2
make: *** [all] Error 2
==



> On 5 Jul 2022, at 5:00 pm, Even Rouault  <mailto:even.roua...@spatialys.com>> wrote:
> 
> Nik,
> 
> in cmake/helpers/configure.cmake, there's a special case of Darwin at line 
> 183 in master
> 
>   if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
> 
> Can you test if replacing it with
> 
>   if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR ${CMAKE_SYSTEM_NAME} MATCHES 
> "iOS")
> 
> works better? (I assume CMAKE_SYSTEM_NAME = iOS from 
> https://cmake.org/cmake/help/latest/variable/IOS.html 
> <https://cmake.org/cmake/help/latest/variable/IOS.html> , but you might want 
> to add a 'message(WARNING "CMAKE_SYSTEM_NAME=${CMAKE_SYSTEM_NAME}")' debug 
> statement to check
> 
> Even
> 
> Le 05/07/2022 à 06:14, Nik Sands a écrit :
>> Hi GDAL devs,
>> 
>> As per my earlier emails, I’m attempting to build GDAL 3.5 for iOS.  The 
>> complete process (so far) for this is below, at the end of this email.
>> 
>> A quick summary of some relevant points is:
>> •  Using a 3rd party cmake toolchain file which caters for iOS, macOS (as 
>> well as other Apple OSs) and can even build a fat binary that works for both 
>> iOS device and simulator (arm64/x86_64).
>> •  Using a 3rd party mirror of SQLite which includes cmake configuration, so 
>> that I can incorporate the same methodology to build iOS SQLite that I’m 
>> using for other dependencies (the standard Apple bundled SQLite throws an 
>> error when building GDAL)
>> 
>> The 'cmake  ..’ succeeds to configure the GDAL build.  However, 
>> when I run ‘cmake —build .’ I get the following output:
>> 
>> ==
>> [  0%] Built target generate_gdal_version_h
>> [  0%] Building CXX object apps/CMakeFiles/appslib.dir/gdalinfo_lib.cpp.o
>> [  0%] Building CXX object apps/CMakeFiles/appslib.dir/gdalbuildvrt_lib.cpp.o
>> [  1%] Building CXX object apps/CMakeFiles/appslib.dir/gdal_grid_lib.cpp.o
>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/apps/gdal_grid_lib.cpp:1213:26:
>>  error: variable has incomplete type 'VSIStatBufL' (aka 'stat64')
>> VSIStatBufL  sStat;
>>  ^
>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/port/cpl_vsi.h:195:16:
>>  note: forward declaration of 'stat64'
>> typedef struct VSI_STAT64_T VSIStatBufL;
>>^
>> /Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/port/cpl_config.h:41:22:
>>  note: expanded from macro 'VSI_STAT64_T'
>> #define VSI_STAT64_T stat64
>>  ^
>> 1 error generated.
>> make[2]: *** [apps/CMakeFiles/appslib.dir/gdal_grid_lib.cpp.o] Error 1
>> make[1]: *** [apps/CMakeFiles/appslib.dir/all] Error 2
>> make: *** [all] Error 2
>> ==
>> 
>> I found a GDAL bug that appears to be related, but it was closed as ‘fixed’ 
>> about 8 years ago:
>> https://trac.osgeo.org/gdal/ticket/1005 
>> <https://trac.osgeo.org/gdal/ticket/1005>
>> 
>> This may also be relevant:
>> https://www.spinics.net/lists/dash/msg02117.html
>> 
>> But this is somewhat beyond my (lack of) expertise to resolve.  Does anybody 
>> have any suggestions for resolving this issue?
>> 
>> Cheers,
>> Nik.
>> 
>> 
>> COMPLETE PROCESS TO BUILD iOS GDAL (so far):
>> 
>> 
>> Install Homebrew package manager:
>> /usr/bin/ruby -e "$(curl -fsSL 
>> https://raw.githubusercontent.com/Homebrew/install/master/install)"
>> 
>> Install cmake using Homebrew:
>> brew install cmakecmake --build . --target install
>> 
>> Install ios.toolchain.cmake:
>> Download from:  https://github.com/leetal/ios-cmake
>> Install at:  
>> $HOME/Documents/Development/3rdParty/ios-cmake-master/ios.toolchain.cmake
>> 
>> Environment Variables:
>> export PREFIX=$HOME/build/arm64
>> export 
>> CMTOOLCHAIN=$HOME/Documents/Development/3rdParty/ios-cmake-master/ios.toolchain.cmake
>> 
>> Build SQLite:
>> Download CMAKE-compatible SQLite amalgamation from:
>> https://github.com/azadkuh/sqlite-amalgamation
>> 
>> cd sqlite-amalgamation-master
>> mkdir build
>> cd build
>> cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN -DPLATFORM=OS64 
>> -DCMAKE_INSTALL_PREFIX=$PREFIX -DSQLITE_E

[gdal-dev] Build GDAL 3.5 for iOS error: forward declaration of 'stat64'

[Nik Sands]

Hi GDAL devs,

As per my earlier emails, I’m attempting to build GDAL 3.5 for iOS.  The 
complete process (so far) for this is below, at the end of this email.

A quick summary of some relevant points is:
•  Using a 3rd party cmake toolchain file which caters for iOS, macOS (as well 
as other Apple OSs) and can even build a fat binary that works for both iOS 
device and simulator (arm64/x86_64).
•  Using a 3rd party mirror of SQLite which includes cmake configuration, so 
that I can incorporate the same methodology to build iOS SQLite that I’m using 
for other dependencies (the standard Apple bundled SQLite throws an error when 
building GDAL)

The 'cmake  ..’ succeeds to configure the GDAL build.  However, when I 
run ‘cmake —build .’ I get the following output:

==
[  0%] Built target generate_gdal_version_h
[  0%] Building CXX object apps/CMakeFiles/appslib.dir/gdalinfo_lib.cpp.o
[  0%] Building CXX object apps/CMakeFiles/appslib.dir/gdalbuildvrt_lib.cpp.o
[  1%] Building CXX object apps/CMakeFiles/appslib.dir/gdal_grid_lib.cpp.o
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/apps/gdal_grid_lib.cpp:1213:26:
 error: variable has incomplete type 'VSIStatBufL' (aka 'stat64')
VSIStatBufL  sStat;
 ^
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/port/cpl_vsi.h:195:16:
 note: forward declaration of 'stat64'
typedef struct VSI_STAT64_T VSIStatBufL;
   ^
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/port/cpl_config.h:41:22:
 note: expanded from macro 'VSI_STAT64_T'
#define VSI_STAT64_T stat64
 ^
1 error generated.
make[2]: *** [apps/CMakeFiles/appslib.dir/gdal_grid_lib.cpp.o] Error 1
make[1]: *** [apps/CMakeFiles/appslib.dir/all] Error 2
make: *** [all] Error 2
==

I found a GDAL bug that appears to be related, but it was closed as ‘fixed’ 
about 8 years ago:
https://trac.osgeo.org/gdal/ticket/1005

This may also be relevant:
https://www.spinics.net/lists/dash/msg02117.html

But this is somewhat beyond my (lack of) expertise to resolve.  Does anybody 
have any suggestions for resolving this issue?

Cheers,
Nik.


COMPLETE PROCESS TO BUILD iOS GDAL (so far):


Install Homebrew package manager:
/usr/bin/ruby -e "$(curl -fsSL 
https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install cmake using Homebrew:
brew install cmakecmake --build . --target install

Install ios.toolchain.cmake:
Download from:  https://github.com/leetal/ios-cmake
Install at:  
$HOME/Documents/Development/3rdParty/ios-cmake-master/ios.toolchain.cmake

Environment Variables:
export PREFIX=$HOME/build/arm64
export 
CMTOOLCHAIN=$HOME/Documents/Development/3rdParty/ios-cmake-master/ios.toolchain.cmake

Build SQLite:
Download CMAKE-compatible SQLite amalgamation from:
https://github.com/azadkuh/sqlite-amalgamation

cd sqlite-amalgamation-master
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN -DPLATFORM=OS64 
-DCMAKE_INSTALL_PREFIX=$PREFIX -DSQLITE_ENABLE_RTREE=ON ..
cmake --build .
cmake --build . --target install

Build Proj:
cd proj-{VERSION}
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN -DPLATFORM=OS64 
-DCMAKE_INSTALL_PREFIX=$PREFIX -DENABLE_TIFF=OFF -DENABLE_CURL=OFF 
-DBUILD_PROJSYNC=OFF -DSQLITE3_INCLUDE_DIR=$PREFIX/include 
-DSQLITE3_LIBRARY=$PREFIX/lib/libsqlite3.a ..
cmake --build .
cmake --build . --target install

Build GDAL:
(Specifying the path to PROJ is not required because cmake automatically adds 
CMAKE_INSTALL_PREFIX to CMAKE_SYSTEM_PREFIX_PATH

cd gdal-{VERSION}
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=$CMTOOLCHAIN -DPLATFORM=OS64 
-DCMAKE_INSTALL_PREFIX=$PREFIX/arm64 -DBUILD_APPS=OFF -DBUILD_SHARED_LIBS=OFF 
-DBUILD_PYTHON_BINDINGS=OFF -DSQLITE3_INCLUDE_DIR=$PREFIX/include 
-DSQLITE3_LIBRARY=$PREFIX/lib/libsqlite3.a -DCMAKE_BUILD_TYPE=Release ..
cmake --build .
cmake --build . --target install
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] CMAKE_INSTALL_PREFIX gdalinfo still looks for .dylib in /usr/lib

[Nik Sands]

Hi GDAL devs,

After having just succeeded in getting GDAL to build on macOS using a 
non-default CMAKE_INSTALL_PREFIX, I found that gdalinfo fails because it cannot 
find gdal.dylib in /usr/lib.  I assume other utilities also fail with the same 
error, but I didn’t try them.

Sorry I didn’t copy the exact error message, before I rebuilt GDAL as a static 
library ( BUILD_SHARED_LIBS=OFF ), after which of course gdalinfo works fine.

Is it expected that these GDAL utilities (such as gdalinfo) would look for GDAL 
in /usr/lib instead of the location in which it was actually built?

Cheers,
Nik.



NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building on macOS - fatal error: 'direct.h' file not found

[Nik Sands]

PS.  Apologies - my last email (below) was premature and resulted from a lack 
of effort on my own part.

I’ve solved this lastest issue now.

I don’t need Python bindings in this case, so the easiest solution (instead of 
installing and/or pointing cmake to a compatible Python environment) is of 
course just to add the following to my cmake command:

-DBUILD_PYTHON_BINDINGS=OFF

So my current cmake command for macOS now looks like this:

cmake -DBUILD_PYTHON_BINDINGS=OFF 
-DSQLITE3_INCLUDE_DIR=$HOME/build/include 
-DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a 
-DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release ..

This results in a successful cmake, and then a successful build.

Thanks again to Even and others for the advice to get me this far.  I expect I 
will have more questions later when I try to build for iOS.  :-)

Cheers,
Nik.


> On 4 Jul 2022, at 12:16 pm, Nik Sands  wrote:
> 
> Hi Even,
> 
> Thanks for the suggestions.  I am now using '$HOME' instead of ‘~’.  I’m 
> using static libraries instead of dynamic libraries because my goal is to 
> build GDAL for iOS once I get the process working for macOS and my 
> understanding is that I cannot use dynamic linking in an iOS app (except for 
> OS-bundled libraries).
> 
> I’ve now attempted to build this way (using custom-built SQLite, as explained 
> earlier):
> 
> cd gdal-{VERSION}
> rm -r build
> mkdir build
> cd build
> cmake -DSQLITE3_INCLUDE_DIR=$HOME/build/include 
> -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a 
> -DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release .. >log.txt 2>&1
> 
> I found that it fails if I don’t include:  -DCMAKE_BUILD_TYPE=Release
> 
> Ignoring the CMake error log, as advised, and now just scanning sdout and 
> stderr instead, I find that I get the following at about half-way through the 
> output:
> 
> ==
> -- Found BISON: /usr/bin/bison (found version "2.3")
> Traceback (most recent call last):
>   File 
> "/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/swig/python/get_suffix.py",
>  line 1, in 
> from setuptools.command.build_ext import EXTENSION_SUFFIXES; 
> print(EXTENSION_SUFFIXES[0])
> ImportError: cannot import name 'EXTENSION_SUFFIXES'
> --   Target system: Darwin
> ==
> 
> I don’t really know where to go from here.
> 
> Cheers,
> Nik.
> 
>> On 1 Jul 2022, at 7:22 pm, Even Rouault > <mailto:even.roua...@spatialys.com>> wrote:
>> 
>> Nik,
>> 
>> regarding the build isssue with Mac system sqlite3, I've filed this as 
>> https://github.com/OSGeo/gdal/issues/6011 
>> <https://github.com/OSGeo/gdal/issues/6011>
>> 
>> regarding your other  "Configuring incomplete, errors occurred!" issue, I've 
>> found that generally the CMakeOutput.log and CMakeError.log files aren't the 
>> best way to spot the issue. They contain a lot of "normal" errors such as 
>> the one with iconv, that are due to trying to detect features available or 
>> not available in the build environment, so it is expected that some 
>> detections fail. You must have another issue, which is in the standard error 
>> stream of the "cmake" invokation
>> 
>> Run "cmake .. 2>&1 >log.txt" and look for "error" in log.txt
>> 
>> You may also want to try to link to the dynamic library of libsqlite3 rather 
>> than the static one (static linking is always more difficult to accomplish), 
>> so something like -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.dylib
>> 
>> I would also avoid using the '~' character for values of CMake variables and 
>> rather use $HOME. On my Linux shell, I see the values in the CMakeCache.txt 
>> are not expanded to full paths, and I doubt CMake will do it by itself.
>> 
>> Even
>> 
>> Le 01/07/2022 à 10:58, Nik Sands a écrit :
>>> Thanks again for all the replies and advice.  I should have provided more 
>>> context around my initial query about building GDAL with cmake on macOS.  
>>> So here goes… (this is quite long, so bear with me…)
>>> 
>>> My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as 
>>> well as for macOS on Intel).  I can then combine them into a fat library 
>>> and use that in my project (which is what I've been doing successfully for 
>>> GDAL 2.2.2 for some time).  GDAL 3.6 isn't yet released, so I'm working 
>>> with 3.5 for now in order to get my build process right.
>>> 
>>> I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages 
>>> installed in /usr/loc

Re: [gdal-dev] building on macOS - fatal error: 'direct.h' file not found

[Nik Sands]

Hi John,

Thanks for this information.  This was definitely not the case when I first 
started building iOS apps (quite some time ago), so I’ll have to do some 
further research to make sure I can incorporate dynamic libraries if/when 
appropriate.

Cheers,
Nik.


> On 4 Jul 2022, at 1:16 pm, John Daniel  wrote:
> 
> Nik,
> You can definitely use dynamic linking in an iOS app. 
> 
> I don’t know how you would do that in CMake.
> 
> John Daniel
> Etresoft, Inc.
> 
>> On Jul 3, 2022, at 9:17 PM, Nik Sands  wrote:
>> 
>>  Hi Even,
>> 
>> Thanks for the suggestions.  I am now using '$HOME' instead of ‘~’.  I’m 
>> using static libraries instead of dynamic libraries because my goal is to 
>> build GDAL for iOS once I get the process working for macOS and my 
>> understanding is that I cannot use dynamic linking in an iOS app (except for 
>> OS-bundled libraries).
>> 
>> I’ve now attempted to build this way (using custom-built SQLite, as 
>> explained earlier):
>> 
>> cd gdal-{VERSION}
>> rm -r build
>> mkdir build
>> cd build
>> cmake -DSQLITE3_INCLUDE_DIR=$HOME/build/include 
>> -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a 
>> -DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release .. >log.txt 
>> 2>&1
>> 
>> I found that it fails if I don’t include:  -DCMAKE_BUILD_TYPE=Release
>> 
>> Ignoring the CMake error log, as advised, and now just scanning sdout and 
>> stderr instead, I find that I get the following at about half-way through 
>> the output:
>> 
>> ==
>> -- Found BISON: /usr/bin/bison (found version "2.3")
>> Traceback (most recent call last):
>>   File 
>> "/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/swig/python/get_suffix.py",
>>  line 1, in 
>> from setuptools.command.build_ext import EXTENSION_SUFFIXES; 
>> print(EXTENSION_SUFFIXES[0])
>> ImportError: cannot import name 'EXTENSION_SUFFIXES'
>> --   Target system: Darwin
>> ==
>> 
>> I don’t really know where to go from here.
>> 
>> Cheers,
>> Nik.
>> 
>>> On 1 Jul 2022, at 7:22 pm, Even Rouault >> <mailto:even.roua...@spatialys.com>> wrote:
>>> 
>>> Nik,
>>> 
>>> regarding the build isssue with Mac system sqlite3, I've filed this as 
>>> https://github.com/OSGeo/gdal/issues/6011 
>>> <https://github.com/OSGeo/gdal/issues/6011>
>>> 
>>> regarding your other  "Configuring incomplete, errors occurred!" issue, 
>>> I've found that generally the CMakeOutput.log and CMakeError.log files 
>>> aren't the best way to spot the issue. They contain a lot of "normal" 
>>> errors such as the one with iconv, that are due to trying to detect 
>>> features available or not available in the build environment, so it is 
>>> expected that some detections fail. You must have another issue, which is 
>>> in the standard error stream of the "cmake" invokation
>>> 
>>> Run "cmake .. 2>&1 >log.txt" and look for "error" in log.txt
>>> 
>>> You may also want to try to link to the dynamic library of libsqlite3 
>>> rather than the static one (static linking is always more difficult to 
>>> accomplish), so something like 
>>> -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.dylib
>>> 
>>> I would also avoid using the '~' character for values of CMake variables 
>>> and rather use $HOME. On my Linux shell, I see the values in the 
>>> CMakeCache.txt are not expanded to full paths, and I doubt CMake will do it 
>>> by itself.
>>> 
>>> Even
>>> 
>>> Le 01/07/2022 à 10:58, Nik Sands a écrit :
>>>> Thanks again for all the replies and advice.  I should have provided more 
>>>> context around my initial query about building GDAL with cmake on macOS.  
>>>> So here goes… (this is quite long, so bear with me…)
>>>> 
>>>> My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as 
>>>> well as for macOS on Intel).  I can then combine them into a fat library 
>>>> and use that in my project (which is what I've been doing successfully for 
>>>> GDAL 2.2.2 for some time).  GDAL 3.6 isn't yet released, so I'm working 
>>>> with 3.5 for now in order to get my build process right.
>>>> 
>>>> I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages 
>>>> installed in /usr/local, 

Re: [gdal-dev] building on macOS - fatal error: 'direct.h' file not found

[Nik Sands]

Hi Even,

Thanks for the suggestions.  I am now using '$HOME' instead of ‘~’.  I’m using 
static libraries instead of dynamic libraries because my goal is to build GDAL 
for iOS once I get the process working for macOS and my understanding is that I 
cannot use dynamic linking in an iOS app (except for OS-bundled libraries).

I’ve now attempted to build this way (using custom-built SQLite, as explained 
earlier):

cd gdal-{VERSION}
rm -r build
mkdir build
cd build
cmake -DSQLITE3_INCLUDE_DIR=$HOME/build/include 
-DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.a 
-DCMAKE_INSTALL_PREFIX=$HOME/build -DCMAKE_BUILD_TYPE=Release .. >log.txt 2>&1

I found that it fails if I don’t include:  -DCMAKE_BUILD_TYPE=Release

Ignoring the CMake error log, as advised, and now just scanning sdout and 
stderr instead, I find that I get the following at about half-way through the 
output:

==
-- Found BISON: /usr/bin/bison (found version "2.3")
Traceback (most recent call last):
  File 
"/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/swig/python/get_suffix.py",
 line 1, in 
from setuptools.command.build_ext import EXTENSION_SUFFIXES; 
print(EXTENSION_SUFFIXES[0])
ImportError: cannot import name 'EXTENSION_SUFFIXES'
--   Target system: Darwin
==

I don’t really know where to go from here.

Cheers,
Nik.

> On 1 Jul 2022, at 7:22 pm, Even Rouault  wrote:
> 
> Nik,
> 
> regarding the build isssue with Mac system sqlite3, I've filed this as 
> https://github.com/OSGeo/gdal/issues/6011
> 
> regarding your other  "Configuring incomplete, errors occurred!" issue, I've 
> found that generally the CMakeOutput.log and CMakeError.log files aren't the 
> best way to spot the issue. They contain a lot of "normal" errors such as the 
> one with iconv, that are due to trying to detect features available or not 
> available in the build environment, so it is expected that some detections 
> fail. You must have another issue, which is in the standard error stream of 
> the "cmake" invokation
> 
> Run "cmake .. 2>&1 >log.txt" and look for "error" in log.txt
> 
> You may also want to try to link to the dynamic library of libsqlite3 rather 
> than the static one (static linking is always more difficult to accomplish), 
> so something like -DSQLITE3_LIBRARY=$HOME/build/lib/libsqlite3.dylib
> 
> I would also avoid using the '~' character for values of CMake variables and 
> rather use $HOME. On my Linux shell, I see the values in the CMakeCache.txt 
> are not expanded to full paths, and I doubt CMake will do it by itself.
> 
> Even
> 
> Le 01/07/2022 à 10:58, Nik Sands a écrit :
>> Thanks again for all the replies and advice.  I should have provided more 
>> context around my initial query about building GDAL with cmake on macOS.  So 
>> here goes… (this is quite long, so bear with me…)
>> 
>> My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as 
>> well as for macOS on Intel).  I can then combine them into a fat library and 
>> use that in my project (which is what I've been doing successfully for GDAL 
>> 2.2.2 for some time).  GDAL 3.6 isn't yet released, so I'm working with 3.5 
>> for now in order to get my build process right.
>> 
>> I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages 
>> installed in /usr/local, etc, as dependencies for the GDAL build.  They will 
>> likely work for macOS, but not for iOS.  Therefore I will need to build any 
>> dependencies manually and install to another location (for both iOS and 
>> macOS), where they do not already exist in the standard macOS/iOS SDK 
>> locations (or where the Apple-supplied libraries in those SDK locations are 
>> otherwise incompatible with GDAL - see SQLite notes below).  For any such 
>> dependencies, I plan to install them in ~/build (as I did previously for 
>> GDAL 2.2.2).
>> 
>> So I'm starting out building simply for macOS, but trying to use a similar 
>> technique to what I hope to use for iOS (after I get it working for macOS).
>> 
>> So with all that background, I will now start at the beginning of my 
>> attempts to build GDAL 3.5 using a method that I hope will also work for 
>> iOS...
>> 
>> The GDAL cmake hints page says to do this:
>> 
>> cd gdal-{VERSION}
>> mkdir build
>> cd build
>> cmake ..
>> cmake --build .
>> cmake --build . --target install
>> 
>> When I run this as-is, the 'cmake ..' succeeds, but the 'cmake --build .' 
>> fails at the 82% mark with this output:
>> 
>> ==
>> [ 82%] Building CXX object 
>> ogr/ogrsf_frmts/sqlite/CMakeF

Re: [gdal-dev] building on macOS - fatal error: 'direct.h' file not found

[Nik Sands]

Thanks again for all the replies and advice.  I should have provided more 
context around my initial query about building GDAL with cmake on macOS.  So 
here goes… (this is quite long, so bear with me…)

My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as well 
as for macOS on Intel).  I can then combine them into a fat library and use 
that in my project (which is what I've been doing successfully for GDAL 2.2.2 
for some time).  GDAL 3.6 isn't yet released, so I'm working with 3.5 for now 
in order to get my build process right.

I believe that for iOS, I cannot use any 'homebrew' or 'macports' packages 
installed in /usr/local, etc, as dependencies for the GDAL build.  They will 
likely work for macOS, but not for iOS.  Therefore I will need to build any 
dependencies manually and install to another location (for both iOS and macOS), 
where they do not already exist in the standard macOS/iOS SDK locations (or 
where the Apple-supplied libraries in those SDK locations are otherwise 
incompatible with GDAL - see SQLite notes below).  For any such dependencies, I 
plan to install them in ~/build (as I did previously for GDAL 2.2.2).

So I'm starting out building simply for macOS, but trying to use a similar 
technique to what I hope to use for iOS (after I get it working for macOS).

So with all that background, I will now start at the beginning of my attempts 
to build GDAL 3.5 using a method that I hope will also work for iOS...

The GDAL cmake hints page says to do this:

cd gdal-{VERSION}
mkdir build
cd build
cmake ..
cmake --build .
cmake --build . --target install

When I run this as-is, the 'cmake ..' succeeds, but the 'cmake --build .' fails 
at the 82% mark with this output:

==
[ 82%] Building CXX object 
ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/ogrsqlitedatasource.cpp.o
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/ogr/ogrsf_frmts/sqlite/ogrsqlitedatasource.cpp:733:21:
 error: use of undeclared identifier 'sqlite3_enable_load_extension'
if( sqlite3_enable_load_extension(hDB, 1) == SQLITE_OK )
^
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/ogr/ogrsf_frmts/sqlite/ogrsqlitedatasource.cpp:746:21:
 error: use of undeclared identifier 'sqlite3_load_extension'
if( sqlite3_load_extension(hDB, aosExtensions[i], nullptr, 
) != SQLITE_OK )
^
2 errors generated.
make[2]: *** 
[ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/ogrsqlitedatasource.cpp.o] 
Error 1
make[1]: *** [ogr/ogrsf_frmts/sqlite/CMakeFiles/ogr_SQLite.dir/all] Error 2
make: *** [all] Error 2
==

So I then build SQLite manually, including the requirements that the built-in 
macOS SQLite seems to be missing, and install to ~/build.  Ie,

./configure SQLITE_ENABLE_RTREE=1 --prefix=/Users/{USERNAME}/build

Then I attempt to GDAL again as follows:

cd gdal-{VERSION}
rm -r build
mkdir build
cd build
cmake -DSQLITE3_INCLUDE_DIR=~/build/include 
-DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a ..


Now cmake fails with:

-- Configuring incomplete, errors occurred!
See also "./CMakeOutput.log".
See also "./CMakeError.log".

The error log is fairly long, but two errors near the beginning seem to be 
perhaps quite significant:

ld: library not found for -lSystem

and a bit further on:

ld: library not found for -lc++

and then skipping to the end of the error log:

==
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19:
 error: use of undeclared identifier '_iconv_close'; did you mean 'iconv_close'?
  return ((int*)(&_iconv_close))[argc];
  ^~~~
  iconv_close
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/iconv.h:78:36:
 note: 'iconv_close' declared here
extern __LIBICONV_DLL_EXPORTED int iconv_close (iconv_t _cd);
   ^
1 error generated.
make[1]: *** [CMakeFiles/cmTC_825af.dir/CheckSymbolExists.c.o] Error 1
make: *** [cmTC_825af/fast] Error 2


File 
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef _iconv_close
  return ((int*)(&_iconv_close))[argc];
#else
  (void)argc;
  return 0;
#endif
}
==

Now if I try the following:

export LDFLAGS=-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
export CFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CCFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CXXFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CPPFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
cd gdal-{VERSION}
rm -r build
mkdir build
cd build
cmake -DSQLITE3_INCLUDE_DIR=~/build/include 
-DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a ..

Then the 

[gdal-dev] building on macOS - fatal error: 'direct.h' file not found

[Nik Sands]

Hi GDAL devs,

Since I last built GDAL (2.2.2), cmake has been introduced and it appears as 
though it is going to be the only option going forward.  So I’m attempting to 
use cmake to build GDAL 3.5.0 on macOS 12.4 ('Monterey’).  I’ve installed cmake 
using the ‘homebrew’ macOS package manager.

However, I’m getting numerous build errors, starting with the following error 
when running cmake to build GDAL 3.5.0:

fatal error: 'direct.h' file not found

(a little more context from the error log is included at the end, below)

I’m attempting to build GDAL as follows:

export LDFLAGS=-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
export CFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CCFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CXXFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
export CPPFLAGS="-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
cd gdal-3.5.0
mkdir build
cd build
cmake -DPROJ_ROOT=~/build -DSQLITE3_INCLUDE_DIR=~/build/include 
-DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a .. -DCMAKE_INSTALL_PREFIX=~/build 
-DCMAKE_BUILD_TYPE=Release ..

I’m a hobbyist and not a professional developer, so my understanding of these 
things is quite limited.  However, my research so far indicates that ‘direct.h’ 
is a Windows-specific header file and therefore perhaps cmake has not been 
configured correctly for macOS in this GDAL distribution?

Is it possible to build GDAL using cmake on macOS?  If so, how to I deal with 
this error?

I can supply the entire CMakeError.log file if that would help (as an 
attachement, or copy/pasted as text in an email).

Cheers,
Nik.

Snippet from CMakeError.log:
--

Source file was:
 int main() { return 0; }
Determining if the include file direct.h exists failed with the following 
output:
Change Dir: 
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make -f Makefile cmTC_190db/fast && 
/Applications/Xcode.app/Contents/Developer/usr/bin/make  -f 
CMakeFiles/cmTC_190db.dir/build.make CMakeFiles/cmTC_190db.dir/build
Building C object CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
 -std=gnu99 -MD -MT CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o -MF 
CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o.d -o 
CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o -c 
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/Users/nsands/Documents/Development/3rdParty/GDAL3/gdal-3.5.0/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10:
 fatal error: 'direct.h' file not found
#include 
 ^~
1 error generated.
make[1]: *** [CMakeFiles/cmTC_190db.dir/CheckIncludeFile.c.o] Error 1
make: *** [cmTC_190db/fast] Error 2

--


========
NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot build for iOS due to GUInt64 error

[Nik Sands]

No output at all (no errors, no warnings) for that test.

Cheers,
Nik.

(PS.  Re-sent to include the list address)

-
NIK SANDS
Line Tamer | Time Traveller | Space Cadet

- Original Message -
From:
 "Even Rouault" <even.roua...@spatialys.com>

To:
"Nik Sands" <n...@nixanz.com>
Cc:
<gdal-dev@lists.osgeo.org>
Sent:
Mon, 13 Nov 2017 21:40:32 +0100
Subject:
Re: [gdal-dev] Cannot build for iOS due to GUInt64 error

On mardi 14 novembre 2017 07:30:14 CET Nik Sands wrote: 

> Hi Even, 

>  

> If I include the -Wall option, then I do get just the one warning.
Here’s 

> the command line I’m using, which is based on similar command
lines from 

> the make output… 

>  

>  

> $ /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o
conftest -arch 

> arm64 -pipe -Os -gdwarf-2 -isysroot 

>
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Deve


> loper/SDKs/iPhoneOS11.1.sdk -Wno-implicit-function-declaration 

> -fembed-bitcode -mno-thumb -Wall -arch arm64 -isysroot 

>
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Deve


> loper/SDKs/iPhoneOS11.1.sdk conftest.c -ldl conftest.c:1:24:
warning: unused 

> variable 'off' [-Wunused-variable] int main() { long long off=0; } 

> ^ 

> 1 warning generated. 

> $ 

  

And what does the above return if you do it on the following
conftest.c: 

  

int main() { long long off=0; (void)off; return 0; } 

  

--  

Spatialys - Geospatial professional services 

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot build for iOS due to GUInt64 error

[Nik Sands]

Hi Even,

If I include the -Wall option, then I do get just the one warning.  Here’s the 
command line I’m using, which is based on similar command lines from the make 
output…


$ /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o conftest -arch 
arm64 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.1.sdk
 -Wno-implicit-function-declaration -fembed-bitcode -mno-thumb -Wall  -arch 
arm64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.1.sdk
 conftest.c -ldl
conftest.c:1:24: warning: unused variable 'off' [-Wunused-variable]
int main() { long long off=0; }
   ^
1 warning generated.
$
——

I made the change you suggested to acinclude.m4 and then ran autoconf.  Then I 
attempted to build GDAL again, but got the same error:

--
geotiff.cpp:7653:13: error: unknown type name 'GUInt64'
typedef GUInt64 WordType;
^
1 error generated.
make[2]: *** [../o/geotiff.lo] Error 1
make[1]: *** [gtiff-install-obj] Error 2
make: *** [frmts-target] Error 2
--

I have to admit that I’m a very small-time developer and I’m somewhat out of my 
depth here, so forgive me if I sound like I don’t understand some of this stuff.

Cheers,
Nik.

> On 12 Nov 2017, at 11:22 pm, Even Rouault <even.roua...@spatialys.com> wrote:
> 
> On dimanche 12 novembre 2017 19:50:47 CET Nik Sands wrote:
> > Hi Even,
> > 
> > Thanks for your reply.  You are correct as usual.  Your ‘cc’ test produced
> > no errors, 
>  
> And no warnings as well ?
> Weird, since this is the test that is used to dected long long presence
> See m4/acinclude.m4
>  
> Do you run configure with CCFLAGS defined ? For example, if CCFLAGS="-Wall", 
> then the test will throw a warning that will make it fail.
> I'm not sure why we use CCFLAGS in that file, whereas CFLAGS is used 
> everywhere else.
>  
> What if you change in m4/acinclude.m4
>   echo 'int main() { long long off=0; }' >> conftest.c
> to
>   echo 'int main() { long long off=0; (void)off; return 0; }' > conftest.c
>  
> and run autoconf to regenerate configure ?
>  
> Even
>  
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com <http://www.spatialys.com/>


NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot build for iOS due to GUInt64 error

[Nik Sands]

Hi Even,

Thanks for your reply.  You are correct as usual.  Your ‘cc’ test produced no 
errors, and your mention of ‘HAVE_LONG_LONG’ reminded me that I had have issues 
with that when compiling older versions of GDAL as well.  So I went back to my 
old build script and checked and found that I always used to do the following:

—
curl -O http://download.osgeo.org/gdal/$gdal_ver/gdal-$gdal_ver.tar.gz
tar -xzf gdal-$gdal_ver.tar.gz
sed 's/#undef HAVE_LONG_LONG/\/\* #undef HAVE_LONG_LONG \*\/\'$'\n#define 
HAVE_LONG_LONG 1/' gdal-$gdal_ver/port/cpl_config.h.in > 
gdal-$gdal_ver/port/cpl_config.h.in.NEW
mv gdal-$gdal_ver/port/cpl_config.h.in 
gdal-$gdal_ver/port/cpl_config.h.in.ORIG
mv gdal-$gdal_ver/port/cpl_config.h.in.NEW 
gdal-$gdal_ver/port/cpl_config.h.in
—

I’ve now done this again with GDAL 2.2.2 and this old work around gets it to 
compile OK (the same way the work around always did for older versions - I had 
just forgotten it).

Is there some way this could be changed in the config/source so that it has the 
correct HAVE_LONG_LONG value for iOS/arm64 without requiring this work around?

Cheers,
Nik.


> On 11 Nov 2017, at 11:44 pm, Even Rouault <even.roua...@spatialys.com> wrote:
> 
> On samedi 11 novembre 2017 11:09:48 CET Nik Sands wrote:
> > Hi,
> > 
> > I’m attempting to build GDAL for the first time in a while, and this is the
> > first time for GDAL 2.2.2.  I’ve getting the following error when building
> > for iOS arm64 on Mac OS X:
> > 
> > 
> > geotiff.cpp:7653:13: error: unknown type name 'GUInt64'
> > typedef GUInt64 WordType;
> > ^
> > 1 error generated.
> > make[2]: *** [../o/geotiff.lo] Error 1
> > make[1]: *** [gtiff-install-obj] Error 2
> > make: *** [frmts-target] Error 2
> > 
> > 
> > The relevant part of geotiff.cpp is:
> > 
> > 
> > #if SIZEOF_VOIDP == 8 || defined(__x86_64__)
> > // We test __x86_64__ for x32 arch where SIZEOF_VOIDP == 4
> > typedef GUInt64 WordType;
> > #else
> > typedef unsigned int WordType;
> > #endif
> > 
> > 
> > Should I be adding some exception condition into the ‘if’ part in order to
> > get it to use unsigned int instead of GUInt64?  Or is there some other way
> > that this should be handled for iOS arm64 when building on Mac OS X?
>  
> Nik,
>  
> This is the sign of a serious configuration error. Patching it there will 
> just hide many other problems elsewhere where 64bit integer is needed.
>  
> This likely occurs because HAVE_LONG_LONG is not set for some reason when 
> configure runs.
> If you run configure, I guess the "Checking for 64bit integer type" returns 
> no.
>  
> Can you try the following (replace cc by the appropriate (cross)compiler 
> binary) ?
> echo 'int main() { long long off=0; }' > conftest.c
> cc  -o conftest conftest.c 
>  
> Even
>  
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com <http://www.spatialys.com/>


NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Cannot build for iOS due to GUInt64 error

[Nik Sands]

Hi,

I’m attempting to build GDAL for the first time in a while, and this is the 
first time for GDAL 2.2.2.  I’ve getting the following error when building for 
iOS arm64 on Mac OS X:


geotiff.cpp:7653:13: error: unknown type name 'GUInt64'
typedef GUInt64 WordType;
^
1 error generated.
make[2]: *** [../o/geotiff.lo] Error 1
make[1]: *** [gtiff-install-obj] Error 2
make: *** [frmts-target] Error 2


The relevant part of geotiff.cpp is:


#if SIZEOF_VOIDP == 8 || defined(__x86_64__)
// We test __x86_64__ for x32 arch where SIZEOF_VOIDP == 4
typedef GUInt64 WordType;
#else
typedef unsigned int WordType;
#endif


Should I be adding some exception condition into the ‘if’ part in order to get 
it to use unsigned int instead of GUInt64?  Or is there some other way that 
this should be handled for iOS arm64 when building on Mac OS X?

Cheers,
Nik.


NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Cannot delete layer - table is locked

[Nik Sands]

Hi GDAL devs,

What is the correct way in GDAL/OGR to release locks on the layer (in this case 
the SQLite tables in a geopackage) so that the layer can be deleted from the 
data source?

My issue is that after writing new features to a layer, I may want to delete 
the layer completely, but when I do so using:

OGR_DS_DeleteLayer()

I get errors like:

ERROR 1: sqlite3_exec(DROP TABLE "rtree_Track_2017_09_18_12_14_09_Line_geom") 
failed: database table is locked
ERROR 1: sqlite3_exec(DROP TABLE 'Track_2017_09_18_12_14_09_Line') failed: 
database table is locked

What is the correct way to handle this situation, so that I can add features to 
a layer, but then delete it?

Cheers,
Nik.


========
NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Attempt to delete layer fails - table locked

[Nik Sands]

Hi Dev list,

I’m attempting to delete a layer using OGR_DS_DeleteLayer(), however, it 
results in errors like:

ERROR 1: sqlite3_exec(DROP TABLE "rtree_Track_2017_09_18_12_41_03_Line_geom") 
failed: database table is locked
ERROR 1: sqlite3_exec(DROP TABLE 'Track_2017_09_18_12_41_03_Line') failed: 
database table is locked

I presume that this is because recently new features were added to the layer 
and it is still considered open/locked.

What is the correct way to release locks so that I can then delete the layer?

Cheers,
Nik.

========
NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] OGR_L_SetFeature() randomly crashes with EXC_BAD_ACCESS in sqlite3

[Nik Sands]

Hello dev list,

I’m using GDAL 2.1.2 in an iOS app (statically linked).  When executing 
OGR_L_SetFeature() it usually works fine, but randomly crashes with 
EXC_BAD_ACCESS.

The crash is in sqlite3 and appears to be due to dereferencing a NULL pointer, 
as far as I can tell from the back trace.

In my app, the crash occurs when I call, "OGR_L_SetFeature(layer, feature)”, at 
which point both “layer” and “feature” are non-NULL, and the layer is in a 
GeoPackage data source.

The top of the back trace is:

MyApp`sqlite3_clear_bindings(pStmt=0x) + 24 at sqlite3.c:75797, 
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x0)
frame #0: 0x00010012684c 
MyApp`sqlite3_clear_bindings(pStmt=0x) + 24 at sqlite3.c:75797 
[opt]
frame #1: 0x0001005c0770 
MyApp`OGRGeoPackageTableLayer::ISetFeature(this=0x00010134af10, 
poFeature=0x000174097750) + 440 at ogrgeopackagetablelayer.cpp:1441 [opt]
  * frame #2: 0x0001000b0074 MyApp`-[VectorFeature 
syncToDisk](self=0x00017422cd00, _cmd="syncToDisk") + 92 at 
VectorFeature.m:56

I don’t know enough about the SQLite or GeoPackage code to make any sensible 
progress on this.  Can somebody please point me in the right direction to 
figure out what I’m doing wrong?

Cheers,
Nik.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] EXC_BAD_ACCESS on 1.11 OGROpen() SQLite or GeoPackage

[Nik Sands]

Please ignore this one (below).  Sorry for wasting the list's time on this one. 
 I can now build GDAL 2.x for iOS no trouble, and I do not get the crash with 
GDAL 2.1.2.

(After not being able to get GDAL 2.x to build for iOS last October, I gave up 
on it and went back to 1.11.  I’ve just tried 2.1.2 and it built first time, no 
trouble, just using the same build script that I’d been using for 1.11.  I do 
not know if it is my build script that has changed since October, or if 2.1.2 
fixed something that was causing me problems.  I can’t recall what the issue 
was back then.)


> On 21 Jan 2017, at 11:27 am, Nik Sands <n...@nixanz.com> wrote:
> 
> Hi all,
> 
> Using GDAL 1.11, I’m getting a crash when attempting to OGROpen() with either 
> the SQLite driver or the GeoPackage driver (which uses SQLite).  Stack trace 
> is below.
> 
> My Googling for answers found no results for the specific search criteria I 
> used.  ("gdal exc_bad_access ogropen sqlite3_auto_extension”)
> 
> I get an EXC_BAD_ACCESS at the only line in the OGR2SQLITE_Register() 
> function in ogrsqliteviritualogr.cpp .  Ie at:
> 
> void OGR2SQLITE_Register()
> {
>sqlite3_auto_extension ((void (*)(void)) OGR2SQLITE_static_register);  //  
> EXC_BAD_ACCESS HERE
> }
> 
> Has anybody come across something like this, or has any idea what I’m doing 
> wrong here?  (Stack trace below).
> 
> (I’m stuck with GDAL 1.x until I can figure out how to build 2.x for iOS.)
> 
> Thanks,
> Nik.
> 
> 
> Stack trace (top few only) from debugger console:
> ——
> (lldb) bt
> * thread #1: tid = 0x3117268, 0x000102423403 GIST`OGR2SQLITE_Register() + 
> 19 at ogrsqlitevirtualogr.cpp:2460, queue = 'com.apple.main-thread', stop 
> reason = EXC_BAD_ACCESS (code=1, address=0x600)
>  * frame #0: 0x000102423403 GIST`OGR2SQLITE_Register() + 19 at 
> ogrsqlitevirtualogr.cpp:2460 [opt]
>frame #1: 0x00010240a78c 
> GIST`OGRSQLiteDataSource::OpenOrCreateDB(this=0x60193db0, flags=2) + 
> 28 at ogrsqlitedatasource.cpp:455 [opt]
>frame #2: 0x00010240b498 
> GIST`OGRSQLiteDataSource::Open(this=0x60193db0, 
> pszNewName=, bUpdateIn=1) + 180 at ogrsqlitedatasource.cpp:993 
> [opt]
>frame #3: 0x00010240fd96 
> GIST`OGRSQLiteDriver::Open(this=, 
> pszFilename="/Users/nsands/Library/Developer/CoreSimulator/Devices/6D46D041-C9C3-498B-A918-85036F1A7EB0/data/Containers/Data/Application/18E913B4-E19B-4C62-8910-2ACB4136C361/Documents/Tracks",
>  bUpdate=1) + 262 at ogrsqlitedriver.cpp:165 [opt]
>frame #4: 0x000102401e31 
> GIST`OGRSFDriverRegistrar::Open(pszName="/Users/nsands/Library/Developer/CoreSimulator/Devices/6D46D041-C9C3-498B-A918-85036F1A7EB0/data/Containers/Data/Application/18E913B4-E19B-4C62-8910-2ACB4136C361/Documents/Tracks",
>  bUpdate=, ppoDriver=) + 227 at 
> ogrsfdriverregistrar.cpp:226 [opt]
>frame #5: 0x000102401f80 GIST`::OGROpen(pszName=, 
> bUpdate=, pahDriverList=) + 35 at 
> ogrsfdriverregistrar.cpp:284 [opt]
>frame #6: 0x000101fdf9cd GIST`-[VectorDataSource 
> initWithURL:](self=0x600269c0, _cmd="initWithURL:", 
> url=@"file:///Users/nsands/Library/Developer/CoreSimulator/Devices/6D46D041-C9C3-498B-A918-85036F1A7EB0/data/Containers/Data/Application/18E913B4-E19B-4C62-8910-2ACB4136C361/Documents/Tracks")
>  + 189 at VectorDataSource.m:33
> 
> 
> NIK SANDS
> Line Tamer | Time Traveller | Space Cadet
> 



NIK SANDS
Line Tamer | Time Traveller | Space Cadet

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Shapefile with one feature and many incrementally-added vertices is huge

[Nik Sands]

Thanks Guys,

I appreciate the great responses, and particularly implementing an
update for this edge case.

Unfortunately, I'm stuck with GDAL 1.x for now (have yet to figure out
how to get 2.x to build for iOS, but will take another look some
time).

As for alternatives to Shapefiles, my preference is for
SQLite/Spatialite, but I'm having other problems with that at present
(haven't defined the problems well enough to post a query here yet).

I will take a look at GeoPackage.  I'm not familiar with this format.

Cheers,
Nik.

- Original Message -
From: "Stefan Keller" 
To:"Even Rouault" 
Cc:"gdal-dev@lists.osgeo.org" 
Sent:Thu, 19 Jan 2017 15:31:07 +0100
Subject:Re: [gdal-dev] Shapefile with one feature and many
incrementally-added vertices is huge

 @Even: Great work!

 @Nik: I would avoid using Shapefile in the first place.
 IMHO there are other formats which hare better suited for this use
 case, like e.g. GeoPackage.

 :Stefan

 2017-01-19 14:38 GMT+01:00 Even Rouault :
 >> In that
 >
 >> particular case the writer could realize that we are editing the
last
 >
 >> geometry, so it could safely overwrite in place, but this isn't
 >> implemented
 >
 >> yet.
 >
 >
 >
 > Well, that was rather simple to implement. So fixed per
 >
 > https://trac.osgeo.org/gdal/ticket/6787
 >
 >
 >
 > Even
 >
 >
 >
 > --
 >
 > Spatialys - Geospatial professional services
 >
 > http://www.spatialys.com
 >
 >
 > ___
 > gdal-dev mailing list
 > gdal-dev@lists.osgeo.org
 > https://lists.osgeo.org/mailman/listinfo/gdal-dev
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] 1.11 OGR_F_SetFieldDouble() then OGR_F_GetFieldAsDouble() always returns zero

[Nik Sands]

Hi List.  I'm using GDAL/OGR 1.11 in an Objective-C (iOS)
application.

I'm attempting to store double values in an OFTReal field using
OGR_F_SetFieldDouble() and then to retrieve these values later using
OGR_F_GetFieldAsDouble().  If I retrieve the value immediately, it
works fine.  However, after closing and re-opening the
datasource/layer, I only ever get zero (0.0) values.  I am running
syncToDisk() after writing values.

I'm using the Esri Shapefile driver.

The code used for writing is:
---

i = OGR_F_GetFieldIndex(feature.feature, "Time");

if ( i > -1 ) {

OGR_F_SetFieldDouble(feature.feature, i, [[NSDate date]
timeIntervalSince1970]);

NSLog(@"Wrote %ld Date  %f", OGR_F_GetFID(feature.feature),
OGR_F_GetFieldAsDouble(feature.feature, i));

//  LOGS EXPECTED NON-ZERO VALUE HERE

}

OGR_L_SyncToDisk(_layer);
---

The code used for reading after re-opening the data source is:
---

i = OGR_F_GetFieldIndex(_feature, "Time");

if ( i > -1 ) {

NSLog(@"Got %ld Cell Date:  %f", OGR_F_GetFID(_feature),
OGR_F_GetFieldAsDouble(_feature, i));

//  ALWAYS LOGS 0.0 HERE (logs a valid FID)

}


Am I doing anything obviously wrong?  Any ideas why this is not
working as I expected?

Let me know if there is any more code that would make it more clear.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How get EPSG code from an OGRSpatialReferenceH?

[Nik Sands]

Thanks for the answer.  Not what I wanted to hear but such is life. (And I 
think it makes sense now that you explain it - ie, it's not a neatly reversible 
translation). 

It will complicate my user interface somewhat, but I think I've got an idea of 
how to work around it. 

Thanks,
Nik. 

On 30 Aug 2014, at 3:45 am, Even Rouault even.roua...@spatialys.com wrote:

 On 8/28/2014 8:42 PM, Nik Sands wrote:
 Hi devs,
 
 What is the correct way to extract the EPSG code from an
 OGRSpatialReferenceH ?
 
 Currently I'm finding that the following works only for SRS of some images
 and not others:
const char *charAuthType = OSRGetAttrValue(gdal.srcSRS, AUTHORITY, 0);
const char *charSrsCode = OSRGetAttrValue(gdal.srcSRS, AUTHORITY, 1);
 
 However, there is no AUTHORITY node in some SRSs so it doesn't work for
 those images.  To cater for this, I'm trying to explicitly set the authority 
 node using:
OSRAutoIdentifyEPSG(gdal.srcSRS);
 
 But this fails with OGRERR_UNSUPPORTED_SRS (even when it is an SRS that
 GDAL recognises and uses well).
 
 Yes, this is expected. There are just a few SRS definitions that are encoded 
 in 
 it.
 
 
 So I'm stumped... how do I reliably determine the EPSG for an
 OGRSpatialReferenceH?
 
 There's no real reliable way of doing that. There are approximative methods 
 to 
 get a best match. For example you could iterate on EPSG codes with 
 importFromEPSG() and exportToProj4(), and compare with exportToProj4() on 
 your 
 WKT, but you can easily find situations where several EPSG SRS resolve to the 
 same proj4 string.
 Anyway, there's currently no such ready-made heuristics method in GDAL, 
 although it might be useful to have one ultimately.
 
 
 Cheers,
 Nik.
 
 ___
 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
 
 -- 
 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] How get EPSG code from an OGRSpatialReferenceH?

[Nik Sands]

Hi devs,

What is the correct way to extract the EPSG code from an OGRSpatialReferenceH ?

Currently I'm finding that the following works only for SRS of some images and 
not others:

const char *charAuthType = OSRGetAttrValue(gdal.srcSRS, AUTHORITY, 0);
const char *charSrsCode = OSRGetAttrValue(gdal.srcSRS, AUTHORITY, 1);

However, there is no AUTHORITY node in some SRSs so it doesn't work for those 
images.  To cater for this, I'm trying to explicitly set the authority node 
using:

OSRAutoIdentifyEPSG(gdal.srcSRS);

But this fails with OGRERR_UNSUPPORTED_SRS (even when it is an SRS that GDAL 
recognises and uses well).

So I'm stumped... how do I reliably determine the EPSG for an 
OGRSpatialReferenceH?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] How to get string representation from OGRStyleMgrH

[Nik Sands]

Hi devs,

I've been working with styles using 'OGRStyleMgrH'.  However, I cannot figure 
out how to get a string directly from an OGRStyleMgrH.  I'd like to be able to 
get the string representation of the style in the same format as can be used to 
initialise the OGRStyleMgrH in OGR_SM_InitStyleString().

How can I do this?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to get string representation from OGRStyleMgrH

[Nik Sands]

Is there a C API equivalent?  Or some other way of doing this without C++?

I'm using C rather than C++.


On 10 Aug 2014, at 7:30 pm, Even Rouault even.roua...@spatialys.com wrote:

 Le dimanche 10 août 2014 08:05:48, Nik Sands a écrit :
 Hi devs,
 
 I've been working with styles using 'OGRStyleMgrH'.  However, I cannot
 figure out how to get a string directly from an OGRStyleMgrH.  I'd like to
 be able to get the string representation of the style in the same format
 as can be used to initialise the OGRStyleMgrH in OGR_SM_InitStyleString().
 
 Nik,
 
 OGRStyleMgr::GetStyleString(NULL) should do :
 
 /**
 * \brief Get the style string from the style manager.
 *
 * @param poFeature feature object from which to read the style or NULL to
 *  get the style string stored in the manager.
 *
 * @return the style string stored in the feature or the style string stored
 *  in the style manager if poFeature is NULL
 *
 * NOTE: this method will call OGRStyleMgr::InitFromFeature() if poFeature is
 *   not NULL and replace the style string stored in the style manager
 */
 
 Even
 
 How can I do this?
 
 Cheers,
 Nik.
 
 ___
 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] How to get string representation from OGRStyleMgrH

[Nik Sands]

Thanks Even,

Sounds like I'd have to assemble the new style string manually by joining up to 
four tool style strings using 'OGR_ST_GetStyleString()' (one for each tool that 
is present) with a ; in between each.

That should be OK.

Cheers,
Nik.


On 10 Aug 2014, at 8:57 pm, Even Rouault even.roua...@spatialys.com wrote:

 Le dimanche 10 août 2014 12:36:02, Nik Sands a écrit :
 Is there a C API equivalent?  
 
 No, from what I can see
 
 Or some other way of doing this without C++?
 
 Actually I'm not sure OGRStyleMgr::GetStyleString(NULL) is what you want, at 
 least not directly. It just returns the m_pszStyleString member of OGRStyleMgr
 
 You didn't explain your use case, but if it is :
 1) initialize a style manager with a style string
 2) browse through the tools with GetPart()
 3) modify some tools with the tool API
 4) get the modified style string
 
 then I believe you have to do something cumbersome :
 4b) create a new style manager with an empty style string
 5) use AddPart(OGRStyleTool *) on the new style manager to add the unmodified 
 and modified tools (you need to keep the pointers obtained from 2), not 
 re-call 
 GetPart() on the first style manager)
 6) call GetStyleString() on the second style manager
 
 When you modify the tools with the tool API it edits the string of the tool, 
 but there's no link with the style manager it comes from, so it won't see the 
 change.
 
 The working of the style manager is a bit weird...
 
 
 I'm using C rather than C++.
 
 On 10 Aug 2014, at 7:30 pm, Even Rouault even.roua...@spatialys.com wrote:
 Le dimanche 10 août 2014 08:05:48, Nik Sands a écrit :
 Hi devs,
 
 I've been working with styles using 'OGRStyleMgrH'.  However, I cannot
 figure out how to get a string directly from an OGRStyleMgrH.  I'd like
 to be able to get the string representation of the style in the same
 format as can be used to initialise the OGRStyleMgrH in
 OGR_SM_InitStyleString().
 
 Nik,
 
 OGRStyleMgr::GetStyleString(NULL) should do :
 
 /**
 * \brief Get the style string from the style manager.
 *
 * @param poFeature feature object from which to read the style or NULL to
 *  get the style string stored in the manager.
 *
 * @return the style string stored in the feature or the style string
 stored *  in the style manager if poFeature is NULL
 *
 * NOTE: this method will call OGRStyleMgr::InitFromFeature() if poFeature
 is *   not NULL and replace the style string stored in the style
 manager */
 
 Even
 
 How can I do this?
 
 Cheers,
 Nik.
 
 ___
 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] Feature style page

[Nik Sands]

There might also be some issues in the sample code, including lines such as:

for (i=0;iGetPartCount();i++)

and:

poStyleTool = GetPart(i);

(or otherwise it's possible I'm completely misunderstanding some of the code)


On 3 Aug 2014, at 7:22 pm, Martin Landa landa.mar...@gmail.com wrote:

 Hi,
 
 2014-08-03 11:19 GMT+02:00 Even Rouault even.roua...@mines-paris.org:
 
 Good catch. Actually the images were only on the www.gdal.org site and not in
 SVN ! Luckily I had made a backup of the old doc before RFC 46 in
 http://www.gdal.org/1.11, so I could fetch them back from there. During the
 next refresh from SVN they should be reinstalled. In the meantime you can see
 them from http://www.gdal.org/1.11/ogr/ogr_feature_style.html
 
 cool, thanks a lot for super-quick fix! Martin
 
 -- 
 Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
 ___
 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] Usage of styles in C API

[Nik Sands]

I'm just starting out using the styles features of OGR (using the C API) but at 
struggling with a few elements of it.

My code (copied below) fails to get any OGRStyleToolH.  Ie, the if ( tool ) 
block never gets run, because 'tool' is always NULL at the point indicated by 
the comment.  But the execution does reach that point in the code which 
indicates that the OGRStyleMrgH does in fact include at least one part (tool).

I'd be grateful if somebody could point out what I'm doing wrong.

Thanks,
Nik.


---
const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
NSString *styleName = [NSString 
stringWithUTF8String:OGR_STBL_GetLastStyleName(table)];
OGRStyleMgrH styleMgr = OGR_SM_Create(NULL);
OGR_SM_InitStyleString(styleMgr, styleChars);


for ( int i = 0; i  OGR_SM_GetPartCount(styleMgr, NULL); i++ )
{
OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);

if ( tool )  //  'tool' always NULL here
{
switch ( OGR_ST_GetType(tool) )
{
case OGRSTCPen:
self.pen = tool;
break;

case OGRSTCBrush:
self.brush = tool;
break;

case OGRSTCSymbol:
self.symbol = tool;
break;

case OGRSTCLabel:
self.label = tool;
break;

default:
NSLog(@Unknown style tool type!);
break;
}
}
}
---


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Usage of styles in C API

[Nik Sands]

On one of the iterations through this code, styleChars is:

'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'

So perhaps the inclusion of the style name is the problem?

This was read into a style table from a text file using 
'OGR_STBL_LoadStyleTable()'.  I had assumed that a similar format to .ofs was 
suitable.  If this is not the case, how should I read a style table from a text 
file in such a way that I can distinguish the various styles by name?

In guess my more general question is:  What is the correct way to read styles 
from an arbitrary text file into a style table, and then use a style manager to 
get the various parts/tools?



On 3 Aug 2014, at 8:26 pm, Even Rouault even.roua...@mines-paris.org wrote:

 Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
 I'm just starting out using the styles features of OGR (using the C API)
 but at struggling with a few elements of it.
 
 My code (copied below) fails to get any OGRStyleToolH.  Ie, the if ( tool
 ) block never gets run, because 'tool' is always NULL at the point
 indicated by the comment.  But the execution does reach that point in the
 code which indicates that the OGRStyleMrgH does in fact include at least
 one part (tool).
 
 I'd be grateful if somebody could point out what I'm doing wrong.
 
 Nothing strikes me as wrong. A potential explanation is that styleChars 
 doesn't contain a valid OGR Feature Style string.
 GetPartCount() counts the number of ; separating style parts, but it 
 doens't 
 check that each style part actually begins by a recognized tool name (PEN, 
 BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check however and if it 
 cannot recognize it it returns a NULL tool.
 
 
 Thanks,
 Nik.
 
 
 ---
  const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
  NSString *styleName = [NSString
 stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
 styleMgr = OGR_SM_Create(NULL);
  OGR_SM_InitStyleString(styleMgr, styleChars);
 
 
  for ( int i = 0; i  OGR_SM_GetPartCount(styleMgr, NULL); i++ )
  {
  OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
 
  if ( tool )  //  'tool' always NULL here
  {
  switch ( OGR_ST_GetType(tool) )
  {
  case OGRSTCPen:
  self.pen = tool;
  break;
 
  case OGRSTCBrush:
  self.brush = tool;
  break;
 
  case OGRSTCSymbol:
  self.symbol = tool;
  break;
 
  case OGRSTCLabel:
  self.label = tool;
  break;
 
  default:
  NSLog(@Unknown style tool type!);
  break;
  }
  }
  }
 ---
 
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Usage of styles in C API

[Nik Sands]

Sorry, my mistake... I had my logging in the wrong place.  styleChars is 
actually of the form (including the leading space):

' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'


On 3 Aug 2014, at 8:35 pm, Nik Sands nix...@nixanz.com wrote:

 On one of the iterations through this code, styleChars is:
 
   'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
 
 So perhaps the inclusion of the style name is the problem?
 
 This was read into a style table from a text file using 
 'OGR_STBL_LoadStyleTable()'.  I had assumed that a similar format to .ofs was 
 suitable.  If this is not the case, how should I read a style table from a 
 text file in such a way that I can distinguish the various styles by name?
 
 In guess my more general question is:  What is the correct way to read styles 
 from an arbitrary text file into a style table, and then use a style manager 
 to get the various parts/tools?
 
 
 
 On 3 Aug 2014, at 8:26 pm, Even Rouault even.roua...@mines-paris.org wrote:
 
 Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
 I'm just starting out using the styles features of OGR (using the C API)
 but at struggling with a few elements of it.
 
 My code (copied below) fails to get any OGRStyleToolH.  Ie, the if ( tool
 ) block never gets run, because 'tool' is always NULL at the point
 indicated by the comment.  But the execution does reach that point in the
 code which indicates that the OGRStyleMrgH does in fact include at least
 one part (tool).
 
 I'd be grateful if somebody could point out what I'm doing wrong.
 
 Nothing strikes me as wrong. A potential explanation is that styleChars 
 doesn't contain a valid OGR Feature Style string.
 GetPartCount() counts the number of ; separating style parts, but it 
 doens't 
 check that each style part actually begins by a recognized tool name (PEN, 
 BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check however and if it 
 cannot recognize it it returns a NULL tool.
 
 
 Thanks,
 Nik.
 
 
 ---
 const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
 NSString *styleName = [NSString
 stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
 styleMgr = OGR_SM_Create(NULL);
 OGR_SM_InitStyleString(styleMgr, styleChars);
 
 
 for ( int i = 0; i  OGR_SM_GetPartCount(styleMgr, NULL); i++ )
 {
 OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
 
 if ( tool )  //  'tool' always NULL here
 {
 switch ( OGR_ST_GetType(tool) )
 {
 case OGRSTCPen:
 self.pen = tool;
 break;
 
 case OGRSTCBrush:
 self.brush = tool;
 break;
 
 case OGRSTCSymbol:
 self.symbol = tool;
 break;
 
 case OGRSTCLabel:
 self.label = tool;
 break;
 
 default:
 NSLog(@Unknown style tool type!);
 break;
 }
 }
 }
 ---
 
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html
 
 ___
 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] Usage of styles in C API

[Nik Sands]

Thanks Even,

Yes, deleting the spaces seems to get it working correctly.  Is this expected?  
Are spaces an illegal part of a style string?

The documentation includes spaces in the example .ofs file there, so I had 
copied that format when creating my text file.

Cheers,
Nik.


On 3 Aug 2014, at 8:45 pm, Even Rouault even.roua...@mines-paris.org wrote:

 Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
 Sorry, my mistake... I had my logging in the wrong place.  styleChars is
 actually of the form (including the leading space):
 
  ' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
 
 The issue must be the leading space before PEN, and potentially LABEL too.
 
 
 On 3 Aug 2014, at 8:35 pm, Nik Sands nix...@nixanz.com wrote:
 On one of the iterations through this code, styleChars is:
 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
 
 So perhaps the inclusion of the style name is the problem?
 
 This was read into a style table from a text file using
 'OGR_STBL_LoadStyleTable()'.  I had assumed that a similar format to
 .ofs was suitable.  If this is not the case, how should I read a style
 table from a text file in such a way that I can distinguish the various
 styles by name?
 
 In guess my more general question is:  What is the correct way to read
 styles from an arbitrary text file into a style table, and then use a
 style manager to get the various parts/tools?
 
 On 3 Aug 2014, at 8:26 pm, Even Rouault even.roua...@mines-paris.org 
 wrote:
 Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
 I'm just starting out using the styles features of OGR (using the C
 API) but at struggling with a few elements of it.
 
 My code (copied below) fails to get any OGRStyleToolH.  Ie, the if (
 tool ) block never gets run, because 'tool' is always NULL at the
 point indicated by the comment.  But the execution does reach that
 point in the code which indicates that the OGRStyleMrgH does in fact
 include at least one part (tool).
 
 I'd be grateful if somebody could point out what I'm doing wrong.
 
 Nothing strikes me as wrong. A potential explanation is that styleChars
 doesn't contain a valid OGR Feature Style string.
 GetPartCount() counts the number of ; separating style parts, but it
 doens't check that each style part actually begins by a recognized tool
 name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check
 however and if it cannot recognize it it returns a NULL tool.
 
 Thanks,
 Nik.
 
 
 ---
 
   const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
   NSString *styleName = [NSString
 
 stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
 styleMgr = OGR_SM_Create(NULL);
 
   OGR_SM_InitStyleString(styleMgr, styleChars);
   
   
   for ( int i = 0; i  OGR_SM_GetPartCount(styleMgr, NULL); i++ )
   {
   
   OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
   
   if ( tool )  //  'tool' always NULL here
   {
   
   switch ( OGR_ST_GetType(tool) )
   {
   
   case OGRSTCPen:
   self.pen = tool;
   break;
   
   case OGRSTCBrush:
   self.brush = tool;
   break;
   
   case OGRSTCSymbol:
   self.symbol = tool;
   break;
   
   case OGRSTCLabel:
   self.label = tool;
   break;
   
   default:
   NSLog(@Unknown style tool type!);
   break;
   
   }
   
   }
   
   }
 
 ---
 
 
 ___
 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
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Style Tool in C API

[Nik Sands]

Hi guys,

I found that there seems to be no explicit C API for the non-generic style tool 
classes such as 'OGRStylePen'.  Now I've just found the documentation at 
https://trac.osgeo.org/gdal/wiki/rfc18_ogr_styles_c_api which states that this 
is deliberate and that they are unecessary, stating:

• NO wrappers will be needed for the following C++ classes which are 
handled internally by the OGR_ST_* wrappers above:
class OGRStylePen : public OGRStyleTool
class OGRStyleBrush : public OGRStyleTool
class OGRStyleSymbol : public OGRStyleTool
class OGRStyleLabel : public OGRStyleTool

So I'm wondering what is the correct way, in the C API, to do the equivalent of 
the 'Color' method on the C++ class 'OGRStylePen'?  Eg, is there some way of 
matching up a parameter number in a 'OGRStyleToolH' with a parameter type (such 
as color)?  Eg, are the different parameter types all guaranteed to be at a 
specific parameter number?  Otherwise how do I know which parameter (by number) 
is which without fully parsing the style string myself?  If this guess is 
correct, is there a documented index telling me which paramters have which 
parameter index numbers.

Or if I'm completely off the mark, can somebody please set me straight with the 
correct usage to get a color from a OGRStyleToolH in the C API?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Style Tool in C API

[Nik Sands]

grrr... I've found the answer to my own question.  Please ignore my query 
below.  For some reason my searching through the doco before I sent the email 
didn't find what I wanted, but after sending the email, I found it:

typedef enum ogr_style_tool_param_pen_id
{  
OGRSTPenColor   = 0,   
OGRSTPenWidth   = 1,   
OGRSTPenPattern = 2,
OGRSTPenId  = 3,
OGRSTPenPerOffset   = 4,
OGRSTPenCap = 5,
OGRSTPenJoin= 6,
OGRSTPenPriority= 7,
OGRSTPenLast= 8
  
} OGRSTPenParam;

(and other similar enums).

Cheers,
Nik.


On 1 Aug 2014, at 2:20 pm, Nik Sands nix...@nixanz.com wrote:

 Hi guys,
 
 I found that there seems to be no explicit C API for the non-generic style 
 tool classes such as 'OGRStylePen'.  Now I've just found the documentation at 
 https://trac.osgeo.org/gdal/wiki/rfc18_ogr_styles_c_api which states that 
 this is deliberate and that they are unecessary, stating:
 
   • NO wrappers will be needed for the following C++ classes which are 
 handled internally by the OGR_ST_* wrappers above:
class OGRStylePen : public OGRStyleTool
class OGRStyleBrush : public OGRStyleTool
class OGRStyleSymbol : public OGRStyleTool
class OGRStyleLabel : public OGRStyleTool
 
 So I'm wondering what is the correct way, in the C API, to do the equivalent 
 of the 'Color' method on the C++ class 'OGRStylePen'?  Eg, is there some way 
 of matching up a parameter number in a 'OGRStyleToolH' with a parameter type 
 (such as color)?  Eg, are the different parameter types all guaranteed to be 
 at a specific parameter number?  Otherwise how do I know which parameter (by 
 number) is which without fully parsing the style string myself?  If this 
 guess is correct, is there a documented index telling me which paramters have 
 which parameter index numbers.
 
 Or if I'm completely off the mark, can somebody please set me straight with 
 the correct usage to get a color from a OGRStyleToolH in the C API?
 
 Cheers,
 Nik.
 
 ___
 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] styles .ofs and OGR_STBL_GetNextStyle()

[Nik Sands]

Hi Devs,

I'm just planning to convert my own 'in-house' drawing styles management to 
using the styles management built into OGR.  The documentation at 
http://www.gdal.org/ogr_feature_style.html suggests that styles can be in a 
'.ofs' file to be automatically associated with a data source of the same name 
as the .ofs file.

But how about if the .ofs file is a stand-alone file passed directly to 
OGR_STBL_LoadStyleTable()?  Eg, OGR_STBL_LoadStyleTable(table, 
/path/to/styles.ofs)

In this case the first two calls to 'OGR_STBL_GetNextStyle(table)' will return 
the 'styles':

OFS-Version :  1.0
2014-07-30 14:38:36.392 Maps n Trax[47458:60b] StyleField :  style

Which are of course not styles at all, but part of the .ofs specification.

From this, I assume that files passed into OGR_STBL_LoadStyleTable() should in 
fact NOT be .ofs files, but merely plain text files with raw style strings 
only (and no .ofs specifications).

Is this correct?

Would there be any advantage on getting OGR_STBL_LoadStyleTable() to ignore the 
first line or two if it is an .ofs file and those two lines match the spec?

Cheers,
Nik.


OFS-Version: 1.0
StyleField: style

DefaultStyle: SYMBOL(c:#00,id:ogr-sym-3,s:5pt); PEN(c:#00,w:2pt); 
BRUSH(fc:#80808080); LABEL(c:#00,s:14pt,t:{title})

locality: LABEL(c:#00,s:24pt,t:{title})
town: SYMBOL(c:#80,id:ogr-sym-3,s:10pt); LABEL(c:#80,s:24pt,t:{title})
city: SYMBOL(c:#80,id:ogr-sym-3,s:15pt); LABEL(c:#80,s:24pt,t:{title})
region: PEN(c:#00,w:2pt); BRUSH(fc:#80808080); 
LABEL(c:#00,s:28pt,t:{title})
country: PEN(c:#00,w:2pt); BRUSH(fc:#80808080); 
LABEL(c:#00,s:32pt,t:{title})

vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})
vegetation_medium: BRUSH(fc:#80C080); LABEL(c:#004000,s:18pt,t:{title})
vegetation_high: BRUSH(fc:#008000); LABEL(c:#004000,s:18pt,t:{title})
water: SYMBOL(c:#80,id:ogr-sym-3,s:2pt); PEN(c:#80,w:2pt,p:18pt 
8pt); BRUSH(fc:#8080C0); LABEL(c:#80,s:18pt,t:{title})
contour: PEN(c:#808080,w:1pt); LABEL(c:#808080,s:12pt,t:{elevation})

road_unsealed: PEN(c:#A08080,w:2pt,p:10pt 6pt); 
LABEL(c:#00,s:18pt,t:{title})
road_minor: PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})
road_medium: PEN(c:#A0,w:4pt); LABEL(c:#00,s:18pt,t:{title})
road_major: PEN(c:#A0,w:6pt); LABEL(c:#00,s:18pt,t:{title})

route: PEN(c:#00,w:2pt,p:2pt 4pt); LABEL(c:#00,s:18pt,t:{title})
track: PEN(c:#00,w:2pt,p:10pt 6pt); LABEL(c:#00,s:18pt,t:{title})
rail: PEN(c:#00,w:4pt,p:2pt 5pt); LABEL(c:#00,s:18pt,t:{title})
cable: PEN(c:#00,w:2pt,p:1pt 6pt); LABEL(c:#00,s:18pt,t:{title})
ferry: PEN(c:#80,w:2pt,p:18pt 8pt); LABEL(c:#80,s:18pt,t:{title})

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Rename and Reorder Layers?

[Nik Sands]

Hi all,

I have two simple questions (not sure if the answers are as simple)...

1.  Is it possible to rename an OGR layer in place within a writeable data 
store without first creating a copy of the entire layer?

The only way I've found to do this is to use OGR_DS_CopyLayer() (or similar) 
and then delete the old layer which is fairly expensive as it has to copy all 
of the features as well.

2.  Is it possible to change the order of layers within a writeable OGR data 
store?  (Ie, change the ordering/indexing of layers as they would be retrieved 
with OGR_DS_GetLayer() ).

If these can be done, then I've missed it in the doco.  Could somebody please 
explain how to do this or otherwise what the best alternative would be?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Rename and Reorder Layers?

[Nik Sands]

Thanks Even.

I'm mostly working with the SQLite/Spatialite driver so the the SQL query may 
be a good work around for my first issue.  Thanks for this suggestion.

The second issue sounds more challenging, and I'll have to investigate the VRT 
file idea, or possibly come up with my own metadata mechanism for managing this.

Cheers,
Nik.


On 17 Jul 2014, at 9:29 pm, Even Rouault even.roua...@mines-paris.org wrote:

 Nik,
 
 I have two simple questions (not sure if the answers are as simple)...
 
 1.  Is it possible to rename an OGR layer in place within a writeable data
 store without first creating a copy of the entire layer?
 
 There's no provision in the OGR API to do that currently. Although it could be
 nice to have. That would require of course updating the drivers that would
 support that capability, and which are coded currently under the assumption 
 that
 the layer name is immutable.
 For which driver(s) would you be interested to have that capability ?
 
 
 The only way I've found to do this is to use OGR_DS_CopyLayer() (or similar)
 and then delete the old layer which is fairly expensive as it has to copy all
 of the features as well.
 
 For drivers that are related to SQL databases, issuing an ALTER TABLE foo
 RENAME TO bar with ExecuteSQL(), and re-opening the datasource afterwards 
 (OGR
 will not notice the change) should do it.
 
 
 2.  Is it possible to change the order of layers within a writeable OGR data
 store?  (Ie, change the ordering/indexing of layers as they would be
 retrieved with OGR_DS_GetLayer() ).
 
 That would be much more involved, not to say impossible. For example, for SQL
 based drivers, the driver list is issued from a request in system tables or
 other tables and there's nothing to control the order of retrieval.
 For filebased drivers, such as a directory of shapefiles, it depends on the
 order of the operating system in which it return the filenames. Nothing you 
 can
 have control on.
 To make it possible reliably would probably involve adding a special OGR
 metadata table with (order_number, layer_name) columns.
 A potential workaround is to use a OGR VRT file as a thin wrapper above your
 real datasource. The layers will be ordered in the order they are listed in
 the VRT.
 
 Best regards,
 
 Even
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html
 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Can't compile 1.11.0 for iOS with 'expected statement' error for gdalgrid.cpp

[Nik Sands]

Hi all,

I'm attempting to upgrade my iOS app from GDAL 1.10.1 to 1.11.0 in order to 
take advantage of the new OpenFileGDB driver.  However, I've been unable to get 
it to compile for iOS so far with the error output below (note that in this 
instance it is attempting to compile for i386 for the iOS simulator.)

I've had a look at code it's complaining about (line 1806 in 'gdalgrid.cpp') 
and I can't figure out what the problem is.  The brackets appear to be OK and 
I'm not sure why it doesn't like the closing bracket there.

Can anybody help me figure this one out?

Cheers,
Nik.


libtool: compile:  /Applications/Xcode.app/Contents/Developer/usr/bin/g++ -arch 
i386 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk
 -Wno-implicit-function-declaration -D__IPHONE_OS_VERSION_MIN_REQUIRED=7 
-Wall -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/port 
-I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/gcore 
-I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/alg 
-I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/ogr 
-I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/ogr/ogrsf_frmts 
-DHAVE_AVX_AT_COMPILE_TIME -DOGR_ENABLED 
-I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/port -c gdalgrid.cpp 
-o gdalgrid.o
gdalgrid.cpp:1806:17: error: expected statement
}
^
1 error generated.
make[1]: *** [gdalgrid.lo] Error 1
make: *** [core-target] Error 2
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't compile 1.11.0 for iOS with 'expected statement' error for gdalgrid.cpp

[Nik Sands]

PS.  (This always happens just AFTER I send to the list, no matter how long I 
mull it over first...)

Actually, I think I see the issue now.  The closing bracket is the end of an 
if () stanza in which there is no content at all if neither 
'HAVE_AVX_AT_COMPILE_TIME' or 'HAVE_SSE_AT_COMPILE_TIME' are defined, which 
must be the case in my situation.

I guess I could either delete the entire stanza, or add in a statement that 
does nothing useful.

Anyhow, I thought you guys should know this situation exists so that you may be 
able to deal with it yourselves for some future release.  :-)

Cheers,
Nik.


On 10 Jul 2014, at 10:03 am, Nik Sands nix...@nixanz.com wrote:

 Hi all,
 
 I'm attempting to upgrade my iOS app from GDAL 1.10.1 to 1.11.0 in order to 
 take advantage of the new OpenFileGDB driver.  However, I've been unable to 
 get it to compile for iOS so far with the error output below (note that in 
 this instance it is attempting to compile for i386 for the iOS simulator.)
 
 I've had a look at code it's complaining about (line 1806 in 'gdalgrid.cpp') 
 and I can't figure out what the problem is.  The brackets appear to be OK and 
 I'm not sure why it doesn't like the closing bracket there.
 
 Can anybody help me figure this one out?
 
 Cheers,
 Nik.
 
 
 libtool: compile:  /Applications/Xcode.app/Contents/Developer/usr/bin/g++ 
 -arch i386 -pipe -Os -gdwarf-2 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk
  -Wno-implicit-function-declaration -D__IPHONE_OS_VERSION_MIN_REQUIRED=7 
 -Wall -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/port 
 -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/gcore 
 -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/alg 
 -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/ogr 
 -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/ogr/ogrsf_frmts 
 -DHAVE_AVX_AT_COMPILE_TIME -DOGR_ENABLED 
 -I/Users/nsands/Documents/Nik/Development/GDAL/gdal-1.11.0/port -c 
 gdalgrid.cpp -o gdalgrid.o
 gdalgrid.cpp:1806:17: error: expected statement
}
^
 1 error generated.
 make[1]: *** [gdalgrid.lo] Error 1
 make: *** [core-target] Error 2
 ___
 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] Unable to get features from OpenFileGDB data source

[Nik Sands]

Hi GDAL devs,

I'm trying to support ESRI File Geodatabase support (read-only) in my iOS app 
and have recently got GDAL 1.11.0 compiled and running in the app for its new 
OpenFileGDB driver.  However, I've been unable to extract features from GDBs 
using the exact same code that works fine for other formats/drivers.

An extract of the code in question is:


ds = OGROpen(path, FALSE, NULL);
layerCount = OGR_DS_GetLayerCount(ds);

for ( int i = 0; i  layerCount; i++ )
{
OGRLayerH sourceLayer = OGR_DS_GetLayer(ds, i);
int sourceFeatureCount = OGR_L_GetFeatureCount(sourceLayer, 
YES);

for ( long j = 0; j  sourceFeatureCount; j++ )
{
OGRFeatureH sourceFeature = 
OGR_L_GetFeature(sourceLayer, j);

if ( ! sourceFeature )
NSLog(@Failed to get feature at index '%ld' 
from layer at index '%d'!, j, i);


The NSLog line is always run for my GDB data sources but never for data sources 
of other formats.  So for GDB data sources 'sourceFeature' is always NULL and 
of course this causes all subsequent OGR functions to which 'sourceFeature' is 
passed to fail with errors like:

ERROR 10: Pointer 'hFeat' is NULL in 'OGR_...'.

Using the CLI utility 'ogrinfo' (different build of GDAL) on the same 
datasource works fine showing all the features are there as expected and it 
works fine in ESRI ArcGIS.  And the fact that it gets into the second 'for' 
loop at all indicates that there are features there, and yet it cannot get the 
feature at index '0'.

The File Geodatabase datasource can be downloaded for testing from:

https://dl.dropboxusercontent.com/u/12436846/Bandicoots.gdb.zip

Can anybody advise me on how I should trouble shoot this further, or how the 
problem can be resolved?

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

You are correct - I did misunderstand.  Thanks for further explaining the 
multiple geometries to me.  :-)

So it looks like the best option for me is to make a copy of each source layer 
which may contain both single and multi variants (eg, point and multipoint 
features) and make the new SQLite layer use the multi variant (eg, multipoint) 
and perhaps I will need to convert every single variant feature (eg, point) to 
the multi variant (eg, multipoint).

I've written some code to try to do this but its rather long and clumsy (and 
doesn't actually work as yet).  I can't help but think there's got to be a 
better way and that I'm doing it all wrong.  Is there any precedent or 
preferred way that this should be done?

I think that perhaps my understanding of the API is a bit lacking in this area.


On 4 Mar 2014, at 8:31 pm, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote:

 Nik Sands nixanz at nixanz.com writes:
 
 
 Thanks Chaitanya,
 It's finally dawned on me that this is what the following is about in the
 OGR SQLite format web page:
 
 
 Tables with multiple geometries
 Starting with OGR 1.10, tables that have multiple geometry columns
 registered in geometry_columns can be used by OGR. For such tables, there
 are as many OGR layers exposed as there are geometry columns. They are named
 table_name(geometry_column_name).Note: this support is limited to
 read-only operations.
 
 Ah... so multiple geometries are NOT avaiable in this format for writable.
 
 Your idea of forcing all geometries to multies is a good idea.  I'll have
 to figure out the most efficient way to do this when converting an entire
 layer at a time, but it's likely to be much better than the way I'm
 currently doing it and would result in the same number of layers as the
 original, which is preferable, especially when the user wants to manage
 drawing styles for layers.
 
 Thanks for your idea.  I'm very grateful.
 
 Hi,
 
 You perhaps understood wrong what was said about multiple geometries.
 Multipolygon is a single geometry. Multiple geometry columns means a
 situation when one feature has many geometries, for example a polygon
 geometry, simplified polygon geometry and point geometry presenting the
 centroid of the polygon. All in one row in a same table but in three
 geometry columns.
 
 I think also that a standard solution in to create multilinesting and
 multipolygon tables into Spatialite and write also simple geometries as
 multivariants. Principally same for multipoints, but at least in data I
 usually use such do not exist. But you know your data and can decide. It is
 also possible to create a Spatialite table with a generic GEOMETRY
 geometry type. Such table accepts all kind of geometries but it may me
 tricky to use data in applications.
 
 -Jukka Rahkonen-
 
 
 Cheers,
 Nik.
 
 
 
 ___
 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] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

Thanks for this information.

I'd like to replicate that ogr2ogr PROMOTE_TO_MULTI functionality in my code, 
but I'm having trouble figuring out how to do it.  I guess I can take a look at 
the ogr2ogr code.

(I could also just include the entire ogr2ogr tool bundled into my app and call 
it from the app, but that seems a bit of overkill for an iOS app, which is best 
as lean as possible.)


On 4 Mar 2014, at 9:50 pm, a.furi...@lqt.it wrote:

 Hi all,
 
 just yo better clarify some relevant details:
 
 a Shapefile can legitimately contain one the following shapes:
 Point, PolyLine, Polygon and MultiPoint; and there are further
 shape-codes intended to support extended XYZ or XYM dimensions,
 such as PointZ and PolyLineM
 
 please note: accordingly to the SHP model there is a very strong
 distinction between Point and MultiPoint; but a PolyLine can
 indifferently contain just a single line or a collection of
 many individual lines, and the same is for Polygons.
 
 on the opposite side, the standard OGC-SFS data model supports
 the following geometry classes:
 Point, Linestring, Polygon, MultiPoint, MultiLinestring,
 MultiPolygon and GeometryCollection; in this case too we have
 further classes supporting extending XYZ, XYM and XYZM
 dimensions, such as PointZ, LinestringM or PolygonZM.
 
 please note: the OGC-SFS model introduces a very sharp distinction
 between e.g. Linestring and MultiLinestring; a Linestring can
 contain just a single line, a MultiLinestring can contain any
 arbitrary number of individual lines ... THIS INCLUDING JUST ONE !!!
 and the same is for Point/MultiPoint and Polygon/MultiPolygon.
 
 quick conclusion: SHP geometry types doesn't exactly match
 OFC-SFS types, and there is enough room to introduce some
 dangerous inconsistency, e.g.:
 
 - the SHP PolyLine type could possibly match the Linestring type
  if (and only if) all PolyLines into the SHP will contain just
  a single line.
 - when some SHP PolyLine does actually contain more individual
  lines a MultiLinestring will always be required on the OGC-SFS
  side
 - anyway OGC-SFS MultiLinestring will always exactly match the
  SHP PolyLine type, even in the case of mixed Polylines
  sometimes being elementary and sometimes being complex.
 - the same considerations obviously apply to Polygon/MultiPolygon
 - conclusion: always assuming a Multi?? type is the safest approach,
  if you aren't absolutely sure about the actual SHP payload.
 
 ogr2ogr does actually has an argument nicely supporting
 all this (just pasted from the ogr2ogr man page):
 
 -nlt type:
Define the geometry type for the created layer.
One of NONE, GEOMETRY, POINT, LINESTRING, POLYGON,
GEOMETRYCOLLECTION, MULTIPOINT, MULTIPOLYGON or
MULTILINESTRING. Add 25D to the name to get 2.5D
versions. Starting with GDAL 1.10, PROMOTE_TO_MULTI
can be used to automatically promote layers that mix
polygon or multipolygons to multipolygons, and layers
that mix linestrings or multilinestrings to multilinestrings.
Can be usefull when converting shapefiles to PostGIS
(and other target drivers) that implements strict checks
for geometry type.
 
 it works for PostGIS, and it works for SpatiaLite as well.
 
 bye Sandro
 
 ___
 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] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

Thanks to everybody who helped me towards getting this working - it is now 
working correctly.  The conversion process is a little slow for large data 
sets, but the results are excellent, and the Spatialite databases are MUCH 
faster for spatial filtered lookups than the Shapefiles I had been using before.

In the end it turns out that I had my code very nearly correct before looking 
at the code in ogr2ogr from which I then corrected my previous cludgy 
force-to-multi code to the following:

OGR_F_SetGeometryDirectly(feature, 
OGR_G_ForceToMultiPoint(OGR_F_StealGeometry(feature)));

(and other variants depending on the geometry type, of course).


On 4 Mar 2014, at 9:58 pm, Nik Sands nix...@nixanz.com wrote:

 Thanks for this information.
 
 I'd like to replicate that ogr2ogr PROMOTE_TO_MULTI functionality in my code, 
 but I'm having trouble figuring out how to do it.  I guess I can take a look 
 at the ogr2ogr code.
 
 (I could also just include the entire ogr2ogr tool bundled into my app and 
 call it from the app, but that seems a bit of overkill for an iOS app, which 
 is best as lean as possible.)
 
 
 On 4 Mar 2014, at 9:50 pm, a.furi...@lqt.it wrote:
 
 Hi all,
 
 just yo better clarify some relevant details:
 
 a Shapefile can legitimately contain one the following shapes:
 Point, PolyLine, Polygon and MultiPoint; and there are further
 shape-codes intended to support extended XYZ or XYM dimensions,
 such as PointZ and PolyLineM
 
 please note: accordingly to the SHP model there is a very strong
 distinction between Point and MultiPoint; but a PolyLine can
 indifferently contain just a single line or a collection of
 many individual lines, and the same is for Polygons.
 
 on the opposite side, the standard OGC-SFS data model supports
 the following geometry classes:
 Point, Linestring, Polygon, MultiPoint, MultiLinestring,
 MultiPolygon and GeometryCollection; in this case too we have
 further classes supporting extending XYZ, XYM and XYZM
 dimensions, such as PointZ, LinestringM or PolygonZM.
 
 please note: the OGC-SFS model introduces a very sharp distinction
 between e.g. Linestring and MultiLinestring; a Linestring can
 contain just a single line, a MultiLinestring can contain any
 arbitrary number of individual lines ... THIS INCLUDING JUST ONE !!!
 and the same is for Point/MultiPoint and Polygon/MultiPolygon.
 
 quick conclusion: SHP geometry types doesn't exactly match
 OFC-SFS types, and there is enough room to introduce some
 dangerous inconsistency, e.g.:
 
 - the SHP PolyLine type could possibly match the Linestring type
 if (and only if) all PolyLines into the SHP will contain just
 a single line.
 - when some SHP PolyLine does actually contain more individual
 lines a MultiLinestring will always be required on the OGC-SFS
 side
 - anyway OGC-SFS MultiLinestring will always exactly match the
 SHP PolyLine type, even in the case of mixed Polylines
 sometimes being elementary and sometimes being complex.
 - the same considerations obviously apply to Polygon/MultiPolygon
 - conclusion: always assuming a Multi?? type is the safest approach,
 if you aren't absolutely sure about the actual SHP payload.
 
 ogr2ogr does actually has an argument nicely supporting
 all this (just pasted from the ogr2ogr man page):
 
 -nlt type:
   Define the geometry type for the created layer.
   One of NONE, GEOMETRY, POINT, LINESTRING, POLYGON,
   GEOMETRYCOLLECTION, MULTIPOINT, MULTIPOLYGON or
   MULTILINESTRING. Add 25D to the name to get 2.5D
   versions. Starting with GDAL 1.10, PROMOTE_TO_MULTI
   can be used to automatically promote layers that mix
   polygon or multipolygons to multipolygons, and layers
   that mix linestrings or multilinestrings to multilinestrings.
   Can be usefull when converting shapefiles to PostGIS
   (and other target drivers) that implements strict checks
   for geometry type.
 
 it works for PostGIS, and it works for SpatiaLite as well.
 
 bye Sandro
 
 ___
 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

Thanks for this tip.  I think you're on the right track with mixing single line 
strings with multi line strings and single polygons with multi polygons.

(I don't think the number of features is causing any problems as it happens for 
some very small groups of features also.)

It appears as though the first time it hits a feature type that is different to 
all of the others so far, it just bails out silently.

So this implies that it's OK to mix feature types (multi/single) in Shapefiles 
(at least for reading) but not in Spatialite (at least for writing).  Is this 
correct?

If this is so, then what is the correct way to convert/copy a layer from 
Shapefiles to Spatialite?

(Note that is seems to work OK for plain SQLite but not for Spatialite).


On 3 Mar 2014, at 4:37 pm, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote:

 Nik Sands nixanz at nixanz.com writes:
 
 
 Hi all,
 
 I'm planning to switch from using a standard file format of Shapefiles to
 Spatialite for internal storage
 of spatial data.
 
 When importing from other formats, the app attempts to convert these to
 SQLite (Spatialite) using
 'OGR_DS_CopyLayer' to copy each layer from the source data set to a new
 layer in the new SQLite dataset.
 
 However, when converting Shapefiles to SQLite, it only copies across about
 a third of the features for many
 of the layers and therefore the new data set is of no use.
 
 The relevant code and output is below.
 
 I'm at a loss to figure out what is going wrong here and I'd be grateful
 is somebody could assist in getting
 this to work as expected (or am I doing the wrong thing completely?).
 
 NB:  This is using Spatialite on iOS (simulator).
 
 When I use ogr2ogr on Mac OS X with SQLite (without Spatialite) it works
 fine and doesn't miss any features.
 
 Cheers,
 Nik.
 
 CODE:
 
  OGRLayerH sourceLayer = OGR_DS_GetLayer(ds, i);
  int sourceFeatureCount = OGR_L_GetFeatureCount(sourceLayer, YES);
 
  OGR_DS_CopyLayer(destDS, sourceLayer, OGR_L_GetName(sourceLayer), NULL);
 
  OGRLayerH destLayer = OGR_DS_GetLayerByName(destDS,
 OGR_L_GetName(sourceLayer));
  printf(sourceFeatureCount:  %d\n, sourceFeatureCount);
  printf(  destFeatureCount:  %d\n, OGR_L_GetFeatureCount(destLayer, 
 YES));
 
 OUTPUT:
 
  sourceFeatureCount:  3882
destFeatureCount:  1200
 
 
 Hi,
 
 My guess is that CopyLayer is making 200 feature sized transactions and only
 6 transactions are accepted by Spatialite which makes 1200 features. The
 rest transactions are not accepted for some reason. With Spatialite my guess
 is that it complains about constraints and some of the features do not share
 the same geometry type and SRID. Perhaps trying to write multipolygons into
 a layer that accepts only polygons or vice versa.
 
 -Jukka Rahkonen-
 
 
 
 ___
 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] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

Thanks Chaitanya,

It's finally dawned on me that this is what the following is about in the OGR 
SQLite format web page:

Tables with multiple geometries

Starting with OGR 1.10, tables that have multiple geometry columns registered 
in geometry_columns can be used by OGR. For such tables, there are as many OGR 
layers exposed as there are geometry columns. They are named 
table_name(geometry_column_name).
Note: this support is limited to read-only operations.

Ah... so multiple geometries are NOT avaiable in this format for writable.

Your idea of forcing all geometries to multies is a good idea.  I'll have to 
figure out the most efficient way to do this when converting an entire layer at 
a time, but it's likely to be much better than the way I'm currently doing it 
and would result in the same number of layers as the original, which is 
preferable, especially when the user wants to manage drawing styles for layers.

Thanks for your idea.  I'm very grateful.

Cheers,
Nik.


On 4 Mar 2014, at 4:12 pm, Chaitanya kumar CH chaitanya...@gmail.com wrote:

 Nik,
 
 One option I frequently use when uploading shapefiles to PostGIS is to set 
 the -nlt option in ogr2ogr. Setting it as 
 multipolygon/multilinestring/multipoint for a shapefile defined as 
 polygon/linestring/point usually overcomes the problem.
 
 Check if Spatialite allows adding single geometries when the datasource is 
 defined as a multigeometry. If not, you can force the geometry to 
 multigeometry before adding.
 
 
 
 On Tue, Mar 4, 2014 at 5:39 AM, Nik Sands nix...@nixanz.com wrote:
 So now, instead of the 'OGR_DS_CopyLayer', I'm using the code below to run 
 SQL queries to split each layer from the source data set into multiple layers 
 in the destination (Spatialite) dataset based on the geometry types.  (The 
 addNewLayerNames: method will not add empty layers).
 
 It appears to be working OK for now (at least the maps LOOK right on screen).
 
 Is this a reasonable approach to overcoming the problem?
 
 Do I need to include more than just the 6 geometry types in the 
 dictionary/hash below?
 
 Cheers,
 Nik.
 
 
 CODE:
 -
 NSDictionary *geomTypeExts = @{
 @POINT : @pt,
 @MULTIPOINT : @mpt,
 @LINESTRING : @ls,
 @MULTILINESTRING : @mls,
 @POLYGON : @pg,
 @MULTIPOLYGON : @mpg,
 };
 
 for ( NSString *geomType in [geomTypeExts allKeys] )
 {
 NSString *sql = [NSString stringWithFormat:@SELECT * FROM %@ 
 WHERE OGR_GEOMETRY = '%@', sourceLayerName, geomType];
 NSString *destLayerName = [NSString 
 stringWithFormat:@%@_%@, sourceLayerName, [geomTypeExts 
 valueForKey:geomType]];
 
 [self addNewLayerNamed:destLayerName withSQL:sql fromDS:ds 
 toDS:destDS];
 }
 
 
 On 4 Mar 2014, at 9:54 am, Nik Sands nix...@nixanz.com wrote:
 
  Thanks for this tip.  I think you're on the right track with mixing single 
  line strings with multi line strings and single polygons with multi 
  polygons.
 
  (I don't think the number of features is causing any problems as it happens 
  for some very small groups of features also.)
 
  It appears as though the first time it hits a feature type that is 
  different to all of the others so far, it just bails out silently.
 
  So this implies that it's OK to mix feature types (multi/single) in 
  Shapefiles (at least for reading) but not in Spatialite (at least for 
  writing).  Is this correct?
 
  If this is so, then what is the correct way to convert/copy a layer from 
  Shapefiles to Spatialite?
 
  (Note that is seems to work OK for plain SQLite but not for Spatialite).
 
 
  On 3 Mar 2014, at 4:37 pm, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote:
 
  Nik Sands nixanz at nixanz.com writes:
 
 
  Hi all,
 
  I'm planning to switch from using a standard file format of Shapefiles to
  Spatialite for internal storage
  of spatial data.
 
  When importing from other formats, the app attempts to convert these to
  SQLite (Spatialite) using
  'OGR_DS_CopyLayer' to copy each layer from the source data set to a new
  layer in the new SQLite dataset.
 
  However, when converting Shapefiles to SQLite, it only copies across about
  a third of the features for many
  of the layers and therefore the new data set is of no use.
 
  The relevant code and output is below.
 
  I'm at a loss to figure out what is going wrong here and I'd be grateful
  is somebody could assist in getting
  this to work as expected (or am I doing the wrong thing completely?).
 
  NB:  This is using Spatialite on iOS (simulator).
 
  When I use ogr2ogr on Mac OS X with SQLite (without Spatialite) it works
  fine and doesn't miss any features.
 
  Cheers,
  Nik.
 
  CODE:
 
  OGRLayerH sourceLayer = OGR_DS_GetLayer(ds, i);
  int sourceFeatureCount = OGR_L_GetFeatureCount(sourceLayer, YES);
 
  OGR_DS_CopyLayer(destDS, sourceLayer, OGR_L_GetName(sourceLayer

Re: [gdal-dev] Cannot compile GDAL 1.10.1 for iOS with spatialite (2, 3 or 4)

[Nik Sands]

Thanks Even, that seems to have done the trick.

Although I've now got a lot of features missing when using a spatial filter to 
decide what to display.  But that's a whole other issue, and I'll need to do 
more investigation about that before deciding if I need to ask about it here.  
:-)

Cheers,
Nik.


On 28 Feb 2014, at 11:02 pm, Even Rouault even.roua...@mines-paris.org wrote:

 Selon Nik Sands nix...@nixanz.com:
 
 For reference, when I add:
 
  LDFLAGS=-liconv -lsqlite3
 
 And configure says that spatialite is going to be included OK, I eventually
 get the error:
 
 libtool: link: /Applications/Xcode.app/Contents/Developer/usr/bin/g++ -arch
 i386 -isysroot
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 gdalinfo.o commonutils.o -o gdalinfo -Wl,-bind_at_load
 /Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a
 
 -L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
 -liconv -lsqlite3 -lproj -lexpat -lz -lpthread -ldl -lspatialite -lxml2
 duplicate symbol _sqlite3_api in:
 
 
 /Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a(ogrsqlitevirtualogr.o)
 
 
 /Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib/libspatialite.a(libsplite_la-spatialite_init.o)
 duplicate symbol _sqlite3_extension_init in:
 
 
 /Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a(ogrsqlitevirtualogr.o)
 
 
 /Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib/libspatialite.a(libsplite_la-spatialite_init.o)
 ld: 2 duplicate symbols for architecture i386
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 make[1]: *** [gdalinfo] Error 1
 make: *** [apps-target] Error 2
 
 
 iOS only does static linking, not dynamic right ? Well, in that case, the
 problem is that both libspatialite and libgdal define sqlite3 extensions, 
 hence
 the symbol conflict. If you don't need OGR SQLITE SQL dialect, then you can 
 try
 editing ogr/ogrsf_frmts/sqlite/ogr_sqlite.h to comment #define HAVE_SQLITE_VFS
 and rebuilding GDAL.
 
 
 On 28 Feb 2014, at 4:47 pm, Nik Sands nix...@nixanz.com wrote:
 
 Hi all,
 
 I can compile GDAL 1.10.1 for iOS OK, including SQLite.  However, I've been
 unable to include spatialite which I think need to get the performance
 increase I'm expecting from proper spatial indexing.
 
 My 'configure' line is:
 
 ./configure
 
 --prefix=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
 --libdir=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/i386/lib
 --host=i386-apple-darwin --disable-shared --enable-static
 --with-unix-stdio-64=no --without-pg --without-grass --without-libgrass
 --without-cfitsio --without-pcraster --without-netcdf --without-ogdi
 --without-fme --without-hdf4 --without-hdf5 --without-jasper --without-kakadu
 --without-bsb --without-grib --without-mysql --without-ingres
 --without-xerces --without-odbc --without-curl --without-idb --without-sde
 --without-sse
 
 --with-expat=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
 --with-static-proj4=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/
 SD
 Ks/iPhon
 eSimulator7.0.sdk
 
 --with-sqlite3=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr
 
 --with-spatialite=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
 But the output of configure includes:
 
 ...
 SQLite support:yes
 ...
 SpatiaLite support:no
 ...
 
 The config.log includes the reasons why (see a large section of it further
 below).  It is a LOT of undefined symbols related to sqlite3 (and a few from
 iconv).
 
 I've had the same results with Spatialite versions 2, 3 and 4.
 
 Initially, I thought the problem might be related to
 https://trac.osgeo.org/gdal/ticket/5122 however, neither of the work arounds
 there worked for me.  At least not completely.  If I use the LDFLags work
 around to force linking against iconv and sqlite3, then the configure appears
 to work OK and does include spatialite.  However, it then fails to compile
 with Duplicate symbol errors.
 
 Could anybody help me to resolve this problem?
 
 Cheers,
 Nik.
 
 
 --
 config.log extract
 --
 
 configure:24960: checking for spatialite_init in -lspatialite
 configure:24985: /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o
 conftest -arch

[gdal-dev] Missing features after copying layers from Shapefiles to SQLite

[Nik Sands]

Hi all,

I'm planning to switch from using a standard file format of Shapefiles to 
Spatialite for internal storage of spatial data.

When importing from other formats, the app attempts to convert these to SQLite 
(Spatialite) using 'OGR_DS_CopyLayer' to copy each layer from the source data 
set to a new layer in the new SQLite dataset.

However, when converting Shapefiles to SQLite, it only copies across about a 
third of the features for many of the layers and therefore the new data set is 
of no use.

The relevant code and output is below.

I'm at a loss to figure out what is going wrong here and I'd be grateful is 
somebody could assist in getting this to work as expected (or am I doing the 
wrong thing completely?).

NB:  This is using Spatialite on iOS (simulator).

When I use ogr2ogr on Mac OS X with SQLite (without Spatialite) it works fine 
and doesn't miss any features.

Cheers,
Nik.


CODE:

OGRLayerH sourceLayer = OGR_DS_GetLayer(ds, i);
int sourceFeatureCount = OGR_L_GetFeatureCount(sourceLayer, YES);

OGR_DS_CopyLayer(destDS, sourceLayer, OGR_L_GetName(sourceLayer), NULL);

OGRLayerH destLayer = OGR_DS_GetLayerByName(destDS, 
OGR_L_GetName(sourceLayer));
printf(sourceFeatureCount:  %d\n, sourceFeatureCount);
printf(  destFeatureCount:  %d\n, OGR_L_GetFeatureCount(destLayer, 
YES));

OUTPUT:

sourceFeatureCount:  3882
  destFeatureCount:  1200
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot compile GDAL 1.10.1 for iOS with spatialite (2, 3 or 4)

[Nik Sands]

For reference, when I add:

LDFLAGS=-liconv -lsqlite3

And configure says that spatialite is going to be included OK, I eventually get 
the error:

libtool: link: /Applications/Xcode.app/Contents/Developer/usr/bin/g++ -arch 
i386 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 gdalinfo.o commonutils.o -o gdalinfo -Wl,-bind_at_load  
/Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a 
-L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
 -liconv -lsqlite3 -lproj -lexpat -lz -lpthread -ldl -lspatialite -lxml2
duplicate symbol _sqlite3_api in:

/Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a(ogrsqlitevirtualogr.o)

/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib/libspatialite.a(libsplite_la-spatialite_init.o)
duplicate symbol _sqlite3_extension_init in:

/Users/nsands/Documents/Nik/Development/gdal-1.10.1/.libs/libgdal.a(ogrsqlitevirtualogr.o)

/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib/libspatialite.a(libsplite_la-spatialite_init.o)
ld: 2 duplicate symbols for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [gdalinfo] Error 1
make: *** [apps-target] Error 2


On 28 Feb 2014, at 4:47 pm, Nik Sands nix...@nixanz.com wrote:

 Hi all,
 
 I can compile GDAL 1.10.1 for iOS OK, including SQLite.  However, I've been 
 unable to include spatialite which I think need to get the performance 
 increase I'm expecting from proper spatial indexing.
 
 My 'configure' line is:
 
 ./configure 
 --prefix=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
  
 --libdir=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/i386/lib
  --host=i386-apple-darwin --disable-shared --enable-static 
 --with-unix-stdio-64=no --without-pg --without-grass --without-libgrass 
 --without-cfitsio --without-pcraster --without-netcdf --without-ogdi 
 --without-fme --without-hdf4 --without-hdf5 --without-jasper --without-kakadu 
 --without-bsb --without-grib --without-mysql --without-ingres 
 --without-xerces --without-odbc --without-curl --without-idb --without-sde 
 --without-sse 
 --with-expat=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
  
 --with-static-proj4=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SD
 Ks/iPhon
 eSimulator7.0.sdk 
 --with-sqlite3=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr
  
 --with-spatialite=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
 But the output of configure includes:
 
 ...
 SQLite support:yes
 ...
 SpatiaLite support:no
 ...
 
 The config.log includes the reasons why (see a large section of it further 
 below).  It is a LOT of undefined symbols related to sqlite3 (and a few from 
 iconv).
 
 I've had the same results with Spatialite versions 2, 3 and 4.
 
 Initially, I thought the problem might be related to 
 https://trac.osgeo.org/gdal/ticket/5122 however, neither of the work arounds 
 there worked for me.  At least not completely.  If I use the LDFLags work 
 around to force linking against iconv and sqlite3, then the configure appears 
 to work OK and does include spatialite.  However, it then fails to compile 
 with Duplicate symbol errors.
 
 Could anybody help me to resolve this problem?
 
 Cheers,
 Nik.
 
 
 --
 config.log extract
 --
 
 configure:24960: checking for spatialite_init in -lspatialite
 configure:24985: /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o 
 conftest -arch i386 -pipe -Os -gdwarf-2 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
  -D__IPHONE_OS_VERSION_MIN_REQUIRED=7  -arch i386 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
  conftest.c -lspatialite 
 -L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
  -lspatialite 
 -L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
  -lexpat -lz -lpthread -ldl  5
 Undefined symbols for architecture i386:
 _iconv, referenced from:
 _gaiaOpenShpRead

[gdal-dev] Cannot compile GDAL 1.10.1 for iOS with spatialite (2, 3 or 4)

[Nik Sands]

Hi all,

I can compile GDAL 1.10.1 for iOS OK, including SQLite.  However, I've been 
unable to include spatialite which I think need to get the performance increase 
I'm expecting from proper spatial indexing.

My 'configure' line is:

./configure 
--prefix=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
--libdir=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/i386/lib
 --host=i386-apple-darwin --disable-shared --enable-static 
--with-unix-stdio-64=no --without-pg --without-grass --without-libgrass 
--without-cfitsio --without-pcraster --without-netcdf --without-ogdi 
--without-fme --without-hdf4 --without-hdf5 --without-jasper --without-kakadu 
--without-bsb --without-grib --without-mysql --without-ingres --without-xerces 
--without-odbc --without-curl --without-idb --without-sde --without-sse 
--with-expat=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 
--with-static-proj4=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhon
 eSimulator7.0.sdk 
--with-sqlite3=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr
 
--with-spatialite=/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk

But the output of configure includes:

...
  SQLite support:yes
...
  SpatiaLite support:no
...

The config.log includes the reasons why (see a large section of it further 
below).  It is a LOT of undefined symbols related to sqlite3 (and a few from 
iconv).

I've had the same results with Spatialite versions 2, 3 and 4.

Initially, I thought the problem might be related to 
https://trac.osgeo.org/gdal/ticket/5122 however, neither of the work arounds 
there worked for me.  At least not completely.  If I use the LDFLags work 
around to force linking against iconv and sqlite3, then the configure appears 
to work OK and does include spatialite.  However, it then fails to compile with 
Duplicate symbol errors.

Could anybody help me to resolve this problem?

Cheers,
Nik.


--
config.log extract
--

configure:24960: checking for spatialite_init in -lspatialite
configure:24985: /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o 
conftest -arch i386 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 -D__IPHONE_OS_VERSION_MIN_REQUIRED=7  -arch i386 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
 conftest.c -lspatialite 
-L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
 -lspatialite 
-L/Users/nsands/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/lib
 -lexpat -lz -lpthread -ldl  5
Undefined symbols for architecture i386:
  _iconv, referenced from:
  _gaiaOpenShpRead in libspatialite.a(gg_shape.o)
  _gaiaOpenShpWrite in libspatialite.a(gg_shape.o)
  _parseDbfField in libspatialite.a(gg_shape.o)
  _gaiaWriteShpEntity in libspatialite.a(gg_shape.o)
  _gaiaOpenDbfRead in libspatialite.a(gg_shape.o)
  _gaiaOpenDbfWrite in libspatialite.a(gg_shape.o)
  _gaiaWriteDbfEntity in libspatialite.a(gg_shape.o)
  ...
  _iconv_close, referenced from:
  _gaiaFreeShapefile in libspatialite.a(gg_shape.o)
  _gaiaFreeDbf in libspatialite.a(gg_shape.o)
  _gaiaConvertCharset in libspatialite.a(gg_utf8.o)
  _gaiaFreeDbf in libspatialite.a(gg_shape.o)
  _gaiaConvertCharset in libspatialite.a(gg_utf8.o)
  _gaiaFreeUTF8Converter in libspatialite.a(gg_utf8.o)
  _iconv_open, referenced from:
  _gaiaOpenShpRead in libspatialite.a(gg_shape.o)
  _gaiaOpenShpWrite in libspatialite.a(gg_shape.o)
  _gaiaOpenDbfRead in libspatialite.a(gg_shape.o)
  _gaiaOpenDbfWrite in libspatialite.a(gg_shape.o)
  _gaiaConvertCharset in libspatialite.a(gg_utf8.o)
  _gaiaCreateUTF8Converter in libspatialite.a(gg_utf8.o)
  _sqlite3_aggregate_context, referenced from:
  _fnct_MD5TotalChecksum_step in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_MD5TotalChecksum_final in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_Extent_step in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_Extent_final in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_MakeLine_step in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_MakeLine_final in libspatialite.a(libsplite_la-spatialite.o)
  _fnct_Collect_step in libspatialite.a(libsplite_la-spatialite.o)
  

Re: [gdal-dev] Can't use two datasets read-only from same files?

[Nik Sands]

Hi Even,

Thanks for your replies.  I think the number of files may be the problem.  Note 
that this is on the iPhone simulator (so effectively Mac OS X).

Yes, the path is a directory that contains shapefiles representing 352 
layers.  Each layer has a .shp, .shx, .dbf, .prj, so 1409 files in total.  I'm 
not sure how many of these OGR needs to have open simultaneously.

Anyhow, I appreciate your reply.  I think I've hit the OS file limit.  I didn't 
even realise how many files were in that directory until you mentioned this 
possibility.

Cheers,
Nik.


On 23 Feb 2014, at 6:51 pm, Even Rouault even.roua...@mines-paris.org wrote:

 Le dimanche 23 février 2014 08:40:11, Even Rouault a écrit :
 Nik,
 
 what you try to do is perfectly valid and should work. I've just tried it
 myself, but I can't reproduce any error. If you are working on Linux, could
 you run your program with valgrind and look if it reports some errors ?
 The only explanation I can imagine for now is that the file system on which
 your shapefile is located doesn't support a file to be opened more than
 once at a time, but this would be extremely surprising !
 
 oh wait, is the path in your example a directory that contains lots of 
 shapefiles ? In that case, you might reach the maximum number of opened files 
 by 
 a process. But... since GDAL 1.9, there is a mechanism in the shapefile 
 driver 
 to limit the number of layers opened simultaneously to 100 per datasource (so 
 200 files for .shp and .dbf). With 2 datasources, this would be 400 files 
 which 
 is still below the 1024 limit on Linux.
 
 
 Best regards,
 
 Even
 
 Hi GDAL devs,
 
 I have a need to open the same set of Shapefiles as two independent
 datasets, BOTH of which are READ ONLY.  However, when I do this, and
 attempt to get the number of layers in the second data set, I get a whole
 
 lot of errors of the form:
 ERROR 4: Failed to open file shapefile.shp.
 It may be corrupt or read-only file accessed in update mode.
 
 ...for most (but not all) of the layers, and of course the dataset is
 incomplete and not useful.
 
 I've crafted the following very simple example of this problem:
  OGRDataSourceH firstDS = OGROpen(path, FALSE, NULL);
  OGRDataSourceH secondDS = OGROpen(path, FALSE, NULL);
  OGR_DS_GetLayerCount(firstDS);   //  THIS LINE WORKS FINE
  OGR_DS_GetLayerCount(secondDS);  //  THIS LINE PRODUCES MANY 
 ERRORS
 
 If I OGR_DS_Destroy the first data set before running the
 OGR_DS_GetLayerCount on the second data set it works fine.
 
 Is this expected?
 
 I really need to have both datasets readable and useable simultaneously
 as they are both in completely independent parts of the application. 
 The first data set should be long-lived and needs to be persistent
 before, during and after the entire short life-cycle of the second data
 set.
 
 The error messages imply that it is either corrupt or accessed in update
 mode.  But clearly it is not corrupt (at the file level) because it works
 fine in the first data set (and in the second if the first data set is
 destroyed first).  It is also being explicitly opened in READ-ONLY mode
 in both cases and therefore should not be in update mode.
 
 I'm using gdal-1.10.1.
 
 Any advice would be very much appreciated.
 
 Cheers,
 Nik.
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html
 ___
 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] Can't use two datasets read-only from same files?

[Nik Sands]

Hi GDAL devs,

I have a need to open the same set of Shapefiles as two independent datasets, 
BOTH of which are READ ONLY.  However, when I do this, and attempt to get the 
number of layers in the second data set, I get a whole lot of errors of the 
form:

ERROR 4: Failed to open file shapefile.shp.
It may be corrupt or read-only file accessed in update mode.

...for most (but not all) of the layers, and of course the dataset is 
incomplete and not useful.

I've crafted the following very simple example of this problem:

 OGRDataSourceH firstDS = OGROpen(path, FALSE, NULL);
 OGRDataSourceH secondDS = OGROpen(path, FALSE, NULL);
 OGR_DS_GetLayerCount(firstDS);   //  THIS LINE WORKS FINE
 OGR_DS_GetLayerCount(secondDS);  //  THIS LINE PRODUCES MANY 
ERRORS

If I OGR_DS_Destroy the first data set before running the OGR_DS_GetLayerCount 
on the second data set it works fine.

Is this expected?

I really need to have both datasets readable and useable simultaneously as they 
are both in completely independent parts of the application.  The first data 
set should be long-lived and needs to be persistent before, during and after 
the entire short life-cycle of the second data set.

The error messages imply that it is either corrupt or accessed in update mode.  
But clearly it is not corrupt (at the file level) because it works fine in the 
first data set (and in the second if the first data set is destroyed first).  
It is also being explicitly opened in READ-ONLY mode in both cases and 
therefore should not be in update mode.

I'm using gdal-1.10.1.

Any advice would be very much appreciated.

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] assert failure (tif_open)

[Nik Sands]

Hi list members,

I've been using GDAL 1.10 as a statically linked library in an iOS app for some 
time.  I recently recompiled GDAL again from the same local set of source 
files, using my notes on configuration options that I used last time, and ever 
since I've been having a problem every time the app attempts to open an image 
file.

The app fails an assert() in the included tiff library (in tif_open.c), 
throwing the error:

Assertion failed: (sizeof(uint64)==8), function TIFFClientOpen, file 
tif_open.c, line 99.

The line in question is the last line of the code snippet from tif_open.c below:

/* The following are configuration checks. They should be redundant, 
but should not
 * compile to any actual code in an optimised release build anyway. If 
any of them
 * fail, (makefile-based or other) configuration is not correct */
assert(sizeof(uint8)==1);
assert(sizeof(int8)==1);
assert(sizeof(uint16)==2);
assert(sizeof(int16)==2);
assert(sizeof(uint32)==4);
assert(sizeof(int32)==4);
assert(sizeof(uint64)==8);  //  - SIBABRT HERE

The comments indicate that there may be a problem with the configure options 
I used when building GDAL, however I'm using exactly the same options (copy and 
pasted) as I used last time when it worked OK.

So this leads me to think that perhaps something has changed in my environment, 
and the only thing I can think of is that I may be using a different version of 
GCC (I'm using the 'gcc' included with Apple's 'Xcode' IDE, and since the last 
compile of GDAL, I've upgraded from a beta build of Xcode to the production 
build of Xcode 5).

I've tried it with GDAL 1.10.1 as well and get exactly the same problem.

I'm stumped as to how to proceed with resolving this issue.  Can anybody help 
me to overcome this?

Note that the problem occurs when running on the real iOS device (armv7s) and 
on the iOS simulator (i386).

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] assert failure (tif_open)

[Nik Sands]

I think you're right Frank.  It may take me some time to figure out how to get 
it working correctly.

Your message did remind me of one HUGE change that Apple made between the beta 
versions of their Xcode IDE and the final production version:  64 bit support 
for the new iPhone 5S.  ( 
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/CocoaTouch64BitGuide.pdf
 )

So it's gotta be related to that, I reckon.  (Should have stuck with the beta 
version!  :-)  )

I'll post back if I can figure out the correct settings in the config files you 
mentioned in order to get it to work properly.



On 27/09/2013, at 9:54 AM, Frank Warmerdam warmer...@pobox.com wrote:

 Nik,
 
 I assume you are using the built in libtiff in GDAL.  In that case the file 
 gdal/frmts/gtiff/libtiff/tif_config.h will include cpl_port.h and includes 
 this line:
 
 #define TIFF_UINT64_T GUIntBig
 
 I assume TIFF_UINT64 ultimately is used to define uint64.
 
 So I think you need to go through gdal/port/cpl_port.h and 
 gdal/port/cpl_config.h to try and figure out how GUIntBig is getting defined. 
  In cpl_port.h it helps to search for the block of code titled 64bit 
 support.  I would guess you want to use unsigned long long in which case 
 you would need to have HAVE_LONG_LONG defined in cpl_config.h.
 
 I'm not aware of any recent changes in this logic so I'm not sure why it used 
 to work and doesn't now.  
 
 Best regards,
 Frank
 
 
 
 
 
 
 On Thu, Sep 26, 2013 at 4:33 PM, Nik Sands nix...@nixanz.com wrote:
 Hi list members,
 
 I've been using GDAL 1.10 as a statically linked library in an iOS app for 
 some time.  I recently recompiled GDAL again from the same local set of 
 source files, using my notes on configuration options that I used last time, 
 and ever since I've been having a problem every time the app attempts to open 
 an image file.
 
 The app fails an assert() in the included tiff library (in tif_open.c), 
 throwing the error:
 
 Assertion failed: (sizeof(uint64)==8), function TIFFClientOpen, file 
 tif_open.c, line 99.
 
 The line in question is the last line of the code snippet from tif_open.c 
 below:
 
 /* The following are configuration checks. They should be redundant, 
 but should not
  * compile to any actual code in an optimised release build anyway. 
 If any of them
  * fail, (makefile-based or other) configuration is not correct */
 assert(sizeof(uint8)==1);
 assert(sizeof(int8)==1);
 assert(sizeof(uint16)==2);
 assert(sizeof(int16)==2);
 assert(sizeof(uint32)==4);
 assert(sizeof(int32)==4);
 assert(sizeof(uint64)==8);  //  - SIBABRT HERE
 
 The comments indicate that there may be a problem with the configure 
 options I used when building GDAL, however I'm using exactly the same options 
 (copy and pasted) as I used last time when it worked OK.
 
 So this leads me to think that perhaps something has changed in my 
 environment, and the only thing I can think of is that I may be using a 
 different version of GCC (I'm using the 'gcc' included with Apple's 'Xcode' 
 IDE, and since the last compile of GDAL, I've upgraded from a beta build of 
 Xcode to the production build of Xcode 5).
 
 I've tried it with GDAL 1.10.1 as well and get exactly the same problem.
 
 I'm stumped as to how to proceed with resolving this issue.  Can anybody help 
 me to overcome this?
 
 Note that the problem occurs when running on the real iOS device (armv7s) and 
 on the iOS simulator (i386).
 
 Cheers,
 Nik.
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 
 
 -- 
 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
 light and sound - activate the windows | http://pobox.com/~warmerdam
 and watch the world go round - Rush| Geospatial Software Developer

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] assert failure (tif_open)

[Nik Sands]

Thanks again for your help Frank.

As usual, you were spot on and adding the following line to 
.../port/cpl_config.h.in before building fixed the problem:

#define HAVE_LONG_LONG 1

I've now added this to my own build notes.

Since the problem didn't occur when using the beta versions of Apple's Xcode 5 
and only occurred with the final version of Xcode 5, I'm assuming that Apple 
changed their developer tools/environment with their production release which 
coincided with their announcement of 64-bit iPhones (iPhone 5S) in such a way 
that it affected what 'configure' wrote to cpl_config.h.

Cheers,
Nik.


On 27/09/2013, at 9:54 AM, Frank Warmerdam warmer...@pobox.com wrote:

 Nik,
 
 I assume you are using the built in libtiff in GDAL.  In that case the file 
 gdal/frmts/gtiff/libtiff/tif_config.h will include cpl_port.h and includes 
 this line:
 
 #define TIFF_UINT64_T GUIntBig
 
 I assume TIFF_UINT64 ultimately is used to define uint64.
 
 So I think you need to go through gdal/port/cpl_port.h and 
 gdal/port/cpl_config.h to try and figure out how GUIntBig is getting defined. 
  In cpl_port.h it helps to search for the block of code titled 64bit 
 support.  I would guess you want to use unsigned long long in which case 
 you would need to have HAVE_LONG_LONG defined in cpl_config.h.
 
 I'm not aware of any recent changes in this logic so I'm not sure why it used 
 to work and doesn't now.  
 
 Best regards,
 Frank
 
 
 
 
 
 
 On Thu, Sep 26, 2013 at 4:33 PM, Nik Sands nix...@nixanz.com wrote:
 Hi list members,
 
 I've been using GDAL 1.10 as a statically linked library in an iOS app for 
 some time.  I recently recompiled GDAL again from the same local set of 
 source files, using my notes on configuration options that I used last time, 
 and ever since I've been having a problem every time the app attempts to open 
 an image file.
 
 The app fails an assert() in the included tiff library (in tif_open.c), 
 throwing the error:
 
 Assertion failed: (sizeof(uint64)==8), function TIFFClientOpen, file 
 tif_open.c, line 99.
 
 The line in question is the last line of the code snippet from tif_open.c 
 below:
 
 /* The following are configuration checks. They should be redundant, 
 but should not
  * compile to any actual code in an optimised release build anyway. 
 If any of them
  * fail, (makefile-based or other) configuration is not correct */
 assert(sizeof(uint8)==1);
 assert(sizeof(int8)==1);
 assert(sizeof(uint16)==2);
 assert(sizeof(int16)==2);
 assert(sizeof(uint32)==4);
 assert(sizeof(int32)==4);
 assert(sizeof(uint64)==8);  //  - SIBABRT HERE
 
 The comments indicate that there may be a problem with the configure 
 options I used when building GDAL, however I'm using exactly the same options 
 (copy and pasted) as I used last time when it worked OK.
 
 So this leads me to think that perhaps something has changed in my 
 environment, and the only thing I can think of is that I may be using a 
 different version of GCC (I'm using the 'gcc' included with Apple's 'Xcode' 
 IDE, and since the last compile of GDAL, I've upgraded from a beta build of 
 Xcode to the production build of Xcode 5).
 
 I've tried it with GDAL 1.10.1 as well and get exactly the same problem.
 
 I'm stumped as to how to proceed with resolving this issue.  Can anybody help 
 me to overcome this?
 
 Note that the problem occurs when running on the real iOS device (armv7s) and 
 on the iOS simulator (i386).
 
 Cheers,
 Nik.
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 
 
 -- 
 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
 light and sound - activate the windows | http://pobox.com/~warmerdam
 and watch the world go round - Rush| Geospatial Software Developer

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot compile 1.10 for iOS due to missing crt_extern

[Nik Sands]

No problem.  I've now logged these issues in GDAL Trac as two separate tickets 
(not sure if they should be in one ticket or two?):

Ticket #5197
Ticket #5198


On 13/08/2013, at 4:06 PM, Even Rouault even.roua...@mines-paris.org wrote:

 Selon Nik Sands nix...@nixanz.com:
 
 PS.  I've got a work around for now...
 
 I edited the file ogr/ogrsf_frmts/vfk/vfkdatablock.cpp and commented out
 the lines that referenced clock(), and the debug line which appears to be
 all that was using it.
 
 It then built OK.   :-)
 
 I'm sure you guys can come up with a proper solution, but this did the job
 for me for now.   :-)
 
 Nick,
 
 can you open a ticket in GDAL Trac about those 2 issues ?
 
 Thanks,
 
 Even
 
 
 Cheers,
 Nik.
 
 
 
 On 13/08/2013, at 10:16 AM, Nik Sands nix...@nixanz.com wrote:
 
 Hi Even,
 
 Your suggestion has helped a little, but I still can't compile for iOS
 (device).  I'm getting the following at the end of the build output...
 
 
 libtool: compile:
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -pipe -Os -gdwarf-2 -isysroot
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 -mno-thumb -mthumb-interwork -Wall
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/gcore
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/alg
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr/ogrsf_frmts
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/frmts -DOGR_ENABLED
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -c commonutils.cpp
 -o commonutils.o
 /bin/sh /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libtool
 
 --mode=link   
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -isysroot
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 gdalinfo.lo commonutils.lo
 /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libgdal.la -o gdalinfo
 libtool: link:
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -isysroot
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 gdalinfo.o commonutils.o -o gdalinfo
 /Users/nsands/Documents/Nik/Development/gdal-1.10.0/.libs/libgdal.a -lsqlite3
 -lz -lpthread -ldl -liconv -lxml2
 Undefined symbols for architecture armv7:
 _clock$UNIX2003, referenced from:
 IVFKDataBlock::LoadGeometry()   in libgdal.a(vfkdatablock.o)
 ld: symbol(s) not found for architecture armv7
 collect2: ld returned 1 exit status
 make[1]: *** [gdalinfo] Error 1
 make: *** [apps-target] Error 2
 
 
 How can I get this resolved?
 
 Cheers,
 Nik.
 
 
 On 12/08/2013, at 4:12 PM, Even Rouault even.roua...@mines-paris.org
 wrote:
 
 Le lundi 12 août 2013 02:17:33, Nik Sands a écrit :
 Hi list members,
 
 I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS
 simulator, however I cannot compile GDAL 1.10 for the actual iOS
 (devices).  It appears that this is because crt_extern is not included in
 iOS.
 
 The code that trips up the build is in 'cpl_spawn.cpp' and appears to be:
 
   #ifdef __APPLE__
   #include crt_externs.h
 
 The last few lines of the build output are below.
 
 Is there some way that I can get GDAL 1.10 built for iOS?  I really need
 one of the changes that was included in this version.
 
 Thanks in advance for any advice that you may be able to provide.
 
 Nick,
 
 Maybe you can try the patch at
 https://github.com/joyent/libuv/pull/321#issuecomment-4155600 that has
 very
 similar code that the one in GDAL and report if it works for you so it can
 get
 integrated ?
 
 Even
 
 
 Cheers,
 Nik.
 
 
 libtool: compile:
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot
 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall
 -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port
 -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o
 cpl_spawn.o cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or
 directory cpl_spawn.cpp: In function 'CPLSpawnedProcess*
 CPLSpawnAsync(int
 (*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int,
 char**)': cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in
 this scope make[1]: *** [cpl_spawn.lo] Error 1
 make: *** [port-target] Error 2
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 --
 Geospatial professional services
 http://even.rouault.free.fr/services.html

Re: [gdal-dev] Cannot compile 1.10 for iOS due to missing crt_extern

[Nik Sands]

Hi Even,

Your suggestion has helped a little, but I still can't compile for iOS 
(device).  I'm getting the following at the end of the build output...


libtool: compile:  
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 -mno-thumb -mthumb-interwork -Wall 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/gcore 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/alg 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr/ogrsf_frmts 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/frmts -DOGR_ENABLED 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -c commonutils.cpp 
-o commonutils.o
/bin/sh /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libtool --mode=link 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 gdalinfo.lo commonutils.lo  
/Users/nsands/Documents/Nik/Development/gdal-1.10.0/libgdal.la -o gdalinfo
libtool: link: 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 gdalinfo.o commonutils.o -o gdalinfo  
/Users/nsands/Documents/Nik/Development/gdal-1.10.0/.libs/libgdal.a -lsqlite3 
-lz -lpthread -ldl -liconv -lxml2
Undefined symbols for architecture armv7:
  _clock$UNIX2003, referenced from:
  IVFKDataBlock::LoadGeometry()   in libgdal.a(vfkdatablock.o)
ld: symbol(s) not found for architecture armv7
collect2: ld returned 1 exit status
make[1]: *** [gdalinfo] Error 1
make: *** [apps-target] Error 2


How can I get this resolved?

Cheers,
Nik.


On 12/08/2013, at 4:12 PM, Even Rouault even.roua...@mines-paris.org wrote:

 Le lundi 12 août 2013 02:17:33, Nik Sands a écrit :
 Hi list members,
 
 I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS
 simulator, however I cannot compile GDAL 1.10 for the actual iOS
 (devices).  It appears that this is because crt_extern is not included in
 iOS.
 
 The code that trips up the build is in 'cpl_spawn.cpp' and appears to be:
 
  #ifdef __APPLE__
  #include crt_externs.h
 
 The last few lines of the build output are below.
 
 Is there some way that I can get GDAL 1.10 built for iOS?  I really need
 one of the changes that was included in this version.
 
 Thanks in advance for any advice that you may be able to provide.
 
 Nick,
 
 Maybe you can try the patch at 
 https://github.com/joyent/libuv/pull/321#issuecomment-4155600 that has very 
 similar code that the one in GDAL and report if it works for you so it can 
 get 
 integrated ?
 
 Even
 
 
 Cheers,
 Nik.
 
 
 libtool: compile: 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall
 -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port
 -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o
 cpl_spawn.o cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or
 directory cpl_spawn.cpp: In function 'CPLSpawnedProcess* CPLSpawnAsync(int
 (*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int,
 char**)': cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in
 this scope make[1]: *** [cpl_spawn.lo] Error 1
 make: *** [port-target] Error 2
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot compile 1.10 for iOS due to missing crt_extern

[Nik Sands]

PS.  I've got a work around for now...

I edited the file ogr/ogrsf_frmts/vfk/vfkdatablock.cpp and commented out the 
lines that referenced clock(), and the debug line which appears to be all 
that was using it.

It then built OK.   :-)

I'm sure you guys can come up with a proper solution, but this did the job for 
me for now.   :-)

Cheers,
Nik.



On 13/08/2013, at 10:16 AM, Nik Sands nix...@nixanz.com wrote:

 Hi Even,
 
 Your suggestion has helped a little, but I still can't compile for iOS 
 (device).  I'm getting the following at the end of the build output...
 
 
 libtool: compile:  
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
  -arch armv7 -pipe -Os -gdwarf-2 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
  -mno-thumb -mthumb-interwork -Wall 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/gcore 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/alg 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr/ogrsf_frmts 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/frmts -DOGR_ENABLED 
 -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -c commonutils.cpp 
 -o commonutils.o
 /bin/sh /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libtool 
 --mode=link   
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
  -arch armv7 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
  gdalinfo.lo commonutils.lo  
 /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libgdal.la -o gdalinfo
 libtool: link: 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
  -arch armv7 -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
  gdalinfo.o commonutils.o -o gdalinfo  
 /Users/nsands/Documents/Nik/Development/gdal-1.10.0/.libs/libgdal.a -lsqlite3 
 -lz -lpthread -ldl -liconv -lxml2
 Undefined symbols for architecture armv7:
  _clock$UNIX2003, referenced from:
  IVFKDataBlock::LoadGeometry()   in libgdal.a(vfkdatablock.o)
 ld: symbol(s) not found for architecture armv7
 collect2: ld returned 1 exit status
 make[1]: *** [gdalinfo] Error 1
 make: *** [apps-target] Error 2
 
 
 How can I get this resolved?
 
 Cheers,
 Nik.
 
 
 On 12/08/2013, at 4:12 PM, Even Rouault even.roua...@mines-paris.org wrote:
 
 Le lundi 12 août 2013 02:17:33, Nik Sands a écrit :
 Hi list members,
 
 I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS
 simulator, however I cannot compile GDAL 1.10 for the actual iOS
 (devices).  It appears that this is because crt_extern is not included in
 iOS.
 
 The code that trips up the build is in 'cpl_spawn.cpp' and appears to be:
 
 #ifdef __APPLE__
 #include crt_externs.h
 
 The last few lines of the build output are below.
 
 Is there some way that I can get GDAL 1.10 built for iOS?  I really need
 one of the changes that was included in this version.
 
 Thanks in advance for any advice that you may be able to provide.
 
 Nick,
 
 Maybe you can try the patch at 
 https://github.com/joyent/libuv/pull/321#issuecomment-4155600 that has very 
 similar code that the one in GDAL and report if it works for you so it can 
 get 
 integrated ?
 
 Even
 
 
 Cheers,
 Nik.
 
 
 libtool: compile: 
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
 eloper/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall
 -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port
 -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o
 cpl_spawn.o cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or
 directory cpl_spawn.cpp: In function 'CPLSpawnedProcess* CPLSpawnAsync(int
 (*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int,
 char**)': cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in
 this scope make[1]: *** [cpl_spawn.lo] Error 1
 make: *** [port-target] Error 2
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 -- 
 Geospatial professional services
 http://even.rouault.free.fr/services.html
 
 ___
 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] Cannot compile 1.10 for iOS due to missing crt_extern

[Nik Sands]

Hi list members,

I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS 
simulator, however I cannot compile GDAL 1.10 for the actual iOS (devices).  It 
appears that this is because crt_extern is not included in iOS.

The code that trips up the build is in 'cpl_spawn.cpp' and appears to be:

#ifdef __APPLE__
#include crt_externs.h

The last few lines of the build output are below.

Is there some way that I can get GDAL 1.10 built for iOS?  I really need one of 
the changes that was included in this version.

Thanks in advance for any advice that you may be able to provide.

Cheers,
Nik.


libtool: compile:  
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++
 -arch armv7 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
 -mno-thumb -mthumb-interwork -Wall -DOGR_ENABLED 
-I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -DHAVE_LIBZ 
-I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o cpl_spawn.o
cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or directory
cpl_spawn.cpp: In function 'CPLSpawnedProcess* CPLSpawnAsync(int 
(*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int, 
char**)':
cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in this scope
make[1]: *** [cpl_spawn.lo] Error 1
make: *** [port-target] Error 2
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can GDALCreate be Used for PNG?

[Nik Sands]

Thanks Frank.

So I think I need to do something like the code below instead, ie, create a 
MEM dataset and later create-copy to a PNG dataset.  This seems to be 
working (although the content of the image is all wrong - but that's another 
issue for me to try to figure out).

Thanks again,
Nik.


GDALDatasetH memDS = GDALCreate( GDALGetDriverByName(MEM), tmp, 256, 256, 
4, GDT_Float32, NULL );

…
…
…

char **options = NULL;

options = CSLSetNameValue( papszOptions, WORLDFILE, NO );
options = CSLSetNameValue( papszOptions, ZLEVEL, 9 );

GDALDatasetH dstDS = GDALCreate( hDriver, /var/tmp/image.png, 256, 256, 4, 
GDT_Float32, options );
GDALDatasetH dstDS = GDALCreateCopy( GDALGetDriverByName(PNG), 
/var/tmp/image.png, memDS, FALSE, options, NULL, NULL );


On 17/07/2013, at 4:50 PM, Frank Warmerdam warmer...@pobox.com wrote:

 Nik,
 
 No, the PNG format does not support direct creation, only creation by copying 
 an existing dataset (GDALCreateCopy()).  You can interactively see the 
 capabilities of a driver like this:
 
 gdalinfo --format png
 Format Details:
   Short Name: PNG
   Long Name: Portable Network Graphics
   Extension: png
   Mime Type: image/png
   Help Topic: frmt_various.html#PNG
   Supports: CreateCopy() - Create dataset by copying another.
   Supports: Virtual IO - eg. /vsimem/
   Creation Datatypes: Byte UInt16
 
 CreationOptionList
   Option name=WORLDFILE type=boolean description=Create world file /
   Option name=ZLEVEL type=int description=DEFLATE compression level 
 1-9 default=6 /
 /CreationOptionList
 
 The Supports: CreateCopy() means you can create the format, but only by 
 copying an existing dataset.  Formats supporting creation will have 
 Supports: Create().  You can get a broad listing of all formats like this:
 
 gdalinfo --formats
 
   SDTS (rov): SDTS Raster
   DTED (rwv): DTED Elevation Raster
   PNG (rwv): Portable Network Graphics
   JPEG (rwv): JPEG JFIF
   MEM (rw+): In Memory Raster
 ...
 
 The w means it supports at least CreateCopy(). The + means it supports 
 create+update.  
 
 Best regards,
 
 
 
 On Tue, Jul 16, 2013 at 10:14 PM, Nik Sands nix...@nixanz.com wrote:
 Can I use GDALCreate to create (and later write to) PNG images?
 If so, is PNG the correct string for GDALGetDriverByName?
 
 Otherwise, can somebody please let me know why the code below returns NULL 
 from GDALCreate (assigned to dstDS)?
 
 Advice much appreciated, as always.
 
 Thanks,
 Nik.
 
 
 
 GDALDriverH hDriver = GDALGetDriverByName(PNG);
 char **papszOptions = NULL;
 
 papszOptions = CSLSetNameValue( papszOptions, WORLDFILE, NO );
 papszOptions = CSLSetNameValue( papszOptions, ZLEVEL, 9 );
 
 GDALDatasetH dstDS = GDALCreate( hDriver, /var/tmp/image.png, 256, 
 256, 4, GDT_Float32, papszOptions );
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
 
 
 
 -- 
 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
 light and sound - activate the windows | http://pobox.com/~warmerdam
 and watch the world go round - Rush| Geospatial Software Developer

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Can GDALCreate be Used for PNG?

[Nik Sands]

Can I use GDALCreate to create (and later write to) PNG images?
If so, is PNG the correct string for GDALGetDriverByName?

Otherwise, can somebody please let me know why the code below returns NULL from 
GDALCreate (assigned to dstDS)?

Advice much appreciated, as always.

Thanks,
Nik.



GDALDriverH hDriver = GDALGetDriverByName(PNG);
char **papszOptions = NULL;

papszOptions = CSLSetNameValue( papszOptions, WORLDFILE, NO );
papszOptions = CSLSetNameValue( papszOptions, ZLEVEL, 9 );

GDALDatasetH dstDS = GDALCreate( hDriver, /var/tmp/image.png, 256, 
256, 4, GDT_Float32, papszOptions );
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Can't get colour table for GeoTIFF

[Nik Sands]

Hi!

I'm using the code below as part of a routine to warp images.  For most images 
it works fine.  However, for one of my users, their images are being converted 
from full colour to black and white which is not supposed to happen.  I've 
narrowed down the issue to the code below where 'hCT' remains NULL.  An example 
of one such source image can be downloaded at:

https://dl.dropboxusercontent.com/u/12436846/jrc_21.tiff

I guess I must be doing something wrong in my code, but can't figure it out.  
Could somebody please help me to understand how to do this correctly?

Ie, how to I get the colour table from the image linked to above, and set that 
colour table for my destination image?

Cheers,
Nik.



GDALColorTableH hCT = GDALGetRasterColorTable( GDALGetRasterBand(hSrcDS,1) );

if ( hCT == NULL )
NSLog(@Failed to get colour table.);
else
GDALSetRasterColorTable( GDALGetRasterBand(hDstDS,1), hCT );

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Too many points for GDALSuggestedWarpOutput with Ozi .map

[Nik Sands]

Thanks for the reply.  Just to clarify though, can you tell me what it is that 
is wrong about it?

I expect the user might come back to me and say, but it works fine in 
OziExplorer, which I don't have to test with. The projection 
Latitude/Longitude appears to be a valid Ozi projection, so I'm guessing that 
you mean it doesn't fit with the other data in the file?



On 05/12/2012, at 6:06 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 On 05/12/2012 03:53, Nik Sands wrote:
 Hi GDAL devs,
 
 I have a problem with GDALSuggestedWarpOutput producing an error.  It works 
 for most of the files I've thrown at it, but I have one file that a user has 
 sent me for which the error occurs.  The file in question can be downloaded 
 for testing at:  https://dl.dropbox.com/u/12436846/715lkmaps.zip
 
 The projection declared in the .map file is wrong.
 
 Jean-Claude

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Too many points for GDALSuggestedWarpOutput with Ozi .map

[Nik Sands]

Hi GDAL devs,

I have a problem with GDALSuggestedWarpOutput producing an error.  It works for 
most of the files I've thrown at it, but I have one file that a user has sent 
me for which the error occurs.  The file in question can be downloaded for 
testing at:  https://dl.dropbox.com/u/12436846/715lkmaps.zip

My code and the output are below.  GDALSuggestedWarpOutput produces the error:

ERROR 1: Too many points (13924 out of 13924) failed to transform, unable to 
compute output bounds.

Could somebody please explain how I can avoid this problem and warp the image 
correctly?

Thanks,
Nik.



CODE:

OSRImportFromEPSG(dstSRS, 3857 );
OSRExportToWkt( dstSRS, (char **)pszDstWKT );

void *hTransformArg = GDALCreateGenImgProjTransformer( hSrcDS, 
pszSrcWKT, NULL, pszDstWKT, FALSE, 0, 1 );
double adfDstGeoTransform[6];
int nPixels=0, nLines=0;

if ( GDALSuggestedWarpOutput( hSrcDS, GDALGenImgProjTransform, 
hTransformArg, adfDstGeoTransform, nPixels, nLines ) != CE_None )
{
NSLog(@Failed to get suggested warp output.);
return NO;
}


OUTPUT:

ERROR 1: Too many points (13924 out of 13924) failed to transform,
unable to compute output bounds.
Failed to get suggested warp output.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Cannot read UTM Ozi .map file

[Nik Sands]

Thanks for the reply.  Firstly, it did resolve my problem, so thanks very much 
for this information.

However, I don't get that warning with gdalinfo (see below).  But I set the 
environment variable in my code, and it did resolve the problem for me there 
which is all that matters, I guess.  :-)

I'm curious though, how does the quality of an image affect this?  I had 
assumed that transforms would work on on pixel x,y coordinates irrespective of 
the colour values of those pixels.

Anyhow, thanks again for your help.  Much appreciated.

Cheers,
Nik.


--
$ env | grep OZI
$ gdalinfo Cradle\ Mountain_ozf.map 
Driver: OZI/OziExplorer Image File
Files: Cradle Mountain_ozf.map
Size is 6535, 11880
Coordinate System is:
PROJCS[UTM Zone 55, Southern Hemisphere,
GEOGCS[GDA94,
DATUM[Geocentric_Datum_of_Australia_1994,
SPHEROID[GRS 1980,6378137,298.257222101,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6283]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
...
...
...
--


On 29/11/2012, at 10:08 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 Le 28/11/2012 22:54, Nik Sands a écrit :
 
 After applying the suggested patch, it no longer errors out in the same way, 
 however, I now get another error just a little further on in my code.
 
 -
 Failed to get geo-transform (error 3) for file:  Cradle Mountain_ozf.map
 -
 
 I'm afraid this is a bit beyond me, so if you can help, I'd be very grateful.
 
 Did you notice that gdalinfo reports the same error ?
 
 $ gdalinfo --debug on -noct Cradle\ Mountain_ozf.map
 GDAL: GDALLoadOziMapFile(Cradle Mountain_ozf.map) found file, wasn't able to 
 derive a first order geotransform.  Using points as GCPs.
 GDAL: GDALOpen(Cradle Mountain_ozf.map, this=0x155a4a0) succeeds as OZI.
 Driver: OZI/OziExplorer Image File
 GDAL: GDALDefaultOverviews::OverviewScan()
 Files: Cradle Mountain_ozf.map
 Size is 6535, 11880
 Coordinate System is `'
 GCP Projection =
 PROJCS[UTM Zone 55, Southern Hemisphere,
GEOGCS[GDA94,
DATUM[Geocentric_Datum_of_Australia_1994,
SPHEROID[GRS 1980,6378137,298.257222101,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6283]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4283]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,0],
PARAMETER[central_meridian,147],
PARAMETER[scale_factor,0.9996],
PARAMETER[false_easting,50],
PARAMETER[false_northing,1000],
UNIT[Meter,1]]
 GCP[  0]: Id=, Info=
  (749,50) - (41,5397000,0)
 GCP[  1]: Id=, Info=
  (4697,38) - (415000,5397000,0)
 GCP[  2]: Id=, Info=
  (4668,11128) - (415000,5383000,0)
 GCP[  3]: Id=, Info=
  (757,11164) - (41,5383000,0)
 GCP[  4]: Id=, Info=
  (1532,5600) - (411000,539,0)
 GCP[  5]: Id=, Info=
  (3112,1611) - (413000,5395000,0)
 GCP[  6]: Id=, Info=
  (3894,7962) - (414000,5387000,0)
 GCP[  7]: Id=, Info=
  (3890,4794) - (414000,5391000,0)
 GCP[  8]: Id=, Info=
  (2318,9563) - (412000,5385000,0)
 Corner Coordinates:
 Upper Left  (0.0,0.0)
 Lower Left  (0.0,11880.0)
 Upper Right ( 6535.0,0.0)
 Lower Right ( 6535.0,11880.0)
 Center  ( 3267.5, 5940.0)
 Band 1 Block=64x64 Type=Byte, ColorInterp=Palette
  Overviews: 1634x2970, 654x1188, 327x594, 163x297, 65x119
  Color Table (RGB with 256 entries)
 GDAL: GDALClose(Cradle Mountain_ozf.map, this=0x155a4a0)
 
 
 This is because the quality of the scan is very bad. Look at the text No 
 Camping Allowed, that appears almost twice. You can ask GDAL to ignore the 
 problem by setting the environment variable OZI_APPROX_GEOTRANSFORM to the 
 value YES (In this case, you can drop the patch I sent you yesterday) :
 
 $ OZI_APPROX_GEOTRANSFORM=YES gdalinfo -noct Cradle\ Mountain_ozf.map Driver: 
 OZI/OziExplorer Image File
 Files: Cradle Mountain_ozf.map
 Size is 6535, 11880
 Coordinate System is:
 PROJCS[UTM Zone 55, Southern Hemisphere,
GEOGCS[GDA94,
DATUM[Geocentric_Datum_of_Australia_1994,
SPHEROID[GRS 1980,6378137,298.257222101,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6283]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4283]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,0],
PARAMETER[central_meridian,147],
PARAMETER[scale_factor,0.9996],
PARAMETER[false_easting,50],
PARAMETER

Re: [gdal-dev] Cannot read UTM Ozi .map file

[Nik Sands]

Hi Jean-Claude,

After applying the suggested patch, it no longer errors out in the same way, 
however, I now get another error just a little further on in my code.

CODE:
-
char *srcWKT = (char *)GDALGetProjectionRef( hDataset );

if ( srcWKT == NULL || strlen(srcWKT) = 0 )
{
NSLog(@Failed to get WKT (%s) from file:  %@, srcWKT, [path 
lastPathComponent]);

return NULL;
}

OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(srcWKT);
OGRSpatialReferenceH llSRS = OSRCloneGeogCS(srcSRS);

if ( ! llSRS )
{
NSLog(@Failed to get geographic node of source spatial 
reference system:);
printf(\n%s\n\n, srcWKT);
NSLog(@(path:  %@, path);

return nil;
}

OGRCoordinateTransformationH ct = OCTNewCoordinateTransformation( 
srcSRS, llSRS );

if ( ! ct )
{
char *srcWKT;
char *llWKT;
OSRExportToWkt(srcSRS, srcWKT);
OSRExportToWkt(llSRS, llWKT);

NSLog(@Failed to create coordinate transformation between 
source and lat/lon spatial reference systems:);
printf(\n%s\n\n, srcWKT);
printf(\n%s\n\n, llWKT);

return nil;
}

double gt[6];
CPLErr err = GDALGetGeoTransform( hDataset, gt );

if ( err != CE_None )
{
NSLog(@Failed to get geo-transform (error %d) for file:  %@, 
err, [path lastPathComponent]);
return NULL;
}
-

OUTPUT:
-
Failed to get geo-transform (error 3) for file:  Cradle Mountain_ozf.map
-

I'm afraid this is a bit beyond me, so if you can help, I'd be very grateful.

(The ozf/map files are at:  
https://dl.dropbox.com/u/12436846/Cradle%20Mountain.zip .)

Cheers,
Nik.


On 29/11/2012, at 3:54 AM, Jean-Claude Repetto jrepe...@free.fr wrote:

 Le 28/11/2012 05:16, Nik Sands a écrit :
 Hi GDAL-dev,
 
 I've recently re-compiled GDAL from the trunk after the patch to fix UTM ozi 
 files was applied.  This has worked well for most UTM files I've tried so 
 far, but I've come across one that produces a strange error in my code, but 
 works OK with gdalinfo.  The following code fails for a dataset generated 
 from this .map file and debugging indicates that 'srcWKT' is an empty string 
 (), and not NULL.
 
 Hi Nik,
 
 Try to apply the following patch :
 
 
 Index: frmts/ozi/ozidataset.cpp
 ===
 --- frmts/ozi/ozidataset.cpp  (révision 25261)
 +++ frmts/ozi/ozidataset.cpp  (copie de travail)
 @@ -746,7 +746,8 @@
 
 const char* OZIDataset::GetProjectionRef()
 {
 -return (pszWKT  nGCPCount == 0) ? pszWKT : ;
 +//return (pszWKT  nGCPCount == 0) ? pszWKT : ;
 +return pszWKT;
 }
 
 //
 
 
 Jean-Claude
 ___
 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] Cannot read UTM Ozi .map file

[Nik Sands]

Hi GDAL-dev,

I've recently re-compiled GDAL from the trunk after the patch to fix UTM ozi 
files was applied.  This has worked well for most UTM files I've tried so far, 
but I've come across one that produces a strange error in my code, but works OK 
with gdalinfo.  The following code fails for a dataset generated from this .map 
file and debugging indicates that 'srcWKT' is an empty string (), and not 
NULL.

gdalinfo works correctly though (as does gdal_translate) and its output is 
shown below.

This file pair can be downloaded for testing in a zip from:
https://dl.dropbox.com/u/12436846/Cradle%20Mountain.zip

-
GDALDatasetH  hDataset = GDALOpen( [path 
cStringUsingEncoding:NSASCIIStringEncoding], GA_ReadOnly );

if ( hDataset == NULL )
{
NSLog(@Failed to get dataset from file:  %@, [path 
lastPathComponent]);

return NULL;
}

// Get Source coordinate system.

char *srcWKT = (char *)GDALGetProjectionRef( hDataset );

if ( srcWKT == NULL || strlen(srcWKT) = 0 )
{
NSLog(@Failed to get WKT (%s) from file:  %@, srcWKT, [path 
lastPathComponent]);

return NULL;
}

Failed to get WKT () from file:  Cradle Mountain_ozf.map



$ ./gdalinfo /Users/nsands/Public/map/Test/Cradle\ Mountain/Cradle\ 
Mountain_ozf.map
Driver: OZI/OziExplorer Image File
Files: /Users/nsands/Public/map/Test/Cradle Mountain/Cradle Mountain_ozf.map
Size is 6535, 11880
Coordinate System is `'
GCP Projection = 
PROJCS[UTM Zone 55, Southern Hemisphere,
GEOGCS[GDA94,
DATUM[Geocentric_Datum_of_Australia_1994,
SPHEROID[GRS 1980,6378137,298.257222101,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6283]],

etc...

Any help with where I'm going wrong would be much appreciated.

Cheers,
Nik.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

Thanks very much for looking into this.  I've filed the bug at 
https://trac.osgeo.org/gdal/ticket/4894



On 13/11/2012, at 10:02 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 Le 13/11/2012 01:03, Nik Sands a écrit :
 Thanks for the replies so far.  Unfortunately, adding a 3rd calibration 
 point to the .map file has not helped.  Of course I'm assuming that the 
 added calibration point is valid (eg, I tried the one suggested below, which 
 looks like it should be OK).
 
 Does anybody have any other suggestions as to why this .map file cannot be 
 interpreted correctly by GDAL?
 
 Is it a bug, or an incomplete .map parsing implementation, or am I doing 
 something wrong?
 
 Hi Nik,
 
 I have looked at the Ozi driver source code, and found that the UTM 
 projection is not supported.
 Please file a bug (https://trac.osgeo.org/gdal/), provide some sample files, 
 and I'll try to improve the driver.
 
 Jean-Claude
 
 ___
 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] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

I will try but don't have any Ozi products  and am not confident I can create 
one that is legitimate.  The same may apply to the user who raised the issue 
but I will check. 

On 12/11/2012, at 7:02 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 On 12/11/2012 08:16, Nik Sands wrote:
 Is that limitation actually built into GDAL?
 Because 2-point .map files are not uncommon, and so long as the two points 
 are both different in both axes, then there should be no reason why a 3rd 
 point in required (especially in UTM).
 
 Nik.
 
 Have you checked if adding a third point solves your problem ?
 
 Jean-Claude
 ___
 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] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

I appreciate that (hence pasting the content of the file in my original email). 
 However, I don't know how to be certain that the text I put into the file 
represents something that makes sense. 

However, as I said I will give it a shot (when I get back to my computer).

On 12/11/2012, at 7:52 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 Le 12/11/2012 09:10, Nik Sands a écrit :
 I will try but don't have any Ozi products  and am not confident I can 
 create one that is legitimate.  The same may apply to the user who raised 
 the issue but I will check.
 
 You don't need Ozi, only a text editor.
 
 ___
 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] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

Thanks for the replies so far.  Unfortunately, adding a 3rd calibration point 
to the .map file has not helped.  Of course I'm assuming that the added 
calibration point is valid (eg, I tried the one suggested below, which looks 
like it should be OK).

Does anybody have any other suggestions as to why this .map file cannot be 
interpreted correctly by GDAL?

Is it a bug, or an incomplete .map parsing implementation, or am I doing 
something wrong?

Cheers,
Nik.


On 12/11/2012, at 11:38 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote:

 Nik Sands nixanz at nixanz.com writes:
 
 
 I appreciate that (hence pasting the content of the file in my original
 email).  However, I don't know how to
 be certain that the text I put into the file represents something that makes
 sense. 
 
 However, as I said I will give it a shot (when I get back to my computer).
 
 This is my guess:
 Point01,xy,0,0,in, deg,,,,,,, grid,
 55,21.09067205,557.7412442,S
 Point02,xy, 1000, 1000,in, deg,,,,,,, grid,
 55,223259.16350298,5566740.6684133,S
 Point03,xy,0, 1000,in, deg,,,,,,, grid,
 55,21.09067205,5566740.6684133,S
 
 Having two calibration points in OziExplorer .map files is not at all uncommon
 and with digital maps and orthophotos in some projected coordinate system 
 there
 is no need to have more. Same situation basically than with ESRI world file
 georeferencing when just one anchor point and pixel size is given.
 http://www.oziexplorer3.com/eng/features/features_moreinfo3.html
 
 -Jukka Rahkonen-
 
 ___
 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] Cannot get spatial reference system from ozi file

[Nik Sands]

Unfortunately, I did not get any reply to my message about GDAL being unable to 
georeference an .ozf2 image using an ozi .map file a user sent me (see below).  
Is there anybody who could take a look and help me out with this?

Please let me know if there is more information that I can provide in order to 
progress this issue.

Cheers,
Nik.


On 07/11/2012, at 11:11 AM, Nik Sands nix...@nixanz.com wrote:

 Hi all,
 
 My application is reading in ozi file pairs (.ozf2/.map), warping them and 
 saving out as GeoTIFF or other file formats using GDAL.  It works fine for my 
 own ozf files, but not for the files sent to me by one of my users (who 
 apparently has a large number of files they want to use).
 
 It has been unable to get a useful spatial reference system from the ozi file 
 pair (.ozf2/.map) sent to me (.map content below).  The following code:
 
 --
   OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(pszSrcWKT);
   char *srcWKT;
 
   OSRExportToWkt(srcSRS, srcWKT);
   printf(\n%s\n\n, srcWKT);
 --
 
 produces the following output:
 
 --
   LOCAL_CS[unnamed,UNIT[unknown,1]]
 --
 
 Can somebody please help me to use GDAL to obtain a valid spatial reference 
 system from this .map file (content below)?
 
 Note that I'm using a fairly recent build of GDAL trunk that includes all the 
 ozi datums, etc, including Australian Geodetic 1966 and it is able to get a 
 valid SRS from my own files that use the same ozi datum.
 
 The complete content of the ozi .map file in question is below.
 
 Thanks in anticipation,
 Nik.
 
 
 OziExplorer Map Data File Version 2.2
 r2256.jgw
 D:\Documents and Settings\nelsonp\My Documents\General 
 Admin\Personal\Tasmania 1 to 25,000\North West OZF2\r2256.ozf2
 1 ,Map Code,
 Australian Geodetic 1966,WGS 84,   0.,   0.,WGS 84
 Reserved 1
 Reserved 2
 Magnetic Variation,,,E
 Map Projection,(UTM) Universal Transverse 
 Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
 Point01,xy,0,0,in, deg,,,,,,, grid, 
 55,21.09067205,557.7412442,S
 Point02,xy, 1000, 1000,in, deg,,,,,,, grid, 
 55,223259.16350298,5566740.6684133,S
 Point03,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point04,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point05,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point06,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point07,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point08,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point09,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point10,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point11,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point12,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point13,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point14,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point15,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point16,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point17,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point18,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point19,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point20,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point21,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point22,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point23,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point24,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point25,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point26,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point27,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point28,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point29,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point30,xy, , ,in, deg,,,,,,, grid

Re: [gdal-dev] Cannot get spatial reference system from ozi file

[Nik Sands]

I still don't have any resolution to this issue, but thanks to feedback from 
one list reader, I've been prompted to find out some more information...

gdalinfo produces the following output, which is contrary to what my 
application produces:

Coordinate System is `LOCAL_CS[Ozi projection (UTM) Universal 
Transverse Mercator,UNIT[Meter,1]]'

So I need to figure out why my application is not getting this from the same 
file.

Note that my build of GDAL is from a recent version of the trunk (September, 
2012):

$ gdalinfo --version
GDAL 2.0dev, released 2011/12/29

And was built for Mac OS X using the following configure (which I noted at the 
time for future reference as it took me ages to get this to work  :-):

./configure \
--with-macosx-framework \
--with-threads \
--disable-static \
--without-pg \
--without-grass \
--without-libgrass \
--without-cfitsio \
--without-pcraster \
--without-netcdf \
--without-ogdi \
--without-fme \
--without-hdf4 \
--without-hdf5 \
--without-jasper \
--without-kakadu \
--without-bsb \
--without-grib \
--without-mysql \
--without-ingres \
--without-xerces \
--without-odbc \
--without-curl \
--without-sqlite3 \
--without-idb \
--without-sde \
CFLAGS=-Os -arch i386 -arch x86_64 \
CXXFLAGS=-Os -arch i386 -arch x86_64 \
LDFLAGS=-arch i386 -arch x86_64



On 07/11/2012, at 11:11 AM, Nik Sands nix...@nixanz.com wrote:

 Hi all,
 
 My application is reading in ozi file pairs (.ozf2/.map), warping them and 
 saving out as GeoTIFF or other file formats using GDAL.  It works fine for my 
 own ozf files, but not for the files sent to me by one of my users (who 
 apparently has a large number of files they want to use).
 
 It has been unable to get a useful spatial reference system from the ozi file 
 pair (.ozf2/.map) sent to me (.map content below).  The following code:
 
 --
   OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(pszSrcWKT);
   char *srcWKT;
 
   OSRExportToWkt(srcSRS, srcWKT);
   printf(\n%s\n\n, srcWKT);
 --
 
 produces the following output:
 
 --
   LOCAL_CS[unnamed,UNIT[unknown,1]]
 --
 
 Can somebody please help me to use GDAL to obtain a valid spatial reference 
 system from this .map file (content below)?
 
 Note that I'm using a fairly recent build of GDAL trunk that includes all the 
 ozi datums, etc, including Australian Geodetic 1966 and it is able to get a 
 valid SRS from my own files that use the same ozi datum.
 
 The complete content of the ozi .map file in question is below.
 
 Thanks in anticipation,
 Nik.
 
 
 OziExplorer Map Data File Version 2.2
 r2256.jgw
 D:\Documents and Settings\nelsonp\My Documents\General 
 Admin\Personal\Tasmania 1 to 25,000\North West OZF2\r2256.ozf2
 1 ,Map Code,
 Australian Geodetic 1966,WGS 84,   0.,   0.,WGS 84
 Reserved 1
 Reserved 2
 Magnetic Variation,,,E
 Map Projection,(UTM) Universal Transverse 
 Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
 Point01,xy,0,0,in, deg,,,,,,, grid, 
 55,21.09067205,557.7412442,S
 Point02,xy, 1000, 1000,in, deg,,,,,,, grid, 
 55,223259.16350298,5566740.6684133,S
 Point03,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point04,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point05,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point06,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point07,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point08,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point09,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point10,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point11,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point12,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point13,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point14,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point15,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point16,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point17,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point18,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point19,xy, , ,in, deg,,,,,,, grid,   ,   
 ,   ,
 Point20,xy, , ,in, deg,,,,,,, grid

Re: [gdal-dev] Cannot get spatial reference system from ozi file

[Nik Sands]

Please ignore this thread.  I've finally figured out that it was an error in 
code on my part.  I thought that my code was reading the .map file, when in 
fact it was reading the GeoTIFF file that had been converted from the .map/ozf2 
earlier in the program.  My humble apologies.

(I may post a new thread later regarding why the GeoTIFF is not georeferenced 
correctly).

Thanks for your tolerance.  :-)
Nik.


On 12/11/2012, at 12:45 PM, Nik Sands nix...@nixanz.com wrote:

 I still don't have any resolution to this issue, but thanks to feedback from 
 one list reader, I've been prompted to find out some more information...
 
 gdalinfo produces the following output, which is contrary to what my 
 application produces:
 
   Coordinate System is `LOCAL_CS[Ozi projection (UTM) Universal 
 Transverse Mercator,UNIT[Meter,1]]'
 
 So I need to figure out why my application is not getting this from the same 
 file.
 
 Note that my build of GDAL is from a recent version of the trunk (September, 
 2012):
 
   $ gdalinfo --version
   GDAL 2.0dev, released 2011/12/29
 
 And was built for Mac OS X using the following configure (which I noted at 
 the time for future reference as it took me ages to get this to work  :-):
 
 ./configure \
 --with-macosx-framework \
 --with-threads \
 --disable-static \
 --without-pg \
 --without-grass \
 --without-libgrass \
 --without-cfitsio \
 --without-pcraster \
 --without-netcdf \
 --without-ogdi \
 --without-fme \
 --without-hdf4 \
 --without-hdf5 \
 --without-jasper \
 --without-kakadu \
 --without-bsb \
 --without-grib \
 --without-mysql \
 --without-ingres \
 --without-xerces \
 --without-odbc \
 --without-curl \
 --without-sqlite3 \
 --without-idb \
 --without-sde \
 CFLAGS=-Os -arch i386 -arch x86_64 \
 CXXFLAGS=-Os -arch i386 -arch x86_64 \
 LDFLAGS=-arch i386 -arch x86_64
 
 
 
 On 07/11/2012, at 11:11 AM, Nik Sands nix...@nixanz.com wrote:
 
 Hi all,
 
 My application is reading in ozi file pairs (.ozf2/.map), warping them and 
 saving out as GeoTIFF or other file formats using GDAL.  It works fine for 
 my own ozf files, but not for the files sent to me by one of my users (who 
 apparently has a large number of files they want to use).
 
 It has been unable to get a useful spatial reference system from the ozi 
 file pair (.ozf2/.map) sent to me (.map content below).  The following code:
 
 --
  OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(pszSrcWKT);
  char *srcWKT;
 
  OSRExportToWkt(srcSRS, srcWKT);
  printf(\n%s\n\n, srcWKT);
 --
 
 produces the following output:
 
 --
  LOCAL_CS[unnamed,UNIT[unknown,1]]
 --
 
 Can somebody please help me to use GDAL to obtain a valid spatial reference 
 system from this .map file (content below)?
 
 Note that I'm using a fairly recent build of GDAL trunk that includes all 
 the ozi datums, etc, including Australian Geodetic 1966 and it is able to 
 get a valid SRS from my own files that use the same ozi datum.
 
 The complete content of the ozi .map file in question is below.
 
 Thanks in anticipation,
 Nik.
 
 
 OziExplorer Map Data File Version 2.2
 r2256.jgw
 D:\Documents and Settings\nelsonp\My Documents\General 
 Admin\Personal\Tasmania 1 to 25,000\North West OZF2\r2256.ozf2
 1 ,Map Code,
 Australian Geodetic 1966,WGS 84,   0.,   0.,WGS 84
 Reserved 1
 Reserved 2
 Magnetic Variation,,,E
 Map Projection,(UTM) Universal Transverse 
 Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
 Point01,xy,0,0,in, deg,,,,,,, grid, 
 55,21.09067205,557.7412442,S
 Point02,xy, 1000, 1000,in, deg,,,,,,, grid, 
 55,223259.16350298,5566740.6684133,S
 Point03,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point04,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point05,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point06,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point07,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point08,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point09,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point10,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point11,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point12,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point13,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point14,xy, , ,in, deg,,,,,,, grid,   ,  
  ,   ,
 Point15,xy, , ,in, deg

[gdal-dev] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

Hi,

I have two sets of Ozi .map files (and corresponding ozf2 files) that behave 
very differently when processed by GDAL using the following code:


char *srcWKT = (char *)GDALGetProjectionRef( hSrcDS );

if ( srcWKT == NULL || strlen(srcWKT) = 0 )
return NO;

printf(srcWKT:\n\n%s\n\n, srcWKT);

OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(srcWKT);

if ( ! srcSRS )
{
printf(FAILED TO GET SOURCE SPATIAL REFERENCE SYSTEM.\n);
}


The first set of .map files work fine, producing output such as this:


srcWKT:

PROJCS[unnamed,GEOGCS[AGD66,DATUM[Australian_Geodetic_Datum_1966,SPHEROID[Australian
 National 
Spheroid,6378160,298.25,AUTHORITY[EPSG,7003]],TOWGS84[-117.808,-51.536,137.784,0.303,0.446,0.234,-0.29],AUTHORITY[EPSG,6202]],PRIMEM[Greenwich,0,AUTHORITY[EPSG,8901]],UNIT[degree,0.0174532925199433,AUTHORITY[EPSG,9122]],AUTHORITY[EPSG,4202]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,147],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,1000],UNIT[Meter,1]]


However, for the second set I cannot get a spatial reference system and I get 
this output:


srcWKT:

LOCAL_CS[Ozi projection (UTM) Universal Transverse 
Mercator,UNIT[Meter,1]]

FAILED TO GET SOURCE SPATIAL REFERENCE SYSTEM.


Please help me figure out why the two sets of .map files behave so differently. 
 In particular, how can I get a spatial reference system for the failing .map 
files?

(Content of two example files are below.  First one is OK, second one fails.  
Let me know if I can provide any further information.)

Thanks in anticipation,
Nik.


OK:

OziExplorer Map Data File Version 2.2
R2257
D:\GPS and Mapping\OziExplorer\Maps\Tassie 25k\R2257.ozf2
1 ,Map Code,
Australian Geodetic 1966,,   0.,   0.,WGS 84
Reserved 1
Reserved 2
Magnetic Variation,,,E
Map Projection,Transverse Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
Point01,xy,0,0,in, deg,,,,,,, grid,   
,22.77942328,557.7247315,
Point02,xy,1,0,in, deg,,,,,,, grid,   
,220004.03889463,557.7247315,
Point03,xy,0,1,in, deg,,,,,,, grid,   
,22.77942328,5579996.4652601,
Point04,xy,1,1,in, deg,,,,,,, grid,   
,220004.03889463,5579996.4652601,
Point05,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point06,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point07,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point08,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point09,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point10,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point11,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point12,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point13,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point14,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point15,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point16,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point17,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point18,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point19,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point20,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point21,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point22,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point23,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point24,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point25,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point26,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point27,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point28,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point29,xy, , ,in, deg,,

Re: [gdal-dev] No Spatial Reference System from UTM Ozi .map file

[Nik Sands]

Is that limitation actually built into GDAL?

Because 2-point .map files are not uncommon, and so long as the two points are 
both different in both axes, then there should be no reason why a 3rd point in 
required (especially in UTM).

Cheers,
Nik.


On 12/11/2012, at 6:13 PM, Jean-Claude Repetto jrepe...@free.fr wrote:

 On 12/11/2012 05:02, Nik Sands wrote:
 
 Please help me figure out why the two sets of .map files behave so 
 differently.  In particular, how can I get a spatial reference system for 
 the failing .map files?
 (Content of two example files are below.  First one is OK, second one fails. 
  Let me know if I can provide any further information.)
 
 Hi,
 I think it is because the second calibration file has only two
 calibration points. Three points are probably necessary.
 
 Jean-Claude
 
 ___
 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] Cannot get spatial reference system from ozi file

[Nik Sands]

Hi all,

My application is reading in ozi file pairs (.ozf2/.map), warping them and 
saving out as GeoTIFF or other file formats using GDAL.  It works fine for my 
own ozf files, but not for the files sent to me by one of my users (who 
apparently has a large number of files they want to use).

It has been unable to get a useful spatial reference system from the ozi file 
pair (.ozf2/.map) sent to me (.map content below).  The following code:

--
OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(pszSrcWKT);
char *srcWKT;

OSRExportToWkt(srcSRS, srcWKT);
printf(\n%s\n\n, srcWKT);
--

produces the following output:

--
LOCAL_CS[unnamed,UNIT[unknown,1]]
--

Can somebody please help me to use GDAL to obtain a valid spatial reference 
system from this .map file (content below)?

Note that I'm using a fairly recent build of GDAL trunk that includes all the 
ozi datums, etc, including Australian Geodetic 1966 and it is able to get a 
valid SRS from my own files that use the same ozi datum.

The complete content of the ozi .map file in question is below.

Thanks in anticipation,
Nik.


OziExplorer Map Data File Version 2.2
r2256.jgw
D:\Documents and Settings\nelsonp\My Documents\General Admin\Personal\Tasmania 
1 to 25,000\North West OZF2\r2256.ozf2
1 ,Map Code,
Australian Geodetic 1966,WGS 84,   0.,   0.,WGS 84
Reserved 1
Reserved 2
Magnetic Variation,,,E
Map Projection,(UTM) Universal Transverse 
Mercator,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No
Point01,xy,0,0,in, deg,,,,,,, grid, 
55,21.09067205,557.7412442,S
Point02,xy, 1000, 1000,in, deg,,,,,,, grid, 
55,223259.16350298,5566740.6684133,S
Point03,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point04,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point05,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point06,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point07,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point08,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point09,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point10,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point11,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point12,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point13,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point14,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point15,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point16,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point17,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point18,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point19,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point20,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point21,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point22,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point23,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point24,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point25,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point26,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point27,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point28,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point29,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Point30,xy, , ,in, deg,,,,,,, grid,   , 
  ,   ,
Projection Setup, 0.0,  -120.0, 0.99960,
0.00, -400.00,34.0,40.5,,,
Map Feature = MF ; Map Comment = MC These follow if they exist
Track File = TF  These follow if they exist
Moving Map Parameters = MM?These follow if they exist
MM0,Yes
MMPNUM,4
MMPXY,1,0,0
MMPXY,2,6136,0
MMPXY,3,6136,3069
MMPXY,4,0,3069
MMPLL,1, 143.721340, -39.973660
MMPLL,2, 143.955261, -39.980047
MMPLL,3, 143.951253, -40.070068

Re: [gdal-dev] Get list of all available SRS

[Nik Sands]

Thanks Frank.  Sorting/organisation is not a big deal in this case.  They will 
be presented in a list which dynamically changes according to search text as it 
is typed.  So a simple alphabetical sort should be fine if I can't come up with 
any better scheme.


On 21/09/2012, at 12:49 PM, Frank Warmerdam warmer...@pobox.com wrote:

 On 12-09-20 07:11 PM, Nik Sands wrote:
 Is there a way to get a list (eg, array) of all Spatial Reference Systems 
 currently available to GDAL (eg, all those defined in files in GDAL_DATA 
 directory)?
 
 In my GUI application, I'd like to be able to present my users with a list 
 of SRS to choose from, but I'm not sure how to generate such a list.
 
 Nik,
 
 GDAL does not provide any services to get the SRS list but you can
 access the gdal/data/pcs.csv and gdal/data/gcs.csv files yourself
 fairly easily to get the names and EPSG identifiers.  What this does
 not help with is a logical organization of the SRSes which can be
 helpful in a GUI since there are a lot.
 
 Best regards,
 -- 
 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
 light and sound - activate the windows | http://home.gdal.org/warmerda
 and watch the world go round - Rush| Geospatial Software Developer
 
 ___
 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] Warp results in wrong colours

[Nik Sands]

My application is doing a warp using GDAL which works fine for some source 
images, but with others results in an image with the colours all wrong (eg, 
water areas are red instead of blue).  I'm guessing that the RGB(A) (bands?) 
are getting mixed up somehow, but I really don't know where to start looking 
after my web searches produced nothing useful.

The problem only occurs for some images.  So far the only thing that the 
problem source images have in common is that they were all converted from ECW 
to GeoTIFF by 'gdal_translate' (with no options).  The source GeoTIFF files 
have all the correct colours before the warp.

The code I'm using is based on the GDAL warp API tutorial and is included below.

I'd be grateful if somebody could point me in the right direction.

Thanks in advance,
Nik.



void *hTransformArg = GDALCreateGenImgProjTransformer( hSrcDS, 
pszSrcWKT, NULL, pszDstWKT, FALSE, 0, 1 );

if ( hTransformArg == NULL )
{
NSLog(@Failed to create transformation.);
return NO;
}

// Get approximate output georeferenced bounds and resolution 
for file.

double adfDstGeoTransform[6];
int nPixels=0, nLines=0;

if ( GDALSuggestedWarpOutput( hSrcDS, GDALGenImgProjTransform, 
hTransformArg, adfDstGeoTransform, nPixels, nLines ) != CE_None )
{
NSLog(@Failed to get suggested warp output.);
return NO;
}

GDALDestroyGenImgProjTransformer( hTransformArg );

// Create the output file.

NSLog(@source band count:  %d, GDALGetRasterCount(hSrcDS));

hDstDS = GDALCreate( hDriver, [dstPath 
cStringUsingEncoding:NSASCIIStringEncoding], nPixels, nLines, 
GDALGetRasterCount(hSrcDS) + 1, eDT, NULL );

if ( hDstDS == NULL )
{
NSLog(@Failed to open destination file '%@' with 
GDALCreate()., [dstPath lastPathComponent]);
return NO;
}

// Write out the projection definition.

GDALSetProjection( hDstDS, pszDstWKT );
GDALSetGeoTransform( hDstDS, adfDstGeoTransform );

// Copy the color table, if required.

GDALColorTableH hCT;

hCT = GDALGetRasterColorTable( GDALGetRasterBand(hSrcDS,1) );
if( hCT != NULL )
GDALSetRasterColorTable( GDALGetRasterBand(hDstDS,1), 
hCT );

// Setup warp options.

GDALWarpOptions *psWarpOptions = GDALCreateWarpOptions();

psWarpOptions-hSrcDS = hSrcDS;
psWarpOptions-hDstDS = hDstDS;
psWarpOptions-nBandCount = 1;
psWarpOptions-panSrcBands =
(int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
psWarpOptions-panSrcBands[0] = 1;
psWarpOptions-panDstBands =
(int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
psWarpOptions-panDstBands[0] = 1;
psWarpOptions-pfnProgress = reportWarpProgress;
psWarpOptions-nDstAlphaBand = GDALGetRasterCount(hSrcDS) + 1;

// Establish reprojection transformer.

psWarpOptions-pTransformerArg =
GDALCreateGenImgProjTransformer( hSrcDS,

GDALGetProjectionRef(hSrcDS),

hDstDS,

GDALGetProjectionRef(hDstDS),

FALSE, 0.0, 1 );
psWarpOptions-pfnTransformer = GDALGenImgProjTransform;

// Initialize and execute the warp operation.

GDALWarpOperationH oOperation = GDALCreateWarpOperation( 
psWarpOptions );

GDALChunkAndWarpImage( oOperation, 0, 0,
  GDALGetRasterXSize( 
hDstDS ),
  GDALGetRasterYSize( 
hDstDS ) );
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Warp results in wrong colours

[Nik Sands]

Hi Even,

Thanks very much for your assistance.  I think I'm understanding this better 
now.  I've changed the relevant portion of the code to what I've copied in here 
and it seems to work now.  I do admit that I'm finding it hard to get my head 
around all this so I'd be grateful if somebody could let me know if I've done 
anything wrong (code below).  It appears to work correctly with all the images 
I've tried so far.

psWarpOptions-nBandCount = GDALGetRasterCount(hSrcDS);
psWarpOptions-panSrcBands = (int *) CPLMalloc(sizeof(int) * 
psWarpOptions-nBandCount );
psWarpOptions-panDstBands = (int *) CPLMalloc(sizeof(int) * 
psWarpOptions-nBandCount );

for ( int i = 0; i  psWarpOptions-nBandCount; i++ )
{
psWarpOptions-panSrcBands[i] = i+1;
psWarpOptions-panDstBands[i] = i+1;
}

In any case, I'm very grateful to the people who've developed GDAL and who are 
supporting it so well.  I'll certainly be donating using the button at 
http://www.osgeo.org/ as soon as I make anything from my new application.


On 24/09/2012, at 7:47 PM, Even Rouault even.roua...@mines-paris.org wrote:

 Selon Nik Sands nix...@nixanz.com:
 
 My application is doing a warp using GDAL which works fine for some source
 images, but with others results in an image with the colours all wrong (eg,
 water areas are red instead of blue).  I'm guessing that the RGB(A) (bands?)
 are getting mixed up somehow, but I really don't know where to start looking
 after my web searches produced nothing useful.
 
 The problem only occurs for some images.  So far the only thing that the
 problem source images have in common is that they were all converted from ECW
 to GeoTIFF by 'gdal_translate' (with no options).  The source GeoTIFF files
 have all the correct colours before the warp.
 
 The code I'm using is based on the GDAL warp API tutorial and is included
 below.
 
 I'd be grateful if somebody could point me in the right direction.
 
 The following snippet only works for single band images. If you have 
 presumably
 RGB images, you must set the nBandCount to 3 and initialize panSrcBands and
 panDstBands appropriately.
 
   psWarpOptions-nBandCount = 1;
   psWarpOptions-panSrcBands =
   (int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
   psWarpOptions-panSrcBands[0] = 1;
   psWarpOptions-panDstBands =
   (int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
   psWarpOptions-panDstBands[0] = 1;

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Get list of all available SRS

[Nik Sands]

Is there a way to get a list (eg, array) of all Spatial Reference Systems 
currently available to GDAL (eg, all those defined in files in GDAL_DATA 
directory)?

In my GUI application, I'd like to be able to present my users with a list of 
SRS to choose from, but I'm not sure how to generate such a list.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Warp to GeoTIFF with Transparency?

[Nik Sands]

I'm very new to GDAL so please be gentle.  My searching has found many 
references to this problem, but no complete solutions that are explained 
clearly enough for me to work through.

I'm using the GDAL API to read in a source image (could be from a variety of 
formats), warp it to Spherical Mercator, and then write out the reprojected 
image as a GeoTIFF.  I would like the parts of the warped TIFF that are not 
included in the original image to be represented by fully transparent pixels 
instead of the black pixels that are being generated.

I've set ALPHA to YES in the warp options but this has not helped.  I've 
also tried adding an extra transparent band, but this made the entire output 
image transparent.

Can anybody please explain in very simple terms (for a complete GDAL novice) 
how to go about this?

The relevant portion of the code that I'm currently using is below (based 
largely on the GDAL warp tutorial).

Thanks in anticipation,
Nik.


void *hTransformArg = GDALCreateGenImgProjTransformer( hSrcDS, 
pszSrcWKT, NULL, pszDstWKT, FALSE, 0, 1 );

if ( hTransformArg == NULL )
{
NSLog(@Failed to create transformation.);
return NULL;
}

// Get approximate output georeferenced bounds and resolution 
for file.

double adfDstGeoTransform[6];
int nPixels=0, nLines=0;

if ( GDALSuggestedWarpOutput( hSrcDS, GDALGenImgProjTransform, 
hTransformArg, adfDstGeoTransform, nPixels, nLines ) != CE_None )
{
NSLog(@Failed to get suggested warp output.);
return NULL;
}

GDALDestroyGenImgProjTransformer( hTransformArg );

// Create the output file.

char **papszOptions = NULL;

papszOptions = CSLSetNameValue( papszOptions, ALPHA, YES );

hDstDS = GDALCreate( hDriver, [dstPath 
cStringUsingEncoding:NSASCIIStringEncoding], nPixels, nLines, 
GDALGetRasterCount(hSrcDS), eDT, papszOptions );

if ( hDstDS == NULL )
{
NSLog(@Failed to open destination file '%@' with 
GDALCreate()., [dstPath lastPathComponent]);
return NULL;
}

// Write out the projection definition.

GDALSetProjection( hDstDS, pszDstWKT );
GDALSetGeoTransform( hDstDS, adfDstGeoTransform );

// Copy the color table, if required.

GDALColorTableH hCT;

hCT = GDALGetRasterColorTable( GDALGetRasterBand(hSrcDS,1) );
if( hCT != NULL )
GDALSetRasterColorTable( GDALGetRasterBand(hDstDS,1), 
hCT );

// Setup warp options.

GDALWarpOptions *psWarpOptions = GDALCreateWarpOptions();

psWarpOptions-papszWarpOptions = 
CSLSetNameValue(psWarpOptions-papszWarpOptions, INIT_DEST, NO_DATA );

psWarpOptions-hSrcDS = hSrcDS;
psWarpOptions-hDstDS = hDstDS;

psWarpOptions-nBandCount = 1;
psWarpOptions-panSrcBands =
(int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
psWarpOptions-panSrcBands[0] = 1;
psWarpOptions-panDstBands =
(int *) CPLMalloc(sizeof(int) * psWarpOptions-nBandCount );
psWarpOptions-panDstBands[0] = 1;

psWarpOptions-pfnProgress = GDALTermProgress;

// Establish reprojection transformer.

psWarpOptions-pTransformerArg =
GDALCreateGenImgProjTransformer( hSrcDS,

GDALGetProjectionRef(hSrcDS),

hDstDS,

GDALGetProjectionRef(hDstDS),

FALSE, 0.0, 1 );
psWarpOptions-pfnTransformer = GDALGenImgProjTransform;

// Initialize and execute the warp operation.

GDALWarpOperationH oOperation = GDALCreateWarpOperation( 
psWarpOptions );

GDALChunkAndWarpImage( oOperation, 0, 0,
  GDALGetRasterXSize( 
hDstDS ),