[gdal-dev] Public XYM or XYZM datasets?

2016-08-25 Thread Carl Godkin
Hi, While I had read about XYM and XYZM on the mailing list a few months ago, I had no experience with those geometry types until today when I happened to stumble on http://www-static.bouldercolorado.gov/docs/opendata/OSMPTrails.zip which contains a shapefile of trails around Boulder, Colorado t

Re: [gdal-dev] Configure with GEOS prefix

2016-08-25 Thread Stadin, Benjamin
Sorry, I've overlooked it (-with-geos). Von: gdal-dev mailto:gdal-dev-boun...@lists.osgeo.org>> on behalf of Benjamin Stadin mailto:benjamin.sta...@heidelberg-mobil.com>> Datum: Freitag, 26. August 2016 um 00:05 An: "gdal-dev@lists.osgeo.org" mailto:gdal-dev@li

[gdal-dev] Configure with GEOS prefix

2016-08-25 Thread Stadin, Benjamin
Hi, Is it possible to configure GDAL with GEOS, using a prefix path to a specific GEOS lib? Cheers Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Preserve Source Raster Resolution When Merging

2016-08-25 Thread Jamie Adams
Hi Sam, If your gdal build has Rasterlite support, you can use that to store multiple rasters at their native resolution. For each raster do something like this, where table is a unique name for each raster. I used the file name for table, but it can be anything. gdal_translate -of Rasterlite r

Re: [gdal-dev] Preserve Source Raster Resolution When Merging

2016-08-25 Thread Rahkonen Jukka (MML)
Sam Wilson wrote: > Hi, > I'm attempting to merge (or maybe the proper term is mosaic) overlapping > raster datasets of varying resolutions. I'd like to have the higher > resolution datasets override the lower resolution datasets where available. > I've been able to get close using various me

Re: [gdal-dev] GDAL 2.1.0 build error (32 bit, Mac)

2016-08-25 Thread Calogero Mauceri
Thanks Even for your reply. I had a look to port/cpl_config.h and in both cases (32 and 64 bit) the following line is commented [...] /* Define to 1, if your compiler supports long long data type */ /* #undef HAVE_LONG_LONG */ [...] I tried --with-macosx-framework and "-arch i386 -arch x86_

Re: [gdal-dev] No way to set natural block size ?

2016-08-25 Thread BRUNEL Samuel
Even Rouault a écrit : On Wednesday 24 August 2016 15:09:15 BRUNEL Samuel wrote: > OK, It's only possible to set "natural" block size with options of > GDALDataset::AddBand() if the driver supports "natural" block size, like > "GTiff" driver. There are actualy very vew drivers that actually supp