[gdal-dev] gdal.m4?

Hi All, Does anybody have a gdal.m4 or equivalent for autoconf that uses gdal-config that they would be share? I'd like to get something better for the visionworkbench folks so that it can handle the various directories not all being together (e.g. fink has the includes in /sw/include/gdal1

Re: [gdal-dev] Motion: Commit Access for Kurt Schwehr

I have read and will comply with http://trac.osgeo.org/gdal/wiki/rfc3_commiters -kurt On Fri, Aug 9, 2013 at 2:41 PM, Frank Warmerdam warmer...@pobox.com wrote: Motion: Commit Access to GDAL for Kurt Schwehr Kurt has been contributing some patches around maritime formats, and other aspects

Re: [gdal-dev] Motion: Commit Access for Kurt Schwehr

Thanks! -kurt On Aug 13, 2013, at 6:59 PM, Frank Warmerdam warmer...@pobox.com wrote: On Fri, Aug 9, 2013 at 2:41 PM, Frank Warmerdam warmer...@pobox.com wrote: Motion: Commit Access to GDAL for Kurt Schwehr I declare this motion passed with support from Daniel, Tamas, Even, Howard

Re: [gdal-dev] Motion: Approve GDAL/OGR 1.10.1RC1 for release

LGTM with respect to fink package on mac osx 10.8 - Looks like I have a todo on jasper. - not sure on http_4 - png.py and test_gdalwarp below. - rest are flagged as know issues or pre-release things -kurt Failures Script: ogr/ogr_shape.py TEST: ogr_shape_68 ...

Re: [gdal-dev] Motion: Approve GDAL/OGR 1.10.1RC1 for release

, at 11:26 AM, Even Rouault even.roua...@mines-paris.org wrote: Le samedi 24 août 2013 19:57:47, Kurt Schwehr a écrit : LGTM with respect to fink package on mac osx 10.8 - Looks like I have a todo on jasper. - not sure on http_4 - png.py and test_gdalwarp below. - rest are flagged as know

Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()

Even, I have been trying to think through how an OGR driver for ISO19115 / 19139 would work. I'm going to work on a band aid to the new BAG tweak to their ISO metadata, but we definitely could use a bare driver for read / write. The quest boils down to what is the minimal set of things that

[gdal-dev] libpng and autotest

Jack, Is there an explanation someplace with more detail as to what is wrong those png's, why older versions of libpng are okay with it and why libpng has changed its behavior? Thanks, -kurt On Nov 8, 2013, at 8:02 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: On Fri, Nov 08, 2013 at

[gdal-dev] What is readlink used for?

Hi all, I ran into trouble with readlink as can be seen in http://trac.osgeo.org/gdal/ticket/5340. I'm working with a system where the run directory is all symbolic links. So if I have nonsquare.vrt refering to ./small.raw, readlink of nonsquare.vrt will end up being in a totally different

Re: [gdal-dev] What is readlink used for?

Thanks for pointing me right at the vrt readlink changeset. This re-arrangement of files is done without me or gdal doing anything. # readonly filesystem with data used by tests. Note that the checksums are different directories /data/checksum1/a.vrt /data/checksum2/small.raw # each test gets

Re: [gdal-dev] Problem calling gdalwarp from within python script

try subprocess.call([gdalwarp, -q, -multi, ... TEST2.tiff]) Each arg must be an element in the list. -kurt On Jan 19, 2014, at 2:27 PM, Simon Proud s...@geo.ku.dk wrote: Hi, I wish to call gdalwarp from within a python script but I cannot get it to work. The command I wish to run

Re: [gdal-dev] Problem calling gdalwarp from within python script

