Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

Kai, Rebuilt Geos with your insight, and two spaces between all -D entries, including eliminating MrSid that was complied under gcc 521 or so and might likely cause problems, using GDAL build hints , and we have success on on *target gcore_mdreader*, and I'll move

[gdal-dev] gdal-utils: understanding the __main__ pattern

Hello folks who know about the python script construction :) The pattern used in all of the python scripts under swig/python/gdal-utils is foreign to me. Can someone explain what's going on and why it's used? (or point to where this has been explored already). if __name__ == '__main__': sys.e

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

It looks like you missed a " " after -DCMAKE_BUILD_TYPE=Release when configuring GEOS: > set_property(TARGET GEOS::geos APPEND PROPERTY IMPORTED_CONFIGURATIONS > RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL) Kai. ___ gdal-dev mailing list gdal-dev@lists.o

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

This generated file, local.cmake, seems to suggest that the build should still be pointing (GEOS_DIR) /usr/local/lib/cmake/GEOS, but GEOS::geos_c location still doesn't get set. # # Generated CMake target import file for configuration

[gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

Concerning (executed in either git download directory or build): ~/gdal$ git describe v3.3.0-2898-gba4e7c404b Condition: was building and stopped with [ 89%] Built target gcore_mdreader CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'. Stop. make[1]: *** [CMakeFiles/Makefile

Re: [gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning

Thanks for the many insights Jukka, it has helped me a lot in thinking where to dig and what to look at. First, and this is what matters the most to me, I was able to confirm data integrity by comparing for each table the pg version to the sqlite version. Some types are altered (e.g. Dates whic

Re: [gdal-dev] Weird behavior while reprojecting geometries

Hi Idan, It is indeed this the issue. I was not aware of this change. Man, it has been a while since I have touched GDAL. Thanks a lot for your help. Idan Miara escreveu no dia sexta, 4/03/2022 à(s) 12:13: > > > On Fri, 4 Mar 2022, 13:12 Idan Miara, wrote: > >> Hi, >> Are you familiar with the

Re: [gdal-dev] Weird behavior while reprojecting geometries

On Fri, 4 Mar 2022, 13:12 Idan Miara, wrote: > Hi, > Are you familiar with the axis order that was introduced in gdal 3 and its > affects on 4326? > https://gdal.org/tutorials/osr_api_tut.html#crs-and-axis-order > > On Fri, 4 Mar 2022, 13:07 Hugo, wrote: > >> Hi guys, >> >> I'm having weird beha

[gdal-dev] Weird behavior while reprojecting geometries

Hi guys, I'm having weird behavior using ogr and osr through python while reprojecting point geometries. Following code: wgs = osr.SpatialReference() wgs.ImportFromEPSG(4326) etrs = osr.SpatialReference() etrs.ImportFromEPSG(3763) geom = ogr.Geometry(ogr.wkbPoint) geom.AddPoint(-9.10165,38.7398