. /Simon Fra: Kurt Schwehr [schw...@gmail.com] Sendt: 19. januar 2014 17:47 Til: Simon Richard Proud Cc: gdal-dev@lists.osgeo.org dev Emne: Re: [gdal-dev] Problem calling gdalwarp from within python script try subprocess.call([gdalwarp, -q

Re: [gdal-dev] Problem calling gdalwarp from within python script

also tried including the -te and -tr arguments in the one argument along with the proj details - no luck with that either. /Simon Fra: Kurt Schwehr [schw...@gmail.com] Sendt: 19. januar 2014 18:05 Til: Simon Richard Proud Cc: gdal-dev@lists.osgeo.org

Re: [gdal-dev] Help request to make Python bindings to build again with MacOS X 10.9

http://en.wikipedia.org/wiki/Xcode#Composition says that clang started at xcode 4.2, for which the version numbering is decoupled from the darwin version. There are two tables at the bottom that only sort of tell the whole story... http://en.wikipedia.org/wiki/Xcode#Versions_compare_table e.g.

Re: [gdal-dev] Motion: Promote 1.11.0RC1 for release

Pretty much everything working with fink on the mac on 10.9 with xcode 5.1 and fink's python 2.7. Test results below. Created one new issue. -kurt test_gdaltindex4 failing: http://trac.osgeo.org/gdal/ticket/5440 Packaging files:

Re: [gdal-dev] Motion: Promote 1.11.0RC1 for release

(compatibility version 11.0.0, current version 11.0.0) /sw/lib/libpng16.16.dylib (compatibility version 27.0.0, current version 27.0.0) On Sun, Apr 20, 2014 at 8:50 AM, Even Rouault even.roua...@mines-paris.orgwrote: Le dimanche 20 avril 2014 17:36:58, Kurt Schwehr a écrit : Pretty much

Re: [gdal-dev] Motion: Promote 1.11.0RC1 for release

What in the test output says that I don't have a working proj4? Thanks for the clarifications on the other points. I can update the checksums tomorrow. -kurt On Sun, Apr 20, 2014 at 10:38 AM, Even Rouault even.roua...@mines-paris.org wrote: Le dimanche 20 avril 2014 18:20:58, Kurt Schwehr

[gdal-dev] GDAL_DATA files from /vsimem?

Hi all, I'm working on a system where I might not have access (or very annoying access) to a local filesystem. I've got an external to gdal wrapper that has the gdal/data files compiled in. Would it work to have a local patch to cpl_findfile that would write the files into /vsimem/gdal_data/*

Re: [gdal-dev] RFC 47 and Threading

I've got threading issues on my list of things to investigate with GDAL. I've been running MSAN on GDAL lately and want to get TSAN going too. I'm out on leave this month, but hope to get more into this stuff (testing, threading, caching, etc) come October. On Fri, Aug 22, 2014 at 6:11 AM,

Re: [gdal-dev] RFC 47 and Threading

, Kurt Schwehr schw...@gmail.com wrote: I've got threading issues on my list of things to investigate with GDAL. I've been running MSAN on GDAL lately and want to get TSAN going too. I'm out on leave this month, but hope to get more into this stuff (testing, threading, caching, etc) come October

Re: [gdal-dev] GDAL/OGR 1.11.2 RC2 Available for Review

, Even Rouault even.roua...@spatialys.com wrote: Le mardi 10 février 2015 20:05:52, Kurt Schwehr a écrit : I think it looks okay w.r.t. fink on mac osx 10.9. autotest failures for anyone who is interested: https://gist.github.com/schwehr/757bae6bd28d9a7ffc4d Kurt, Some of the output traces

Re: [gdal-dev] GDAL/OGR 1.11.2 RC2 Available for Review

AVX optimized version GDAL_GRID: Using 8 threads Segmentation fault: 11 On Thu, Feb 12, 2015 at 12:23 PM, Even Rouault even.roua...@spatialys.com wrote: Le jeudi 12 février 2015 20:54:42, Kurt Schwehr a écrit : Here is the full output: https://gist.github.com/schwehr/c9e9fb595d0370e7eff7

Re: [gdal-dev] GDAL/OGR 1.11.2 RC2 Available for Review

I think it looks okay w.r.t. fink on mac osx 10.9. autotest failures for anyone who is interested: https://gist.github.com/schwehr/757bae6bd28d9a7ffc4d On Tue, Feb 10, 2015 at 4:30 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, I have prepared a second GDAL/OGR 1.11.2 release

Re: [gdal-dev] Gdal 1.11.2 and libtiff

février 2015 18:21:59, Kurt Schwehr a écrit : Sorry this is so last minute, but I suggest that 1.11.2 be held back until libtiff is updated. e.g. to ftp://ftp.remotesensing.org/pub/libtiff/tiff-4.0.4beta.tar.gz or head. There are a number of issues out in the wild: http

[gdal-dev] autotest/ogr_mitab.py in trunk_mingw_w64

Even (or anyone else), Any idea what is up with the trunk_mingw_w64 failures with ogr_mitab? I'm worried that I somehow caused this, but can't come up with how. https://trac.osgeo.org/gdal/ticket/6076 -kurt ___ gdal-dev mailing list

Re: [gdal-dev] Regarding libkml driver

Hi Rashad, I am starting to look into libkml from the Google side. I will chat with mashbridge in next week and see if we can get some motion on libkml. -kurt Engineer at Google On Sun, Aug 2, 2015 at 12:22 PM, Rashad M mohammedrasha...@gmail.com wrote: On Sun, Aug 2, 2015 at 9:05 PM, Even

Re: [gdal-dev] Regarding libkml driver

to collaborating on future development of libkml. -kurt On Tue, Aug 4, 2015 at 9:59 PM, Kurt Schwehr schw...@gmail.com wrote: Hi Rashad, I am starting to look into libkml from the Google side. I will chat with mashbridge in next week and see if we can get some motion on libkml. -kurt Engineer

[gdal-dev] Use cases for the old PCIDSK driver?

Hi all, For the head of svn trunk Anyone have use cases that only work with the old PCIDSK driver? If so, let me know and I'll see if I can add some documentation. Otherwise, I propose removing the old driver and the autoconf/make tests and conditionals that support it.

Re: [gdal-dev] Current SVN doesn't build with VS

Hi Joaquim, I broke the build with https://trac.osgeo.org/gdal/changeset/31403/. Even created a ticket: https://trac.osgeo.org/gdal/ticket/6212 and I added your error message to the ticket. http://build.gisinternals.com/sdk/Default.aspx has been down, so it's been tough to see what is

Re: [gdal-dev] Current SVN doesn't build with VS

Hi Joaquim, Yes, MAX should work - that was what was originally in the code. I'm trying hard to get away from macros and such and get to the most robust code we can. I really want to find a way that we can use std::max which is the C++ way to

Re: [gdal-dev] Trying to debug a GDAL crash in "GDALClose(hDataset); "

nLockCount should be set by https://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdal_priv.h#L598 https://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_atomic_ops.cpp#L56 which uses InterlockedCompareExchange to change it. Can you give the whole stack trace? On Fri, Nov 13, 2015 at 6:47 PM,

Re: [gdal-dev] Current SVN doesn't build with VS

woohoo! Thank! I'll see if I can address any of those other warnings: https://trac.osgeo.org/gdal/ticket/6219 I will give https://trac.osgeo.org/gdal/ticket/6212 a couple days and close it out if I don't get any more failure reports On Fri, Nov 13, 2015 at 4:10 PM, Joaquim Luis

Re: [gdal-dev] SIGPIPE missing due to not including signal.h

Patch applied: https://trac.osgeo.org/gdal/changeset/31286 On Sun, Nov 1, 2015 at 9:04 AM, Greg Troxel wrote: > > Even Rouault writes: > > > Le dimanche 01 novembre 2015 17:43:35, vous avez écrit : > >> I am building on netbsd-6 i386 with gcc 4.5.3.

Re: [gdal-dev] Motion: Adopt RFC 60: Improved round-tripping in OGR

+1 On Wed, Nov 4, 2015 at 9:32 AM, Even Rouault wrote: > Hi, > > Since no remarks have been done on the latest proposal, I move to adopt RFC > 60 : Improved round-tripping in OGR > > https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr > > Starting

Re: [gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR

Just gave RFC 60 a quick look. In general, I think we absolutely need this. Some thoughts: - There are users who need the old behavior. We need an easy way to get that. I think the default should be the more functional RFC 60 way. I see the -noNativeData flag, so I think this is well

Re: [gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR

Sean got what I was meaning to say. Do we want the output to have some record of which mode was used. I think the answer is likely no. And it reminds me that I need to think about a driver for writing ISO metadata files. (bleck) The processing steps would go in an xml iso metadata sidecar.

Re: [gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR

> Kurt, > A driver for writing ISO metadata files would be quite welcome. Anything > to make compiling and writing metadata less painful is always a good thing. > :-) > > Doug > > On Wed, Oct 14, 2015 at 6:20 PM, Kurt Schwehr <schw...@gmail.com> wrote: > >> Se

[gdal-dev] ISO Metadata

If anyone wants to follow up on metadata, Sean is right... here is a different subject thread for metadata. On Thu, Oct 15, 2015 at 11:44 AM, Sean Gillies <s...@mapbox.com> wrote: > Kurt, > > On Wed, Oct 14, 2015 at 4:20 PM, Kurt Schwehr <schw...@gmail.com> wrote:

Re: [gdal-dev] Refactoring: class members clean-up

I personally like foo_, but m_ is fine. I worry about unexpected side effects of changing member naming with private members. I don't think there will be any if everything builds, but I still worry. If we go for changing publics, we should pick a time and go for a major version number bump and

Re: [gdal-dev] GDAL testing

ic, so I'd like to pull some more details to > better > understand the idea, if you don't mind. > > > Kurt Schwehr-2 wrote > > For my production work, I'm not able to use the autotest python code > > because of its non-unittest architecture. > > Could you elaborate mo

Re: [gdal-dev] Dropping Windows-CE support?

Mateusz, Thanks for the build test. Even, thanks for the pointer to the Appveyor builds. On Thu, Oct 8, 2015 at 1:18 PM, Mateusz Loskot wrote: > Kurt, > > I have checked building latest trunk on Windows 8.1 with VS2015 and 32-bit > build seems fine. > > Regards, > Mateusz >

[gdal-dev] Dropping Windows-CE support?

Hi all, Any objections to me removing Windows-CE support from GDAL svn-trunk head? -kurt https://trac.osgeo.org/gdal/ticket/6133 For removal of MacOS 9 and older. Even Mentioned WinCE. find . -name \*.cpp -o -name \*.c -o -name \*.h | egrep -v 'zlib|png|svn' | xargs egrep -i 'WIN32_WCE|windows

Re: [gdal-dev] Motion: Add Kurt Schwehr to GDAL PSC

Thanks! On Fri, Oct 9, 2015 at 2:11 PM, Even Rouault <even.roua...@spatialys.com> wrote: > Le mercredi 07 octobre 2015 22:54:09, Even Rouault a écrit : > > Hi, > > > > I propose to add Kurt Schwehr to the GDAL project steering committee. > > > > Kurt has

Re: [gdal-dev] Dropping Windows-CE support?

I can get it fixed ASAP. I don't think I did, but all I have to go on is the MingW Travis-CI builds. Cheers, -kurt On Wed, Oct 7, 2015 at 10:05 AM, Even Rouault <even.roua...@spatialys.com> wrote: > Le mardi 06 octobre 2015 23:07:41, Kurt Schwehr a écrit : > > Hi all, > &g

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

Oh.. https://en.wikipedia.org/wiki/C_(programming_language)#Keywords - C99 added _Bool. Yuck. I thought that C matched C++ with bool. So never mind this comment on bool. - Can we get away from 0/FALSE and TRUE/1 for bools in in C++. e.g. psOptions-bQuiet The API is intended to be C

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

+1 from a non-voting person. It will definitely make testing a lot cleaner / easier without having to run a separate binary to get most of the testing done. There is also an enormous amount of python code that runs os.system / subprocess. That code is very error prone / a pain to maintain.

[gdal-dev] Coverity scan schedule

Hi Kyle and/or the other coverity project admins (Even, Frank, Tamas, & Pirmin), Any chance you could add additional times throughout the week for Coverity Scans? We should be able to get 4 a week (for 500K-1M LOC). I propose that we add Weds, Thurs, Sun. That would be a big help for my

Re: [gdal-dev] GDAL testing

(Subject change to focus on testing) Hi all, First off... what GDAL has with autotest, travis-ci and coverity is awesome! Thoughts / discussion more than welcome! For my production work, I'm not able to use the autotest python code because of its non-unittest architecture. So... I started

Re: [gdal-dev] GDAL testing

need to use autotest2? > > Best regards, > Dmitry > > 05.09.2015 20:37, Kurt Schwehr пишет: > > (Subject change to focus on testing) > > Hi all, > > First off... what GDAL has with autotest, travis-ci and coverity is > awesome! > > Thoughts / discussion more than

Re: [gdal-dev] FLIF format?

Why yes :). Slashdot... I left them two feature requests already. > On Oct 2, 2015, at 9:59 AM, Newcomb, Doug wrote: > > Hi Folks, > has anyone heard of the Flif FORMAT? > > http://flif.info/ > > Github site looks like it's only been up a short time. > >

[gdal-dev] Possible code style changes to GDAL C++

Hi all, TL;DR: This is a list of possible topics for change to RFC 8 . I think the default action should be to not to add / change anything. If a point is worth discussing, we should probably create a bug for just that point and discuss it there.

Re: [gdal-dev] Installation prefix for Python bindings on MacOSX ?

I've also not had a chance to try to figure out how to get gdal2 into fink on mac osx. I've been focusing my time on Linux lately. Fink only works in a user configurable tree (/sw by default), so fink often hits this type of issue with packages. I'll try to get that soonish. I'll be making a

[gdal-dev] Fwd: GDAL AppVeyor

I will take a look at fixing this in the next couple hours Begin forwarded message: > From: AppVeyor > Date: December 24, 2015 at 6:23:27 PM PST > To: schw...@gmail.com > Subject: GDAL AppVeyor > > Build gdal_coverage 1.0.1842 failed > > Commit 751d8531ff

[gdal-dev] db2 python test issues

Hi David, I just did a quick touchup on ogr_db2.py with r32484 With a python3 copy of pyflakes, you will get errors about prints without parens. e.g. pyflakes ogr_db2.py ogr_db2.py:334:47: invalid syntax print "These tests only run on

[gdal-dev] Making a small(er) test netcdf from a netcdf with subdatasets?

Also asked here: http://gis.stackexchange.com/questions/170882/how-can-a-make-a-netcdf-with-subgroups-smaller Is there an easy way to make a netcdf with subdatasets but shrink it without resorting to C or Fortan? I'm trying to write a test for code that works with hycom netcdf global ocean

Re: [gdal-dev] Making a small(er) test netcdf from a netcdf with subdatasets?

have seen that your > recent commits completely break my patches, but this is my fault because I > should have done before, but time is missing... :-( > > Cheers, > Julien > > ------ > *De :* gdal-dev [gdal-dev-boun...@lists.osgeo.org] de la part de Kurt &

Re: [gdal-dev] Making a small(er) test netcdf from a netcdf with subdatasets?

d be able to keep 0..360 > but change the step by decimating: -d lon,0,360,10 for example to keep only > 37 longitudes. > http://research.jisao.washington.edu/data_sets/nco/#example10 > > Julien > > ------ > *De :* Kurt Schwehr [schw...@gmail.com] >

Re: [gdal-dev] GDAL 2.0.2 and 1.11.4: RC1 end of next week ?

+1 I see lots of good fixes since 2.0.1 in the 2.0 branch On Wed, Jan 13, 2016 at 8:47 AM, Even Rouault wrote: > Hi, > > What about preparing RC1s for both branches for end of next week ? There > are ~ > 30 tickets

Re: [gdal-dev] Questions on working with HYCOM data in netcdf format

gt; dataset also, but the values 1-3298 and 1-4500 which is the size of the > file in pixels, so not helpful. > > I've looked on the HYCOM forum but that has not been very helpful yet. > > Thanks, > -Steve > > > On 6/5/2016 2:04 PM, Kurt Schwehr wrote: > >> Stephen,

Re: [gdal-dev] Questions on working with HYCOM data in netcdf format

/26895009754/ On Mon, Jun 6, 2016 at 7:51 AM, Stephen Woodbridge <wood...@swoodbridge.com> wrote: > On 6/5/2016 2:04 PM, Kurt Schwehr wrote: > >> Stephen, >> >> Take a look at these two discussions for starters on working with hycom: >> >> >> http://gis.s

Re: [gdal-dev] Starting a discussion on style and coding guidelines

n of large objects would like be an important fraction of runtime. I'm sure they are there, but I would bet they are rare. On Thu, Jun 2, 2016 at 3:29 AM, Even Rouault <even.roua...@spatialys.com> wrote: > Le jeudi 02 juin 2016 00:46:06, Kurt Schwehr a écrit : > > > https:

Re: [gdal-dev] Starting a discussion on style and coding guidelines

https://docs.google.com/document/d/1O1B7LY13L532kXcYcB2EdO65m5LOCsqaqn5R9iJfSPU/pub The optimized stack .o is 1248 bytes and the on the heap vector is 1600 bytes with gcc 4.8. The cost of either is pretty small. So, if there are 100 of these in gdal, we are talking about 30-60K of extra object

[gdal-dev] RFC: int bFoo -> bool bFoo (simple case)

Hi all The large arrays on the stack RFC discussion was impressive. Here is a second RFC. I tried to use the experience of the first to improve this one. Thoughts on the simplest case of int bFoo to bool bFoo? https://goo.gl/hdzhXD I figure we need to discuss a bunch more of these before

Re: [gdal-dev] supportive data files for re-projection

Nick, What Even said and here is the list of files I use for a very restricted build of GDAL with just a minimum of drivers. e.g. I don't build support for S57, so I don't include the S57 only data files. But if you include GML, you might need gml_registry.xml and the files that the xml

Re: [gdal-dev] GDAL and Sentinel2

Possibly a dumb question... Why not checkout, build and use the svn trunk? If you get unlucky and hit a version that is not building, we usually get things back to building in a couple hours. It might take a little bit to tune the configuration to your needs, but once you have it, you should be

Re: [gdal-dev] RFC 61: Call for vote on adoption

OGRGeometry::OGR_G_NOT_EMPTY_POINT On Wed, Feb 10, 2016 at 7:34 AM, Ari Jolma <ari.jo...@gmail.com> wrote: > > 10.02.2016, 15:21, Kurt Schwehr kirjoitti: > >> >> One request: >> >> #define OGR_G_NOT_EMPTY_POINT 0x1 >> #define OGR_G_3D

Re: [gdal-dev] RFC 61: Call for vote on adoption

I'm +0. Neither for nor against. One request: #define OGR_G_NOT_EMPTY_POINT 0x1 #define OGR_G_3D 0x2 #define OGR_G_MEASURED 0x4 #define OGR_G_IGNORE_MEASURED 0x8 Can you make these a static const int or static const unsigned int member of the OGRGeometry class? #defines make life more

Re: [gdal-dev] GDAL/OGR 2.0.2 and 1.11.4 released

Progress with other libraries and tools is happening. Maybe not speedy, but it's going. e.g. I just got this patch in for Vision Workbench: https://github.com/visionworkbench/visionworkbench/pull/42 On Fri, Jan 29, 2016 at 2:36 PM, Roger Bivand wrote: > Even Rouault

Re: [gdal-dev] Motion: Committer Status for Lucian Plesea

+1 Kurt On Tue, Feb 23, 2016 at 4:10 PM, Even Rouault wrote: > Motion: Committer Status for Lucian Plesea > --- > > Dear PSC, > > Lucian is the maintainer of the MRF (Meta Raster Format) driver who has > existed as an out-of-tree driver and whose main repository is

Re: [gdal-dev] Dropping Windows-CE support?

Andrew, You might find useful the changes listed in the ticket that I used for the remove of macos <= 9 and wince: https://trac.osgeo.org/gdal/ticket/6133 -kurt On Sun, Feb 14, 2016 at 12:13 PM, Mateusz Loskot wrote: > On 13 February 2016 at 21:30, byte

Re: [gdal-dev] GDAL/OGR 1.11.4 RC1 Available for Review

+1 for packaging on Mac OSX fink, but I've managed to create an environment where I get lots of segfaults will all sorts of stuff (e.g. other branches of gdal), so I can't comment on passing the tests. One trivial nit... could drop the .gitignore file from the tar. On Fri, Jan 22, 2016 at 3:14

Re: [gdal-dev] Building GDAL 2.0.0 without ogr on Linux fails

I propose that we remove --without-ogr and OGR_ENABLED. Happy to hear arguments for the contrary. I commented here: https://trac.osgeo.org/gdal/ticket/6117 On Tue, Jun 23, 2015 at 9:14 AM, Even Rouault wrote: > Kor, > > I'm half surprised this ended up being

Re: [gdal-dev] Building GDAL 2.0.0 without ogr on Linux fails

try > > 17.03.2016 19:19, Kurt Schwehr пишет: > > I propose that we remove --without-ogr and OGR_ENABLED. Happy to hear > arguments for the contrary. I commented here: > > https://trac.osgeo.org/gdal/ticket/6117 > > On Tue, Jun 23, 2015 at 9:14 AM, Even Rouault <even.ro

Re: [gdal-dev] Proposed change regarding wkbCurve, wkbSurface and their M/Z/ZM variants

+1 On Sun, Mar 6, 2016 at 7:17 AM, Even Rouault wrote: > Hi, > > During > https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries > discussion, we introduced wkbCurveM/Z/ZM and wkbSurfaceM/Z/ZM as #define > and > not in OGRwkbGeometryType enumeration.

Re: [gdal-dev] Motion: Promote 2.1.0RC4 for release

+1 Kurt On Wed, Apr 27, 2016 at 1:18 AM, Even Rouault wrote: > Motion: GDAL/OGR 2.1.0RC4 is promoted to be the official 2.1.0 final > release. > > --- > > +1 Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com >

Re: [gdal-dev] Starting a discussion on style and coding guidelines

All, Just to be totally obvious and not meant to squash questions, comments, concerns. I'm trying to narrow the scope of this discussion. http://goo.gl/vuA3D6 (Especially after I fixed the "Status:"... which I just changed again). My intent was to have a super narrow focus to the proposal,

Re: [gdal-dev] Starting a discussion on style and coding guidelines

ze; i++) { >>> if (GDALRasterIO(hSrcBand, GF_Read, 0, i, nXSize, 1, >>> pafThreeLineWin + i * nXSize, nXSize, 1, >>> GDT_Float32, 0, 0) != CE_None ) { >>> eErr = CE_Failure; >>> goto end; >>>

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I intend to argue strongly against the many styles at a later date and in a separate thread. On Mon, May 9, 2016 at 9:21 AM, Mateusz Loskot <mate...@loskot.net> wrote: > On 9 May 2016 at 16:47, Kurt Schwehr <schw...@gmail.com> wrote: > > There are lots of implicit style

Re: [gdal-dev] Minimum supported C and C++ standards

6 at 2:33 AM, Mateusz Loskot <mate...@loskot.net> wrote: > On 7 May 2016 at 19:10, Kurt Schwehr <schw...@gmail.com> wrote: > >> > >> If we move to a later C++ standard, or even use features of C++98 we > >> currently > >> don't use, I'd advocate for

Re: [gdal-dev] Minimum supported C and C++ standards

tain gunit/gmock prefer that projects package the gunit code inside their repos. git clone g...@github.com:google/googletest.git cd googletest find . -type f | wc -l 340 du -hs 8.9M . e.g. for libais, I just made third_party and put them in side that... https://github.com/schwehr/libais/tre

Re: [gdal-dev] Minimum supported C and C++ standards

://amodernstory.com/2015/07/27/upgrading-travisci-build-scripts/ On Mon, May 9, 2016 at 11:38 AM, Kurt Schwehr <schw...@gmail.com> wrote: > Agreed on the 11 v 14 issues. > > On Mon, May 9, 2016 at 11:17 AM, Even Rouault <even.roua...@spatialys.com> > wrote: > >> Le lundi 09 m

Re: [gdal-dev] Starting a discussion on style and coding guidelines

unique_ptr exists, is a standard and is more robust. std::vector was not the first solution I came up with for this issue. On Fri, May 6, 2016 at 2:37 PM, Tim Keitt <tke...@utexas.edu> wrote: > > > http://www.keittlab.org/ > > On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr &l

[gdal-dev] Minimum supported C and C++ standards

There has been lively discussion on if/when GDAL moves to require compilers with newer C and C++ standard versions. This email is meant to fork the this discussion away from the local stack + memset -> std::vector discussion. I'm trying to draft a proposal based on the discussion, but it is a

Re: [gdal-dev] Segfault in GDALWriteBlock

What version of GDAL are you using? Can you provide the command or calling code that you are using? Can you use a debugger and give a stack trace? On Thu, May 5, 2016 at 12:42 AM, jramm wrote: > Hi I am getting a segfault in a call to GDALWriteBlock with this code: > >

[gdal-dev] Starting a discussion on style and coding guidelines

a form that extends RFC 8. Please don't be shy in commenting any way you feel is constructive on this doc. We can discuss on this list or if people really want, I can give individuals comment access to the Google doc. cheers, -kurt Use vector(length, initial_value) for local blocks of storage. Author

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Thanks all for your comments! I will try to write up a similar proposal for C++11 based on what people have written. I've integrated (and still working on) a number of the points from the discussion so far on the stack storage issue into the doc and added a section titled "Impact of the proposed

Re: [gdal-dev] Python port newcomer

Doc strings would be a great place to start. That would really help people take advantage of more of what GDAL has to offer. On Sat, Apr 16, 2016 at 8:16 AM, Even Rouault wrote: > Gregory, > > You can have a look at the tickets identified by the following request >

Re: [gdal-dev] Minimum supported C and C++ standards

This is example demonstrates that we are in-general fighting hard against C++... up-hill both ways in a blizzard. :) This is why starting with zero features and working our way up with a white list gives examples of correct usage. It looks like a lot of GDAL development happens by

Re: [gdal-dev] Starting a discussion on style and coding guidelines

ote: > On 6 May 2016 at 21:55, Kurt Schwehr <schw...@gmail.com> wrote: > > My belief is that for this particular proposal, we should not have the > > C++11/14 discussion unless the best overall solution requires a newer > > version of C++. The solution I propose to b

Re: [gdal-dev] [GDAL Python] Save a dataset to an in memory Python Bytes object

There are lots of examples to learn from in the autotest suite. That's where I learn a lot of stuff. https://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/png.py?rev=33793#L211 Or for examples in C++14, there is also my draft autotest2. You can see examples like this:

Re: [gdal-dev] Call for discussion on RFC 63 : Sparse datasets improvements

Scratch my enum comment... http://stackoverflow.com/questions/1448396/how-to-use-enums-as-flags-in-c On Mon, Jul 11, 2016 at 8:31 AM, Even Rouault <even.roua...@spatialys.com> wrote: > Le lundi 11 juillet 2016 17:11:59, Kurt Schwehr a écrit : > > Even, > > > > I thin

Re: [gdal-dev] Call for discussion on RFC 63 : Sparse datasets improvements

Even, I think this looks good and a big win for a lot of use cases. Comments related to the flags defined in gcore/gdal.h: - If possible, use an enum rather than bare defines. - Add comments to gdal.h explaining what the values are - Should an unimplemented also have the _DATA flag set rather

Re: [gdal-dev] Motions: Promote 1.11.5 RC 1, 2.0.3 RC2 and and 2.1.1 RC2 for release

On Fri, Jul 8, 2016 at 3:02 AM, Even Rouault wrote: > Hi, > > Motions under vote: > Motion 1: GDAL/OGR 1.11.5 RC1 is promoted to be the official 1.11.5 final > release. > +1 > > Motion 2: GDAL/OGR 2.0.3 RC2 is promoted to be the official 2.0.3 final > release. > >

Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements

+1 for this change. This will be awesome! On Thu, Aug 4, 2016 at 3:12 AM, Even Rouault wrote: > On Thursday 04 August 2016 12:11:18 Daniele Romagnoli wrote: > > That's a very valuable improvement! > > Thanks for that. > > > > Is there any future plan to backport it

[gdal-dev] Status of ESRI ARcSDE raster (frmts/sde) driver

Hi all, The ArcSDE raster format driver is not currently being built by any of the automated testing systems (as far as I know). With r34811 , I broke the code back 2 weeks ago

[gdal-dev] Removing one of the two svn:keyword Id lines in all source files

See: https://trac.osgeo.org/gdal/ticket/6547 I propose to remove the $id line from the comments at the top of the file for files that already have CPL_CVSID. Having two lines means we have a redundant copy of all this info, which is changing for every commit. In addition, I propose to set the

Re: [gdal-dev] Zip files and VISFileFromMemBuffer()

Sean, Very cool. One follow up question, do you really need the "with" for open? Does this not work (and MemoryFile can drop the file descriptor as soon as it wants to)? with MemoryFile(open(path_zip_file, 'rb')) as memfile: with memfile.open('white-gemini-iv.vrt') as dataset:

Re: [gdal-dev] Motion: Promote 2.1.3RC1 for release

And a little after the fact :) Just checked 2.1.3 into fink on the mac. Thanks Even! +1 kurt On Fri, Jan 27, 2017 at 2:53 AM, Even Rouault wrote: > On mercredi 25 janvier 2017 09:27:06 CET Even Rouault wrote: > > > Hi, > > > > > > Motion: GDAL/OGR 2.1.3RC1 is

Re: [gdal-dev] [gdal2tiles.py] python engineering

> You are completely right. Symbolic link. Don't know what I was thinking > about at the time! > > > On Wed, 25 Jan 2017 at 19:12, Kurt Schwehr <schw...@gmail.com> wrote: > >> Gregory, >> >> Aside: A point of terminology, by hyperlink, I think you mean symbolic >

Re: [gdal-dev] [gdal2tiles.py] python engineering

Gregory, Aside: A point of terminology, by hyperlink, I think you mean symbolic link or hard link. As a point of information, I'm using both python unittest and C++ gunit very effectively for GDAL. I do use bazel as the build system, but that

Re: [gdal-dev] gdal-autotest2

EOS tests are dead simple based on lightweight runner. > > If something is missing, just add it and submit to GEOS. > > Rewriting tests just for the sake of making them based on GTest. > Well... > > Mateusz > > On 21 Feb 2017 8:10 p.m., "Kurt Schwehr" <schw...

  1   2   3   4   >