From georgec_511 at yahoo.com Tue Mar 1 10:45:31 2011 From: georgec_511 at yahoo.com (George C) Date: Tue Mar 1 10:52:24 2011 Subject: [gdal-dev] Gdal and solaris compile question Message-ID: Hello, I was wondering if I should include all of the binary files in my LD_LIBRARY path. For example, the .a files, or the .la files? Or should I just include the .so files? I also noticed that there are soft links to libgdal.so->libgdal.so.1.14.3 should I include the soft links too? The same question for the swig directory, which also has .lo and .o files in it. Much appreciated Thanks, George From misha at mail.geometrics.com Tue Mar 1 12:29:21 2011 From: misha at mail.geometrics.com (Mikhail Tchernychev) Date: Tue Mar 1 12:29:25 2011 Subject: [gdal-dev] How files are handled in OGR / GDAL In-Reply-To: References: Message-ID: <4D6D2CF1.4050002@mail.geometrics.com> Hello List, I could probably figure it out from the source, but I would apprecaite if someone could point me in the right direction. The question is: does GDAL / OGR loads the file in the memory when it opens in or it just keeps reference to the actual file Say if I open it, process it etc hDS =OGROpen ("point.shp", FALSE, NULL ); .... and then do (without closing) poLayer->ResetReading (); and process again would it actually trigger re-reading file from the disk or not? In other words does OGR creates complete memory image for the file or just reads actual file when it needs something? Thank you Mikhail PLEASE NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any dissemination, distribution or copy of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Information provided via electronic media is not guaranteed against defects including translation and transmission errors. The company accepts no liability for any damage caused by any virus transmitted by this email. Geometrics Inc. 2190 Fortune Drive San Jose, CA 95131 USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110301/ec0e839e/attachment.html From warmerdam at pobox.com Tue Mar 1 12:35:59 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 1 12:36:03 2011 Subject: [gdal-dev] How files are handled in OGR / GDAL In-Reply-To: <4D6D2CF1.4050002@mail.geometrics.com> References: <4D6D2CF1.4050002@mail.geometrics.com> Message-ID: <4D6D2E7F.2090803@pobox.com> On 11-03-01 12:29 PM, Mikhail Tchernychev wrote: > Hello List, > > I could probably figure it out from the source, but I would apprecaite > if someone could point me in the right direction. > > The question is: does GDAL / OGR loads the file in the memory when it > opens in or it just keeps reference to the actual file > > Say if I open it, process it etc > > hDS =OGROpen ("point.shp", FALSE, NULL ); > > .... > > and then do (without closing) > > poLayer->ResetReading (); > > and process again > > would it actually trigger re-reading file from the disk or not? > > In other words does OGR creates complete memory image for the file or > just reads actual file when it needs something? Mikhail, These is driver dependent. But we try to avoid holding too much of the underlying file in memory. In the case of the shapefile driver the .shx index contents are loaded into RAM and kept there but the .shp and .dbf records are read as-needed. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From armin.burger at gmx.net Tue Mar 1 13:00:32 2011 From: armin.burger at gmx.net (Armin Burger) Date: Tue Mar 1 13:00:31 2011 Subject: [gdal-dev] Windows builds and wildcard usage for gdaltindex & gdalbuildvrt In-Reply-To: References: <4D66BE14.5000904@gmx.net> Message-ID: <4D6D3440.8010407@gmx.net> Tamas, Frank thanks a lot for the quick response to this issue (I just noticed today...). I will download the new Windows binaries. Armin On 24/02/2011 22:40, Tamas Szekeres wrote: > Hi Armin, > > I've just added wildcard support to the builds at > http://vbkto.dyndns.org/sdk/ according to Frank's suggestion. The > corresponding binaries should be available with the next daily builds. > > Best regards, > > Tamas > > > > 2011/2/24 Armin Burger > > > Hi all > > I wanted to use a more recent Windows build than the latest FW Tools > which are a bit old now. I used the binaries from > > http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1310-gdal-1-8-0-mapserver-5-6-6.zip > > All works fine, just the usage of wildcards in tools like gdaltindex > or gdalbuildvrt does not work any more. If I run eg > > gdaltindex tileindex.shp *.tif > > I just get the error that the file "*.tif" could not be found. Same > happens for gdalbuildvrt.exe. So the wildcard resolution seems not > to work any more (it still did work in the last FWTools 2.4.7). For > gdaltindex I can use a "for" loop command because it adds every tif > to the same shape, but I don't think this workaround works for the > gdalbuildvrt. > > On Linux builds the wildcards usage still works fine with GDAL 1.8. > Any ideas if this will be fixed for Windows? > > Armin > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > From yehil at rafael.co.il Tue Mar 1 13:42:06 2011 From: yehil at rafael.co.il (Livneh Yehiyam) Date: Tue Mar 1 13:45:16 2011 Subject: [gdal-dev] windows 7 64 bit Message-ID: Hi We will start soon to move our product to 64 bit on windows 7, and I'm starting to check all of our dependencies. As far as I can see, gdal has a 64 bit version. Are there any issues specific to this version? Do the c# binding work without a problem? Thanks Yehiyam Livneh Sent from my mobile ********************************************************************************************** This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:lawraf@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ********************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110301/17fe5873/attachment.html From even.rouault at mines-paris.org Tue Mar 1 13:59:48 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 1 13:59:49 2011 Subject: [gdal-dev] Re: PHP bindings In-Reply-To: <201102282006.38116.mgleahy@alumni.uwaterloo.ca> References: <201102061450.35281.mgleahy@alumni.uwaterloo.ca> <201102241945.17074.mgleahy@alumni.uwaterloo.ca> <201102282006.38116.mgleahy@alumni.uwaterloo.ca> Message-ID: <201103011959.48700.even.rouault@mines-paris.org> Mike, > Hello again, > > I think I stumbled upon the part that was tripping up the methods I was > using with the php_osr.so library. Posted at http://pastebin.com/SXKKfe6v > is a patch that should work on both 1.8.0, and the trunk svn. It adds the > missing CSL typemap, and corrects the OGRErr related typemaps to ensure > that it only returns results for non-zero error responses. > I'm not sure if/when someone will act on this, but you should perhaps open a GDAL Trac ticket and attach your patch there so it is kept in a safer place than a pastebin that will be lost in a few days/weeks. > The patch also includes changes to the GNUmakefile in the swig/php folder > to make sure that the gdal libs are linked, and that all of the php > modules are compiles instead of just php_gdal.so (not sure if this is > fully necessary, but I was having trouble with linking before). > > In addition to this, I had to substitute all instances of > 'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with > 'zend_error'...I don't know if this is just specific to my environment, but > the best I could determine from searching online is that more recent > versions of PHP no longer define zend_error_noreturn, yet swig still uses > it. It seems that zend_error is a sufficient substitute (without this, I > would find that when the module raised errors, it would cause a segfault > instead of actually producing a descriptive error in Apache/PHP). Perhaps something to share with the swig mailing list ? > > If this patch is applied and gdal is configured/compiled with the > '--with-php' option, then when swig/php/php_osr.so is installed and loaded > into the PHP environment, the following PHP script will work as expected: > > include("/path/to/gdal/swig/php/osr.php"); > $sr = new SpatialReference(); > $sr->ImportFromProj4('+init=epsg:4326'); > echo $sr->ExportToProj4(); > ?> > > This is about as far as I can get for now - looking through typemaps_php.i, > I think I see plenty of stuff that still needs fixing/updating. There are > also function name conflicts if I try to load php_gdal.so and/or > php_ogr.so. I think that's out of my league, however. Hopefully this is > enough to peak the interest of someone who has a little more familarity > with c/swig/php, and we could get a more fully-supported set of PHP > bindings. > > Best regards, > Mike > > On Thursday, February 24, 2011 19:45:16 Mike Leahy wrote: > > Hello all, > > > > To keep this topic somewhat alive, I might note that I can identify that > > at the very least, php_osr.so works in some ways, but not how I would > > expect compared with the same bindings in other languages. > > > > I also found that at least one typemap was needed in typemaps_php.i: > > > > /* Almost same as %typemap(out) char **options */ > > /* but we CSLDestroy the char** pointer at the end */ > > %typemap(out) char **CSL > > { > > > > /* %typemap(out) char ** -> ( string ) */ > > char **stringarray = $1; > > if ( stringarray == NULL ) { > > > > RETVAL_NULL(); > > > > } > > else { > > > > int len = CSLCount( stringarray ); > > array_init($result); > > for ( int i = 0; i < len; ++i, ++stringarray ) { > > > > add_next_index_string( $result, *stringarray, 1 ); > > > > } > > > > } > > CSLDestroy($1); > > > > } > > > > This seems to have removed the warnings about that being missing when I > > compile the osr library (I'm continuing to focus just on this binding as > > a simple case). > > > > In terms of actually using php_osr.so, I can successfully import a proj4 > > string, and export that to WKT using the '__str__' method: > > > > > $sr = new_SpatialReference(); > > SpatialReference_ImportFromProj4($sr,'+init=epsg:4326'); > > echo SpatialReference___str__($sr); > > ?> > > > > I would expect that the last line would be equivalent to > > "SpatialReference_ExportToWkt($sr);", but that isn't the case...I'm still > > getting zero, which I think stems from the fact that the data type for > > the ExportToWkt (and similar functions) in osr.i is of the type > > 'OGRErr', and this is what is getting returned in PHP instead of the > > desired wkt output. > > > > I'm guessing that there's a difference in how swig interprets these > > functions when compiling in PHP versus the other languages. In osr.i, I > > added an extra declaration that mimics how the __str__ function works, > > but returns proj4 strings. It looks like this: > > > > %newobject ExportToProj4Test; > > > > char *ExportToProj4Test() { > > > > char *buf = 0; > > OSRExportToProj4( self, &buf ); > > return buf; > > > > } > > > > After compiling that, the following code will successfully return a Proj4 > > string: > > > > > $sr = new_SpatialReference(); > > SpatialReference_ImportFromProj4($sr,'+init=epsg:4326'); > > echo SpatialReference_ExportToProj4Test($sr); > > ?> > > > > So...with this in mind, does this suggest that PHP will essentially need > > an entirely rewritten list of functions? I would hope that there's a > > more effective way to go about it this, and that I'm just looking at > > this with my relatively novice perspective. > > > > Best regards, > > Mike From jmckenna at gatewaygeomatics.com Tue Mar 1 14:21:31 2011 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Tue Mar 1 14:21:36 2011 Subject: [gdal-dev] windows 7 64 bit In-Reply-To: References: Message-ID: <4D6D473B.40901@gatewaygeomatics.com> On 11-03-01 2:42 PM, Livneh Yehiyam wrote: > Hi > We will start soon to move our product to 64 bit on windows 7, and I'm > starting to check all of our dependencies. > As far as I can see, gdal has a 64 bit version. Are there any issues > specific to this version? Do the c# binding work without a problem? > I have compiled and tested recently GDAL 1.8.0 and MapServer 5.6.6 on Windows x64 with C# mapscript, if that helps you. I can tell you that it is not an easy process to compile. If you need more information please contact me directly. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From szekerest at gmail.com Tue Mar 1 14:25:27 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Tue Mar 1 14:25:30 2011 Subject: [gdal-dev] windows 7 64 bit In-Reply-To: References: Message-ID: Hi, I'm not aware of any issue related to x64 specifically. You can obtain compiled binaries from http://vbkto.dyndns.org/sdk/ (including the csharp bindings) Best regards, Tamas 2011/3/1 Livneh Yehiyam > Hi > We will start soon to move our product to 64 bit on windows 7, and I'm > starting to check all of our dependencies. > As far as I can see, gdal has a 64 bit version. Are there any issues > specific to this version? Do the c# binding work without a problem? > > Thanks > Yehiyam Livneh > > Sent from my mobile > ------------------------------ > * This message (including any attachments) issued by RAFAEL- ADVANCED > DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential > information intended for a specific individual and purpose, may constitute > information that is privileged or confidential or otherwise protected from > disclosure. If you are not the intended recipient, you should contact us > immediately and thereafter delete this message from your system. You are > hereby notified that any disclosure, copying, dissemination, distribution or > forwarding of this message, or the taking of any action based on it, is > strictly prohibited. If you have received this e-mail in error, please > notify us immediately by e-mail mailto:lawraf@rafael.co.il and completely > delete or destroy any and all electronic or other copies of the original > message and any attachments thereof. * > ------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110301/af880d5d/attachment-0001.html From sumitpandey87 at gmail.com Tue Mar 1 17:28:01 2011 From: sumitpandey87 at gmail.com (Delirious) Date: Tue Mar 1 17:28:03 2011 Subject: [gdal-dev] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N ) Message-ID: <1299018481319-6078961.post@n2.nabble.com> I am trying to convert a file in WGS format to Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), comman line input is C:\Program Files (x86)\FWTools2.4.7>gdalwarp -t_srs EPSG:26912 G:\TestData\dem43m.tif G:\TestData\opt.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. I am giving above stated error. gdalinfo of the input file is given below Size is 1201, 1201 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (74.999583333333334,36.000416666666666) Pixel Size = (0.000833333333333,-0.000833333333333) Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 74.9995833, 36.0004167) ( 74d59'58.50"E, 36d 0'1.50"N) Lower Left ( 74.9995833, 34.9995833) ( 74d59'58.50"E, 34d59'58.50"N) Upper Right ( 76.0004167, 36.0004167) ( 76d 0'1.50"E, 36d 0'1.50"N) Lower Right ( 76.0004167, 34.9995833) ( 76d 0'1.50"E, 34d59'58.50"N) Center ( 75.5000000, 35.5000000) ( 75d30'0.00"E, 35d30'0.00"N) Band 1 Block=64x64 Type=Int16, ColorInterp=Gray Am i doing anything wrong? Thanks Sumit Pandey -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Conversion-from-WGS84-to-NAD83-EPSG-26912-NAD83-UTM-zone-12N-tp6078961p6078961.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From EAdam at co.lincoln.or.us Tue Mar 1 18:03:20 2011 From: EAdam at co.lincoln.or.us (Eli Adam) Date: Tue Mar 1 18:07:49 2011 Subject: [gdal-dev] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N ) In-Reply-To: <1299018481319-6078961.post@n2.nabble.com> References: <1299018481319-6078961.post@n2.nabble.com> Message-ID: <4D6D0AB1.4F75.00CE.0@co.lincoln.or.us> Sumit, Looking at EPSG:26912 on spatial reference, http://spatialreference.org/ref/epsg/26912/ and your longitude coordinates (74-76 East, no less) makes it questionable if 26912 is an appropriate projection. That projection looks valid for western Mexico, and midwestern US/CA. You data looks to be roughly in Asia. I think that error says that it is not in a valid area of the target projection. Bests, Eli >>> On 3/1/2011 at 2:28 PM, in message <1299018481319-6078961.post@n2.nabble.com>, Delirious wrote: > I am trying to convert a file in WGS format to Conversion from WGS84 to > NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), > > comman line input is > C:\Program Files (x86)\FWTools2.4.7>gdalwarp -t_srs EPSG:26912 > G:\TestData\dem43m.tif G:\TestData\opt.tif > ERROR 1: Too many points (441 out of 441) failed to transform, > unable to compute output bounds. > > I am giving above stated error. > > gdalinfo of the input file is given below > > Size is 1201, 1201 > Coordinate System is: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > Origin = (74.999583333333334,36.000416666666666) > Pixel Size = (0.000833333333333,-0.000833333333333) > Metadata: > TIFFTAG_SOFTWARE=ERDAS IMAGINE > TIFFTAG_XRESOLUTION=1 > TIFFTAG_YRESOLUTION=1 > TIFFTAG_RESOLUTIONUNIT=1 (unitless) > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( 74.9995833, 36.0004167) ( 74d59'58.50"E, 36d 0'1.50"N) > Lower Left ( 74.9995833, 34.9995833) ( 74d59'58.50"E, 34d59'58.50"N) > Upper Right ( 76.0004167, 36.0004167) ( 76d 0'1.50"E, 36d 0'1.50"N) > Lower Right ( 76.0004167, 34.9995833) ( 76d 0'1.50"E, 34d59'58.50"N) > Center ( 75.5000000, 35.5000000) ( 75d30'0.00"E, 35d30'0.00"N) > Band 1 Block=64x64 Type=Int16, ColorInterp=Gray > > Am i doing anything wrong? > > Thanks > Sumit Pandey > From sumitpandey87 at gmail.com Tue Mar 1 18:21:09 2011 From: sumitpandey87 at gmail.com (Delirious) Date: Tue Mar 1 18:21:11 2011 Subject: [gdal-dev] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N ) In-Reply-To: <4D6D0AB1.4F75.00CE.0@co.lincoln.or.us> References: <1299018481319-6078961.post@n2.nabble.com> <4D6D0AB1.4F75.00CE.0@co.lincoln.or.us> Message-ID: <1299021669799-6079096.post@n2.nabble.com> Thanks adam, I am novice to this field. So my question might seem trivial or vague - "Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors might be high, but it should be convertible". If i want to convert this data in NAD83 datum and UTM projection what should i do? Cheers Sumit Pandey -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Conversion-from-WGS84-to-NAD83-EPSG-26912-NAD83-UTM-zone-12N-tp6078961p6079096.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From EAdam at co.lincoln.or.us Tue Mar 1 19:06:22 2011 From: EAdam at co.lincoln.or.us (Eli Adam) Date: Tue Mar 1 19:07:10 2011 Subject: [gdal-dev] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 /UTMzone 12N ) In-Reply-To: <1299021669799-6079096.post@n2.nabble.com> References: <1299018481319-6078961.post@n2.nabble.com> <4D6D0AB1.4F75.00CE.0@co.lincoln.or.us> <1299021669799-6079096.post@n2.nabble.com> Message-ID: <4D6D1976.4F75.00CE.0@co.lincoln.or.us> Sumit, There are a lot of NAD83 UTM projection zones. You need to chose the proper one. Without learning a fair amount about datums, projections, and the area where you are working, you may be best looking on wikipedia and spatial reference to guess a UTM zone that matches your general area. NAD83 is the North American Datum of 1983, you may want a different datum for your area. A rough guess that may be a decent starting place might be WGS84 UTM 45N. Datums, projections, etc are incredibly complex. USGS gives an overview here, http://egsc.usgs.gov/isb/pubs/MapProjections/projections.html I don't have any advice for any easy or quick way to select a proper datum and projection. If you know someone working with similar data in the same area, ask them. You may be best leaving the data in EPSG:4326, I don't know. HTH, Eli >>> On 3/1/2011 at 3:21 PM, in message <1299021669799-6079096.post@n2.nabble.com>, Delirious wrote: > Thanks adam, > > I am novice to this field. So my question might seem trivial or vague - > "Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors > might be high, but it should be convertible". If i want to convert this data > in NAD83 datum and UTM projection what should i do? > > Cheers > Sumit Pandey From mgleahy at alumni.uwaterloo.ca Tue Mar 1 19:11:09 2011 From: mgleahy at alumni.uwaterloo.ca (Mike Leahy) Date: Tue Mar 1 19:11:16 2011 Subject: [gdal-dev] Re: PHP bindings In-Reply-To: <20110301192531.BA1B8E021E1@lists.osgeo.org> References: <20110301192531.BA1B8E021E1@lists.osgeo.org> Message-ID: <201103011911.09753.mgleahy@alumni.uwaterloo.ca> Even/all, As you recommended, I've created a ticket for this (http://trac.osgeo.org/gdal/ticket/3984). I was able to resolve the function name conflicts (I think) that were blocking the gdal/ogr modules. After this, I find that I can get some partial functionality out of the php_ogr.so module...though some functions will also produce segfaults. However, php_gdal.so causes PHP to segfault immediately on startup if the module is loaded. I've posted some debug info in the ticket...I think it's something to do with null pointers, which I'm guessing may need to be accounted for in some way through the php typemaps. Regards, Mike > Date: Tue, 1 Mar 2011 19:59:48 +0100 > From: Even Rouault > Subject: Re: [gdal-dev] Re: PHP bindings > To: gdal-dev@lists.osgeo.org, mgleahy@alumni.uwaterloo.ca > Message-ID: <201103011959.48700.even.rouault@mines-paris.org> > Content-Type: Text/Plain; charset="utf-8" > > Mike, > > > Hello again, > > > > I think I stumbled upon the part that was tripping up the methods I was > > using with the php_osr.so library. Posted at > > http://pastebin.com/SXKKfe6v is a patch that should work on both 1.8.0, > > and the trunk svn. It adds the missing CSL typemap, and corrects the > > OGRErr related typemaps to ensure that it only returns results for > > non-zero error responses. > > I'm not sure if/when someone will act on this, but you should perhaps open > a GDAL Trac ticket and attach your patch there so it is kept in a safer > place than a pastebin that will be lost in a few days/weeks. > > > The patch also includes changes to the GNUmakefile in the swig/php folder > > to make sure that the gdal libs are linked, and that all of the php > > modules are compiles instead of just php_gdal.so (not sure if this is > > fully necessary, but I was having trouble with linking before). > > > > In addition to this, I had to substitute all instances of > > 'zend_error_noreturn' that swig inserts into the *_wrap.cpp files with > > 'zend_error'...I don't know if this is just specific to my environment, > > but the best I could determine from searching online is that more recent > > versions of PHP no longer define zend_error_noreturn, yet swig still > > uses it. It seems that zend_error is a sufficient substitute (without > > this, I would find that when the module raised errors, it would cause a > > segfault instead of actually producing a descriptive error in > > Apache/PHP). > > Perhaps something to share with the swig mailing list ? > > > If this patch is applied and gdal is configured/compiled with the > > '--with-php' option, then when swig/php/php_osr.so is installed and > > loaded into the PHP environment, the following PHP script will work as > > expected: > > > > > include("/path/to/gdal/swig/php/osr.php"); > > $sr = new SpatialReference(); > > $sr->ImportFromProj4('+init=epsg:4326'); > > echo $sr->ExportToProj4(); > > ?> > > > > This is about as far as I can get for now - looking through > > typemaps_php.i, I think I see plenty of stuff that still needs > > fixing/updating. There are also function name conflicts if I try to > > load php_gdal.so and/or php_ogr.so. I think that's out of my league, > > however. Hopefully this is enough to peak the interest of someone who > > has a little more familarity with c/swig/php, and we could get a more > > fully-supported set of PHP bindings. > > > > Best regards, > > Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110301/aad884ad/attachment-0001.html From jmckenna at gatewaygeomatics.com Wed Mar 2 09:46:02 2011 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Wed Mar 2 09:46:06 2011 Subject: [gdal-dev] Re: PHP bindings In-Reply-To: <201102071857.42980.mgleahy@alumni.uwaterloo.ca> References: <201102061450.35281.mgleahy@alumni.uwaterloo.ca> <201102071857.42980.mgleahy@alumni.uwaterloo.ca> Message-ID: <4D6E582A.5080006@gatewaygeomatics.com> > > On Sunday, February 06, 2011 14:50:34 Mike Leahy wrote: > > > Hello List, > > > > > > Does anyone have an idea if there is any likelihood for a revival of php > > > bindings for GDAL/OGR. I know if these were available, I'd be making use > > > of them...although, I have no experience creating/maintaining SWIG > > > libraries. So I'm curious to know what someone would need to know to get > > > started on this, and how big of a job would it likely be? > Just a quick note, that MapServer for Windows (MS4W) has always included the php_ogr extension...and if you are curious about where that project lives here is how to checkout the php_ogr code through CVS: % cvs -d :pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot login Password: % cvs -d :pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot co php_ogr Hope that helps. If you have questions about MS4W and its use of the php_ogr extension please use the MS4W mailing list (subscribe at http://lists.maptools.org/mailman/listinfo/ms4w-users) -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From bhudspeth at edac.unm.edu Wed Mar 2 12:00:16 2011 From: bhudspeth at edac.unm.edu (William Hudspeth) Date: Wed Mar 2 12:00:20 2011 Subject: [gdal-dev] Problems generating float32 geotiffs using OSGEO gdal python bindings Message-ID: <1299085216.1471.9.camel@wilbur-desktop> Hello, I am trying to export a numPY float array/matrix to a Lambert Conformal Geotiff/Float32 image. While the script exports an image, all pixel values are zero. May numpy array seems to be built correctly, and when I print it, looks like this... [[ 0.03678615 0.0390082 0.04026087 ..., 0.03603812 0.03531498 0.03276101] [ 0.03677472 0.03901754 0.04030903 ..., 0.03583324 0.0350121 0.03258276] [ 0.03676465 0.03900253 0.04031235 ..., 0.03625959 0.03476617 0.03255093] ..., [ 0.03522387 0.03507313 0.03519889 ..., 0.03515329 0.03527898 0.03535137] [ 0.03499253 0.03495976 0.03493112 ..., 0.03491645 0.03497614 0.0349773 ] [ 0.03486236 0.03487948 0.03492932 ..., 0.03490033 0.03487814 0.03489009]] ..... My python code for the export is: floatNumPyArray=floatNumPyArray(numpy.float) format="GTiff" dst_driver=GetDriverByName(format) srs=osr.SpatialReference() srs.ImportFromProj4('+proj=lcc +lat_1=33 +lat_2=45 +lat_0=40 +lon_0=-97 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs') output=dst_driver.Create(LambertOutput.tif,cols,rows,1,GDT_Float32) lambert_geotransform=[-1440000,4000,0.0,84000,0.0,-4000] output.SetGeoTransform(lambert_geotransform) output.SetProjection(srs.ExportToWkt()) output.GetRasterBand(1).WriteArray(floatNumPyArray) Thanks in advance for any help... Bill From wbhk at unm.edu Wed Mar 2 11:49:06 2011 From: wbhk at unm.edu (William Hudspeth) Date: Wed Mar 2 12:19:11 2011 Subject: [gdal-dev] Problems exporting numPY array to float Geotiff using OSGEO gdal python bindings Message-ID: <1299084546.1471.8.camel@wilbur-desktop> Hello, I am trying to export a numPY float array/matrix to a Lambert Conformal Geotiff/Float32 image. While the script exports an image, all pixel values are zero. May numpy array seems to be built correctly, and when I print it, looks like this... [[ 0.03678615 0.0390082 0.04026087 ..., 0.03603812 0.03531498 0.03276101] [ 0.03677472 0.03901754 0.04030903 ..., 0.03583324 0.0350121 0.03258276] [ 0.03676465 0.03900253 0.04031235 ..., 0.03625959 0.03476617 0.03255093] ..., [ 0.03522387 0.03507313 0.03519889 ..., 0.03515329 0.03527898 0.03535137] [ 0.03499253 0.03495976 0.03493112 ..., 0.03491645 0.03497614 0.0349773 ] [ 0.03486236 0.03487948 0.03492932 ..., 0.03490033 0.03487814 0.03489009]] ..... My python code for the export is: floatNumPyArray=floatNumPyArray(numpy.float) format="GTiff" dst_driver=GetDriverByName(format) srs=osr.SpatialReference() srs.ImportFromProj4('+proj=lcc +lat_1=33 +lat_2=45 +lat_0=40 +lon_0=-97 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs') output=dst_driver.Create(LambertOutput.tif,cols,rows,1,GDT_Float32) lambert_geotransform=[-1440000,4000,0.0,84000,0.0,-4000] output.SetGeoTransform(lambert_geotransform) output.SetProjection(srs.ExportToWkt()) output.GetRasterBand(1).WriteArray(floatNumPyArray) Thanks in advance for any help... Bill From Chris.Barker at noaa.gov Wed Mar 2 16:08:44 2011 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed Mar 2 16:08:49 2011 Subject: [gdal-dev] Problems exporting numPY array to float Geotiff using OSGEO gdal python bindings In-Reply-To: <1299084546.1471.8.camel@wilbur-desktop> References: <1299084546.1471.8.camel@wilbur-desktop> Message-ID: <4D6EB1DC.8040506@noaa.gov> On 3/2/11 8:49 AM, William Hudspeth wrote: > Geotiff/Float32 image. While the script exports an image, all pixel ... > My python code for the export is: > > floatNumPyArray=floatNumPyArray(numpy.float) I don't know if this is your problem, but numpy.float is a 64 bitfloat, you might try numpy.float32 Also, that call doesn't look right, do you want? floatNumPyArray=floatNumPyArray.astype(numpy.float32) That will convert a numpy array to the float32 type. HTH, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From mgleahy at alumni.uwaterloo.ca Thu Mar 3 05:41:29 2011 From: mgleahy at alumni.uwaterloo.ca (Mike Leahy) Date: Thu Mar 3 05:41:36 2011 Subject: [gdal-dev] Re: gdal-dev Digest, Vol 82, Issue 4 In-Reply-To: <20110302170018.1505EE0227B@lists.osgeo.org> References: <20110302170018.1505EE0227B@lists.osgeo.org> Message-ID: <201103030541.29693.mgleahy@alumni.uwaterloo.ca> Hi Jeff, I was aware of the php_ogr module in the MS4W project...if I was working in the Windows environment I would certainly consider that first for the ogr functionality. But it would also be nice to be able to get this in the Linux environment...as well as to get the gdal and osr modules running. I've updated the trac ticket I submitted (http://trac.osgeo.org/gdal/ticket/3984) with an extra fix that was causing segfaults when using the CreateGeometryFromWkt method in the ogr module. The gdal module still segfaults on startup, however...and I'm sure there's plenty of other bits that will still need fixing. Mike > Date: Wed, 02 Mar 2011 10:46:02 -0400 > From: Jeff McKenna > Subject: Re: [gdal-dev] Re: PHP bindings > To: gdal-dev@lists.osgeo.org > Message-ID: <4D6E582A.5080006@gatewaygeomatics.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Just a quick note, that MapServer for Windows (MS4W) has always included > the php_ogr extension...and if you are curious about where that project > lives here is how to checkout the php_ogr code through CVS: > > % cvs -d :pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot login > Password: > > % cvs -d :pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot co > php_ogr > > Hope that helps. If you have questions about MS4W and its use of the > php_ogr extension please use the MS4W mailing list (subscribe at > http://lists.maptools.org/mailman/listinfo/ms4w-users) > > -jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/be3967ad/attachment.html From a.leclerc at valabre.com Thu Mar 3 08:04:05 2011 From: a.leclerc at valabre.com (Alexandre Leclerc) Date: Thu Mar 3 08:10:50 2011 Subject: [gdal-dev] Polygon Message-ID: <002101cbd9a3$79fef600$6dfce200$@leclerc@valabre.com> Hello I try to draw a polygon from shapefile on geoconcept. But the points that I get are corrupted. Strangely a shapefile with no prj, and one ring in WGS84 works. Here I try with a prj with lambert 2 extend projection. The shapefile contains 2 rings. See my code below. ifstream Prj; Prj.open(PrjPath,ios::in); if(Prj.is_open()) { /*-----------read of PRJ--------------*/ Prj.seekg(0, ios::end); int size = Prj.tellg(); Prj.seekg(0,ios::beg); char * Buffer = new char[size+1]; Prj.read(Buffer,size); /*---------------------------------------*/ Buffer[size+1]='\0'; OGRSpatialReference oSRS, oSRS2; OGRCoordinateTransformation *poCT; oSRS.importFromESRI(&Buffer); oSRS2.SetGeogCS( "My geographic coordinate system", "WGS_1984", "My WGS84 Spheroid", SRS_WGS84_SEMIMAJOR, SRS_WGS84_INVFLATTENING, "Greenwich", 0.0, "degree", atoi(SRS_UA_DEGREE_CONV)); poCT = OGRCreateCoordinateTransformation(&oSRS,&oSRS2); if((poCT == NULL)||(poPoly->transform(poCT)!= OGRERR_NONE)) //Convert lambert 2 to WGS84 { MessageBox(NULL,"Erreur, R?essayez","Erreur",MB_ICONERROR); PRJ = true; return; } } Prj.close(); int nparts = poPoly->getNumInteriorRings(); if(nparts==0) nparts = 1; for(int n=0;ngetNumInteriorRings()>0) //if I understand correctly, through the function poRing = poPoly->getInteriorRing(n); // OGRGeometryFactory::organizePolygons() of else //SHPReadOGRObject, all the outer rings are converted in inner rings poRing = poPoly->getExteriorRing(); //so if there is more rings than 0, there is many interior rings //else getInteriorRing(n) should be give the N rings //but the function gives one ring with one point which as an incorrect value const LPXTNPOINT3D tabPoints = new XTNPOINT3D[poRing->getNumPoints()]; //Tab of points for draw ring for(i=0;igetNumPoints();i++) // Loop To Assign Points good projection { XTNPROJECTIONINFO xtnProjectionInfo = XtnStartMapProjection(xtnMapID); // Creating a projection for the coordinates LPXTNPROJECTION lpxtnProjection = new XTNPROJECTION; //--------------------------------------------------------------- lpxtnProjection->prLongitude = poRing->getX(i)*3.1415926535/180; //Longitude point conversion in Projected lpxtnProjection->prLatitude = poRing->getY(i)*3.1415926535/180; //Latitude-------------------------------------- XtnProjection_Do(xtnProjectionInfo, lpxtnProjection); //Projection conversion XtnProjection_Destroy(xtnProjectionInfo); tabPoints[i].X =((long)((double)(lpxtnProjection->prX * 100.0 + 1.0))) / 100; //Conversion long tabPoints[i].Y =((long)((double)(lpxtnProjection->prY * 100.0 + 1.0))) / 100; tabPoints[i].Z = 0 ; } XtnGeom_SetPoints(MaForme,n,poRing->getNumPoints(),tabPoints); // Insertion Points in the figure } So, can you help me to fix my problem please ? Sincerely. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/ebbb9051/attachment-0001.html From a.leclerc at valabre.com Thu Mar 3 08:40:21 2011 From: a.leclerc at valabre.com (Alexandre Leclerc) Date: Thu Mar 3 08:40:28 2011 Subject: [gdal-dev] Polygon(suite) Message-ID: <003501cbd9a8$8bda6530$a38f2f90$@leclerc@valabre.com> Sorry, I forgot to tell you that I used SHPReadOGRObject for read the SHPObject. put it at the beginning of the code of previous mail SHPHandle hSHP = SHPOpen(chemin.c_str(),"rb"); SHPObject *psShape = SHPReadObject(hSHP,0); OGRGeometry *poPoly = SHPReadOGRObject(hSHP, 0,psShape); Sincerly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/5eb89ab7/attachment.html From chaitanya.ch at gmail.com Thu Mar 3 10:24:39 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 3 10:24:47 2011 Subject: [gdal-dev] Polygon In-Reply-To: <-3552216435185692850@unknownmsgid> References: <-3552216435185692850@unknownmsgid> Message-ID: Alexandre, Can you send your code as a .cpp file as an attachment? Also, I think you should change the line Buffer[size+1]='\0'; to Buffer[size]='\0'; On Thu, Mar 3, 2011 at 6:34 PM, Alexandre Leclerc wrote: > Hello I try to draw a polygon from shapefile on geoconcept. > > > > But the points that I get are corrupted. > > > > Strangely a shapefile with no prj, and one ring in WGS84 works. > > > > Here I try with a prj with lambert 2 extend projection. > > > > The shapefile contains 2 rings. > > > > See my code below. > > > > > > ifstream Prj; > > Prj.open(PrjPath,ios::in); > > > if(Prj.is_open()) > > { > > > > /*-----------read of PRJ--------------*/ > > Prj.seekg(0, > ios::end); > > int size = > Prj.tellg(); > > Prj.seekg(0,ios::beg); > > > char * Buffer = new char[size+1]; > > Prj.read(Buffer,size); > > /*---------------------------------------*/ > > > > Buffer[size+1]='\0'; > > > > OGRSpatialReference oSRS, oSRS2; > > OGRCoordinateTransformation *poCT; > > > > oSRS.importFromESRI(&Buffer); > > oSRS2.SetGeogCS( "My geographic coordinate system", > > "WGS_1984", > > "My WGS84 Spheroid", > > SRS_WGS84_SEMIMAJOR, > SRS_WGS84_INVFLATTENING, > > "Greenwich", 0.0, > > "degree", > atoi(SRS_UA_DEGREE_CONV)); > > > > poCT = > OGRCreateCoordinateTransformation(&oSRS,&oSRS2); > > > > > > if((poCT == NULL)||(poPoly->transform(poCT)!= OGRERR_NONE)) > //Convert lambert 2 to WGS84 > > { > > MessageBox(NULL,"Erreur, > R?essayez","Erreur",MB_ICONERROR); > > PRJ = true; > > return; > > } > > > > } > > Prj.close(); > > > > int nparts = poPoly->getNumInteriorRings(); > > > > if(nparts==0) > > nparts = 1; > > > > for(int > n=0;n npart? > > { > > OGRLinearRing *poRing; > > > > if(poPoly->getNumInteriorRings()>0) > //if I understand correctly, through the function > > poRing = > poPoly->getInteriorRing(n); // > OGRGeometryFactory::organizePolygons() of > > else > //SHPReadOGRObject, > all the outer rings are converted in inner rings > > poRing = > poPoly->getExteriorRing(); //so if there is > more rings than 0, there is many interior rings > > > //else getInteriorRing(n) should be give the N rings > > > //but the function gives one ring with one point which as an incorrect value > > > > > const LPXTNPOINT3D tabPoints = new > XTNPOINT3D[poRing->getNumPoints()]; //Tab of points for draw ring > > > > for(i=0;igetNumPoints();i++) > > // Loop To Assign Points good projection > > { > > XTNPROJECTIONINFO xtnProjectionInfo = > XtnStartMapProjection(xtnMapID); // Creating a > projection for the coordinates > > LPXTNPROJECTION lpxtnProjection = new > XTNPROJECTION; > //--------------------------------------------------------------- > > > > lpxtnProjection->prLongitude = > poRing->getX(i)*3.1415926535/180; > //Longitude point conversion in Projected > > lpxtnProjection->prLatitude = > poRing->getY(i)*3.1415926535/180; > //Latitude-------------------------------------- > > > > XtnProjection_Do(xtnProjectionInfo, > lpxtnProjection); //Projection > conversion > > XtnProjection_Destroy(xtnProjectionInfo); > > > > tabPoints[i].X > =((long)((double)(lpxtnProjection->prX * 100.0 + 1.0))) / 100; //Conversion > long > > tabPoints[i].Y > =((long)((double)(lpxtnProjection->prY * 100.0 + 1.0))) / 100; > > tabPoints[i].Z = 0 ; > > } > > > XtnGeom_SetPoints(MaForme,n,poRing->getNumPoints(),tabPoints); > // Insertion Points in the figure > > } > > > > > > So, can you help me to fix my problem please ? > > > > Sincerely. > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/a584d6e1/attachment-0001.html From mafunk at nmsu.edu Thu Mar 3 19:33:30 2011 From: mafunk at nmsu.edu (Matt Funk) Date: Thu Mar 3 19:33:28 2011 Subject: [gdal-dev] gdal and hdf-eos Message-ID: <4D70335A.8040601@nmsu.edu> Hi, i am using python/gdal. I am trying to open a MODIS satellite file from the Terra satellite (which is hdf4-eos format). Doing: ds = gdal.Open(file) drivertype=ds.GetDriver().LongName returns ERROR 4: `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' not recognised as a supported file format. Is this file format not supported? thanks matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/7b73be05/attachment.html From dan.putler at sauder.ubc.ca Thu Mar 3 20:15:19 2011 From: dan.putler at sauder.ubc.ca (Dan Putler) Date: Thu Mar 3 20:16:31 2011 Subject: [gdal-dev] Python bindings to force geometry collections to mulitpoint, multipolygon, multiline Message-ID: <4D703D27.4000409@sauder.ubc.ca> All, I am currently running gdal 1.7.3, and it appears that in this version the geometry factory methods to force a geometry collection to multipoint, etc. aren't exposed to Python. Am I wrong? If not, are they exposed in gdal 1.8? Dan From chaitanya.ch at gmail.com Thu Mar 3 23:30:49 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 3 23:37:28 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: <4D70335A.8040601@nmsu.edu> References: <4D70335A.8040601@nmsu.edu> Message-ID: Matt, Did you build GDAL yourself? HDF4 format is not compiled by default. You can check if this by running the command "gdalinfo --formats". See if HDF4 is in the output. http://www.gdal.org/frmt_hdf4.html On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk wrote: > Hi, > i am using python/gdal. I am trying to open a MODIS satellite file from > the Terra satellite (which is hdf4-eos format). Doing: > ds = gdal.Open(file) > drivertype=ds.GetDriver().LongName > > returns > ERROR 4: > `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' > not recognised as a supported file format. > > Is this file format not supported? > > thanks > matt > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/bc2fc417/attachment.html From refriguy68 at yahoo.com Fri Mar 4 02:58:29 2011 From: refriguy68 at yahoo.com (Robert Zermeno) Date: Fri Mar 4 03:05:13 2011 Subject: [gdal-dev] Visual Studio 2005 Debug mode error Message-ID: <522989.51769.qm@web32906.mail.mud.yahoo.com> GDAL Devs, ? I added GDAL into my exisiting project to see how GDAL handles WMS and JPIP and I get an exception error when calling GDALAllRegister(). ? This is odd to me, but I downloaded the SVN for 3-1-2011 and made modifications in nmake.opt to handle WMS and JPIP (via kakadu v5.2) files (this is not the error). ? Here is the pop-up message display error output: ? Visual Studio ?Unhandled exception at 0x772bc41b in GDAL_DEBUG_PROBLEMS.exe: ?0xC0000005: Access violation writing location 0x5a74c985. ? ? NOW, here is the call-stack.? ? ?GetGDALDriverManager returned?0x00764360 {nDrivers=0 papoDrivers=0x00000000 pszHome=0x008794d0 "" }?GDALDriverManager * pData?0x00879580?void * >?gdal19dev.dll!VSIFree(void * pData=0x00879580)? Line 573 + 0xa bytes?C++ ??gdal19dev.dll!VSIWin32FilesystemHandler::ReadDir(const char * pszPath=0x007694e8)? Line 622 + 0x9 bytes?C++ ??gdal19dev.dll!VSIReadDir(const char * pszPath=0x007694e8)? Line 67?C++ ??gdal19dev.dll!GDALDriverManager::AutoLoadDrivers()? Line 686 + 0x11 bytes?C++ ??gdal19dev.dll!GDALAllRegister()? Line 79?C++ ??GDAL_DEBUG_PROBLEMS.exe!wmain(int argc=1, wchar_t * * argv=0x00874e68)? Line 43?C++ ??GDAL_DEBUG_PROBLEMS.exe!__tmainCRTStartup()? Line 594 + 0x19 bytes?C ??GDAL_DEBUG_PROBLEMS.exe!wmainCRTStartup()? Line 414?C ? ? ? >From what I see, the problem lies in the method call in gdalallregister.cpp line 76: GetGDALDriverManager()->AutoLoadDrivers(); ? This should not happen.? What is odd is if I build it in Release mode, I do not get this issue.? However, that defeats the purpose because I want to step through the code. ? Anyone can confirm my problem?? Solutions why only in Debug mode this occurs? ? Any suggestions would be great, ? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110303/0af52ad1/attachment.html From goocreations at gmail.com Fri Mar 4 04:38:11 2011 From: goocreations at gmail.com (Goo Creations) Date: Fri Mar 4 04:38:12 2011 Subject: [gdal-dev] gdalwarp without metadata Message-ID: Hi all I'm using gdal warp to warp a jpeg (with world file) to GeoTiff. After the Tif was created, I can open it in any image viewer and the image looks fine (width, height and correct rotation) When I open the image in any GIS software (eg: QGIS or FreeView) the image is rotated twice as much as it should. I think that gdalwarp warps (rotates) the image pixel itselfs and additionally stores the info in the tif header. So when I open the image, the already rotated pixels get rotated again. Is there any way I can pass gdalwarp a flag that either doesn't store the metadata (if this is the problem) or doesn't rotate the pixels? Chris From goocreations at gmail.com Fri Mar 4 04:47:07 2011 From: goocreations at gmail.com (Goo Creations) Date: Fri Mar 4 04:47:09 2011 Subject: [gdal-dev] gdalwarp without metatdat Message-ID: Hi again Sorry about this, the problem is solved. I actually needed gdal_translate. Sorry for the inconvenience. Chris From even.rouault at mines-paris.org Fri Mar 4 04:48:14 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 4 04:48:23 2011 Subject: [gdal-dev] gdalwarp without metadata In-Reply-To: References: Message-ID: <1299232094.4d70b55e964a1@webmail.free.fr> Selon Goo Creations : It should just work. Perhaps retry by deleting first the output file and then running gdalwarp, in case the output file had pre-existing inconsistant georeferencing information (gdalwarp doesn't recreate from scratch existing output files, unless you pass the -overwrite parameter which was added in GDAL 1.8.0). Make also sure you have no .tfw file matching the output filename that would lay around. > Hi all > > I'm using gdal warp to warp a jpeg (with world file) to GeoTiff. After > the Tif was created, I can open it in any image viewer and the image > looks fine (width, height and correct rotation) > When I open the image in any GIS software (eg: QGIS or FreeView) the > image is rotated twice as much as it should. > > I think that gdalwarp warps (rotates) the image pixel itselfs and > additionally stores the info in the tif header. So when I open the > image, the already rotated pixels get rotated again. > Is there any way I can pass gdalwarp a flag that either doesn't store > the metadata (if this is the problem) or doesn't rotate the pixels? > > Chris > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From a.leclerc at valabre.com Fri Mar 4 05:02:56 2011 From: a.leclerc at valabre.com (Alexandre Leclerc) Date: Fri Mar 4 05:03:03 2011 Subject: [gdal-dev] Polygon Message-ID: <001201cbda53$55db0970$01911c50$@leclerc@valabre.com> Anybody can help me please ? I feel that the SHPWriteObject() write a bad way in the file. Do you think it could come from compiler ? I use Borland C++ 6 When I edit the file in text editor it seems good, the length of the file is 1904 But when I read file with SHPOpen() the psSHP->nFileSize attribute is 100. oddly this corresponds to the size of the header (shx). So I wonder if It comes from compiler or not. What do you think ? Here in shpOpen(). /* -------------------------------------------------------------------- */ /* Read the file size from the SHP file. */ /* -------------------------------------------------------------------- */ pabyBuf = (uchar *) malloc(100); psSHP->sHooks.FRead( pabyBuf, 100, 1, psSHP->fpSHP ); psSHP->nFileSize = ((unsigned int)pabyBuf[24] * 256 * 256 * 256 + (unsigned int)pabyBuf[25] * 256 * 256 + (unsigned int)pabyBuf[26] * 256 + (unsigned int)pabyBuf[27]) * 2; Only papybuf[27] has a value (50) , others have 0 as value.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/1ccc8e03/attachment-0001.html From chaitanya.ch at gmail.com Fri Mar 4 06:31:49 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Fri Mar 4 06:31:51 2011 Subject: [gdal-dev] Polygon In-Reply-To: <-8144916393913145814@unknownmsgid> References: <-8144916393913145814@unknownmsgid> Message-ID: Alexandre, Did you check the file before trying it with your application? What do you get if you run "ogrinfo -al "? On Fri, Mar 4, 2011 at 3:32 PM, Alexandre Leclerc wrote: > Anybody can help me please ? > > > > I feel that the SHPWriteObject() write a bad way in the file. > > > > Do you think it could come from compiler ? I use Borland C++ 6 > > > > When I edit the file in text editor it seems good, the length of the file > is 1904 > > > > But when I read file with SHPOpen() the psSHP->nFileSize attribute is 100? > oddly this corresponds to the size of the header (shx). > > > > So I wonder if It comes from compiler or not? > > > > What do you think ? > > > > Here in shpOpen(). > > > > /* -------------------------------------------------------------------- */ > > /* Read the file size from the SHP > file. */ > > /* -------------------------------------------------------------------- */ > > pabyBuf = (uchar *) malloc(100); > > psSHP->sHooks.FRead( pabyBuf, 100, 1, psSHP->fpSHP ); > > > > psSHP->nFileSize = ((unsigned int)pabyBuf[24] * 256 * 256 * 256 > > + (unsigned int)pabyBuf[25] > * 256 * 256 > > + (unsigned int)pabyBuf[26] > * 256 > > + (unsigned int)pabyBuf[27]) > * 2; > > > > > > Only papybuf[27] has a value (50) , others have 0 as value?. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/c5c0f4ac/attachment.html From warmerdam at pobox.com Fri Mar 4 07:47:46 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 4 07:47:49 2011 Subject: [gdal-dev] Polygon In-Reply-To: <001201cbda53$55db0970$01911c50$@leclerc@valabre.com> References: <001201cbda53$55db0970$01911c50$@leclerc@valabre.com> Message-ID: <4D70DF72.9010908@pobox.com> On 11-03-04 05:02 AM, Alexandre Leclerc wrote: > Anybody can help me please ? > > I feel that the SHPWriteObject() write a bad way in the file. > > Do you think it could come from compiler ? I use Borland C++ 6 > > When I edit the file in text editor it seems good, the length of the file is 1904 > > But when I read file with SHPOpen() the psSHP->nFileSize attribute is 100? > oddly this corresponds to the size of the header (shx). > > So I wonder if It comes from compiler or not? > > What do you think ? Alexandre, It sounds like you neglected to close the file so the header remains as it was on creation. Shapelib related questions are better sent to the Shapelib mailing list. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From dmorissette at mapgears.com Fri Mar 4 07:57:11 2011 From: dmorissette at mapgears.com (Daniel Morissette) Date: Fri Mar 4 07:57:14 2011 Subject: [gdal-dev] OSGeo Montreal Code Sprint seeking more sponsors due to record participation Message-ID: <4D70E1A7.3020500@mapgears.com> Dear GDAL/OGR users, The Montreal Code Sprint of March 15-18, 2011 has reached a record of 29 registered participants from 9 open source projects as of yesterday. This is awesome news for OSGeo and its projects that will get a significant boost of code and contributions during that week! This will also greatly benefit the GDAL/OGR project since this number includes 6 people who signed up to work on GDAL/OGR as you can see in the list of participants at: http://wiki.osgeo.org/wiki/Montreal_Code_Sprint_2011#Participation The downside of this is that our initial budget was for ~20 participants, and with close to 50% more sprinters we need to adjust the budget accordingly and are turning to you to help us find more sponsors to balance the new budget. ** CALL FOR NEW SPONSORS - An investment in the technology that you use! ** We are looking for another round of sponsors ($750 each) to support food and fun for the sprinters as they work hard and play hard for four productive days. Each $750 sponsorship will be put towards lunch, snacks and dinner costs for the sprinters, and any surplus at the end of the event will be turned over to OSGeo or used for a future code sprint. If your organization is using one of the software projects listed below, then please consider this call for sponsorship as an investment in GDAL/OGR, the technology that you use, and contact me at dmorissette at mapgears.com to confirm your sponsorship. In addition to visibility in our public announcements you will get recognition for your contribution from the developers and from the OSGeo community. Please also keep in mind that all the participants are volunteering several days of their time in addition to paying for their own travel and hotel expenses. More information about this event is available here: http://wiki.osgeo.org/wiki/Montreal_Code_Sprint_2011 The Open Source projects currently represented are: * MapServer * GDAL/OGR * PostGIS * libLAS * ZOO Project * TinyOWS * GeoPrisma * OpenLayers * GeoExt Thank you once again to our current sponsors (http://wiki.osgeo.org/wiki/Montreal_Code_Sprint_2011#2011_Sponsors) 750$ Sponsors: - LizardTech - http://www.lizardtech.com/ - Azavea - http://www.azavea.com/ - qPublic - http://qpublic.net/ - Farallon Geographics - http://fargeo.com/ - Airborne Interactive - http://airborne.aero/ - Boreal - Information Strategies (Borealis) - http://www.boreal-is.com/ - Mapgears - http://www.mapgears.com/ Hockey Night Sponsor: - Gateway Geomatics - http://gatewaygeomatics.com/ Host (Room and Internet): - Communaut? M?tropolitaine de Montr?al (CMM) - http://cmm.qc.ca/ Please do not hesitate to redistribute this announcement in your respective channels. Daniel -- Daniel Morissette http://www.mapgears.com/ From mateusz at loskot.net Fri Mar 4 08:02:10 2011 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri Mar 4 08:03:14 2011 Subject: [gdal-dev] Visual Studio 2005 Debug mode error In-Reply-To: <522989.51769.qm@web32906.mail.mud.yahoo.com> References: <522989.51769.qm@web32906.mail.mud.yahoo.com> Message-ID: <4D70E2D2.6030209@loskot.net> On 04/03/11 07:58, Robert Zermeno wrote: > This should not happen. What is odd is if I build it in Release > mode, I do not get this issue. However, that defeats the purpose > because I want to step through the code > Anyone can confirm my problem? Solutions why only in Debug mode this occurs? > Any suggestions would be great, GDAL debug mode is not a real debug mode as expected by Visual C++ and it is a known issue which IMHO is a bug in GDAL, but there are different opinions about that. The only fix is: http://lists.osgeo.org/pipermail/gdal-dev/2010-May/024683.html You can find quite a number of of related tickets: http://trac.osgeo.org/gdal/ticket/1647 http://trac.osgeo.org/gdal/ticket/540 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org From mafunk at nmsu.edu Fri Mar 4 12:31:45 2011 From: mafunk at nmsu.edu (Matt Funk) Date: Fri Mar 4 12:31:39 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: References: <4D70335A.8040601@nmsu.edu> Message-ID: <4D712201.2070007@nmsu.edu> Hi Chaitanya, no, i didn't build it myself. I simply downloaded the self-installing package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ I am a little unfamiliar still with building stuff on windows, so i am not sure whether it's worth trying to build gdal and the python bindings from scratch or simply use h4toh5 called from the script. thanks matt On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: > Matt, > > Did you build GDAL yourself? HDF4 format is not compiled by default. > You can check if this by running the command "gdalinfo --formats". See > if HDF4 is in the output. > http://www.gdal.org/frmt_hdf4.html > > On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk > wrote: > > Hi, > i am using python/gdal. I am trying to open a MODIS satellite file > from the Terra satellite (which is hdf4-eos format). Doing: > ds = gdal.Open(file) > drivertype=ds.GetDriver().LongName > > returns > ERROR 4: > `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' > not recognised as a supported file format. > > Is this file format not supported? > > thanks > matt > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/6c659a5e/attachment.html From chaitanya.ch at gmail.com Fri Mar 4 13:03:44 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Fri Mar 4 13:03:47 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: <4D712201.2070007@nmsu.edu> References: <4D70335A.8040601@nmsu.edu> <4D712201.2070007@nmsu.edu> Message-ID: Matt, If there is a work around it's better to avoid building. HDF4 requires some extra libraries. They are probably missing. On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk wrote: > Hi Chaitanya, > no, i didn't build it myself. I simply downloaded the self-installing > package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ > I am a little unfamiliar still with building stuff on windows, so i am not > sure whether it's worth trying to build gdal and the python bindings from > scratch or simply use h4toh5 called from the script. > > thanks > matt > > > On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: > > Matt, > > Did you build GDAL yourself? HDF4 format is not compiled by default. You > can check if this by running the command "gdalinfo --formats". See if HDF4 > is in the output. > http://www.gdal.org/frmt_hdf4.html > > On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk wrote: > >> Hi, >> i am using python/gdal. I am trying to open a MODIS satellite file from >> the Terra satellite (which is hdf4-eos format). Doing: >> ds = gdal.Open(file) >> drivertype=ds.GetDriver().LongName >> >> returns >> ERROR 4: >> `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' >> not recognised as a supported file format. >> >> Is this file format not supported? >> >> thanks >> matt >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/9106deaa/attachment.html From bhudspeth at edac.unm.edu Fri Mar 4 13:23:35 2011 From: bhudspeth at edac.unm.edu (Wilbur60) Date: Fri Mar 4 13:23:37 2011 Subject: [gdal-dev] Re: Problems exporting numPY array to float Geotiff using OSGEO gdal python bindings In-Reply-To: <4D6EB1DC.8040506@noaa.gov> References: <1299084546.1471.8.camel@wilbur-desktop> <4D6EB1DC.8040506@noaa.gov> Message-ID: <1299263015555-6089518.post@n2.nabble.com> Chris, Thanks for responding.... Your suggestion worked! Because the values are all very low, I am having to contrast stretch the images to actually be able to see anything, but the floats are coming coming through the file creation. Thanks again, Bill -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Problems-exporting-numPY-array-to-float-Geotiff-using-OSGEO-gdal-python-bindings-tp6081833p6089518.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From nhatzop at gmail.com Fri Mar 4 13:50:04 2011 From: nhatzop at gmail.com (Nikolaos Hatzopoulos) Date: Fri Mar 4 13:50:22 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: References: <4D70335A.8040601@nmsu.edu> <4D712201.2070007@nmsu.edu> Message-ID: what extra libraries requires hdf4? i think only requires szip zlib and jpeg On Fri, Mar 4, 2011 at 10:03 AM, Chaitanya kumar CH wrote: > Matt, > > If there is a work around it's better to avoid building. HDF4 requires some > extra libraries. They are probably missing. > > > On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk wrote: > >> Hi Chaitanya, >> no, i didn't build it myself. I simply downloaded the self-installing >> package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ >> I am a little unfamiliar still with building stuff on windows, so i am not >> sure whether it's worth trying to build gdal and the python bindings from >> scratch or simply use h4toh5 called from the script. >> >> thanks >> matt >> >> >> On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: >> >> Matt, >> >> Did you build GDAL yourself? HDF4 format is not compiled by default. You >> can check if this by running the command "gdalinfo --formats". See if HDF4 >> is in the output. >> http://www.gdal.org/frmt_hdf4.html >> >> On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk wrote: >> >>> Hi, >>> i am using python/gdal. I am trying to open a MODIS satellite file from >>> the Terra satellite (which is hdf4-eos format). Doing: >>> ds = gdal.Open(file) >>> drivertype=ds.GetDriver().LongName >>> >>> returns >>> ERROR 4: >>> `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' >>> not recognised as a supported file format. >>> >>> Is this file format not supported? >>> >>> thanks >>> matt >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> >> >> -- >> Best regards, >> Chaitanya kumar CH. >> /t?a???nj?/ /k?m?r/ >> +91-9494447584 >> 17.2416N 80.1426E >> >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/3b6a5351/attachment.html From chaitanya.ch at gmail.com Fri Mar 4 13:57:01 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Fri Mar 4 13:57:04 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: References: <4D70335A.8040601@nmsu.edu> <4D712201.2070007@nmsu.edu> Message-ID: GDAL's HDF4 driver is built on top of NCSA HDF library. On Sat, Mar 5, 2011 at 12:20 AM, Nikolaos Hatzopoulos wrote: > what extra libraries requires hdf4? i think only requires szip zlib and > jpeg > > > > On Fri, Mar 4, 2011 at 10:03 AM, Chaitanya kumar CH gmail.com> wrote: > >> Matt, >> >> If there is a work around it's better to avoid building. HDF4 requires >> some extra libraries. They are probably missing. >> >> >> On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk wrote: >> >>> Hi Chaitanya, >>> no, i didn't build it myself. I simply downloaded the self-installing >>> package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ >>> I am a little unfamiliar still with building stuff on windows, so i am >>> not sure whether it's worth trying to build gdal and the python bindings >>> from scratch or simply use h4toh5 called from the script. >>> >>> thanks >>> matt >>> >>> >>> On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: >>> >>> Matt, >>> >>> Did you build GDAL yourself? HDF4 format is not compiled by default. You >>> can check if this by running the command "gdalinfo --formats". See if HDF4 >>> is in the output. >>> http://www.gdal.org/frmt_hdf4.html >>> >>> On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk wrote: >>> >>>> Hi, >>>> i am using python/gdal. I am trying to open a MODIS satellite file from >>>> the Terra satellite (which is hdf4-eos format). Doing: >>>> ds = gdal.Open(file) >>>> drivertype=ds.GetDriver().LongName >>>> >>>> returns >>>> ERROR 4: >>>> `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' >>>> not recognised as a supported file format. >>>> >>>> Is this file format not supported? >>>> >>>> thanks >>>> matt >>>> >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Chaitanya kumar CH. >>> /t?a???nj?/ /k?m?r/ >>> +91-9494447584 >>> 17.2416N 80.1426E >>> >>> >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> >> >> -- >> Best regards, >> Chaitanya kumar CH. >> /t?a???nj?/ /k?m?r/ >> +91-9494447584 >> 17.2416N 80.1426E >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110305/c83fb699/attachment-0001.html From nhatzop at gmail.com Fri Mar 4 14:57:36 2011 From: nhatzop at gmail.com (Nikolaos Hatzopoulos) Date: Fri Mar 4 14:57:38 2011 Subject: [gdal-dev] gdal and hdf-eos In-Reply-To: References: <4D70335A.8040601@nmsu.edu> <4D712201.2070007@nmsu.edu> Message-ID: you are not compiling things from source? On Fri, Mar 4, 2011 at 10:57 AM, Chaitanya kumar CH wrote: > GDAL's HDF4 driver is built on top of NCSA HDF library. > > On Sat, Mar 5, 2011 at 12:20 AM, Nikolaos Hatzopoulos wrote: > >> what extra libraries requires hdf4? i think only requires szip zlib and >> jpeg >> >> >> >> On Fri, Mar 4, 2011 at 10:03 AM, Chaitanya kumar CH > gmail.com> wrote: >> >>> Matt, >>> >>> If there is a work around it's better to avoid building. HDF4 requires >>> some extra libraries. They are probably missing. >>> >>> >>> On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk wrote: >>> >>>> Hi Chaitanya, >>>> no, i didn't build it myself. I simply downloaded the self-installing >>>> package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ >>>> I am a little unfamiliar still with building stuff on windows, so i am >>>> not sure whether it's worth trying to build gdal and the python bindings >>>> from scratch or simply use h4toh5 called from the script. >>>> >>>> thanks >>>> matt >>>> >>>> >>>> On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: >>>> >>>> Matt, >>>> >>>> Did you build GDAL yourself? HDF4 format is not compiled by default. You >>>> can check if this by running the command "gdalinfo --formats". See if HDF4 >>>> is in the output. >>>> http://www.gdal.org/frmt_hdf4.html >>>> >>>> On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk wrote: >>>> >>>>> Hi, >>>>> i am using python/gdal. I am trying to open a MODIS satellite file from >>>>> the Terra satellite (which is hdf4-eos format). Doing: >>>>> ds = gdal.Open(file) >>>>> drivertype=ds.GetDriver().LongName >>>>> >>>>> returns >>>>> ERROR 4: >>>>> `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' >>>>> not recognised as a supported file format. >>>>> >>>>> Is this file format not supported? >>>>> >>>>> thanks >>>>> matt >>>>> >>>>> _______________________________________________ >>>>> gdal-dev mailing list >>>>> gdal-dev@lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Chaitanya kumar CH. >>>> /t?a???nj?/ /k?m?r/ >>>> +91-9494447584 >>>> 17.2416N 80.1426E >>>> >>>> >>>> >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Chaitanya kumar CH. >>> /t?a???nj?/ /k?m?r/ >>> +91-9494447584 >>> 17.2416N 80.1426E >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110304/03d6fe23/attachment.html From ilias.koen at dukodestudio.com Sun Mar 6 15:24:31 2011 From: ilias.koen at dukodestudio.com (Ilia Koen) Date: Sun Mar 6 16:03:13 2011 Subject: [gdal-dev] ogr2ogr vector central meridian change, vector offset issue. Message-ID: <4D73ED7F.2010303@dukodestudio.com> Hello, We are trying to re-project the coral reef dataset via ogr2ogr for the dataset to fit the bluemarble projection. The coral reef is a vector shape dataset and it is using the Lambert Cylindrical Equal Area at -160 central meridian. Once we re-project we are getting lines connecting the shapes that are cutoff at the edges from -180 to 180. Is that a bug ? or are we doing something wrong? You can see the offset issue here http://dukodestudio.com/client_room/coralreefs/coralReefData-offsetlineissue.png Here is the location of the dataset http://www.wri.org/publication/reefs-at-risk-revisited#datasets Our command is as follows: ogr2ogr -s_srs '+proj=cea +lon_0=-160 +lat_ts=0 +x_0=0 +y_0=0' -t_srs EPSG:4326 reefPoly28.shp reef_500_poly.shp We did try to use the "-spat -180 -90 180 90" flag with the above commnd but without success. Thanks, ik. From simone.micozzi at tin.it Sun Mar 6 17:12:30 2011 From: simone.micozzi at tin.it (simone.micozzi@tin.it) Date: Sun Mar 6 17:17:38 2011 Subject: [gdal-dev] OGR mysql.sock path Message-ID: <12e8d3a94f6.simone.micozzi@tin.it> Ciao to all. How can I tell OGR where to look for the mysql.sock file? It looks for it in the standard path ( /tmp/mysql.sock ) but on my server (a MacOS XServe) the socket file is not there and I cannot simply make a link to the right path, because at every start-up my server clean the /tmp directory. Is there by any chance a configuration option where I can hardcode the right path? Thank you anyway, Simone Micozzi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110306/f9a491b0/attachment.html From even.rouault at mines-paris.org Sun Mar 6 17:47:11 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 6 17:47:20 2011 Subject: [gdal-dev] ogr2ogr vector central meridian change, vector offset issue. In-Reply-To: <4D73ED7F.2010303@dukodestudio.com> References: <4D73ED7F.2010303@dukodestudio.com> Message-ID: <201103062347.11811.even.rouault@mines-paris.org> Ilia, Try adding -wrapdateline to your command line. The wrapdateline option instructs ogr2ogr to split geometries crossing the dateline meridian. I've just tested it successfully on one of those datasets. > Hello, > We are trying to re-project the coral reef dataset via ogr2ogr for > the dataset to fit the bluemarble projection. The coral reef is a vector > shape dataset and it is using the Lambert Cylindrical Equal Area at -160 > central meridian. Once we re-project we are getting lines connecting the > shapes that are cutoff at the edges from -180 to 180. Is that a bug ? > or are we doing something wrong? > > You can see the offset issue here > http://dukodestudio.com/client_room/coralreefs/coralReefData-offsetlineissu > e.png > > > Here is the location of the dataset > http://www.wri.org/publication/reefs-at-risk-revisited#datasets > > Our command is as follows: > ogr2ogr -s_srs '+proj=cea +lon_0=-160 +lat_ts=0 +x_0=0 +y_0=0' -t_srs > EPSG:4326 reefPoly28.shp reef_500_poly.shp > > We did try to use the "-spat -180 -90 180 90" flag with the above commnd > but without success. > > Thanks, ik. > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From ilias.koen at dukodestudio.com Sun Mar 6 18:28:59 2011 From: ilias.koen at dukodestudio.com (Ilia Koen) Date: Sun Mar 6 18:29:06 2011 Subject: [gdal-dev] ogr2ogr vector central meridian change, vector offset issue. In-Reply-To: <201103062347.11811.even.rouault@mines-paris.org> References: <4D73ED7F.2010303@dukodestudio.com> <201103062347.11811.even.rouault@mines-paris.org> Message-ID: <4D7418BB.3020108@dukodestudio.com> Hi Even, I was using ogr2ogr version : GDAL 1.6.3, released 2009/11/19. I had updated to 1.8 and the issue was a re-sourcing my path. The following command worked. ogr2ogr -wrapdateline -s_srs '+proj=cea +lon_0=-160 +lat_ts=0 +x_0=0 +y_0=0' -t_srs EPSG:4326 reefPoly28.shp reef_500_poly.shp Thanks for trying the data and letting me know that it worked on your system. It really helped solve the problem. Best ik. On 3/6/11 5:47 PM, Even Rouault wrote: > Ilia, > > Try adding -wrapdateline to your command line. The wrapdateline option > instructs ogr2ogr to split geometries crossing the dateline meridian. I've > just tested it successfully on one of those datasets. > >> Hello, >> We are trying to re-project the coral reef dataset via ogr2ogr for >> the dataset to fit the bluemarble projection. The coral reef is a vector >> shape dataset and it is using the Lambert Cylindrical Equal Area at -160 >> central meridian. Once we re-project we are getting lines connecting the >> shapes that are cutoff at the edges from -180 to 180. Is that a bug ? >> or are we doing something wrong? >> >> You can see the offset issue here >> http://dukodestudio.com/client_room/coralreefs/coralReefData-offsetlineissu >> e.png >> >> >> Here is the location of the dataset >> http://www.wri.org/publication/reefs-at-risk-revisited#datasets >> >> Our command is as follows: >> ogr2ogr -s_srs '+proj=cea +lon_0=-160 +lat_ts=0 +x_0=0 +y_0=0' -t_srs >> EPSG:4326 reefPoly28.shp reef_500_poly.shp >> >> We did try to use the "-spat -180 -90 180 90" flag with the above commnd >> but without success. >> >> Thanks, ik. >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From chaitanya.ch at gmail.com Sun Mar 6 22:45:07 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Sun Mar 6 22:45:10 2011 Subject: [gdal-dev] OGR mysql.sock path In-Reply-To: <12e8d3a94f6.simone.micozzi@tin.it> References: <12e8d3a94f6.simone.micozzi@tin.it> Message-ID: Simone, I don't know about MacOS, but in Linux you can use the environment variable MYSQL_UNIX_PORT to set the location of the socket file. http://dev.mysql.com/doc/refman/5.5/en/problems-with-mysql-sock.html On Mon, Mar 7, 2011 at 3:42 AM, simone.micozzi@tin.it wrote: > Ciao to all. > > How can I tell OGR where to look for the mysql.sock file? > It looks for it in the standard path ( /tmp/mysql.sock ) > but on my server (a MacOS XServe) the socket file is not there > and I cannot simply make a link to the right path, > because at every start-up my server clean the /tmp directory. > Is there by any chance a configuration option > where I can hardcode the right path? > > Thank you anyway, > > Simone Micozzi > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110307/2e493019/attachment.html From vasile.craciunescu at gmail.com Mon Mar 7 13:37:34 2011 From: vasile.craciunescu at gmail.com (Vasile Craciunescu) Date: Mon Mar 7 13:37:39 2011 Subject: [gdal-dev] gdal_retile error Message-ID: <4D7525EE.9000504@gmail.com> Dear all, I'm trying to create tiled pyramids levels with gdal_retile.py. The input is a 441671px x 311892px VRT collection (1615 JPEG compressed GeoTiff files). The command is presented bellow: gdal_retile.py -levels 8 -ps 2048 2048 -r bilinear -v -co "TILED=YES" -co "BLOCKXSIZE=256" -co COMPRESS=JPEG -s_srs EPSG:31700 -targetDir pt merge.vrt This runs smoothly for a while (I manage to create 4151 tiles from level 0). Then throws the following error: ERROR 1: TIFFOpen:2479.tif: Operation not permitted Traceback (most recent call last): File "/usr/bin/gdal_retile.py", line 1001, in sys.exit(main(sys.argv)) File "/usr/bin/gdal_retile.py", line 911, in main dsCreatedTileIndex = tileImage(minfo,ti) File "/usr/bin/gdal_retile.py", line 349, in tileImage createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS) File "/usr/bin/gdal_retile.py", line 494, in createTile dec.uly+offsetY*dec.scaleY) File "/usr/bin/gdal_retile.py", line 257, in getDataSet t_band.WriteRaster(writeOffsetX,writeOffsetY,readX,readY,data ) File "/usr/local/lib/python2.6/dist-packages/GDAL-1.8.0-py2.6-linux-i686.egg/osgeo/gdal.py", line 941, in WriteRaster return _gdal.Band_WriteRaster(self, *args, **kwargs) TypeError: not a string After several attempts I decided to remove 2479.tif from VRT. The same error is displayed when gdal_retile reach the next file (2579.tif). I get this error on the following configuration. OS: Ubuntu server 10.10 GDAL: 1.8 Python: 2.6.5 Hardware: Dell PowerEdge 6650; 4 x Xeon 3.00Ghz dual core; 16GB DDR SDRAM; 5 x 72GB SCSI + 4TB SATA Any clues? Regards, Vasile From simone.micozzi at tin.it Mon Mar 7 19:05:54 2011 From: simone.micozzi at tin.it (simone.micozzi@tin.it) Date: Mon Mar 7 19:05:57 2011 Subject: R: Re: [gdal-dev] OGR mysql.sock path Message-ID: <12e92c8c5be.simone.micozzi@tin.it> Thank you, Chaitanya, for your reply. I'll look if in MacOS is the same as in Linux. After all it's still based on UNIX. Best regards, Simone Micozzi ----Messaggio originale---- Da: chaitanya.ch@gmail.com Data: 7-mar-2011 4.45 A: "simone.micozzi@tin.it" Cc: Ogg: Re: [gdal-dev] OGR mysql.sock path Simone, I don't know about MacOS, but in Linux you can use the environment variable MYSQL_UNIX_PORT to set the location of the socket file. http://dev.mysql.com/doc/refman/5.5/en/problems-with-mysql-sock.html On Mon, Mar 7, 2011 at 3:42 AM, simone.micozzi@tin.it wrote: Ciao to all. How can I tell OGR where to look for the mysql.sock file? It looks for it in the standard path ( /tmp/mysql.sock ) but on my server (a MacOS XServe) the socket file is not there and I cannot simply make a link to the right path, because at every start-up my server clean the /tmp directory. Is there by any chance a configuration option where I can hardcode the right path? Thank you anyway, Simone Micozzi _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110308/361cda8b/attachment.html From christian.mueller at nvoe.at Tue Mar 8 03:13:52 2011 From: christian.mueller at nvoe.at (christian.mueller@nvoe.at) Date: Tue Mar 8 03:19:22 2011 Subject: [gdal-dev] gdal_retile error In-Reply-To: <4D7525EE.9000504@gmail.com> References: <4D7525EE.9000504@gmail.com> Message-ID: <20110308091352.j37ftlz28g8wkksg@webmail.nvoe.at> Perhaps a problem with the file permissions ? After creating the tiles for level 0, the utility wants to create a subdir called "1" and store the tiles for level 1 in this subdir. Check this with your user. Make mkdir 1 cd 1 touch test.tif rm test.tif Quoting Vasile Craciunescu : > Dear all, > > I'm trying to create tiled pyramids levels with gdal_retile.py. The > input is a 441671px x 311892px VRT collection (1615 JPEG compressed > GeoTiff files). The command is presented bellow: > > gdal_retile.py -levels 8 -ps 2048 2048 -r bilinear -v -co "TILED=YES" > -co "BLOCKXSIZE=256" -co COMPRESS=JPEG -s_srs EPSG:31700 -targetDir pt > merge.vrt > > This runs smoothly for a while (I manage to create 4151 tiles from > level 0). Then throws the following error: > > ERROR 1: TIFFOpen:2479.tif: Operation not permitted > Traceback (most recent call last): > File "/usr/bin/gdal_retile.py", line 1001, in > sys.exit(main(sys.argv)) > File "/usr/bin/gdal_retile.py", line 911, in main > dsCreatedTileIndex = tileImage(minfo,ti) > File "/usr/bin/gdal_retile.py", line 349, in tileImage > createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS) > File "/usr/bin/gdal_retile.py", line 494, in createTile > dec.uly+offsetY*dec.scaleY) > File "/usr/bin/gdal_retile.py", line 257, in getDataSet > t_band.WriteRaster(writeOffsetX,writeOffsetY,readX,readY,data ) > File > "/usr/local/lib/python2.6/dist-packages/GDAL-1.8.0-py2.6-linux-i686.egg/osgeo/gdal.py", line 941, > in > WriteRaster > return _gdal.Band_WriteRaster(self, *args, **kwargs) > TypeError: not a string > > After several attempts I decided to remove 2479.tif from VRT. The same > error is displayed when gdal_retile reach the next file (2579.tif). I > get this error on the following configuration. > > OS: Ubuntu server 10.10 > GDAL: 1.8 > Python: 2.6.5 > Hardware: Dell PowerEdge 6650; 4 x Xeon 3.00Ghz dual core; 16GB DDR > SDRAM; 5 x 72GB SCSI + 4TB SATA > > Any clues? > > Regards, > Vasile > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From silyko at gmail.com Tue Mar 8 03:57:51 2011 From: silyko at gmail.com (Simon Lyngby Kokkendorff) Date: Tue Mar 8 03:57:52 2011 Subject: [gdal-dev] Polygon topology Message-ID: Hi List, I am using ogr via the python bindings to construct various polygons. Here's just a simple question, to which someone might have some input. Is there anyway to determine the topology, i.e. the number of holes, of a polygon without e.g. having to export to WKT and examining the output string. There doesn't seem to be any methods exposed in the bindings to do this directly? Cheers, Simon Kokkendorff, National Survey and Cadastre of Denmark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110308/4171c404/attachment.html From chaitanya.ch at gmail.com Tue Mar 8 04:29:38 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 8 04:29:40 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: References: Message-ID: Simon, You can use the OGRPolygon::getNumInteriorRings() method to get the number of holes in an OGR polygon object. On Tue, Mar 8, 2011 at 2:27 PM, Simon Lyngby Kokkendorff wrote: > Hi List, > > I am using ogr via the python bindings to construct various polygons. > Here's just a simple question, to which someone might have some input. Is > there anyway to determine the topology, i.e. the number of holes, of a > polygon without e.g. having to export to WKT and examining the output > string. There doesn't seem to be any methods exposed in the bindings to do > this directly? > > Cheers, > Simon Kokkendorff, > National Survey and Cadastre of Denmark > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110308/4ce6e7d0/attachment.html From chaitanya.ch at gmail.com Tue Mar 8 04:33:11 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 8 04:33:13 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: References: Message-ID: I'm sorry. I now see that this method is not exposed in the python bindings. On Tue, Mar 8, 2011 at 2:59 PM, Chaitanya kumar CH wrote: > Simon, > > You can use the OGRPolygon::getNumInteriorRings() method to get the number > of holes in an OGR polygon object. > > On Tue, Mar 8, 2011 at 2:27 PM, Simon Lyngby Kokkendorff > wrote: > >> Hi List, >> >> I am using ogr via the python bindings to construct various polygons. >> Here's just a simple question, to which someone might have some input. Is >> there anyway to determine the topology, i.e. the number of holes, of a >> polygon without e.g. having to export to WKT and examining the output >> string. There doesn't seem to be any methods exposed in the bindings to do >> this directly? >> >> Cheers, >> Simon Kokkendorff, >> National Survey and Cadastre of Denmark >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110308/91eb843e/attachment.html From mwtoews at gmail.com Tue Mar 8 05:08:48 2011 From: mwtoews at gmail.com (Mike Toews) Date: Tue Mar 8 05:09:10 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: References: Message-ID: You could use the `interiors` length in Shapely: from osgeo import ogr from shapely.wkb import loads source = ogr.Open('my_polygons.shp') layer = source.GetLayer() feature = layer.GetNextFeature() num = 0 while feature: g = loads(feature.GetGeometryRef().ExportToWkb()) if g.geom_type == 'Polygon': g.num_holes = len(g.interiors) elif g.geom_type == 'MultiPolygon': g.num_holes = sum([len(mp.interiors) for mp in g]) else: raise Exception('Unexpected geom_type: '+g.geom_type) print g.geom_type, num, 'with', g.num_holes, 'hole'+('s' if g.num_holes != 1 else '') feature = layer.GetNextFeature() num += 1 -Mike On 8 March 2011 21:57, Simon Lyngby Kokkendorff wrote: > Hi List, > > ? I am using ogr via the python bindings to construct various polygons. > Here's just a simple question, to which someone might have some input. Is > there anyway to determine the topology, i.e. the number of holes, of a > polygon without e.g. having to export to WKT and examining the output > string. There doesn't seem to be any methods exposed in the bindings to do > this directly? > > ? Cheers, > ? Simon Kokkendorff, > ? National Survey and Cadastre of Denmark > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From even.rouault at mines-paris.org Tue Mar 8 05:22:19 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 8 05:22:28 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: References: Message-ID: <1299579739.4d76035b8d977@webmail.free.fr> Selon Chaitanya kumar CH : > I'm sorry. I now see that this method is not exposed in the python bindings. Not exactly. In fact you have to use the Geometry.GetGeometryCount() that returns 1 (the exterior ring) + the number of interior rings. So polygon.GetGeometryCount() - 1 should return the number of interior rings See http://gdal.org/ogr/ogr__api_8h.html#1fa07ddf969f97f6444de6ae5128d842 > > On Tue, Mar 8, 2011 at 2:59 PM, Chaitanya kumar CH > wrote: > > > Simon, > > > > You can use the OGRPolygon::getNumInteriorRings() method to get the number > > of holes in an OGR polygon object. > > > > On Tue, Mar 8, 2011 at 2:27 PM, Simon Lyngby Kokkendorff > > wrote: > > > >> Hi List, > >> > >> I am using ogr via the python bindings to construct various polygons. > >> Here's just a simple question, to which someone might have some input. Is > >> there anyway to determine the topology, i.e. the number of holes, of a > >> polygon without e.g. having to export to WKT and examining the output > >> string. There doesn't seem to be any methods exposed in the bindings to do > >> this directly? > >> > >> Cheers, > >> Simon Kokkendorff, > >> National Survey and Cadastre of Denmark > >> > >> > >> _______________________________________________ > >> gdal-dev mailing list > >> gdal-dev@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > >> > > > > > > > > -- > > Best regards, > > Chaitanya kumar CH. > > /t??a??????nj??/ /k??m??r/ > > +91-9494447584 > > 17.2416N 80.1426E > > > > > > -- > Best regards, > Chaitanya kumar CH. > /t??a??????nj??/ /k??m??r/ > +91-9494447584 > 17.2416N 80.1426E > From vasile.craciunescu at gmail.com Tue Mar 8 05:36:29 2011 From: vasile.craciunescu at gmail.com (Vasile Craciunescu) Date: Tue Mar 8 05:36:34 2011 Subject: [gdal-dev] gdal_retile error In-Reply-To: <20110308091352.j37ftlz28g8wkksg@webmail.nvoe.at> References: <4D7525EE.9000504@gmail.com> <20110308091352.j37ftlz28g8wkksg@webmail.nvoe.at> Message-ID: <4D7606AD.2020709@gmail.com> Christian, The permissions are OK. 1-8 subdirs are created as soon as the command is launched. The program stops after generating 10-15% of the level0 tiles. -Vasile On 3/8/11 10:13 AM, christian.mueller@nvoe.at wrote: > Perhaps a problem with the file permissions ? > After creating the tiles for level 0, the utility wants to create a > subdir called "1" and store the tiles for level 1 in this subdir. > > Check this with your user. Make > mkdir 1 > cd 1 > touch test.tif > rm test.tif > > > > > Quoting Vasile Craciunescu : > >> Dear all, >> >> I'm trying to create tiled pyramids levels with gdal_retile.py. The >> input is a 441671px x 311892px VRT collection (1615 JPEG compressed >> GeoTiff files). The command is presented bellow: >> >> gdal_retile.py -levels 8 -ps 2048 2048 -r bilinear -v -co "TILED=YES" >> -co "BLOCKXSIZE=256" -co COMPRESS=JPEG -s_srs EPSG:31700 -targetDir pt >> merge.vrt >> >> This runs smoothly for a while (I manage to create 4151 tiles from >> level 0). Then throws the following error: >> >> ERROR 1: TIFFOpen:2479.tif: Operation not permitted >> Traceback (most recent call last): >> File "/usr/bin/gdal_retile.py", line 1001, in >> sys.exit(main(sys.argv)) >> File "/usr/bin/gdal_retile.py", line 911, in main >> dsCreatedTileIndex = tileImage(minfo,ti) >> File "/usr/bin/gdal_retile.py", line 349, in tileImage >> createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS) >> File "/usr/bin/gdal_retile.py", line 494, in createTile >> dec.uly+offsetY*dec.scaleY) >> File "/usr/bin/gdal_retile.py", line 257, in getDataSet >> t_band.WriteRaster(writeOffsetX,writeOffsetY,readX,readY,data ) >> File >> "/usr/local/lib/python2.6/dist-packages/GDAL-1.8.0-py2.6-linux-i686.egg/osgeo/gdal.py", >> line 941, in >> WriteRaster >> return _gdal.Band_WriteRaster(self, *args, **kwargs) >> TypeError: not a string >> >> After several attempts I decided to remove 2479.tif from VRT. The same >> error is displayed when gdal_retile reach the next file (2579.tif). I >> get this error on the following configuration. >> >> OS: Ubuntu server 10.10 >> GDAL: 1.8 >> Python: 2.6.5 >> Hardware: Dell PowerEdge 6650; 4 x Xeon 3.00Ghz dual core; 16GB DDR >> SDRAM; 5 x 72GB SCSI + 4TB SATA >> >> Any clues? >> >> Regards, >> Vasile >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > From mwtoews at gmail.com Tue Mar 8 05:44:12 2011 From: mwtoews at gmail.com (Mike Toews) Date: Tue Mar 8 05:44:34 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: <1299579739.4d76035b8d977@webmail.free.fr> References: <1299579739.4d76035b8d977@webmail.free.fr> Message-ID: On 8 March 2011 23:22, Even Rouault wrote: > Not exactly. In fact you have to use the Geometry.GetGeometryCount() that > returns 1 (the exterior ring) + the number of interior rings. So > polygon.GetGeometryCount() - 1 should return the number of interior rings I initially thought so too, except that assumption doesn't work for MultiPolygon geometry types. -Mike From even.rouault at mines-paris.org Tue Mar 8 05:51:08 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 8 05:51:17 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: References: <1299579739.4d76035b8d977@webmail.free.fr> Message-ID: <1299581468.4d760a1ce3ac4@webmail.free.fr> Selon Mike Toews : > On 8 March 2011 23:22, Even Rouault wrote: > > Not exactly. In fact you have to use the Geometry.GetGeometryCount() that > > returns 1 (the exterior ring) + the number of interior rings. So > > polygon.GetGeometryCount() - 1 should return the number of interior rings > > I initially thought so too, except that assumption doesn't work for > MultiPolygon geometry types. In that case, you have to first test the geometry type ( geometry.GetGeometryType() ) If equal to ogr.wkbPolygon, apply the above method. If equal to ogr.wkbMultiPolygon, iterate over the polygons with geometry.GetGeometryRef(i) the index varying between 0 and geometry.GetGeometryCount() (which in that case will be the number of polygons). For each polygon, apply the above method. > > -Mike > From silyko at gmail.com Tue Mar 8 06:43:52 2011 From: silyko at gmail.com (Simon Lyngby Kokkendorff) Date: Tue Mar 8 06:43:54 2011 Subject: [gdal-dev] Polygon topology In-Reply-To: <1299581468.4d760a1ce3ac4@webmail.free.fr> References: <1299579739.4d76035b8d977@webmail.free.fr> <1299581468.4d760a1ce3ac4@webmail.free.fr> Message-ID: Thanks a lot. Didn't know that GetGeometryCount did that on polygons :-) Cheers, Simon On Tue, Mar 8, 2011 at 11:51 AM, Even Rouault wrote: > Selon Mike Toews : > > > On 8 March 2011 23:22, Even Rouault > wrote: > > > Not exactly. In fact you have to use the Geometry.GetGeometryCount() > that > > > returns 1 (the exterior ring) + the number of interior rings. So > > > polygon.GetGeometryCount() - 1 should return the number of interior > rings > > > > I initially thought so too, except that assumption doesn't work for > > MultiPolygon geometry types. > > In that case, you have to first test the geometry type ( > geometry.GetGeometryType() ) > > If equal to ogr.wkbPolygon, apply the above method. > If equal to ogr.wkbMultiPolygon, iterate over the polygons with > geometry.GetGeometryRef(i) the index varying between 0 and > geometry.GetGeometryCount() (which in that case will be the number of > polygons). > For each polygon, apply the above method. > > > > > -Mike > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110308/8f9aa6ab/attachment.html From christian.mueller at nvoe.at Tue Mar 8 08:16:11 2011 From: christian.mueller at nvoe.at (christian.mueller@nvoe.at) Date: Tue Mar 8 08:16:25 2011 Subject: [gdal-dev] gdal_retile error In-Reply-To: <4D7606AD.2020709@gmail.com> References: <4D7525EE.9000504@gmail.com> <20110308091352.j37ftlz28g8wkksg@webmail.nvoe.at> <4D7606AD.2020709@gmail.com> Message-ID: <20110308141611.8qpphoe1gcowwkoo@webmail.nvoe.at> Perhaps there is a resource limit for the number of the files in a directory. Try using -useDirForEachRow This builds another directory hierarchy with less files per directory. Quoting Vasile Craciunescu : > Christian, > > The permissions are OK. 1-8 subdirs are created as soon as the command > is launched. The program stops after generating 10-15% of the level0 > tiles. > > -Vasile > > On 3/8/11 10:13 AM, christian.mueller@nvoe.at wrote: >> Perhaps a problem with the file permissions ? >> After creating the tiles for level 0, the utility wants to create a >> subdir called "1" and store the tiles for level 1 in this subdir. >> >> Check this with your user. Make >> mkdir 1 >> cd 1 >> touch test.tif >> rm test.tif >> >> >> >> >> Quoting Vasile Craciunescu : >> >>> Dear all, >>> >>> I'm trying to create tiled pyramids levels with gdal_retile.py. The >>> input is a 441671px x 311892px VRT collection (1615 JPEG compressed >>> GeoTiff files). The command is presented bellow: >>> >>> gdal_retile.py -levels 8 -ps 2048 2048 -r bilinear -v -co "TILED=YES" >>> -co "BLOCKXSIZE=256" -co COMPRESS=JPEG -s_srs EPSG:31700 -targetDir pt >>> merge.vrt >>> >>> This runs smoothly for a while (I manage to create 4151 tiles from >>> level 0). Then throws the following error: >>> >>> ERROR 1: TIFFOpen:2479.tif: Operation not permitted >>> Traceback (most recent call last): >>> File "/usr/bin/gdal_retile.py", line 1001, in >>> sys.exit(main(sys.argv)) >>> File "/usr/bin/gdal_retile.py", line 911, in main >>> dsCreatedTileIndex = tileImage(minfo,ti) >>> File "/usr/bin/gdal_retile.py", line 349, in tileImage >>> createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS) >>> File "/usr/bin/gdal_retile.py", line 494, in createTile >>> dec.uly+offsetY*dec.scaleY) >>> File "/usr/bin/gdal_retile.py", line 257, in getDataSet >>> t_band.WriteRaster(writeOffsetX,writeOffsetY,readX,readY,data ) >>> File >>> "/usr/local/lib/python2.6/dist-packages/GDAL-1.8.0-py2.6-linux-i686.egg/osgeo/gdal.py", >>> line 941, in >>> WriteRaster >>> return _gdal.Band_WriteRaster(self, *args, **kwargs) >>> TypeError: not a string >>> >>> After several attempts I decided to remove 2479.tif from VRT. The same >>> error is displayed when gdal_retile reach the next file (2579.tif). I >>> get this error on the following configuration. >>> >>> OS: Ubuntu server 10.10 >>> GDAL: 1.8 >>> Python: 2.6.5 >>> Hardware: Dell PowerEdge 6650; 4 x Xeon 3.00Ghz dual core; 16GB DDR >>> SDRAM; 5 x 72GB SCSI + 4TB SATA >>> >>> Any clues? >>> >>> Regards, >>> Vasile >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From dan.putler at sauder.ubc.ca Tue Mar 8 16:03:41 2011 From: dan.putler at sauder.ubc.ca (Dan Putler) Date: Tue Mar 8 16:03:48 2011 Subject: [gdal-dev] Is it possible to test if GDAL has been built with GEOS in a python script Message-ID: <4D7699AD.3000601@sauder.ubc.ca> Hi all, As the message heading indicates, I am hoping to run a check within a python script to determine if GDAL on a machine has been built with GEOS support, and exit if it hasn't. Looking at inspect.getmembers( gdal ) suggests that I'm out of luck, but I wanted to confirm this. Dan From even.rouault at mines-paris.org Tue Mar 8 16:21:01 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 8 16:21:17 2011 Subject: [gdal-dev] Is it possible to test if GDAL has been built with GEOS in a python script In-Reply-To: <4D7699AD.3000601@sauder.ubc.ca> References: <4D7699AD.3000601@sauder.ubc.ca> Message-ID: <201103082221.01321.even.rouault@mines-paris.org> Le mardi 08 mars 2011 22:03:41, Dan Putler a ?crit : > Hi all, > > As the message heading indicates, I am hoping to run a check within a > python script to determine if GDAL on a machine has been built with GEOS > support, and exit if it hasn't. Looking at inspect.getmembers( gdal ) > suggests that I'm out of luck, but I wanted to confirm this. Look at the have_geos() method at the end of http://trac.osgeo.org/gdal/browser/trunk/autotest/pymod/ogrtest.py This is how the GDAL autotest suite detects if it must run the GEOS related tests. This is a bit of indirect way of detecting it, but if you have no GEOS support, the Union() method will return None. You may want to silent the error emitted by surrounding the call to Union() with gdal.PushErrorHandler('CPLQuietErrorHandler') gdal.PopErrorHandler() > > Dan > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From vasile.craciunescu at gmail.com Tue Mar 8 18:48:45 2011 From: vasile.craciunescu at gmail.com (Vasile Craciunescu) Date: Tue Mar 8 18:48:52 2011 Subject: [gdal-dev] gdal_retile error In-Reply-To: <20110308141611.8qpphoe1gcowwkoo@webmail.nvoe.at> References: <4D7525EE.9000504@gmail.com> <20110308091352.j37ftlz28g8wkksg@webmail.nvoe.at> <4D7606AD.2020709@gmail.com> <20110308141611.8qpphoe1gcowwkoo@webmail.nvoe.at> Message-ID: <4D76C05D.5010105@gmail.com> Solved (I hope). Something I fail to mention in the first place: the drive where the tiles are processed is mounted through sshfs (physically the disk is incorporated in another server). After moving the data on a local drive, gdal_retile.py passed, without error, the 4151 tile limit. Currently, the tilling process is far from finish, but more than 8000 tiles from level 0 were successfully written on disk. Definitively, somethings goes wrong when tiles are written through sshfs. But, this is not caused by a directory maximum file number limit (through other types of gdal scripting I generated 10000+ files in the same folder through sshfs). Thank you for your help, Vasile On 3/8/11 3:16 PM, christian.mueller@nvoe.at wrote: > Perhaps there is a resource limit for the number of the files in a > directory. > > Try using > > -useDirForEachRow > > This builds another directory hierarchy with less files per directory. > > > > Quoting Vasile Craciunescu : > >> Christian, >> >> The permissions are OK. 1-8 subdirs are created as soon as the command >> is launched. The program stops after generating 10-15% of the level0 >> tiles. >> >> -Vasile >> >> On 3/8/11 10:13 AM, christian.mueller@nvoe.at wrote: >>> Perhaps a problem with the file permissions ? >>> After creating the tiles for level 0, the utility wants to create a >>> subdir called "1" and store the tiles for level 1 in this subdir. >>> >>> Check this with your user. Make >>> mkdir 1 >>> cd 1 >>> touch test.tif >>> rm test.tif >>> >>> >>> >>> >>> Quoting Vasile Craciunescu : >>> >>>> Dear all, >>>> >>>> I'm trying to create tiled pyramids levels with gdal_retile.py. The >>>> input is a 441671px x 311892px VRT collection (1615 JPEG compressed >>>> GeoTiff files). The command is presented bellow: >>>> >>>> gdal_retile.py -levels 8 -ps 2048 2048 -r bilinear -v -co "TILED=YES" >>>> -co "BLOCKXSIZE=256" -co COMPRESS=JPEG -s_srs EPSG:31700 -targetDir pt >>>> merge.vrt >>>> >>>> This runs smoothly for a while (I manage to create 4151 tiles from >>>> level 0). Then throws the following error: >>>> >>>> ERROR 1: TIFFOpen:2479.tif: Operation not permitted >>>> Traceback (most recent call last): >>>> File "/usr/bin/gdal_retile.py", line 1001, in >>>> sys.exit(main(sys.argv)) >>>> File "/usr/bin/gdal_retile.py", line 911, in main >>>> dsCreatedTileIndex = tileImage(minfo,ti) >>>> File "/usr/bin/gdal_retile.py", line 349, in tileImage >>>> createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS) >>>> File "/usr/bin/gdal_retile.py", line 494, in createTile >>>> dec.uly+offsetY*dec.scaleY) >>>> File "/usr/bin/gdal_retile.py", line 257, in getDataSet >>>> t_band.WriteRaster(writeOffsetX,writeOffsetY,readX,readY,data ) >>>> File >>>> "/usr/local/lib/python2.6/dist-packages/GDAL-1.8.0-py2.6-linux-i686.egg/osgeo/gdal.py", >>>> >>>> line 941, in >>>> WriteRaster >>>> return _gdal.Band_WriteRaster(self, *args, **kwargs) >>>> TypeError: not a string >>>> >>>> After several attempts I decided to remove 2479.tif from VRT. The same >>>> error is displayed when gdal_retile reach the next file (2579.tif). I >>>> get this error on the following configuration. >>>> >>>> OS: Ubuntu server 10.10 >>>> GDAL: 1.8 >>>> Python: 2.6.5 >>>> Hardware: Dell PowerEdge 6650; 4 x Xeon 3.00Ghz dual core; 16GB DDR >>>> SDRAM; 5 x 72GB SCSI + 4TB SATA >>>> >>>> Any clues? >>>> >>>> Regards, >>>> Vasile >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > From jluis at ualg.pt Tue Mar 8 20:23:03 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Tue Mar 8 20:46:13 2011 Subject: [gdal-dev] Fail to build with OpenJpeg Message-ID: <4D76D677.9000608@ualg.pt> Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f makefile.vc && cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim From gcpp.kalxas at gmail.com Tue Mar 8 21:59:09 2011 From: gcpp.kalxas at gmail.com (Angelos Tzotsos) Date: Tue Mar 8 21:58:54 2011 Subject: [gdal-dev] Fail to build with OpenJpeg In-Reply-To: <4D76D677.9000608@ualg.pt> References: <4D76D677.9000608@ualg.pt> Message-ID: <4D76ECFD.6080708@gmail.com> Hi Joaquim, In order to build with OpenJpeg, you must use the unreleased version 2.0 of OpenJpeg. Try the following: http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip Regards, Angelos On 03/09/2011 03:23 AM, Joaquim Luis wrote: > Hi, > > My attempt to build gdal (trunk) on Windows with OpenJpeg failed with > these errors > > C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f > makefile.vc && cd .. || exit 1 > cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE > /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 > /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port > -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts > -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c > openjpegdataset.cpp > openjpegdataset.cpp > openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' > before identifier 'JP2OpenJPEGDataset_Read' > openjpegdataset.cpp(80) : error C4430: missing type specifier - int > assumed. Note: C++ does not support default-int > openjpegdataset.cpp(80) : error C2061: syntax error : identifier > 'OPJ_UINT32' > > I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and > there was no sign of it. > I am using openjpeg_v1_4_source_r697 as per its web site. > > > Joaquim > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos From sherstad at gmail.com Wed Mar 9 05:11:38 2011 From: sherstad at gmail.com (Sigbjorn Herstad) Date: Wed Mar 9 05:11:41 2011 Subject: [gdal-dev] GDAL-processing center Message-ID: Hi! I would like some feedback on creating a GDAL-processing center. What I want to achieve is the following: - 1 server running a webserver with GDAL and "everything" installed on it. This can be accessed by other machines through a local network with for instance http://LOCALIP/GDALPROCESSING. - I want "any browser" to go to that webpage and give access to it`s computer resources. When "jobs" are added they should be distributed to the connected computers. So the processing is local on each computer Do you have any recommendations on software-combinations (free) to start to be able to do this, or are there some limitations (on the browsers etc) that makes it "impossible" to do this processing locally on some machines? Greetings from Sigbj?rn From radim.blazek at gmail.com Wed Mar 9 06:25:47 2011 From: radim.blazek at gmail.com (Radim Blazek) Date: Wed Mar 9 06:25:49 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage on source without CRS Message-ID: Hi, I am using GDALWarpOperation.ChunkAndWarpImage to read data, everything works well except when a source dataset does not have a CRS defined. Then it crashes with #0 GDALGenImgProjTransform (pTransformArg=0x0, bDstToSrc=1, nPointCount=84, padfX=0xa1093f0, padfY=0xa109690, padfZ=0xa109930, panSuccess=0xa1090a0) at gdaltransformer.cpp:1402 #1 0x01f56c6c in GDALWarpOperation::ComputeSourceWindow (this=0xbf7fd214, nDstXOff=0, nDstYOff=0, nDstXSize=32, nDstYSize=32, pnSrcXOff=0xbf7fd12c, pnSrcYOff=0xbf7fd128, pnSrcXSize=0xbf7fd124, pnSrcYSize=0xbf7fd120) at gdalwarpoperation.cpp:1977 gdaltransformer.cpp:1402: pGCPTransformArg = psInfo->pDstGCPTransformArg; but if I grep gdal for pDstGCPTransformArg it does not seem to be set at all. Could you please give mi a hint? The code is here and above: http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp?rev=15400#L625 Radim From jluis at ualg.pt Wed Mar 9 09:54:32 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Wed Mar 9 09:54:39 2011 Subject: [gdal-dev] Fail to build with OpenJpeg In-Reply-To: <4D76ECFD.6080708@gmail.com> References: <4D76D677.9000608@ualg.pt> <4D76ECFD.6080708@gmail.com> Message-ID: <4D7794A8.3020706@ualg.pt> On 09-03-2011 02:59, Angelos Tzotsos wrote: > Hi Joaquim, > > In order to build with OpenJpeg, you must use the unreleased version > 2.0 of OpenJpeg. > Try the following: > http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip > Thanks Angelos, but with this version I'm not even able to build OpenJpeg as it hangs on CMake with this error Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) Easy to fix the above by pointing into its local libtiff directory but compilation hangs latter on with (only first of many) Error 1 error C2373: 'opj_stream_create' : redefinition; different type modifiers C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c 228 1 openjpeg Also, since it comes with a libtif.lib it would not likely compile for Win64 which is may main goal to try this. Regards Joaquim > > Regards, > Angelos > > On 03/09/2011 03:23 AM, Joaquim Luis wrote: >> Hi, >> >> My attempt to build gdal (trunk) on Windows with OpenJpeg failed with >> these errors >> >> C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f >> makefile.vc && cd .. || exit 1 >> cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE >> /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 >> /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port >> -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts >> -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c >> openjpegdataset.cpp >> openjpegdataset.cpp >> openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' >> before identifier 'JP2OpenJPEGDataset_Read' >> openjpegdataset.cpp(80) : error C4430: missing type specifier - int >> assumed. Note: C++ does not support default-int >> openjpegdataset.cpp(80) : error C2061: syntax error : identifier >> 'OPJ_UINT32' >> >> I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and >> there was no sign of it. >> I am using openjpeg_v1_4_source_r697 as per its web site. >> >> >> Joaquim >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110309/9907ee1a/attachment-0001.html From szekerest at gmail.com Wed Mar 9 11:28:42 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 9 11:28:45 2011 Subject: [gdal-dev] Fail to build with OpenJpeg In-Reply-To: <4D7794A8.3020706@ualg.pt> References: <4D76D677.9000608@ualg.pt> <4D76ECFD.6080708@gmail.com> <4D7794A8.3020706@ualg.pt> Message-ID: I had to do the following tweaks in order to compile openjpegv2 from SVN. Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 660) +++ CMakeLists.txt (working copy) @@ -50,6 +50,7 @@ IF(WIN32) IF(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_EXPORTS) + ADD_DEFINITIONS(-DUSE_OPJ_DEPRECATED) ELSE(BUILD_SHARED_LIBS) ADD_DEFINITIONS(-DOPJ_STATIC) ENDIF(BUILD_SHARED_LIBS) Index: openjpeg.h =================================================================== --- openjpeg.h (revision 660) +++ openjpeg.h (working copy) @@ -37,7 +37,7 @@ #define OPJ_API #define OPJ_CALLCONV #else - #define OPJ_CALLCONV __stdcall + #define OPJ_CALLCONV //__stdcall #ifdef OPJ_EXPORTS #define OPJ_API __declspec(dllexport) #else BTW: The compiled binaries/libs/headers (including x64) are available to download from: http://vbkto.dyndns.org/sdk/ Best regards, Tamas 2011/3/9 Joaquim Luis > On 09-03-2011 02:59, Angelos Tzotsos wrote: > > Hi Joaquim, > > In order to build with OpenJpeg, you must use the unreleased version 2.0 of > OpenJpeg. > Try the following: > > http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip > > > Thanks Angelos, but with this version I'm not even able to build OpenJpeg > as it hangs on CMake with this error > Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) > > Easy to fix the above by pointing into its local libtiff directory but > compilation hangs latter on with (only first of many) > > Error 1 error C2373: 'opj_stream_create' : redefinition; different > type modifiers > C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c > 228 1 openjpeg > > Also, since it comes with a libtif.lib it would not likely compile for > Win64 which is may main goal to try this. > > Regards > > Joaquim > > > > Regards, > Angelos > > On 03/09/2011 03:23 AM, Joaquim Luis wrote: > > Hi, > > My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these > errors > > C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f > makefile.vc && cd .. || exit 1 > cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE > /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 > /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr > -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts > -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c > openjpegdataset.cpp > openjpegdataset.cpp > openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before > identifier 'JP2OpenJPEGDataset_Read' > openjpegdataset.cpp(80) : error C4430: missing type specifier - int > assumed. Note: C++ does not support default-int > openjpegdataset.cpp(80) : error C2061: syntax error : identifier > 'OPJ_UINT32' > > I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was > no sign of it. > I am using openjpeg_v1_4_source_r697 as per its web site. > > > Joaquim > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110309/64f6c755/attachment.html From warmerdam at pobox.com Wed Mar 9 11:40:46 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 9 11:40:50 2011 Subject: [gdal-dev] Geocentric Coordinate System Support Message-ID: <4D77AD8E.7070006@pobox.com> Folks, Yesterday I introduced Geocentric coordinate system support in GDAL/OGR. This includes OGRSpatialReference support for geocentric coordinate systems, the ability to looking them up from EPSG, and the ability to translate them to/from PROJ.4 format so they can be used for transformation. This is an example of a geocentric coordinate system looked up from EPSG. (Note the root is "GEOCCS") GEOCCS["WGS 84 (geocentric)", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Geocentric X",OTHER], AXIS["Geocentric Y",OTHER], AXIS["Geocentric Z",NORTH], AUTHORITY["EPSG","4328"]] I think there will be relatively little need for this coordinate system, but I would appreciate feedback from anyone using it. http://trac.osgeo.org/gdal/changeset/21916 Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From jluis at ualg.pt Wed Mar 9 12:11:28 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Wed Mar 9 12:11:35 2011 Subject: [gdal-dev] Fail to build with OpenJpeg In-Reply-To: References: <4D76D677.9000608@ualg.pt> <4D76ECFD.6080708@gmail.com> <4D7794A8.3020706@ualg.pt> Message-ID: <4D77B4C0.7090505@ualg.pt> On 09-03-2011 16:28, Tamas Szekeres wrote: > I had to do the following tweaks in order to compile openjpegv2 from SVN. > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 660) > +++ CMakeLists.txt (working copy) > @@ -50,6 +50,7 @@ > IF(WIN32) > IF(BUILD_SHARED_LIBS) > ADD_DEFINITIONS(-DOPJ_EXPORTS) > + ADD_DEFINITIONS(-DUSE_OPJ_DEPRECATED) > ELSE(BUILD_SHARED_LIBS) > ADD_DEFINITIONS(-DOPJ_STATIC) > ENDIF(BUILD_SHARED_LIBS) > Index: openjpeg.h > =================================================================== > --- openjpeg.h (revision 660) > +++ openjpeg.h (working copy) > @@ -37,7 +37,7 @@ > #define OPJ_API > #define OPJ_CALLCONV > #else > - #define OPJ_CALLCONV __stdcall > + #define OPJ_CALLCONV //__stdcall > #ifdef OPJ_EXPORTS > #define OPJ_API __declspec(dllexport) > #else > > > BTW: The compiled binaries/libs/headers (including x64) are available > to download from: http://vbkto.dyndns.org/sdk/ Thank you very much Tamas. I guess that to build the X64 you had to point it to a X64 libtiff.lib that you have build yourself as well? And, sorry, which one of your files has the libs and includes? Not this one: release-1600-x64-gdal-mapserver.zip perhaps this? gdal-19dev-1600-x64-core.msi I confess that I don't like the .msi installers because i never know what else the they do besides installing the package. Joaquim > > Best regards, > > Tamas > > > > 2011/3/9 Joaquim Luis > > > On 09-03-2011 02:59, Angelos Tzotsos wrote: >> Hi Joaquim, >> >> In order to build with OpenJpeg, you must use the unreleased >> version 2.0 of OpenJpeg. >> Try the following: >> http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip >> > > Thanks Angelos, but with this version I'm not even able to build > OpenJpeg as it hangs on CMake with this error > Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) > > Easy to fix the above by pointing into its local libtiff directory > but compilation hangs latter on with (only first of many) > > Error 1 error C2373: 'opj_stream_create' : redefinition; > different type modifiers > C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c > 228 1 openjpeg > > Also, since it comes with a libtif.lib it would not likely compile > for Win64 which is may main goal to try this. > > Regards > > Joaquim > > >> >> Regards, >> Angelos >> >> On 03/09/2011 03:23 AM, Joaquim Luis wrote: >>> Hi, >>> >>> My attempt to build gdal (trunk) on Windows with OpenJpeg failed >>> with these errors >>> >>> C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f >>> makefile.vc && cd .. || exit 1 >>> cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE >>> /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 >>> /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port >>> -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts >>> -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg >>> -DOGR_ENABLED /c openjpegdataset.cpp >>> openjpegdataset.cpp >>> openjpegdataset.cpp(80) : error C2146: syntax error : missing >>> ';' before identifier 'JP2OpenJPEGDataset_Read' >>> openjpegdataset.cpp(80) : error C4430: missing type specifier - >>> int assumed. Note: C++ does not support default-int >>> openjpegdataset.cpp(80) : error C2061: syntax error : identifier >>> 'OPJ_UINT32' >>> >>> I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) >>> and there was no sign of it. >>> I am using openjpeg_v1_4_source_r697 as per its web site. >>> >>> >>> Joaquim >>> _______________________________________________ >>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110309/aa560a08/attachment.html From wendell at enflight.com Wed Mar 9 11:51:49 2011 From: wendell at enflight.com (Wendell Turner) Date: Wed Mar 9 12:22:44 2011 Subject: [gdal-dev] crop a non-square subwindow? Message-ID: <20110309165149.GB17957@cloud3.rho.net> Do any of the gdal utilities crop an image on non-square boundaries? I use gdal_translate with -projwin ulx uly lrx lry to crop an image that is square (left and right edges are vertical, and the top and bottom edges are horizontal). Is there a command that will crop other shapes, for instance a diamond shape, where the edges are not horizontal/vertical? If it must be done by programming (pref. Python), is there a sample that I could use to start with? Thanks, Wendell From warmerdam at pobox.com Wed Mar 9 12:35:57 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 9 12:36:00 2011 Subject: [gdal-dev] crop a non-square subwindow? In-Reply-To: <20110309165149.GB17957@cloud3.rho.net> References: <20110309165149.GB17957@cloud3.rho.net> Message-ID: <4D77BA7D.3020500@pobox.com> On 11-03-09 11:51 AM, Wendell Turner wrote: > > Do any of the gdal utilities crop an image on non-square > boundaries? > > I use gdal_translate with -projwin ulx uly lrx lry to crop > an image that is square (left and right edges are vertical, > and the top and bottom edges are horizontal). Is there a > command that will crop other shapes, for instance a diamond > shape, where the edges are not horizontal/vertical? > > If it must be done by programming (pref. Python), is there a > sample that I could use to start with? Wendell, I think gdalwarp with -crop_to_cutline and a cutline specified with the shape will accomplish what you want. http://www.gdal.org/gdalwarp.html The cutline comes from an OGR supported file but this can be as simple as a .csv file with a WKT geometry in it. The -crop_to_cutline may be new to 1.8. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ilias.koen at dukodestudio.com Wed Mar 9 13:37:23 2011 From: ilias.koen at dukodestudio.com (Ilia Koen) Date: Wed Mar 9 13:37:28 2011 Subject: [gdal-dev] ogr2ogr vector central meridian change, vector offset issue. In-Reply-To: <4D73ED7F.2010303@dukodestudio.com> References: <4D73ED7F.2010303@dukodestudio.com> Message-ID: <4D77C8E3.6040706@dukodestudio.com> Hello all, The same re-projection issue is not fixed by the -wrapdateline . Here is a screenshot of the issue http://dukodestudio.com/client_room/coralreefs/robinson_projection-offsetlineissue.png This is used to reproject the bluemarble. gdalwarp -s_srs EPSG:4326 -t_srs '+proj=robin +lon_0=-90 +x_0=0 +y_0=0' world.topo.200407.3x5400x2700.geo.tif world.topo.200407.3x5400x2700.robin(-90).tif and this to re- project the countries outline to the robinson projection. ogr2ogr -overwrite -wrapdateline -s_srs EPSG:4326 -t_srs '+proj=robin +lon_0=-90 +x_0=0 +y_0=0' -spat -180 -90 180 90 countries_robin.shp countries.shp Is it possible to fix the offset lines with some sort of processing in gdal ? I was thinking that one way to fix this is to rasterize the countries outline while at EPSG:4326 and then warp it to the robinson projection. But then I will loose the vectors to rasters. Any suggestions or work practices are welcome ! Best ik. On 3/6/11 3:24 PM, Ilia Koen wrote: > Hello, > We are trying to re-project the coral reef dataset via ogr2ogr for > the dataset to fit the bluemarble projection. The coral reef is a > vector shape dataset and it is using the Lambert Cylindrical Equal > Area at -160 central meridian. Once we re-project we are getting lines > connecting the shapes that are cutoff at the edges from -180 to 180. > Is that a bug ? or are we doing something wrong? > > You can see the offset issue here > http://dukodestudio.com/client_room/coralreefs/coralReefData-offsetlineissue.png > > > Here is the location of the dataset > http://www.wri.org/publication/reefs-at-risk-revisited#datasets > > Our command is as follows: > ogr2ogr -s_srs '+proj=cea +lon_0=-160 +lat_ts=0 +x_0=0 +y_0=0' -t_srs > EPSG:4326 reefPoly28.shp reef_500_poly.shp > > We did try to use the "-spat -180 -90 180 90" flag with the above > commnd but without success. > > Thanks, ik. > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From radim.blazek at gmail.com Wed Mar 9 13:46:26 2011 From: radim.blazek at gmail.com (Radim Blazek) Date: Wed Mar 9 13:46:27 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs Message-ID: Hi, GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow on larger geotiff (over 1GB). Is it possible that it is much slower with respect to GDALRasterIO() even without reprojection? Should I return to 'manualy' reading data via GDALRasterIO() + fidling with data extents and cells alignement? I thought that GDAL ChunkAndWarpImage will do it even faster, possibly knowing better (?) various formats nature. Is there way to tune somehow performance? Currently no reprojection and GRA_NearestNeighbour. Still the same code which I posted before http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp?rev=15400#L625 Thanks for help. Radim From even.rouault at mines-paris.org Wed Mar 9 13:49:40 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 9 13:50:01 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage on source without CRS In-Reply-To: References: Message-ID: <201103091949.40902.even.rouault@mines-paris.org> Le mercredi 09 mars 2011 12:25:47, Radim Blazek a ?crit : Radim, I don't see anything obviously wrong in your code, but the warping API is admitedly quite tricky to use. The closest code in GDAL that you could take insipiration from is perhaps GDALReprojectImage() in alg/gdalwarper.cpp that does pretty similar things to your code (apps/gdalwarp.cpp does similar things too but perhaps a bit less clear to follow). 1) The cause of the crash is the pTransformArg=0x0 passed to GDALGenImgProjTransform () which causes a null pointer deferencing when doing psInfo->pDstGCPTransformArg. I'm surprised that it crashes here and not the line before where the psInfo is already deferenced (is your GDAL build with - O2 ? If yes, you should perhaps rebuild it without it). I don't either understand how you get a null pointer at that point. I don't either understand why the fact that the source dataset has a SRS or not has an impact at that point... Stepping in the code with a debugger might help to track where that null pointer comes from. (the line numbers didn't match the ones of my copy so I suspect you're not using GDAL 1.8.0, but that shouldn't be an issue however) 2) Yes, indeed pDstGCPTransformArg is unused. So there's perhaps some code cleaning possible inside GDAL here, but that's unlikely to cause a problem per se. 3) You should check the return value of myOperation.Initialize( myWarpOptions ). If the validation of the warp options failed, it would be unsafe to go on with the warping itself. 4) myMemDsn.sprintf( "MEM:::DATAPOINTER=%lu,PIXELS=%d,LINES=%d,BANDS=1,DATATYPE=%s,PIXELOFFSET=0,LINEOFFSET=0,BANDOFFSET=0", ( long )theBlock, thePixelWidth, thePixelHeight, GDALGetDataTypeName(( GDALDataType )mGdalDataType[theBandNo-1] ) ); is dangerous. I think it will not work for a Win64 build where pointers are 64 bits but long is still 32 bit. You could use the CPLPrintPointer() function from GDAL to format it : char szPointer[64]; memset( szPointer, 0, sizeof(szPointer) ); CPLPrintPointer( szPointer, theBlock, sizeof(szPointer) ); Best regards, Even > Hi, > I am using GDALWarpOperation.ChunkAndWarpImage to read data, > everything works well except when a source dataset does not have a CRS > defined. Then it crashes with > > #0 GDALGenImgProjTransform (pTransformArg=0x0, bDstToSrc=1, > nPointCount=84, padfX=0xa1093f0, padfY=0xa109690, padfZ=0xa109930, > panSuccess=0xa1090a0) at gdaltransformer.cpp:1402 > #1 0x01f56c6c in GDALWarpOperation::ComputeSourceWindow (this=0xbf7fd214, > nDstXOff=0, nDstYOff=0, nDstXSize=32, nDstYSize=32, > pnSrcXOff=0xbf7fd12c, pnSrcYOff=0xbf7fd128, pnSrcXSize=0xbf7fd124, > pnSrcYSize=0xbf7fd120) at gdalwarpoperation.cpp:1977 > > gdaltransformer.cpp:1402: > > pGCPTransformArg = psInfo->pDstGCPTransformArg; > > but if I grep gdal for pDstGCPTransformArg it does not seem to be set at > all. > > Could you please give mi a hint? The code is here and above: > http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalpro > vider.cpp?rev=15400#L625 > > Radim > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From warmerdam at pobox.com Wed Mar 9 14:00:12 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 9 14:00:17 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs In-Reply-To: References: Message-ID: <4D77CE3C.6090406@pobox.com> On 11-03-09 01:46 PM, Radim Blazek wrote: > Hi, > > GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow > on larger geotiff (over 1GB). Is it possible that it is much slower > with respect to GDALRasterIO() even without reprojection? Should I > return to 'manualy' reading data via GDALRasterIO() + fidling with > data extents and cells alignement? I thought that GDAL > ChunkAndWarpImage will do it even faster, possibly knowing better (?) > various formats nature. > > Is there way to tune somehow performance? Currently no reprojection > and GRA_NearestNeighbour. Radim, GDALWarpOperation is intended to be a high precision image resampler. Within the constraints of doing this correctly it attempts to be fast, but it will generally be quite a bit slower than direct RasterIO calls and in some situations dramatically slower. Particularly it is completely inappropriate to use for radical downsampling. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From even.rouault at mines-paris.org Wed Mar 9 14:13:29 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 9 14:13:51 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs In-Reply-To: References: Message-ID: <201103092013.30066.even.rouault@mines-paris.org> Le mercredi 09 mars 2011 19:46:26, Radim Blazek a ?crit : > Hi, > > GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow > on larger geotiff (over 1GB). Is it possible that it is much slower > with respect to GDALRasterIO() even without reprojection? Should I > return to 'manualy' reading data via GDALRasterIO() + fidling with > data extents and cells alignement? I thought that GDAL > ChunkAndWarpImage will do it even faster, possibly knowing better (?) > various formats nature. Yes, I wouldn't be surprised that ChunkAndWarpImage is noticeably slower if it is used only as a GDALRasterIO() replacement for the no reprojection case. There are quite a lot of extra processing that will be done to handle the nominal case of reprojection and you'll pay that cost even if you don't need it. By reading the code of GDALCreateGenImgProjTransformer2(), namely if( pszSrcWKT != NULL && strlen(pszSrcWKT) > 0 && pszDstWKT != NULL && strlen(pszDstWKT) > 0 && !EQUAL(pszSrcWKT,pszDstWKT) ) { CPLString osSrcWKT = pszSrcWKT; if (hSrcDS && CSLFetchBoolean( papszOptions, "INSERT_CENTER_LONG", TRUE ) ) osSrcWKT = InsertCenterLong( hSrcDS, osSrcWKT ); psInfo->pReprojectArg = GDALCreateReprojectionTransformer( osSrcWKT.c_str(), pszDstWKT ); } you can see a small optimization in which the reprojection transformer isn't instanciated if the 2 SRS are identical. But the WKT strings must really match. We should perhaps use OSRIsEqual() instead to be more robust to minor differences in WKT. Dunno if you run into this however. And I don't know if this optimization accounts for much. I've just run this non-scientifical benchmark (GDAL built with -O2) that confirms your findings : $ time gdal_translate ~/gdal/data/bmng/world.topo.bathy.200406.3x21600x21600.B2.tif out.tif Input file size is 21600, 21600 0...10...20...30...40...50...60...70...80...90...100 - done. real 0m12.102s user 0m7.560s sys 0m1.320s $ time gdalwarp ~/gdal/data/bmng/world.topo.bathy.200406.3x21600x21600.B2.tif out2.tif Processing input file /home/even/gdal/data/bmng/world.topo.bathy.200406.3x21600x21600.B2.tif. 0...10...20...30...40...50...60...70...80...90...100 - done. real 1m13.387s user 0m48.610s sys 0m23.270s where the source is a 21600x21600x3 JPEG-compressed TIFF with 256x256 tiles. (with a unoptimized build, it is 14 s versus 3 minutes...) > > Is there way to tune somehow performance? Currently no reprojection > and GRA_NearestNeighbour. > > Still the same code which I posted before > http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalpro > vider.cpp?rev=15400#L625 > > Thanks for help. > Radim > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From szekerest at gmail.com Wed Mar 9 14:37:42 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 9 14:37:47 2011 Subject: [gdal-dev] Fail to build with OpenJpeg In-Reply-To: <4D77B4C0.7090505@ualg.pt> References: <4D76D677.9000608@ualg.pt> <4D76ECFD.6080708@gmail.com> <4D7794A8.3020706@ualg.pt> <4D77B4C0.7090505@ualg.pt> Message-ID: Hi Joaquim. You can download http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1600-x64-dev.zipto obtain the libs/includes. Best regards, Tamas 2011/3/9 Joaquim Luis > On 09-03-2011 16:28, Tamas Szekeres wrote: > > I had to do the following tweaks in order to compile openjpegv2 from SVN. > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 660) > +++ CMakeLists.txt (working copy) > @@ -50,6 +50,7 @@ > IF(WIN32) > IF(BUILD_SHARED_LIBS) > ADD_DEFINITIONS(-DOPJ_EXPORTS) > + ADD_DEFINITIONS(-DUSE_OPJ_DEPRECATED) > ELSE(BUILD_SHARED_LIBS) > ADD_DEFINITIONS(-DOPJ_STATIC) > ENDIF(BUILD_SHARED_LIBS) > Index: openjpeg.h > =================================================================== > --- openjpeg.h (revision 660) > +++ openjpeg.h (working copy) > @@ -37,7 +37,7 @@ > #define OPJ_API > #define OPJ_CALLCONV > #else > - #define OPJ_CALLCONV __stdcall > + #define OPJ_CALLCONV //__stdcall > #ifdef OPJ_EXPORTS > #define OPJ_API __declspec(dllexport) > #else > > > BTW: The compiled binaries/libs/headers (including x64) are available to > download from: http://vbkto.dyndns.org/sdk/ > > > Thank you very much Tamas. > I guess that to build the X64 you had to point it to a X64 libtiff.lib that > you have build yourself as well? > > And, sorry, which one of your files has the libs and includes? > Not this one: release-1600-x64-gdal-mapserver.zip > > perhaps this? gdal-19dev-1600-x64-core.msi > > I confess that I don't like the .msi installers because i never know what > else the they do besides installing the package. > > Joaquim > > > > Best regards, > > Tamas > > > > 2011/3/9 Joaquim Luis > >> On 09-03-2011 02:59, Angelos Tzotsos wrote: >> >> Hi Joaquim, >> >> In order to build with OpenJpeg, you must use the unreleased version 2.0 >> of OpenJpeg. >> Try the following: >> >> http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip >> >> >> Thanks Angelos, but with this version I'm not even able to build OpenJpeg >> as it hangs on CMake with this error >> Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) >> >> Easy to fix the above by pointing into its local libtiff directory but >> compilation hangs latter on with (only first of many) >> >> Error 1 error C2373: 'opj_stream_create' : redefinition; different >> type modifiers >> C:\programs\compa_libs\OpenJPEG_V2_Alpha\Development\libopenjpeg\cio.c >> 228 1 openjpeg >> >> Also, since it comes with a libtif.lib it would not likely compile for >> Win64 which is may main goal to try this. >> >> Regards >> >> Joaquim >> >> >> >> Regards, >> Angelos >> >> On 03/09/2011 03:23 AM, Joaquim Luis wrote: >> >> Hi, >> >> My attempt to build gdal (trunk) on Windows with OpenJpeg failed with >> these errors >> >> C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f >> makefile.vc && cd .. || exit 1 >> cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE >> /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 >> /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr >> -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts >> -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c >> openjpegdataset.cpp >> openjpegdataset.cpp >> openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before >> identifier 'JP2OpenJPEGDataset_Read' >> openjpegdataset.cpp(80) : error C4430: missing type specifier - int >> assumed. Note: C++ does not support default-int >> openjpegdataset.cpp(80) : error C2061: syntax error : identifier >> 'OPJ_UINT32' >> >> I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there >> was no sign of it. >> I am using openjpeg_v1_4_source_r697 as per its web site. >> >> >> Joaquim >> _______________________________________________ >> 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110309/bfc2589d/attachment.html From even.rouault at mines-paris.org Wed Mar 9 14:50:52 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 9 14:51:13 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs In-Reply-To: References: Message-ID: <201103092050.52693.even.rouault@mines-paris.org> Le mercredi 09 mars 2011 19:46:26, Radim Blazek a ?crit : > Hi, > Skimming qgis mailing list, I read this http://lists.osgeo.org/pipermail/qgis- developer/2011-March/013291.html Was it the report you were refering too ? If yes, then the report gives an interesting hint. You must be aware that the warping code does not take advantage of overviews (it is intended to operate on the full-resolution raster, and not for downsampling as Frank underlined), so you will have really bad performance comparing too GDALRasterIO() if the output dimensions are much smaller than the input window size. > GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow > on larger geotiff (over 1GB). Is it possible that it is much slower > with respect to GDALRasterIO() even without reprojection? Should I > return to 'manualy' reading data via GDALRasterIO() + fidling with > data extents and cells alignement? I thought that GDAL > ChunkAndWarpImage will do it even faster, possibly knowing better (?) > various formats nature. > > Is there way to tune somehow performance? Currently no reprojection > and GRA_NearestNeighbour. > > Still the same code which I posted before > http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalpro > vider.cpp?rev=15400#L625 > > Thanks for help. > Radim > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From cpadwick at digitalglobe.com Wed Mar 9 16:15:28 2011 From: cpadwick at digitalglobe.com (cpadwick) Date: Wed Mar 9 16:15:31 2011 Subject: [gdal-dev] Re: building with PDF driver on Windows + ? In-Reply-To: <4CBDA602.8060204@geoanalytic.com> References: <4CB71B32.90200@ualg.pt> <201010141932.53400.even.rouault@mines-paris.org> <4CB752EB.4070201@ualg.pt> <4CB774E7.5020800@ualg.pt> <4CBB1CBD.5000200@geoanalytic.com> <4CBB3C54.2020802@ualg.pt> <4CBB3F75.3020101@geoanalytic.com> <4CBB42DE.9090801@ualg.pt> <4CBDA602.8060204@geoanalytic.com> Message-ID: <1299705328334-6155509.post@n2.nabble.com> Hi, I've followed the instructions posted above but have run into a linker error. Any ideas which lib I'm missing? Thanks, Chris 2 File(s) copied cd .. if exist gdal.lib del gdal.lib lib /nologo /out:gdal.lib port\*.obj gcore\*.obj alg\*.obj frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib link /nologo /dll /INCLUDE:_OGRFeatureStylePuller /INCLUDE:_OSRValidate /INCLUDE:_OPTGetProjectionMethods /INCLUDE:_OGR_G_GetPointCount /INCLUDE:_OG RRegisterAll /INCLUDE:_GDALSimpleImageWarp@36 /INCLUDE:_GDALReprojectImage@48 /INCLUDE:_GDALComputeMedianCutPCT@32 /INCLUDE:_GDALDitherRGB2PCT@28 /INCLUDE:_ OCTNewCoordinateTransformation@8 port\*.obj gcore\*.obj alg\*.obj frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib C:\cgp\code\xerces\xerces-c-3.0. 1\Build\Win32\VC9\Release\xerces-c_3.lib "C:\cgp\code\mrsid\Lidar_DSDK\li b\lti_lidar_dsdk.lib" "C:\cgp\code\mrsid\Raster_DSDK\lib\lti_dsdk.lib" odbc32.lib odbccp32.lib user32.lib C:\KDE\lib\poppler.li b C:\KDE\lib\poppler-cpp.lib C:\KDE\lib\poppler-qt4.lib C:\KDE\lib\freetype.lib C:\KDE\lib\lcms-1.lib advapi32.lib gdi32.lib gcore\Version.res /out:gdal18.dll /implib:gdal_i.lib poppler.lib(GlobalParams.cc.obj) : error LNK2005: _DllMain@12 already defined in gdaldllmain.obj Creating library gdal_i.lib and object gdal_i.exp poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_de stroy_decompress imported in function "public: virtual __thiscall DCTStream::~DC TStream(void)" (??1DCTStream@@UAE@XZ) poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_Cr eateDecompress imported in function "private: void __thiscall DCTStream::init(vo id)" (?init@DCTStream@@AAEXXZ) poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_re sync_to_restart imported in function "private: void __thiscall DCTStream::init(v oid)" (?init@DCTStream@@AAEXXZ) poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_st d_error imported in function "private: void __thiscall DCTStream::init(void)" (? init@DCTStream@@AAEXXZ) poppler.lib(JpegWriter.cc.obj) : warning LNK4049: locally defined symbol _jpeg_s td_error imported poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_st art_decompress imported in function "public: virtual void __thiscall DCTStream:: reset(void)" (?reset@DCTStream@@UAEXXZ) poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_re ad_header imported in function "public: virtual void __thiscall DCTStream::reset (void)" (?reset@DCTStream@@UAEXXZ) poppler.lib(DCTStream.cc.obj) : warning LNK4217: locally defined symbol _jpeg_re ad_scanlines imported in function "public: virtual int __thiscall DCTStream::get Char(void)" (?getChar@DCTStream@@UAEHXZ) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_d estroy_compress imported in function "public: virtual __thiscall JpegWriter::~Jp egWriter(void)" (??1JpegWriter@@UAE@XZ) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_s tart_compress imported in function "public: virtual bool __thiscall JpegWriter:: init(struct _iobuf *,int,int,int,int)" (?init@JpegWriter@@UAE_NPAU_iobuf@@HHHH@Z ) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_s imple_progression imported in function "public: virtual bool __thiscall JpegWrit er::init(struct _iobuf *,int,int,int,int)" (?init@JpegWriter@@UAE_NPAU_iobuf@@HH HH@Z) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_s et_quality imported in function "public: virtual bool __thiscall JpegWriter::ini t(struct _iobuf *,int,int,int,int)" (?init@JpegWriter@@UAE_NPAU_iobuf@@HHHH@Z) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_s et_defaults imported in function "public: virtual bool __thiscall JpegWriter::in it(struct _iobuf *,int,int,int,int)" (?init@JpegWriter@@UAE_NPAU_iobuf@@HHHH@Z) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_C reateCompress imported in function "public: virtual bool __thiscall JpegWriter:: init(struct _iobuf *,int,int,int,int)" (?init@JpegWriter@@UAE_NPAU_iobuf@@HHHH@Z ) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_w rite_scanlines imported in function "public: virtual bool __thiscall JpegWriter: :writePointers(unsigned char * *,int)" (?writePointers@JpegWriter@@UAE_NPAPAEH@Z ) poppler.lib(JpegWriter.cc.obj) : warning LNK4217: locally defined symbol _jpeg_f inish_compress imported in function "public: virtual bool __thiscall JpegWriter: :close(void)" (?close@JpegWriter@@UAE_NXZ) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_destroy_decompress@4 referenced in function "public: virtual void __th iscall JPXStream::close(void)" (?close@JPXStream@@UAEXXZ) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_image_destroy@4 referenced in function "public: virtual void __thiscal l JPXStream::close(void)" (?close@JPXStream@@UAEXXZ) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_cio_close@4 referenced in function "private: void __thiscall JPXStream ::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXPAEHW4COD EC_FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_decode@8 referenced in function "private: void __thiscall JPXStream::i nit2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXPAEHW4CODEC_ FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_cio_open@12 referenced in function "private: void __thiscall JPXStream ::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXPAEHW4COD EC_FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_setup_decoder@8 referenced in function "private: void __thiscall JPXSt ream::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXPAEHW 4CODEC_FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_set_event_mgr@12 referenced in function "private: void __thiscall JPXS tream::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXPAEH W4CODEC_FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_create_decompress@4 referenced in function "private: void __thiscall J PXStream::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPXStream@@AAEXP AEHW4CODEC_FORMAT@@@Z) poppler.lib(JPEG2000Stream.cc.obj) : error LNK2019: unresolved external symbol _ _imp__opj_set_default_decoder_parameters@4 referenced in function "private: void __thiscall JPXStream::init2(unsigned char *,int,enum CODEC_FORMAT)" (?init2@JPX Stream@@AAEXPAEHW4CODEC_FORMAT@@@Z) poppler.lib(PNGWriter.cc.obj) : error LNK2019: unresolved external symbol _png_s et_longjmp_fn referenced in function "public: virtual bool __thiscall PNGWriter: :init(struct _iobuf *,int,int,int,int)" (?init@PNGWriter@@UAE_NPAU_iobuf@@HHHH@Z ) gdal18.dll : fatal error LNK1120: 10 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \link.EXE"' : return code '0x460' Stop. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-building-with-PDF-driver-on-Windows-tp5635431p6155509.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From radim.blazek at gmail.com Wed Mar 9 16:27:19 2011 From: radim.blazek at gmail.com (Radim Blazek) Date: Wed Mar 9 16:27:22 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage on source without CRS In-Reply-To: <201103091949.40902.even.rouault@mines-paris.org> References: <201103091949.40902.even.rouault@mines-paris.org> Message-ID: Hi, thank you a lot for your help and recommendations. The problem seems to be in GDALCreateGenImgProjTransformer2 in the block which begins on line 1072 (alg/gdaltransformer.cpp) current trunk: else if( (pszMethod == NULL || EQUAL(pszMethod,"GEOTRANSFORM")) && GDALGetGeoTransform( hSrcDS, psInfo->adfSrcGeoTransform ) == CE_None && (psInfo->adfSrcGeoTransform[0] != 0.0 || psInfo->adfSrcGeoTransform[1] != 1.0 || psInfo->adfSrcGeoTransform[2] != 0.0 || psInfo->adfSrcGeoTransform[3] != 0.0 || psInfo->adfSrcGeoTransform[4] != 0.0 || ABS(psInfo->adfSrcGeoTransform[5]) != 1.0) ) here it excludes all source data sources which are not georeferenced. If I comment the psInfo->adfSrcGeoTransform check, everything works OK. Is there a good reason to not allow to transform images which are not georeferenced? I can get around also setting for example psInfo->adfSrcGeoTransform[0] = 0.00000001; in my code, but that is not nice of course. Is there a better workaround? Radim On Wed, Mar 9, 2011 at 7:49 PM, Even Rouault wrote: > Le mercredi 09 mars 2011 12:25:47, Radim Blazek a ?crit : > > Radim, > > I don't see anything obviously wrong in your code, but the warping API is > admitedly quite tricky to use. The closest code in GDAL that you could take > insipiration from is perhaps GDALReprojectImage() in alg/gdalwarper.cpp that > does pretty similar things to your code (apps/gdalwarp.cpp does similar things > too but perhaps a bit less clear to follow). > > 1) The cause of the crash is the pTransformArg=0x0 passed to > GDALGenImgProjTransform () which causes a null pointer deferencing when doing > psInfo->pDstGCPTransformArg. I'm surprised that it crashes here and not the > line before where the psInfo is already deferenced (is your GDAL build with - > O2 ? If yes, you should perhaps rebuild it without it). I don't either > understand how you get a null pointer at that point. I don't either understand > why the fact that the source dataset has a SRS or not has an impact at that > point... Stepping in the code with a debugger might help to track where that > null pointer comes from. (the line numbers didn't match the ones of my copy so > I suspect you're not using GDAL 1.8.0, but that shouldn't be an issue however) > > 2) Yes, indeed pDstGCPTransformArg is unused. So there's perhaps some code > cleaning possible inside GDAL here, but that's unlikely to cause a problem per > se. > > 3) You should check the return value of myOperation.Initialize( myWarpOptions > ). > If the validation of the warp options failed, it would be unsafe to go on with > the warping itself. > > 4) myMemDsn.sprintf( > "MEM:::DATAPOINTER=%lu,PIXELS=%d,LINES=%d,BANDS=1,DATATYPE=%s,PIXELOFFSET=0,LINEOFFSET=0,BANDOFFSET=0", > ( long )theBlock, thePixelWidth, thePixelHeight, ?GDALGetDataTypeName(( > GDALDataType )mGdalDataType[theBandNo-1] ) ); ?is dangerous. I think it will > not work for a Win64 build where pointers are 64 bits but long is still 32 > bit. You could use the CPLPrintPointer() function from GDAL to format it : > > ? ?char szPointer[64]; > ? ?memset( szPointer, 0, sizeof(szPointer) ); > ? ?CPLPrintPointer( szPointer, theBlock, sizeof(szPointer) ); > > Best regards, > > Even > > >> Hi, >> I am using GDALWarpOperation.ChunkAndWarpImage to read data, >> everything works well except when a source dataset does not have a CRS >> defined. Then it crashes with >> >> #0 ?GDALGenImgProjTransform (pTransformArg=0x0, bDstToSrc=1, >> nPointCount=84, padfX=0xa1093f0, padfY=0xa109690, padfZ=0xa109930, >> panSuccess=0xa1090a0) at gdaltransformer.cpp:1402 >> #1 ?0x01f56c6c in GDALWarpOperation::ComputeSourceWindow (this=0xbf7fd214, >> ? ? nDstXOff=0, nDstYOff=0, nDstXSize=32, nDstYSize=32, >> pnSrcXOff=0xbf7fd12c, pnSrcYOff=0xbf7fd128, pnSrcXSize=0xbf7fd124, >> pnSrcYSize=0xbf7fd120) at gdalwarpoperation.cpp:1977 >> >> gdaltransformer.cpp:1402: >> >> ? ? ? ? pGCPTransformArg = psInfo->pDstGCPTransformArg; >> >> but if I grep gdal for pDstGCPTransformArg it does not seem to be set at >> all. >> >> Could you please give mi a hint? The code is here and above: >> http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalpro >> vider.cpp?rev=15400#L625 >> >> Radim >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From radim.blazek at gmail.com Wed Mar 9 17:00:39 2011 From: radim.blazek at gmail.com (Radim Blazek) Date: Wed Mar 9 17:00:41 2011 Subject: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs In-Reply-To: <201103092050.52693.even.rouault@mines-paris.org> References: <201103092050.52693.even.rouault@mines-paris.org> Message-ID: Hi, yes that is the mail reporting the error. Thank you for explanation. I see that I have to reintroduce all the staff for GDALRasterIO() Radim On Wed, Mar 9, 2011 at 8:50 PM, Even Rouault wrote: > Le mercredi 09 mars 2011 19:46:26, Radim Blazek a ?crit : >> Hi, >> > > Skimming qgis mailing list, I read this http://lists.osgeo.org/pipermail/qgis- > developer/2011-March/013291.html > > Was it the report you were refering too ? If yes, then the report gives an > interesting hint. You must be aware that the warping code does not take > advantage of overviews (it is intended to operate on the full-resolution > raster, and not for downsampling as Frank underlined), so you will have really > bad performance comparing too GDALRasterIO() if the output dimensions are much > smaller than the input window size. > >> GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow >> on larger geotiff (over 1GB). Is it possible that it is much slower >> with respect to GDALRasterIO() ?even without reprojection? Should I >> return to 'manualy' reading data via GDALRasterIO() + fidling with >> data extents and cells alignement? I thought that GDAL >> ChunkAndWarpImage will do it even faster, possibly knowing better (?) >> various formats nature. >> >> Is there way to tune somehow performance? Currently no reprojection >> and GRA_NearestNeighbour. >> >> Still the same code which I posted before >> http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalpro >> vider.cpp?rev=15400#L625 >> >> Thanks for help. >> Radim >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From mariusjigmond at hotmail.com Wed Mar 9 19:05:20 2011 From: mariusjigmond at hotmail.com (Marius Jigmond) Date: Wed Mar 9 19:05:29 2011 Subject: [gdal-dev] crop a non-square subwindow? In-Reply-To: <4D77BA7D.3020500@pobox.com> References: <20110309165149.GB17957@cloud3.rho.net> <4D77BA7D.3020500@pobox.com> Message-ID: On Wed, 2011-03-09 at 12:35 -0500, Frank Warmerdam wrote: > On 11-03-09 11:51 AM, Wendell Turner wrote: > > > > Do any of the gdal utilities crop an image on non-square > > boundaries? > > > > I use gdal_translate with -projwin ulx uly lrx lry to crop > > an image that is square (left and right edges are vertical, > > and the top and bottom edges are horizontal). Is there a > > command that will crop other shapes, for instance a diamond > > shape, where the edges are not horizontal/vertical? > > > > If it must be done by programming (pref. Python), is there a > > sample that I could use to start with? > > Wendell, > > I think gdalwarp with -crop_to_cutline and a cutline specified > with the shape will accomplish what you want. > > http://www.gdal.org/gdalwarp.html > > The cutline comes from an OGR supported file but this can be as simple > as a .csv file with a WKT geometry in it. The -crop_to_cutline may be > new to 1.8. > > Best regards, Wendell, Please be aware that this method may introduce raster shifting and possibly resampling (depending on the original cell size). It might or might not matter for your purposes. A better approach is to use gdal_translate with -projwin to extract to shape envelope and then gdal_rasterize with -i to burn nodata where shape is missing. -marius From yehil at rafael.co.il Thu Mar 10 01:38:01 2011 From: yehil at rafael.co.il (Livneh Yehiyam) Date: Thu Mar 10 01:37:48 2011 Subject: [gdal-dev] writing geoPDF Message-ID: Hi Are there plans to add write support to the geoPDF driver? If not in the near future do you know of another solution? Preferably open source? Thanks Yehiyam. Sent from my mobile ********************************************************************************************** This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:lawraf@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ********************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/fa5d1e7a/attachment.html From natashachatterjee at rediffmail.com Thu Mar 10 01:41:47 2011 From: natashachatterjee at rediffmail.com (natasha chatterjee) Date: Thu Mar 10 01:48:41 2011 Subject: [gdal-dev] how to build gdal with oracle spatial Message-ID: <20110310064147.26567.qmail@f4mail-235-145.rediffmail.com> Hi All GDAL is new for me.i need to build GDAL with oracle spatial so that i can use OGR2OGR for further conversion of oracle spatial data to shape file. I have installed FWTools 2.4.7 and want to run the commands from FWTools shell only.Please can anyone help me out and guide me by telling me the step by step process of configuring GDAL with oracle support.Kindly reply back soon as am stuck. Thanks & Regards Natasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/9ea2abb9/attachment.html From natashachatterjee at rediffmail.com Thu Mar 10 01:42:12 2011 From: natashachatterjee at rediffmail.com (natasha chatterjee) Date: Thu Mar 10 01:49:03 2011 Subject: [gdal-dev] how to build gdal with oracle spatial Message-ID: <20110310064212.26984.qmail@f4mail212.rediffmail.com> Hi All GDAL is new for me.i need to build GDAL with oracle spatial so that i can use OGR2OGR for further conversion of oracle spatial data to shape file. I have installed FWTools 2.4.7 and want to run the commands from FWTools shell only.Please can anyone help me out and guide me by telling me the step by step process of configuring GDAL with oracle support.Kindly reply back soon as am stuck. Thanks & Regards Natasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/7b3037e8/attachment.html From natashachatterjee at rediffmail.com Thu Mar 10 01:42:18 2011 From: natashachatterjee at rediffmail.com (natasha chatterjee) Date: Thu Mar 10 01:49:11 2011 Subject: [gdal-dev] how to build gdal with oracle spatial Message-ID: <20110310064218.27721.qmail@f4mail-235-145.rediffmail.com> Hi All GDAL is new for me.i need to build GDAL with oracle spatial so that i can use OGR2OGR for further conversion of oracle spatial data to shape file. I have installed FWTools 2.4.7 and want to run the commands from FWTools shell only.Please can anyone help me out and guide me by telling me the step by step process of configuring GDAL with oracle support.Kindly reply back soon as am stuck. Thanks & Regards Natasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/a3ef7281/attachment-0001.html From chaitanya.ch at gmail.com Thu Mar 10 01:55:34 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 10 01:55:36 2011 Subject: [gdal-dev] how to build gdal with oracle spatial In-Reply-To: <20110310064147.26567.qmail@f4mail-235-145.rediffmail.com> References: <20110310064147.26567.qmail@f4mail-235-145.rediffmail.com> Message-ID: Natasha, OSGeo4W has the Oracle-10g plugin for GDAL. You can use the GDAL package from it too. On Thu, Mar 10, 2011 at 12:11 PM, natasha chatterjee < natashachatterjee@rediffmail.com> wrote: > > Hi All > GDAL is new for me.i need to build GDAL with oracle spatial so that i can > use OGR2OGR for further conversion of oracle spatial data to shape file. > I have installed FWTools 2.4.7 and want to run the commands from FWTools > shell only.Please can anyone help me out and > guide me by telling me the step by step process of configuring GDAL with > oracle support.Kindly reply back soon as am stuck. > > Thanks & Regards > Natasha > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/c84d75e3/attachment.html From P.Halls at york.ac.uk Thu Mar 10 02:10:06 2011 From: P.Halls at york.ac.uk (Peter J Halls) Date: Thu Mar 10 02:10:16 2011 Subject: [gdal-dev] how to build gdal with oracle spatial In-Reply-To: <20110310064147.26567.qmail@f4mail-235-145.rediffmail.com> References: <20110310064147.26567.qmail@f4mail-235-145.rediffmail.com> Message-ID: <4D78794E.1070300@york.ac.uk> Natasha, I do not believe FWTools to have the Oracle driver built in, so that you may have to build it from source, having first installed the Orcale client libraries (free download from Oracle - this also includes the Oracle ODBC driver, which you will need if you want to connect to Oracle using ODBC). Alternatively, can you use OSGeo4w as previously suggested? Hope that helps, best wishes, Peter natasha chatterjee wrote: > Hi All > GDAL is new for me.i need to build GDAL with oracle spatial so that i can use OGR2OGR for further conversion of oracle spatial data to shape file. > I have installed FWTools 2.4.7 and want to run the commands from FWTools shell only.Please can anyone help me out and > guide me by telling me the step by step process of configuring GDAL with oracle support.Kindly reply back soon as am stuck. > > Thanks & Regards > Natasha > > > ------------------------------------------------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -------------------------------------------------------------------------------- Peter J Halls, GIS Advisor & Acting Team Leader Applications Support Group, Information Directorate, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: C/O IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication -------------------------------------------------------------------------------- From fmarkham at gmail.com Thu Mar 10 02:39:59 2011 From: fmarkham at gmail.com (Francis Markham) Date: Thu Mar 10 02:40:23 2011 Subject: [gdal-dev] Polygonize and 8CONNECTED Message-ID: Hi all, I was writing to enquire about the status of the "8CONNECTED=8" option in the Polygonize function of GDAL 1.8. I would expect that this option joins all pixels of equal value that are diagonally adjacent into a single polygon. However, with the following raster dataset (see http://i.imgur.com/jdUla.png) I receive two polygons in my output shapefile (see http://i.imgur.com/CZWMU.png ). For a copy of the raster, see http://dl.dropbox.com/u/6732375/mish9000.img.zip I am calling polygonize from GDAL's python bindings, which reports itself as "GDAL 1.8.0, released 2011/01/12". My code looks like: gdal.Polygonize(tmprasterband, tmprasterband, shapefile_polygons_layer, 0, ["8CONNECTED=8"]) Is this the expected behaviour or a bug? Can I modify my call to polygonize to get the desired behaviour? If not, how would I merge multiple polygons with the same attribute value (an id number) into a single geometry? Thanks for your help, Francis Markham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/5c14ae7a/attachment.html From amonteiro at dbxgeomatics.com Thu Mar 10 10:31:34 2011 From: amonteiro at dbxgeomatics.com (Andrew Monteiro) Date: Thu Mar 10 10:27:22 2011 Subject: [gdal-dev] Inconsistent handling of Lambert Conformal Conic projection Message-ID: Hi All, I'm experiencing some inconsistent behavior with GDAL 1.8.0's projection handling routines that I'd like to bring to someone's attention. I'm playing with some maps in Lambert Conformal Conic, and the same projection information is getting handled differently depending on how I provide it to GDAL. I started with a MapInfo coordinate system string: Coordsys Earth Projection 3, 74, "m", -95, 49, 49, 77, 0, 0 When that's used, it will come back in Proj4 format as: +proj=lcc +lat_1=49 +lat_2=77 +lat_0=49 +lon_0=-95 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,-0,-0,-0,0 +units=m +no_defs However, if I start with the above Proj4 format string and ask for it back, I get +proj=lcc +lat_1=49 +lat_0=49 +lon_0=-95 +k_0=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs You can see that the lat_2 parameter is no longer to be found... After poking around in the source code, I've found a difference between two routines that handle importing coordinate systems. gdal-1.8.0\ogr\ogrsf_frmts\mitab\mitab_coordsys.cpp has code /*-------------------------------------------------------------- * Lambert Conic Conformal *-------------------------------------------------------------*/ case 3: poSR->SetLCC( GetMIFParm( papszNextField, 2, 0.0 ), GetMIFParm( papszNextField, 3, 0.0 ), GetMIFParm( papszNextField, 1, 0.0 ), GetMIFParm( papszNextField, 0, 0.0 ), GetMIFParm( papszNextField, 4, 0.0 ), GetMIFParm( papszNextField, 5, 0.0 ) ); break; however, in \gdal-1.8.0\ogr\ogr_srs_proj4.cpp the code is: else if( EQUAL(pszProj,"lcc") ) { if( OSR_GDV(papszNV, "lat_0", 0.0 ) == OSR_GDV(papszNV, "lat_1", 0.0 ) ) { /* 1SP form */ SetLCC1SP( OSR_GDV( papszNV, "lat_0", 0.0 ), OSR_GDV( papszNV, "lon_0", 0.0 ), OSR_GDV( papszNV, "k_0", 1.0 ), OSR_GDV( papszNV, "x_0", 0.0 ), OSR_GDV( papszNV, "y_0", 0.0 ) ); } else { /* 2SP form */ SetLCC( OSR_GDV( papszNV, "lat_1", 0.0 ), OSR_GDV( papszNV, "lat_2", 0.0 ), OSR_GDV( papszNV, "lat_0", 0.0 ), OSR_GDV( papszNV, "lon_0", 0.0 ), OSR_GDV( papszNV, "x_0", 0.0 ), OSR_GDV( papszNV, "y_0", 0.0 ) ); } } As far as I can figure, these are the two spots that are setting up the internals for the coordinate system, and they're not quite doing it the same. I just don't know enough about the Lambert Conformal Conic coordinate system any more to tell if I should tweak the MapInfo import routine or the proj4 import routine. So I thought I'd throw this out there and see what the experts had to say. Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/d2108a5b/attachment-0001.html From yang3kui at gmail.com Thu Mar 10 10:42:18 2011 From: yang3kui at gmail.com (kui yang) Date: Thu Mar 10 10:42:20 2011 Subject: [gdal-dev] (no subject) Message-ID: gdal 1.8.0 has problem. when the filename is in Chinese -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/e567ba6b/attachment.html From warmerdam at pobox.com Thu Mar 10 11:07:11 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 10 11:07:15 2011 Subject: [gdal-dev] Chinese Filenames In-Reply-To: References: Message-ID: <4D78F72F.8090202@pobox.com> On 11-03-10 10:42 AM, kui yang wrote: > gdal 1.8.0 has problem. when the filename is in Chinese Kui Yang, That is not a very detailed bug report. GDAL 1.8 includes some changes in the underlying handling of filenames such that filenames passed in to GDALOpen() should be passed in UTF-8 rather than the local encoding. This was generally the situation already on Linux and I suppose most other unix type operating systems. But it was a change on windows. Are you working on windows? How are you encoding the filenames being passed to GDALOpen()? As a workaround, you can restore essentially the old filename handling behavior on windows by setting the GDAL_FILENAME_IS_UTF8 configuration variable to "NO". Some info on setting config options is available at: http://trac.osgeo.org/gdal/wiki/ConfigOptions Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From wendell at enflight.com Thu Mar 10 17:07:10 2011 From: wendell at enflight.com (Wendell Turner) Date: Thu Mar 10 17:07:12 2011 Subject: [gdal-dev] crop a non-square subwindow? In-Reply-To: References: <20110309165149.GB17957@cloud3.rho.net> <4D77BA7D.3020500@pobox.com> Message-ID: <20110310220710.GA5258@cloud3.rho.net> On Wed, Mar 09, 2011 at 06:05:20PM -0600, Marius Jigmond wrote: > On Wed, 2011-03-09 at 12:35 -0500, Frank Warmerdam wrote: > > On 11-03-09 11:51 AM, Wendell Turner wrote: > > > > > > Do any of the gdal utilities crop an image on non-square > > > boundaries? > > > ... > > I think gdalwarp with -crop_to_cutline and a cutline specified > > with the shape will accomplish what you want. > > http://www.gdal.org/gdalwarp.html > > The cutline comes from an OGR supported file but this can be as simple > > as a .csv file with a WKT geometry in it. The -crop_to_cutline may be > > new to 1.8. > > Wendell, > > Please be aware that this method may introduce raster shifting and > possibly resampling (depending on the original cell size). It might or > might not matter for your purposes. A better approach is to use > gdal_translate with -projwin to extract to shape envelope and then > gdal_rasterize with -i to burn nodata where shape is missing. Marius & Frank, The -crop_to_cutline worked as advertised, and I didn't notice any shifting or resampling. However, it seemed to place the cropped image into a larger bounding box and the pixels that are outside the cropping shapefile are black, not transparent. The gdal_rasterize with -i looks interesting, but my input is raster, not vector, and gdal_rasterize doesn't seem to like that. Is there a way to force pixels outside of the cropping polygon to be 'not there', or transparent? Is there a burn value that indicates that? Wendell From warmerdam at pobox.com Thu Mar 10 17:17:39 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 10 17:17:42 2011 Subject: [gdal-dev] crop a non-square subwindow? In-Reply-To: <20110310220710.GA5258@cloud3.rho.net> References: <20110309165149.GB17957@cloud3.rho.net> <4D77BA7D.3020500@pobox.com> <20110310220710.GA5258@cloud3.rho.net> Message-ID: <4D794E03.5010709@pobox.com> On 11-03-10 05:07 PM, Wendell Turner wrote: > Is there a way to force pixels outside of the cropping > polygon to be 'not there', or transparent? Is there a burn > value that indicates that? Wendell, The -dstnodata parameter can be used to set the output nodata value. I'm not sure if it will properly mark that value as no data or not and whether the end application honours nodata values in geotiff is ... variable. Another approach is to use -dstalpha to add an alpha channel to the output. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From wendell at enflight.com Thu Mar 10 17:58:03 2011 From: wendell at enflight.com (Wendell Turner) Date: Thu Mar 10 17:58:05 2011 Subject: [gdal-dev] crop a non-square subwindow? In-Reply-To: <4D794E03.5010709@pobox.com> References: <20110309165149.GB17957@cloud3.rho.net> <4D77BA7D.3020500@pobox.com> <20110310220710.GA5258@cloud3.rho.net> <4D794E03.5010709@pobox.com> Message-ID: <20110310225803.GA10398@cloud3.rho.net> On Thu, Mar 10, 2011 at 05:17:39PM -0500, Frank Warmerdam wrote: > On 11-03-10 05:07 PM, Wendell Turner wrote: > >Is there a way to force pixels outside of the cropping > >polygon to be 'not there', or transparent? Is there a burn > >value that indicates that? > > Another approach is to use -dstalpha to add an alpha channel to the output. That worked fine. Mapserver/OpenLayers likes it that way. Wendell From saad.hessane at gmail.com Fri Mar 11 06:11:03 2011 From: saad.hessane at gmail.com (=?ISO-8859-1?Q?Mohamed_Sa=E2d_HESSANE?=) Date: Fri Mar 11 06:11:06 2011 Subject: [gdal-dev] [OGR]Add a vertex to a feature Message-ID: Hy list, I' m trying to add on the fly points comming from GPS to a shapefile. But the only way i find is to delete the feature from the shapefille, and create a new feature with the added point. There's another way? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110311/6dfe688d/attachment.html From chaitanya.ch at gmail.com Fri Mar 11 06:24:46 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Fri Mar 11 06:24:48 2011 Subject: [gdal-dev] [OGR]Add a vertex to a feature In-Reply-To: References: Message-ID: Mohamed, OGR's shapefile driver may not write the file to the disk until the handle is closed. If the data is going to me simple enough you should consider the CSV format. http://www.gdal.org/ogr/ogr_formats.html http://www.gdal.org/ogr/drv_csv.html 2011/3/11 Mohamed Sa?d HESSANE > Hy list, > I' m trying to add on the fly points comming from GPS to a shapefile. > But the only way i find is to delete the feature from the shapefille, and > create a new feature with the added point. There's another way? > Thank you > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110311/e50566b7/attachment.html From even.rouault at mines-paris.org Fri Mar 11 07:03:14 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 11 07:03:22 2011 Subject: [gdal-dev] [OGR]Add a vertex to a feature In-Reply-To: References: Message-ID: <1299844994.4d7a0f8215aea@webmail.free.fr> Selon Mohamed Sa?d HESSANE : Mohamed, you can also use the OGRLayer::SetFeature() method to update an existing feature from a shapefile. But be aware that if you expand the geometry, its binary size will increase, so when you ask the geometry to be written by SetFeature(), the shape driver will write it at the end of the .shp file, so you might end up losing a lot of space. The same also applies to your current method of deleting and recreating a new feature. Best regards, Even > Hy list, > I' m trying to add on the fly points comming from GPS to a shapefile. > But the only way i find is to delete the feature from the shapefille, and > create a new feature with the added point. There's another way? > Thank you > From saad.hessane at gmail.com Fri Mar 11 07:11:46 2011 From: saad.hessane at gmail.com (=?ISO-8859-1?Q?Mohamed_Sa=E2d_HESSANE?=) Date: Fri Mar 11 07:11:48 2011 Subject: [gdal-dev] [OGR]Add a vertex to a feature In-Reply-To: <1299844994.4d7a0f8215aea@webmail.free.fr> References: <1299844994.4d7a0f8215aea@webmail.free.fr> Message-ID: Thank's for your suggestion. I test the OGRLayer::SetFeature() method, but it don't write the file after that. I think the reason is what say Chaitanya (thank you) about the driver which don't write until the handle is closed. I think the best way is to write a CSV/VRT file. I'm trying now. 2011/3/11 Even Rouault > Selon Mohamed Sa?d HESSANE : > > Mohamed, > > you can also use the OGRLayer::SetFeature() method to update an existing > feature > from a shapefile. But be aware that if you expand the geometry, its binary > size > will increase, so when you ask the geometry to be written by SetFeature(), > the > shape driver will write it at the end of the .shp file, so you might end up > losing a lot of space. The same also applies to your current method of > deleting > and recreating a new feature. > > Best regards, > > Even > > > Hy list, > > I' m trying to add on the fly points comming from GPS to a shapefile. > > But the only way i find is to delete the feature from the shapefille, and > > create a new feature with the added point. There's another way? > > Thank you > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110311/f5403b69/attachment.html From even.rouault at mines-paris.org Fri Mar 11 08:51:02 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 11 08:51:11 2011 Subject: [gdal-dev] [OGR]Add a vertex to a feature In-Reply-To: References: <1299844994.4d7a0f8215aea@webmail.free.fr> Message-ID: <1299851462.4d7a28c681a73@webmail.free.fr> Selon Mohamed Sa?d HESSANE : > Thank's for your suggestion. > I test the OGRLayer::SetFeature() method, but it don't write the file after > that. I think the reason is what say Chaitanya (thank you) about the driver > which don't write until the handle is closed. You can try the OGRLayer::SyncToDisk() method that should write the updated headers to disk. > I think the best way is to write a CSV/VRT file. I doubt it will work as you expect. The CSV driver is an append-only driver. You cannot delete or update existing features. > I'm trying now. > > > 2011/3/11 Even Rouault > > > Selon Mohamed Sa??d HESSANE : > > > > Mohamed, > > > > you can also use the OGRLayer::SetFeature() method to update an existing > > feature > > from a shapefile. But be aware that if you expand the geometry, its binary > > size > > will increase, so when you ask the geometry to be written by SetFeature(), > > the > > shape driver will write it at the end of the .shp file, so you might end up > > losing a lot of space. The same also applies to your current method of > > deleting > > and recreating a new feature. > > > > Best regards, > > > > Even > > > > > Hy list, > > > I' m trying to add on the fly points comming from GPS to a shapefile. > > > But the only way i find is to delete the feature from the shapefille, and > > > create a new feature with the added point. There's another way? > > > Thank you > > > > > > > > > > From yang3kui at gmail.com Fri Mar 11 09:46:52 2011 From: yang3kui at gmail.com (kui yang) Date: Fri Mar 11 09:46:55 2011 Subject: [gdal-dev] Re: gdal-dev Digest, Vol 82, Issue 20 In-Reply-To: <20110310170016.5F97FE024B9@lists.osgeo.org> References: <20110310170016.5F97FE024B9@lists.osgeo.org> Message-ID: My operating system is Win7. Thanks a lot. I tried to add #ifdef WIN32 CPLSetConfigOption( "GDAL_FILENAME_IS_UTF8", "NO" ); #endif in GDALAllRegister. And it works. Now my GDAL1.8.0 work well with filename in Chinese. Really appreciate all you have done. Wish all of you have a nice day. 2011/3/11 > Send gdal-dev mailing list submissions to > gdal-dev@lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > gdal-dev-request@lists.osgeo.org > > You can reach the person managing the list at > gdal-dev-owner@lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. (no subject) (kui yang) > 2. Re: Chinese Filenames (Frank Warmerdam) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Mar 2011 23:42:18 +0800 > From: kui yang > Subject: [gdal-dev] (no subject) > To: gdal-dev@lists.osgeo.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > gdal 1.8.0 has problem. when the filename is in Chinese > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110310/e567ba6b/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 10 Mar 2011 11:07:11 -0500 > From: Frank Warmerdam > Subject: Re: [gdal-dev] Chinese Filenames > To: gdal-dev@lists.osgeo.org > Message-ID: <4D78F72F.8090202@pobox.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11-03-10 10:42 AM, kui yang wrote: > > gdal 1.8.0 has problem. when the filename is in Chinese > > > Kui Yang, > > That is not a very detailed bug report. GDAL 1.8 includes some changes > in the underlying handling of filenames such that filenames passed in to > GDALOpen() should be passed in UTF-8 rather than the local encoding. This > was generally the situation already on Linux and I suppose most other unix > type operating systems. But it was a change on windows. > > Are you working on windows? > > How are you encoding the filenames being passed to GDALOpen()? > > As a workaround, you can restore essentially the old filename handling > behavior on windows by setting the GDAL_FILENAME_IS_UTF8 configuration > variable to "NO". Some info on setting config options is available at: > > http://trac.osgeo.org/gdal/wiki/ConfigOptions > > Best regards, > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent > > > > ------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > End of gdal-dev Digest, Vol 82, Issue 20 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110311/c557ee2c/attachment-0001.html From maciek at mailinator.com Mon Mar 14 09:07:25 2011 From: maciek at mailinator.com (maciek) Date: Mon Mar 14 09:07:28 2011 Subject: [gdal-dev] reprojecting to Near-sided perspective Message-ID: <1300108045669-6168970.post@n2.nabble.com> I am using GDAL embeded in FWTools 2.4.7, I am trying to repoject a raster image into Near-sided perspective. I call: gdalwarp -t_srs "+proj=nsper" s.tif s2.tif And I get: ERROR 1: Translating source or target SRS failed: +proj=nsper I tried adding diferent parameters configuring the projection but nothing seems to help. Other reprojections work fine. What might be the problem with this one? Is there a way to find more details about the error? -- Maciek -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/reprojecting-to-Near-sided-perspective-tp6168970p6168970.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From mike at stamen.com Mon Mar 14 12:50:16 2011 From: mike at stamen.com (Michal Migurski) Date: Mon Mar 14 13:23:07 2011 Subject: [gdal-dev] Need help generating output with alpha channels using Python API Message-ID: Hello, I'm having some difficulties understanding how to get GDAL to generate images with usable alpha channels. I have 3-channel RGB input JPEG image, delivered to GDAL as a VRT with a projection and ground control points, which I'm warping to an output that's no longer rectangular, leaving background areas exposed. Here is an example output: http://things.teczno.com/gnomotile.png The black parts are intended to be transparent, but I haven't been able to understand how to make that work. Here's the relevant part of my Python code: http://dpaste.com/hold/500308/ I've tried to switch to a four channel output which gets me what I think are CMYK channels. I've tried to use SetNoDataValue on the destination bands to make the background purple so it can be easily knocked out. I've tried to create the GTiff output dataset using the ALPHA=YES creation option, but it seemingly doesn't make a difference. None of these ideas has worked - does anyone have any ideas on how the Python API can be used to create transparent output? -mike. ---------------------------------------------------------------- michal migurski- mike@stamen.com 415.558.1610 From xunlei at renci.org Mon Mar 14 14:07:51 2011 From: xunlei at renci.org (Xunlei Wu) Date: Mon Mar 14 14:08:59 2011 Subject: [gdal-dev] identify attribute in GDALRasterBand::RasterBand Message-ID: <7F7CB2A87C76454FA8409EA326FC029728E6C190@exch-mbx1.ad.renci.org> Hi All, I am a novice user of GDAL. I am using GDAL to decode GRIB and GRIB2 files. I followed http://www.gdal.org/gdal_tutorial.html and http://www.gdal.org/gdal_datamodel.html. However, I still have trouble accessing metadata from a GDALRasterBand object and GDALDataset object. For instance, how do I know the count of Metadata items in the return value of GDALMajorObject::GetMetadata()? I was not sure what to put in as "pszName" in GDALMajorObject::GetMEtadataItem(). And is it the right way to retrieve attributes of a GRIB data file? I know a GRIB file contains at least moisture and pressure at each grid point. I have no idea how to GDAL to identify which GDALRasterBand in GDALDataset and their units for instance. Is there a way to tell the elevation of a particular GDALRasterBand? Thanks a lot for your help. Best, 8gpus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110314/155486d6/attachment.html From chaitanya.ch at gmail.com Mon Mar 14 14:42:24 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Mon Mar 14 14:42:27 2011 Subject: [gdal-dev] identify attribute in GDALRasterBand::RasterBand In-Reply-To: <7F7CB2A87C76454FA8409EA326FC029728E6C190@exch-mbx1.ad.renci.org> References: <7F7CB2A87C76454FA8409EA326FC029728E6C190@exch-mbx1.ad.renci.org> Message-ID: Xunlei, GetMetaData() returns a string list. Each string will contain a metadata item. You can read the documentation for handling string list at http://www.gdal.org/cpl__string_8h.html If you happen to know the name of the metadata item, you can use GetMetaDataItem(). Ex: GetMetaDataItem("GRIB_SHORT_NAME") may return a string "100000-ISBL". I think most of your other queries will be resolved when you can read the metadata. On Mon, Mar 14, 2011 at 11:37 PM, Xunlei Wu wrote: > Hi All, > > I am a novice user of GDAL. I am using GDAL to decode GRIB and GRIB2 files. > I followed > > http://www.gdal.org/gdal_tutorial.html and > http://www.gdal.org/gdal_datamodel.html. However, I still have trouble > accessing metadata from a GDALRasterBand object and GDALDataset object. For > instance, how do I know the count of Metadata items in the return value of > GDALMajorObject::GetMetadata()? I was not sure what to put in as ?pszName? > in GDALMajorObject::GetMEtadataItem(). And is it the right way to retrieve > attributes of a GRIB data file? I know a GRIB file contains at least > moisture and pressure at each grid point. I have no idea how to GDAL to > identify which GDALRasterBand in GDALDataset and their units for instance. > Is there a way to tell the elevation of a particular GDALRasterBand? > > Thanks a lot for your help. > > > > Best, > > 8gpus > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/a3955ad4/attachment.html From even.rouault at mines-paris.org Mon Mar 14 15:01:55 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 14 15:02:28 2011 Subject: [gdal-dev] reprojecting to Near-sided perspective In-Reply-To: <1300108045669-6168970.post@n2.nabble.com> References: <1300108045669-6168970.post@n2.nabble.com> Message-ID: <201103142001.55998.even.rouault@mines-paris.org> Le lundi 14 mars 2011 14:07:25, maciek a ?crit : > I am using GDAL embeded in FWTools 2.4.7, I am trying to repoject a raster > image into Near-sided perspective. I call: > > gdalwarp -t_srs "+proj=nsper" s.tif s2.tif > > And I get: > > ERROR 1: Translating source or target SRS failed: > +proj=nsper > > I tried adding diferent parameters configuring the projection but nothing > seems to help. Other reprojections work fine. What might be the problem > with this one? Is there a way to find more details about the error? The near-sided perspective projection isn't handled by GDAL/OGR, but you can try however the following ugly hack that will bypass it. Create a file nsper_wkt.txt for example with the following content : PROJCS["foo", GEOGCS["foo"], PROJECTION["foo"], EXTENSION["PROJ4","+proj=nsper +h=34700.0 +wktext"]] You certainly need to adjust the string in the PROJ4 extension with the appropriate proj.4 definition. And then you can specify nsper_wkt.txt as the value for the -t_srs argument. From kellison at geocue.com Mon Mar 14 17:23:11 2011 From: kellison at geocue.com (Kyle Ellison) Date: Mon Mar 14 17:30:09 2011 Subject: [gdal-dev] Many files over the network Message-ID: <008701cbe28e$06b1f370$1415da50$@com> Often, we need to open many raster files over a network connection with thousands of other files residing in the same directory. Previously, we were using version 1.7.0 of GDAL (from FW Tools), and we used SetConfigOption("GDAL_DISABLE_READDIR_ON_OPEN", "TRUE") to suppress the automatic search for sibling files. This approach served us well. We upgraded to 1.8.0. It was quite a bit slower opening the raster files. I was able to get GDAL built in debug and stepped through the code and discovered the following: 1. It searches for several files containing RPC metadata. 2. It searches for files for PAM as well. I was able to use SetConfigOption("GDAL_PAM_ENABLED", "NO") to suppress searching for PAM files. However, I do not see a way to suppress searching for RPC metadata. Does anyone know of a way to do this or other workarounds? If there is no way to currently do this, is the community open to adding this option? I apologize if this question has been posted previously, but I haven't yet found a convenient way to search the archives. Thanks, Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110314/5388fb2c/attachment.html From even.rouault at mines-paris.org Mon Mar 14 18:40:34 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 14 18:40:42 2011 Subject: [gdal-dev] Many files over the network In-Reply-To: <008701cbe28e$06b1f370$1415da50$@com> References: <008701cbe28e$06b1f370$1415da50$@com> Message-ID: <201103142340.34361.even.rouault@mines-paris.org> Kyle, you didn't mention which driver was in question. I guess this is GeoTIFF ? I've looked at the code of the driver and it appears that it loads the .rpb and .imd files at least since GDAL 1.6.0. The new thing in GDAL 1.8.0 is that it also tries to load the _rpc.txt file. Is it that small difference which causes the slowdown you observe ? In fact, setting GDAL_DISABLE_READDIR_ON_OPEN = TRUE might make things actually worse (w.r.t to that aspect of loading rpb/rpc/imd) since the driver has to really test the filesystem to look for the existence of the files, whereas by default it would rely on the papszSiblingsFile list. Anyway, I've attached a patch (against SVN trunk) that differs the loading of RPC and IMD until necessary (that is to say when GetMetadata() or GetMetadataItem() is called with "RPC" or "IMD" metadata domain, or when GetFileList() is called). Could you try it and report if it makes things better for you ? Another idea to solve the performance problem would be to use an alternate GDALOpen() where you could provide the papszSiblingFile list. If you read several files in the same directory, you could build the list one and provide it multiple times afterwards. Best regards, Even > Often, we need to open many raster files over a network connection with > thousands of other files residing in the same directory. > > > > Previously, we were using version 1.7.0 of GDAL (from FW Tools), and we > used SetConfigOption("GDAL_DISABLE_READDIR_ON_OPEN", "TRUE") > > to suppress the automatic search for sibling files. This approach served > us well. > > > > We upgraded to 1.8.0. It was quite a bit slower opening the raster files. > I was able to get GDAL built in debug and stepped through the code and > discovered the following: > > > > 1. It searches for several files containing RPC metadata. > > 2. It searches for files for PAM as well. > > > > I was able to use SetConfigOption("GDAL_PAM_ENABLED", "NO") to suppress > searching for PAM files. > > > > However, I do not see a way to suppress searching for RPC metadata. Does > anyone know of a way to do this or other workarounds? If there is no way to > currently do this, is the community open to adding this option? > > > > I apologize if this question has been posted previously, but I haven't yet > found a convenient way to search the archives. > > > > Thanks, > > Kyle -------------- next part -------------- A non-text attachment was scrubbed... Name: differ_reading_rpc_and_imd.patch Type: text/x-patch Size: 6389 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110314/347272a1/differ_reading_rpc_and_imd-0001.bin From EAdam at co.lincoln.or.us Mon Mar 14 21:33:26 2011 From: EAdam at co.lincoln.or.us (Eli Adam) Date: Mon Mar 14 21:34:09 2011 Subject: [gdal-dev] Many files over the network In-Reply-To: <008701cbe28e$06b1f370$1415da50$@com> References: <008701cbe28e$06b1f370$1415da50$@com> Message-ID: <4D7E5F75.4F75.00CE.0@co.lincoln.or.us> > I apologize if this question has been posted previously, but I haven't yet > found a convenient way to search the archives. > Thanks, > > Kyle Kyle, It took me a while to find how to do that as well. Try nabble, http://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.html Bests, Eli From devrimbaris at gmail.com Tue Mar 15 08:18:50 2011 From: devrimbaris at gmail.com (Devrim Baris Acar) Date: Tue Mar 15 08:19:56 2011 Subject: [gdal-dev] image quality with pyramids (with gdal_retile) Message-ID: Hi, I am building a pyramid from a 650 MB geotiff file (rgb) , with the following command from fwtools 2.4.6 on a win32 box gdal_retile -levels 5 -pyramidOnly -targetDir pyramid bathymetry. I loaded these image files to geoserver and see that when I zoomed to the higheest available level, the images are "degraded in quality" in comparison to original one. Also , I expected that the resulting pyramid size to be bigger than the original file size, but it is NOT. What is the reason for this , any ideas, and solutions? Best regards, Devrim Baris Acar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/1dc0d6d5/attachment.html From saad.hessane at gmail.com Tue Mar 15 09:30:38 2011 From: saad.hessane at gmail.com (=?ISO-8859-1?Q?Mohamed_Sa=E2d_HESSANE?=) Date: Tue Mar 15 09:30:41 2011 Subject: [gdal-dev] image quality with pyramids (with gdal_retile) In-Reply-To: References: Message-ID: I never use gdal_retile, but i use gdaladdo. It's perfect and there's no qualtity degradation. gdaladdo create one tiff (or other format if you want) overview, containing different level. Syntax : gdaladdo -ro filename 2 4 8 16 32 http://www.gdal.org/gdaladdo.html 2011/3/15 Devrim Baris Acar > Hi, > I am building a pyramid from a 650 MB geotiff file (rgb) , with the > following command from fwtools 2.4.6 on a win32 box > > gdal_retile -levels 5 -pyramidOnly -targetDir pyramid bathymetry. > > I loaded these image files to geoserver and see that when I zoomed to the > higheest available level, the images are "degraded in quality" in > comparison to original one. > Also , I expected that the resulting pyramid size to be bigger than the > original file size, but it is NOT. > > What is the reason for this , any ideas, and solutions? > > Best regards, > > Devrim Baris Acar > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/1ea01abb/attachment.html From christian.mueller at nvoe.at Tue Mar 15 09:41:17 2011 From: christian.mueller at nvoe.at (christian.mueller@nvoe.at) Date: Tue Mar 15 09:41:25 2011 Subject: [gdal-dev] image quality with pyramids (with gdal_retile) In-Reply-To: References: Message-ID: <20110315144117.iitf70x9wck4gw0o@webmail.nvoe.at> Quoting Devrim Baris Acar : > Hi, > I am building a pyramid from a 650 MB geotiff file (rgb) , with the > following command from fwtools 2.4.6 on a win32 box > > gdal_retile -levels 5 -pyramidOnly -targetDir pyramid bathymetry. > > I loaded these image files to geoserver and see that when I zoomed to the > higheest available level, the images are "degraded in quality" in > comparison to original one. Try another interpolation using the -r switch. Default is nearest neighbor, which is fast bot does not produce the best quality. try -r bilinear or -r cubic > Also , I expected that the resulting pyramid size to be bigger than the > original file size, but it is NOT. I do not understand exactly what you are meaning here, but consider the following fact. Each pixel of level n substitutes 4 pixels at level n-1. If your original image = 1024 x 1024, the first level is 512 x 512, the second 256 x 256, the third 128x128, the fourth 64 * 64. Let us stop here and use a calculator for 1024*1024 - 512*512 - 256*256 - 128*128-64*64 The result is 700416, the original image has 700416 pixel more than the sum of all pyramids. Cheers > > What is the reason for this , any ideas, and solutions? > > Best regards, > > Devrim Baris Acar > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kellison at geocue.com Tue Mar 15 09:51:02 2011 From: kellison at geocue.com (Kyle Ellison) Date: Tue Mar 15 09:50:10 2011 Subject: [gdal-dev] Many files over the network Message-ID: <00d001cbe318$06187ee0$12497ca0$@com> Thanks Even. Yes it is GeoTIFF. This is the first time I've ever looked at the GDAL source, so I am not sure what the faster version we have was actually doing regarding metadata files. I know that by commenting out the search for RPC files, I was able to get the image open time back down to what it was previously. It was taking a half second just to search for RPC files in the new version. I know the previous version I was using must NOT have been doing that, because the image open time previously was more like a tenth of a second. I've not been using SVN (I do have a small bit of experience with Hg). I built GDAL from source code downloaded from Tamas Szekeres since that is where I am getting my GDAL binaries now. Do you have any suggestions on the best way for me to proceed to test your patch? Thanks, Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/26c58592/attachment.html From even.rouault at mines-paris.org Tue Mar 15 10:07:45 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 15 10:07:54 2011 Subject: [gdal-dev] Many files over the network In-Reply-To: <00d001cbe318$06187ee0$12497ca0$@com> References: <00d001cbe318$06187ee0$12497ca0$@com> Message-ID: <1300198065.4d7f72b1d0e66@webmail.free.fr> Selon Kyle Ellison : > Thanks Even. Yes it is GeoTIFF. This is the first time I've ever looked at > the GDAL source, so I am not sure what the faster version we have was > actually doing regarding metadata files. I know that by commenting out the > search for RPC files, I was able to get the image open time back down to > what it was previously. It was taking a half second just to search for RPC > files in the new version. I know the previous version I was using must NOT > have been doing that, because the image open time previously was more like a > tenth of a second. I've not been using SVN (I do have a small bit of > experience with Hg). I built GDAL from source code downloaded from Tamas > Szekeres since that is where I am getting my GDAL binaries now. Do you have > any suggestions on the best way for me to proceed to test your patch? > Use one of the source packages tagged -devel as they reflect SVN head. You should be able to apply the patch cleanly over it. > > > Thanks, > > Kyle > > From natashachatterjee at rediffmail.com Tue Mar 15 13:22:23 2011 From: natashachatterjee at rediffmail.com (natasha chatterjee) Date: Tue Mar 15 13:29:18 2011 Subject: [gdal-dev] Where is this nmake.opt file located? Message-ID: <20110315172223.32752.qmail@f4mail-235-131.rediffmail.com> Hi All I am using FWTools.Can anyone tell me where is this nmake.opt file located on our system?if its not there then how to get it?(As i want to configure oracle spatial with GDAL) please reply soon. Thanks and regards Natasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/7e95b772/attachment.html From oliver.bgr at googlemail.com Tue Mar 15 13:43:40 2011 From: oliver.bgr at googlemail.com (Oliver Burger) Date: Tue Mar 15 13:43:47 2011 Subject: [gdal-dev] Strange issue on debian squeeze Message-ID: <201103151843.40949.oliver.bgr@googlemail.com> I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit server. I'm using the following configure: ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes Installed are: libxerces-c-dev 3.1.1-1+b1 libxerces-c3.1 3.1.1-1+b1 out of the debian repositories. And I'm getting the following output from configure: checking for Xerces C++ Parser headers in /usr/include and /usr/include/xercesc... not found checking for Xerces C++ Parser... no Xerces-C support: no The same happens e.g. with expat and openjpeg. It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. Do you have any idea, what is happening here? Thanks, Oliver From chaitanya.ch at gmail.com Tue Mar 15 14:20:19 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 15 14:20:21 2011 Subject: [gdal-dev] Where is this nmake.opt file located? In-Reply-To: <20110315172223.32752.qmail@f4mail-235-131.rediffmail.com> References: <20110315172223.32752.qmail@f4mail-235-131.rediffmail.com> Message-ID: Natasha, nmake.opt file is for when you compile the source. It is in the root directory of the GDAL source tree. If you intend to use Oracle Spatial with GDAL on Windows, you are better off with OSGeo4W than FWTools. It provides oracle support as a separate plugin. http://trac.osgeo.org/osgeo4w/ On Tue, Mar 15, 2011 at 10:52 PM, natasha chatterjee < natashachatterjee@rediffmail.com> wrote: > > Hi All > I am using FWTools.Can anyone tell me where is this > nmake.opt file located on our system?if its not there then > how to get it?(As i want to configure oracle spatial with > GDAL) > > please reply soon. > > Thanks and regards > Natasha > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/b9fe1226/attachment.html From chaitanya.ch at gmail.com Tue Mar 15 14:23:45 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 15 14:23:48 2011 Subject: [gdal-dev] Strange issue on debian squeeze In-Reply-To: <201103151843.40949.oliver.bgr@googlemail.com> References: <201103151843.40949.oliver.bgr@googlemail.com> Message-ID: Oliver, Can you confirm if you have xerces headers in /etc/include directory? On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger wrote: > I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit > server. > > I'm using the following configure: > ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes > > Installed are: > libxerces-c-dev 3.1.1-1+b1 > libxerces-c3.1 3.1.1-1+b1 > > out of the debian repositories. > > And I'm getting the following output from configure: > checking for Xerces C++ Parser headers in /usr/include and > /usr/include/xercesc... not found > checking for Xerces C++ Parser... no > Xerces-C support: no > > The same happens e.g. with expat and openjpeg. > > It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. > > Do you have any idea, what is happening here? > > > Thanks, > > Oliver > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110315/c2b7b108/attachment.html From woodbri at swoodbridge.com Tue Mar 15 15:15:02 2011 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Tue Mar 15 15:17:03 2011 Subject: [gdal-dev] Strange issue on debian squeeze In-Reply-To: References: <201103151843.40949.oliver.bgr@googlemail.com> Message-ID: <4D7FBAB6.9090001@swoodbridge.com> On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: > Oliver, > > Can you confirm if you have xerces headers in /etc/include directory? That should probably say /usr/include directory, in case that was not obvious. -Steve > On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger > > wrote: > > I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit > server. > > I'm using the following configure: > ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes > > Installed are: > libxerces-c-dev 3.1.1-1+b1 > libxerces-c3.1 3.1.1-1+b1 > > out of the debian repositories. > > And I'm getting the following output from configure: > checking for Xerces C++ Parser headers in /usr/include and > /usr/include/xercesc... not found > checking for Xerces C++ Parser... no > Xerces-C support: no > > The same happens e.g. with expat and openjpeg. > > It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. > > Do you have any idea, what is happening here? > > > Thanks, > > Oliver > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From kellison at geocue.com Tue Mar 15 17:48:16 2011 From: kellison at geocue.com (Kyle Ellison) Date: Tue Mar 15 17:47:46 2011 Subject: [gdal-dev] Many files over the network In-Reply-To: <201103142340.34361.even.rouault@mines-paris.org> References: <008701cbe28e$06b1f370$1415da50$@com> <201103142340.34361.even.rouault@mines-paris.org> Message-ID: <013e01cbe35a$b44f5190$1cedf4b0$@com> Even, I tried out the patch. I was unable to actually try it in the 1.9 source since my environment uses the C# bindings and gdal18.dll. So, I applied the patch manually to the 1.8 version I had. That was not terribly difficult... mainly just different line numbers in geotiff.cpp. Anyway, we got the performance of yesteryear back. I would very much like you to commit that change to the main trunk if that is possible. Thanks for your help on this. Best Regards, Kyle -----Original Message----- From: Even Rouault [mailto:even.rouault@mines-paris.org] Sent: Monday, March 14, 2011 5:41 PM To: gdal-dev@lists.osgeo.org Cc: Kyle Ellison Subject: Re: [gdal-dev] Many files over the network Kyle, you didn't mention which driver was in question. I guess this is GeoTIFF ? I've looked at the code of the driver and it appears that it loads the .rpb and .imd files at least since GDAL 1.6.0. The new thing in GDAL 1.8.0 is that it also tries to load the _rpc.txt file. Is it that small difference which causes the slowdown you observe ? In fact, setting GDAL_DISABLE_READDIR_ON_OPEN = TRUE might make things actually worse (w.r.t to that aspect of loading rpb/rpc/imd) since the driver has to really test the filesystem to look for the existence of the files, whereas by default it would rely on the papszSiblingsFile list. Anyway, I've attached a patch (against SVN trunk) that differs the loading of RPC and IMD until necessary (that is to say when GetMetadata() or GetMetadataItem() is called with "RPC" or "IMD" metadata domain, or when GetFileList() is called). Could you try it and report if it makes things better for you ? Another idea to solve the performance problem would be to use an alternate GDALOpen() where you could provide the papszSiblingFile list. If you read several files in the same directory, you could build the list one and provide it multiple times afterwards. Best regards, Even > Often, we need to open many raster files over a network connection > with thousands of other files residing in the same directory. > > > > Previously, we were using version 1.7.0 of GDAL (from FW Tools), and > we used SetConfigOption("GDAL_DISABLE_READDIR_ON_OPEN", "TRUE") > > to suppress the automatic search for sibling files. This approach > served us well. > > > > We upgraded to 1.8.0. It was quite a bit slower opening the raster files. > I was able to get GDAL built in debug and stepped through the code and > discovered the following: > > > > 1. It searches for several files containing RPC metadata. > > 2. It searches for files for PAM as well. > > > > I was able to use SetConfigOption("GDAL_PAM_ENABLED", "NO") to > suppress searching for PAM files. > > > > However, I do not see a way to suppress searching for RPC metadata. > Does anyone know of a way to do this or other workarounds? If there is > no way to currently do this, is the community open to adding this option? > > > > I apologize if this question has been posted previously, but I haven't > yet found a convenient way to search the archives. > > > > Thanks, > > Kyle From even.rouault at mines-paris.org Tue Mar 15 17:53:37 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 15 17:53:54 2011 Subject: [gdal-dev] Many files over the network In-Reply-To: <013e01cbe35a$b44f5190$1cedf4b0$@com> References: <008701cbe28e$06b1f370$1415da50$@com> <201103142340.34361.even.rouault@mines-paris.org> <013e01cbe35a$b44f5190$1cedf4b0$@com> Message-ID: <201103152253.38044.even.rouault@mines-paris.org> Le mardi 15 mars 2011 22:48:16, Kyle Ellison a ?crit : > Even, > > I tried out the patch. I was unable to actually try it in the 1.9 source > since my environment uses the C# bindings and gdal18.dll. So, I applied > the patch manually to the 1.8 version I had. That was not terribly > difficult... mainly just different line numbers in geotiff.cpp. Anyway, > we got the performance of yesteryear back. I would very much like you to > commit that change to the main trunk if that is possible. Thanks for your > help on this. Would you mind opening a GDAL Trac ticket to record this ? Thanks > > Best Regards, > Kyle > > -----Original Message----- > From: Even Rouault [mailto:even.rouault@mines-paris.org] > Sent: Monday, March 14, 2011 5:41 PM > To: gdal-dev@lists.osgeo.org > Cc: Kyle Ellison > Subject: Re: [gdal-dev] Many files over the network > > Kyle, > > you didn't mention which driver was in question. I guess this is GeoTIFF ? > I've looked at the code of the driver and it appears that it loads the .rpb > and .imd files at least since GDAL 1.6.0. The new thing in GDAL 1.8.0 is > that it also tries to load the _rpc.txt file. Is it that small difference > which causes the slowdown you observe ? > > In fact, setting GDAL_DISABLE_READDIR_ON_OPEN = TRUE might make things > actually worse (w.r.t to that aspect of loading rpb/rpc/imd) since the > driver has to really test the filesystem to look for the existence of the > files, whereas by default it would rely on the papszSiblingsFile list. > > Anyway, I've attached a patch (against SVN trunk) that differs the loading > of RPC and IMD until necessary (that is to say when GetMetadata() or > GetMetadataItem() is called with "RPC" or "IMD" metadata domain, or when > GetFileList() is called). > > Could you try it and report if it makes things better for you ? > > Another idea to solve the performance problem would be to use an alternate > GDALOpen() where you could provide the papszSiblingFile list. If you read > several files in the same directory, you could build the list one and > provide it multiple times afterwards. > > Best regards, > > Even > > > Often, we need to open many raster files over a network connection > > with thousands of other files residing in the same directory. > > > > > > > > Previously, we were using version 1.7.0 of GDAL (from FW Tools), and > > we used SetConfigOption("GDAL_DISABLE_READDIR_ON_OPEN", "TRUE") > > > > to suppress the automatic search for sibling files. This approach > > served us well. > > > > > > > > We upgraded to 1.8.0. It was quite a bit slower opening the raster > > files. I was able to get GDAL built in debug and stepped through the > > code and discovered the following: > > > > > > > > 1. It searches for several files containing RPC metadata. > > > > 2. It searches for files for PAM as well. > > > > > > > > I was able to use SetConfigOption("GDAL_PAM_ENABLED", "NO") to > > suppress searching for PAM files. > > > > > > > > However, I do not see a way to suppress searching for RPC metadata. > > Does anyone know of a way to do this or other workarounds? If there is > > no way to currently do this, is the community open to adding this option? > > > > > > > > I apologize if this question has been posted previously, but I haven't > > yet found a convenient way to search the archives. > > > > > > > > Thanks, > > > > Kyle From marco.lechner at fossgis.de Tue Mar 15 18:49:30 2011 From: marco.lechner at fossgis.de (Marco Lechner - FOSSGIS e.V.) Date: Tue Mar 15 18:50:09 2011 Subject: [gdal-dev] Strange issue on debian squeeze In-Reply-To: <4D7FBAB6.9090001@swoodbridge.com> References: <201103151843.40949.oliver.bgr@googlemail.com> <4D7FBAB6.9090001@swoodbridge.com> Message-ID: <4D7FECFA.1010407@fossgis.de> I can reproduce this feature/bug on a freshly installed minimal squeeze having nothing than downloaded gdal-source using # ./configure --with-xerces=yes --with-xerces-inc=/usr/include/ --with-xerces-lib=/usr/lib/ and having installed i libxerces-c-dev v libxerces-c3-dev v libxerces-c3-doc v libxerces-c3-samples i libxerces-c3.1 providing libxerces-c-3.1.so libxerces-c.a libxerces-c.la libxerces-c.so in /usr/lib and providing a bunch of *.hpp in subfolders of /usr/include/xercesc Marco Am 15.03.2011 20:15, schrieb Stephen Woodbridge: > On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: >> Oliver, >> >> Can you confirm if you have xerces headers in /etc/include directory? > > That should probably say /usr/include directory, in case that was not > obvious. > > -Steve > >> On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger >> > wrote: >> >> I have a strange problem installing gdal-1.8.0 on a debian >> squeeze 64bit >> server. >> >> I'm using the following configure: >> ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes >> >> Installed are: >> libxerces-c-dev 3.1.1-1+b1 >> libxerces-c3.1 3.1.1-1+b1 >> >> out of the debian repositories. >> >> And I'm getting the following output from configure: >> checking for Xerces C++ Parser headers in /usr/include and >> /usr/include/xercesc... not found >> checking for Xerces C++ Parser... no >> Xerces-C support: no >> >> The same happens e.g. with expat and openjpeg. >> >> It's working all right on a Ubuntu 32bit and a Mandriva 32bit >> machine. >> >> Do you have any idea, what is happening here? >> >> >> Thanks, >> >> Oliver >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> >> >> >> -- >> Best regards, >> Chaitanya kumar CH. >> /t?a???nj?/ /k?m?r/ >> +91-9494447584 >> 17.2416N 80.1426E >> >> >> >> _______________________________________________ >> 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 From even.rouault at mines-paris.org Tue Mar 15 19:54:06 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 15 19:54:24 2011 Subject: [gdal-dev] Strange issue on debian squeeze In-Reply-To: <4D7FECFA.1010407@fossgis.de> References: <201103151843.40949.oliver.bgr@googlemail.com> <4D7FBAB6.9090001@swoodbridge.com> <4D7FECFA.1010407@fossgis.de> Message-ID: <201103160054.06866.even.rouault@mines-paris.org> Le mardi 15 mars 2011 23:49:30, Marco Lechner - FOSSGIS e.V. a ?crit : > I can reproduce this feature/bug on a freshly installed minimal squeeze > having nothing than downloaded gdal-source using Well, I've just installed a virtual machine with a Debian Squeeze 64 bit and installed libxerces-c-dev and ibxerces-c3.1 All : You don't need to provide any argument at all. ./configure will automagically find xerces (at least for Debian and most other popular distros) Marco : If you want to provide the arguments, you must be aware that the -- with-xerces-lib must be followed with the linker flags and not the library path. So it should be : ./configure --with-xerces=yes --with-xerces- inc=/usr/include/ --with-xerces-lib="-lxerces-c" Oliver : stupid question, but did you check if g++ is installed. Not recognizing xerces (which has a C++ API) would be a typical symtom of an absence of g++. Admitedly, GDAL ./configure should error out loudly at the very moment where it can't find a c++ compiler... > > # ./configure --with-xerces=yes --with-xerces-inc=/usr/include/ > --with-xerces-lib=/usr/lib/ > > and having installed > > i libxerces-c-dev > v libxerces-c3-dev > v libxerces-c3-doc > v libxerces-c3-samples > i libxerces-c3.1 > > providing > > libxerces-c-3.1.so > libxerces-c.a > libxerces-c.la > libxerces-c.so > > in /usr/lib > > and providing a bunch of *.hpp in subfolders of /usr/include/xercesc > > Marco > > Am 15.03.2011 20:15, schrieb Stephen Woodbridge: > > On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: > >> Oliver, > >> > >> Can you confirm if you have xerces headers in /etc/include directory? > > > > That should probably say /usr/include directory, in case that was not > > obvious. > > > > -Steve > > > >> On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger > >> > >> > wrote: > >> I have a strange problem installing gdal-1.8.0 on a debian > >> > >> squeeze 64bit > >> > >> server. > >> > >> I'm using the following configure: > >> ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes > >> > >> Installed are: > >> libxerces-c-dev 3.1.1-1+b1 > >> libxerces-c3.1 3.1.1-1+b1 > >> > >> out of the debian repositories. > >> > >> And I'm getting the following output from configure: > >> checking for Xerces C++ Parser headers in /usr/include and > >> /usr/include/xercesc... not found > >> checking for Xerces C++ Parser... no > >> Xerces-C support: no > >> > >> The same happens e.g. with expat and openjpeg. > >> > >> It's working all right on a Ubuntu 32bit and a Mandriva 32bit > >> > >> machine. > >> > >> Do you have any idea, what is happening here? > >> > >> > >> Thanks, > >> > >> Oliver > >> _______________________________________________ > >> 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 > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From armin.burger at gmx.net Tue Mar 15 20:08:48 2011 From: armin.burger at gmx.net (Armin Burger) Date: Tue Mar 15 20:08:53 2011 Subject: [gdal-dev] Calculate footprints of shapefiles Message-ID: <4D7FFF90.6050104@gmx.net> Hi all I would like to catalogue shapefiles scattered over lots of directories of the file system and store retrievable information of the shapefiles in a PostGIS layer. Extracting parameters like extent, projection, fields, etc works very fine with GDAL's Python bindings. But I would also like to store a sort of "footprint" of the whole shapefile as a geometry object since the extent is a bit coarse geographic representation of the shapefile. So far I have no better idea than eg. for polygon shapefiles looping through all features, applying a Union function on them. And at the end trying to use the Simplify method on the resulting polygon that will be used as the footprint. This is for sure not very efficient for larger shapefiles with lots of records. And for line and point shapefiles I still don't have a clue how their records could be represented by an enclosing polygon (maybe the Boundary functions does something like this...). Any ideas how this footprint generation could be achieved in a feasible way using GDAL/OGR Python? Cheers, Armin From mariusjigmond at hotmail.com Tue Mar 15 20:35:59 2011 From: mariusjigmond at hotmail.com (Marius Jigmond) Date: Tue Mar 15 20:37:08 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: <4D7FFF90.6050104@gmx.net> References: <4D7FFF90.6050104@gmx.net> Message-ID: Armin, Not sure if this would be straightforward in GDAL but you might want to consider a combination of GDAL + Shapely (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). What you're trying to do is spatial analysis not directly implemented in GDAL. Shapely requires that you're working with Cartesian coordinates. The upside is that it has WKT/WKB support for direct loading into PostGIS. -marius On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: > Hi all > > I would like to catalogue shapefiles scattered over lots of directories > of the file system and store retrievable information of the shapefiles > in a PostGIS layer. Extracting parameters like extent, projection, > fields, etc works very fine with GDAL's Python bindings. > > But I would also like to store a sort of "footprint" of the whole > shapefile as a geometry object since the extent is a bit coarse > geographic representation of the shapefile. > > So far I have no better idea than eg. for polygon shapefiles looping > through all features, applying a Union function on them. And at the end > trying to use the Simplify method on the resulting polygon that will be > used as the footprint. > > This is for sure not very efficient for larger shapefiles with lots of > records. And for line and point shapefiles I still don't have a clue how > their records could be represented by an enclosing polygon (maybe the > Boundary functions does something like this...). > > Any ideas how this footprint generation could be achieved in a feasible > way using GDAL/OGR Python? > > Cheers, Armin > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From armin.burger at gmx.net Tue Mar 15 20:53:40 2011 From: armin.burger at gmx.net (Armin Burger) Date: Tue Mar 15 20:53:44 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: References: <4D7FFF90.6050104@gmx.net> Message-ID: <4D800A14.9080802@gmx.net> Marius, thanks for the suggestion. I don't know if shapely supports re-projection of geometries or has a simplify algorithm, which I will both need. There could be some other functions of GDAL/OGR that I might need in the future as well. So in principal I'd prefer to stick to GDAL. armin On 16/03/2011 01:35, Marius Jigmond wrote: > Armin, > > Not sure if this would be straightforward in GDAL but you might want to > consider a combination of GDAL + Shapely > (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). > What you're trying to do is spatial analysis not directly implemented in > GDAL. Shapely requires that you're working with Cartesian coordinates. > The upside is that it has WKT/WKB support for direct loading into > PostGIS. > > -marius > > On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: >> Hi all >> >> I would like to catalogue shapefiles scattered over lots of directories >> of the file system and store retrievable information of the shapefiles >> in a PostGIS layer. Extracting parameters like extent, projection, >> fields, etc works very fine with GDAL's Python bindings. >> >> But I would also like to store a sort of "footprint" of the whole >> shapefile as a geometry object since the extent is a bit coarse >> geographic representation of the shapefile. >> >> So far I have no better idea than eg. for polygon shapefiles looping >> through all features, applying a Union function on them. And at the end >> trying to use the Simplify method on the resulting polygon that will be >> used as the footprint. >> >> This is for sure not very efficient for larger shapefiles with lots of >> records. And for line and point shapefiles I still don't have a clue how >> their records could be represented by an enclosing polygon (maybe the >> Boundary functions does something like this...). >> >> Any ideas how this footprint generation could be achieved in a feasible >> way using GDAL/OGR Python? >> >> Cheers, Armin >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > From manuelrainer at hotmail.com Tue Mar 15 22:51:53 2011 From: manuelrainer at hotmail.com (Manuel Rainer) Date: Tue Mar 15 22:51:55 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: Message-ID: Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7> GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/3f398d1e/attachment.html From chaitanya.ch at gmail.com Wed Mar 16 00:02:16 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Wed Mar 16 00:02:19 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: Message-ID: Manuel, Shapefile is for vector formats alone. Try a raster format to convert the netCDF data. As for the performance, you don't need to cache anything. But it may help to tweak the GDAL_CACHEMAX setting. http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer wrote: > Hi, > > I would like to convert certain time slices (records) out of a netCDF file > to a Shapefile. > The netCDF file has 7> GB, so what is the best proceed to get an > appropriate performance? > I mean, should the data be cached (e.g. in an ASCII file, ...) > before writing a Shapefile or can the shp directly be generated? > Perhaps you have some experiences... > > Thanks for your help! > Best regards > Manuel > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/42fe748a/attachment.html From manuelrainer at hotmail.com Wed Mar 16 00:17:26 2011 From: manuelrainer at hotmail.com (Manuel Rainer) Date: Wed Mar 16 00:17:31 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: , , Message-ID: Thanks for your help, it has to be a Shapefile because we do some further processing (symbology, map creation...). The netCDF file contains hydrodynamics point data. Best regards Manuel Date: Wed, 16 Mar 2011 09:32:16 +0530 Subject: Re: [gdal-dev] netCDF to Shapefile From: chaitanya.ch@gmail.com To: manuelrainer@hotmail.com CC: gdal-dev@lists.osgeo.org Manuel, Shapefile is for vector formats alone. Try a raster format to convert the netCDF data. As for the performance, you don't need to cache anything. But it may help to tweak the GDAL_CACHEMAX setting. http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer wrote: Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7> GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/9b081eff/attachment-0001.html From chaitanya.ch at gmail.com Wed Mar 16 00:36:57 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Wed Mar 16 00:36:59 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: <4D800A14.9080802@gmx.net> References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> Message-ID: Armin, This can be done in either OGR or PostGIS. For OGR, refer to the OGRGeometry class reference, especially the ConvexHull(), Union() and UnionCascaded() functions. For PostGIS, ST_Boundary() and ST_Union(). On Wed, Mar 16, 2011 at 6:23 AM, Armin Burger wrote: > Marius, > > thanks for the suggestion. I don't know if shapely supports re-projection > of geometries or has a simplify algorithm, which I will both need. There > could be some other functions of GDAL/OGR that I might need in the future as > well. So in principal I'd prefer to stick to GDAL. > > armin > > > On 16/03/2011 01:35, Marius Jigmond wrote: > >> Armin, >> >> Not sure if this would be straightforward in GDAL but you might want to >> consider a combination of GDAL + Shapely >> (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). >> What you're trying to do is spatial analysis not directly implemented in >> GDAL. Shapely requires that you're working with Cartesian coordinates. >> The upside is that it has WKT/WKB support for direct loading into >> PostGIS. >> >> -marius >> >> On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: >> >>> Hi all >>> >>> I would like to catalogue shapefiles scattered over lots of directories >>> of the file system and store retrievable information of the shapefiles >>> in a PostGIS layer. Extracting parameters like extent, projection, >>> fields, etc works very fine with GDAL's Python bindings. >>> >>> But I would also like to store a sort of "footprint" of the whole >>> shapefile as a geometry object since the extent is a bit coarse >>> geographic representation of the shapefile. >>> >>> So far I have no better idea than eg. for polygon shapefiles looping >>> through all features, applying a Union function on them. And at the end >>> trying to use the Simplify method on the resulting polygon that will be >>> used as the footprint. >>> >>> This is for sure not very efficient for larger shapefiles with lots of >>> records. And for line and point shapefiles I still don't have a clue how >>> their records could be represented by an enclosing polygon (maybe the >>> Boundary functions does something like this...). >>> >>> Any ideas how this footprint generation could be achieved in a feasible >>> way using GDAL/OGR Python? >>> >>> Cheers, Armin >>> _______________________________________________ >>> 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 > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/1a880c10/attachment.html From mdsumner at gmail.com Wed Mar 16 01:21:23 2011 From: mdsumner at gmail.com (Michael Sumner) Date: Wed Mar 16 01:21:26 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: Message-ID: Hi Manuel, I think you will still need to be more specific. You've indicated that the data is points, but not what the variables in the file are, which variables need to be interrogated for coordinates vs. values, what their dimensions are, whether you want several shapefiles, or just one with (say) multiple attributes, etc. There are a number of ways to convert such data to shapefile, but it might be best to choose a reasonably easy scripting language to do it, such as Python or R - and so there are probably better forums than this for your problem. Either way you'll need to provide a lot more detail - it's likely to be a two step process, with converting the NetCDF grids to tables (in memory or file), and then those to point shapefiles. Cheers, Mike. On Wed, Mar 16, 2011 at 3:17 PM, Manuel Rainer wrote: > Thanks for your help, > it has to be a Shapefile because we do some?further processing (symbology, > map creation...). > The netCDF file contains hydrodynamics point data. > > Best regards > Manuel > > ________________________________ > Date: Wed, 16 Mar 2011 09:32:16 +0530 > Subject: Re: [gdal-dev] netCDF to Shapefile > From: chaitanya.ch@gmail.com > To: manuelrainer@hotmail.com > CC: gdal-dev@lists.osgeo.org > > Manuel, > > Shapefile is for vector formats alone. Try a raster format to convert the > netCDF data. > > As for the performance, you don't need to cache anything. But it may help to > tweak the GDAL_CACHEMAX setting. > http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance > > On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer > wrote: > > Hi, > > I would like to convert certain time slices (records) out of a netCDF file > to a Shapefile. > The netCDF file has 7> GB, so what is the best proceed to get an appropriate > performance? > I mean, should the data be cached (e.g. in an ASCII file, ...) > before?writing a?Shapefile?or can the shp directly be generated? > Perhaps you have some experiences... > > Thanks for your help! > Best regards > Manuel > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsumner@gmail.com From manuelrainer at hotmail.com Wed Mar 16 03:45:07 2011 From: manuelrainer at hotmail.com (Manuel Rainer) Date: Wed Mar 16 03:45:10 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: , , , , Message-ID: Ok, here are more details: I am using Python (2.6) together with netCDF4, numpy and gdal/ogr. So far, I am able to read the dimensions, attributes and variables. I have to choose records depending on certain time slices and export these records together with their dimensions into a shapefile. So, if four time slices are selected four shp files will be created. Currently, I am designing a GUI with Tkinter for data I/O and time slice selection. For the conversion task i would prefer a direct method without caching into a file. I may use normal arrays or pytables.... Just wanted to know what is the more efficient method for caching the data. Thanks for your support Mike! > Date: Wed, 16 Mar 2011 16:21:23 +1100 > Subject: Re: [gdal-dev] netCDF to Shapefile > From: mdsumner@gmail.com > To: manuelrainer@hotmail.com > CC: gdal-dev@lists.osgeo.org > > Hi Manuel, I think you will still need to be more specific. You've > indicated that the data is points, but not what the variables in the > file are, which variables need to be interrogated for coordinates vs. > values, what their dimensions are, whether you want several > shapefiles, or just one with (say) multiple attributes, etc. > > There are a number of ways to convert such data to shapefile, but it > might be best to choose a reasonably easy scripting language to do it, > such as Python or R - and so there are probably better forums than > this for your problem. > > Either way you'll need to provide a lot more detail - it's likely to > be a two step process, with converting the NetCDF grids to tables (in > memory or file), and then those to point shapefiles. > > Cheers, Mike. > > On Wed, Mar 16, 2011 at 3:17 PM, Manuel Rainer wrote: > > Thanks for your help, > > it has to be a Shapefile because we do some further processing (symbology, > > map creation...). > > The netCDF file contains hydrodynamics point data. > > > > Best regards > > Manuel > > > > ________________________________ > > Date: Wed, 16 Mar 2011 09:32:16 +0530 > > Subject: Re: [gdal-dev] netCDF to Shapefile > > From: chaitanya.ch@gmail.com > > To: manuelrainer@hotmail.com > > CC: gdal-dev@lists.osgeo.org > > > > Manuel, > > > > Shapefile is for vector formats alone. Try a raster format to convert the > > netCDF data. > > > > As for the performance, you don't need to cache anything. But it may help to > > tweak the GDAL_CACHEMAX setting. > > http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance > > > > On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer > > wrote: > > > > Hi, > > > > I would like to convert certain time slices (records) out of a netCDF file > > to a Shapefile. > > The netCDF file has 7> GB, so what is the best proceed to get an appropriate > > performance? > > I mean, should the data be cached (e.g. in an ASCII file, ...) > > before writing a Shapefile or can the shp directly be generated? > > Perhaps you have some experiences... > > > > Thanks for your help! > > Best regards > > Manuel > > > > > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > > > -- > > Best regards, > > Chaitanya kumar CH. > > /t?a???nj?/ /k?m?r/ > > +91-9494447584 > > 17.2416N 80.1426E > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > Michael Sumner > Institute for Marine and Antarctic Studies, University of Tasmania > Hobart, Australia > e-mail: mdsumner@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/239b9d1a/attachment.html From pcorti at gmail.com Wed Mar 16 04:21:57 2011 From: pcorti at gmail.com (Paolo Corti) Date: Wed Mar 16 04:22:40 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: Message-ID: On Wed, Mar 16, 2011 at 3:51 AM, Manuel Rainer wrote: > Hi, > > I would like to convert certain time slices (records) out of a netCDF file > to a Shapefile. > The netCDF file has 7> GB, so what is the best proceed to get an appropriate > performance? > I mean, should the data be cached (e.g. in an ASCII file, ...) > before?writing a?Shapefile?or can the shp directly be generated? > Perhaps you have some experiences... Hi I don't know what you mean with performance (maybe the time needed to make the export or the subsequent access to them?), but as far as I remember shapefile has a file size limit of 2 Gb, I personally would avoid that approach. Here PostGis seems to well suit in the scenario, but if you don't have the possibility to access/create a PostGis infrastructure, I personally would give a try to Spatialite. If performance are really a concern, you could instead opt for a NoSQL database: CouchDb has a nice spatial module [0] as far as I have heard. You could use the shp2geocouch approach utility [1] (first export to json with ogr2ogr then json to couchdb) for loading your data. Please note that if you opt for the latest, I am not sure if you will have tools for symbology and map creation at this time, neither you can use the GDAL API. best regards Paolo [0] http://vmx.cx/blog/2009-11-17/geodata-and-couchdb.htm [1] https://github.com/maxogden/shp2geocouch/blob/master/bin/shp2geocouch -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @paolo_corti From armin.burger at gmx.net Wed Mar 16 06:11:10 2011 From: armin.burger at gmx.net (Armin Burger) Date: Wed Mar 16 06:11:15 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> Message-ID: <20110316101110.307410@gmx.net> Chaitanya thanks for the hints. So a sort of Union operation seems to be necessary. I need to check how fast that is with OGR on larger shapefiles (I want to store in PostGIS just the footprint, not the full geometry collection). The ConvexHull could be a good alternative to a simplified boundary. I understand how the normal Union() works, it merges 2 geometries into a new one. But I don't get it what UnionCascade() is doing. It applies a Union on a single geometry and returns the new geometry, what is it actually unioning/merging then? Regards, Armin -------- Original-Nachricht -------- > Datum: Wed, 16 Mar 2011 10:06:57 +0530 > Von: Chaitanya kumar CH > An: armin.burger@gmx.net > CC: Marius Jigmond , gdal-dev@lists.osgeo.org > Betreff: Re: [gdal-dev] Calculate footprints of shapefiles > Armin, > > This can be done in either OGR or PostGIS. > > For OGR, refer to the OGRGeometry class reference, especially the > ConvexHull(), Union() and UnionCascaded() functions. > For PostGIS, ST_Boundary() and ST_Union(). > -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From andreasft at gmail.com Wed Mar 16 07:05:18 2011 From: andreasft at gmail.com (=?ISO-8859-1?Q?Andreas_For=F8_Tollefsen?=) Date: Wed Mar 16 07:05:34 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: Message-ID: I have done this but not to a shapefile direct, but into a postgis database. Use for loops to loop through the temporal dimension, then the lon and lat as sub loops. Then you create an insert string to input each line of data into the sql database. In our NetCDF we have 720x360 observations spatially and 1308 temporal dimension observations. Thats a lot of data! Andreas 2011/3/16 Paolo Corti > On Wed, Mar 16, 2011 at 3:51 AM, Manuel Rainer > wrote: > > Hi, > > > > I would like to convert certain time slices (records) out of a netCDF > file > > to a Shapefile. > > The netCDF file has 7> GB, so what is the best proceed to get an > appropriate > > performance? > > I mean, should the data be cached (e.g. in an ASCII file, ...) > > before writing a Shapefile or can the shp directly be generated? > > Perhaps you have some experiences... > > Hi > I don't know what you mean with performance (maybe the time needed to > make the export or the subsequent access to them?), but as far as I > remember shapefile has a file size > limit of 2 Gb, I personally would avoid that approach. > Here PostGis seems to well suit in the scenario, but if you don't have > the possibility to access/create a PostGis infrastructure, I > personally would give a try to Spatialite. > > If performance are really a concern, you could instead opt for a NoSQL > database: CouchDb has a nice spatial module [0] as far as I have > heard. > You could use the shp2geocouch approach utility [1] (first export to json > with > ogr2ogr then json to couchdb) for loading your data. > Please note that if you opt for the latest, I am not sure if you will > have tools for symbology and map creation at this time, neither you > can use the GDAL API. > > best regards > Paolo > > [0] http://vmx.cx/blog/2009-11-17/geodata-and-couchdb.htm > [1] https://github.com/maxogden/shp2geocouch/blob/master/bin/shp2geocouch > > -- > Paolo Corti > Geospatial software developer > web: http://www.paolocorti.net > twitter: @paolo_corti > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/adf77726/attachment.html From jasonbeverage at gmail.com Wed Mar 16 11:24:54 2011 From: jasonbeverage at gmail.com (Jason Beverage) Date: Wed Mar 16 11:25:15 2011 Subject: [gdal-dev] Pickling OGR Geometry Message-ID: Hi all, I'm looking at pickling ogr geometry. I took the following code from the gdal autotests to try it out: geom_wkt = 'MULTIPOLYGON( ((0 0,1 1,1 0,0 0)),((0 0,10 0, 10 10, 0 10),(1 1,1 2,2 2,2 1)) )' geom = ogr.CreateGeometryFromWkt(geom_wkt) p = pickle.dumps(geom) g = pickle.loads(p) if not geom.Equal(g): print "pickled geometries were not equal" else: print "pickled geometries equal" The geometries are equal and appears to work fine but I get an error printed out right after the loads call: ERROR 1: Empty geometries cannot be constructed If I do ogr.UseExceptions() I get the stack trace: Traceback (most recent call last): File "test.py", line 32, in g = pickle.loads(p) File "/usr/lib/python2.6/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/lib/python2.6/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.6/pickle.py", line 1133, in load_reduce value = func(*args) File "/usr/local/lib/python2.6/dist-packages/GDAL-1.7.2-py2.6-linux-x86_64.egg/osgeo/ogr.py", line 2935, in __init__ this = _ogr.new_Geometry(*args, **kwargs) RuntimeError: Empty geometries cannot be constructed Is this a problem or is it just noise? I'm using GDAL 1.7.2. Thanks, Jason From warmerdam at pobox.com Wed Mar 16 12:58:55 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 16 12:58:57 2011 Subject: [gdal-dev] Need help generating output with alpha channels using Python API In-Reply-To: References: Message-ID: <4D80EC4F.6050900@pobox.com> On 11-03-14 12:50 PM, Michal Migurski wrote: > Hello, > > I'm having some difficulties understanding how to get GDAL to generate > images with usable alpha channels. I have 3-channel RGB input JPEG image, > delivered to GDAL as a VRT with a projection and ground control points, > which I'm warping to an output that's no longer rectangular, leaving > background areas exposed. Here is an example output: > > http://things.teczno.com/gnomotile.png > > The black parts are intended to be transparent, but I haven't been able to > understand how to make that work. Here's the relevant part of my Python > code: > > http://dpaste.com/hold/500308/ > > I've tried to switch to a four channel output which gets me what I think are > CMYK channels. I've tried to use SetNoDataValue on the destination bands to > make the background purple so it can be easily knocked out. I've tried to > create the GTiff output dataset using the ALPHA=YES creation option, but it > seemingly doesn't make a difference. None of these ideas has worked - does > anyone have any ideas on how the Python API can be used to create > transparent output? Mike, I would have thought preinitializing the destination dataset to a marker value should have done the trick. I'm not sure what you mean by using SetNoDatavalue(). Are you aware that this just records metadata with the band indicating what the nodata value should be? Normally I would suggest adding an alpha band on the output and ensuring it is used. But I see GDALReprojectImage() does not make it easy to do this particularly the way it is bound in Python which does not allow one to pass in the warp options structure. So one approach is for you to precreate the output image, initializing with some particular nodata pixel value and then using that in post processing. Another approach might be for the me to modify GDALReprojectImage to utilize an alpha band properly if it exists on the destination image. I can do this in trunk if that would be helpful to you. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From jaadfoo at gmail.com Wed Mar 16 15:01:23 2011 From: jaadfoo at gmail.com (Jamie Adams) Date: Wed Mar 16 15:01:25 2011 Subject: [gdal-dev] gdal_translate format listing is too long Message-ID: Hello all, Question - is there some reason why gdal_translate needs to show a format listing when invoked on the command line with no arguments? On my system this outputs 61 lines which is nearly a maximized shell on my 24" monitor. Wouldn't requiring the --formats flag be more consistent with other tools? I can file a feature request for this - just though I'd ask first. Cheers, Jamie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/ea79a5da/attachment.html From alexander.bruy at gmail.com Wed Mar 16 16:21:28 2011 From: alexander.bruy at gmail.com (Alexander Bruy) Date: Wed Mar 16 16:26:20 2011 Subject: [gdal-dev] Get pixel values from all bands Message-ID: <20110316222128.b943f4e3.alexander.bruy@gmail.com> Hi all I work on raster processing application (developed with C++ and Qt). For reading rasters we use GDAL and it's C++ API. For one task we need to get pixel values from all raster bands. For this I get all GDALRasterBands and store them in list. Then in loop read image row by row and store row from each band in another list. Here is simplified code // iterate over image row by row for ( int row = 0; row < ySize; ++row ) { // read one row from each band and store it in list for ( int b = 0; b < bandCount; ++b ) { float *scanline; scanline = (float *) CPLMalloc( sizeof( float ) * xSize ); bands[ i ]->RasterIO( GF_Read, 0, row, xSize, 1, scanline, xSize, 1, GDT_Float32, 0, 0 ); rows[ i ] = scanline; } // iterate on pixels in row for (int col = 0; col < ySize; ++col) { // get pixel value from bands float pixel[bandCount]; for ( int r = 0; r < bandCount; ++r ) { // get value in (row, col) from band r double pixel[r] = rows[ r ][ col ]; } // do something with this pixel } } Is this correct approach? Or maybe there is another more correct way to do this? Also I'm not sure where I should free memory allocated with CPLMalloc(). After reading pixels and before reading next rows or at end when all rows processed? I'm not a big C++ programmer, so any help is very appreciated Thanks -- Alexander Bruy From mateusz at loskot.net Wed Mar 16 16:38:28 2011 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed Mar 16 16:38:30 2011 Subject: [gdal-dev] Get pixel values from all bands In-Reply-To: <20110316222128.b943f4e3.alexander.bruy@gmail.com> References: <20110316222128.b943f4e3.alexander.bruy@gmail.com> Message-ID: <92c573d1655ac662a5ed17b5fbc370ce.squirrel@loskot.net> Alexander Bruy wrote: > > Here is simplified code > > // iterate over image row by row > for ( int row = 0; row < ySize; ++row ) > { > // read one row from each band and store it in list > for ( int b = 0; b < bandCount; ++b ) > { > float *scanline; > scanline = (float *) CPLMalloc( sizeof( float ) * xSize ); > bands[ i ]->RasterIO( GF_Read, 0, row, xSize, 1, scanline, xSize, > 1, GDT_Float32, 0, 0 ); > rows[ i ] = scanline; > } > > // iterate on pixels in row > for (int col = 0; col < ySize; ++col) > { > // get pixel value from bands > float pixel[bandCount]; > for ( int r = 0; r < bandCount; ++r ) > { > // get value in (row, col) from band r > double pixel[r] = rows[ r ][ col ]; > } > // do something with this pixel > } > } > > Is this correct approach? Or maybe there is another more correct way > to do this? Seems OK to me, except that I don't understand what is the cache of row array for. Why not to process pixels straight from scanline. > Also I'm not sure where I should free memory allocated with CPLMalloc(). > After reading pixels and before reading next rows or at end when > all rows processed? Don't bother with CPLMalloc, let the compiler to clean after you. typedef std::vector raster_data_t; raster_data_t scanline(xSize); bands[ i ]->RasterIO( GF_Read, 0, row, xSize, 1, &scanline[0], xSize, 1, GDT_Float32, 0, 0 ); Best regards, -- Mateusz Loskot http://mateusz.loskot.net From EAdam at co.lincoln.or.us Wed Mar 16 16:41:35 2011 From: EAdam at co.lincoln.or.us (Eli Adam) Date: Wed Mar 16 16:42:15 2011 Subject: [gdal-dev] Get pixel values from all bands In-Reply-To: <20110316222128.b943f4e3.alexander.bruy@gmail.com> References: <20110316222128.b943f4e3.alexander.bruy@gmail.com> Message-ID: <4D80BE0E.4F75.00CE.0@co.lincoln.or.us> Alexander, Not sure if it meets you situation, but there is a command line utility with similar functionality, gdallocationinfo, http://gdal.org/gdallocationinfo.html HTH, Eli >>> On 3/16/2011 at 1:21 PM, in message <20110316222128.b943f4e3.alexander.bruy@gmail.com>, Alexander Bruy wrote: > Hi all > > I work on raster processing application (developed with C++ and Qt). > For reading rasters we use GDAL and it's C++ API. > > For one task we need to get pixel values from all raster bands. For > this I get all GDALRasterBands and store them in list. Then in loop > read image row by row and store row from each band in another list. > > Here is simplified code > > // iterate over image row by row > for ( int row = 0; row < ySize; ++row ) > { > // read one row from each band and store it in list > for ( int b = 0; b < bandCount; ++b ) > { > float *scanline; > scanline = (float *) CPLMalloc( sizeof( float ) * xSize ); > bands[ i ]->RasterIO( GF_Read, 0, row, xSize, 1, scanline, xSize, > 1, GDT_Float32, 0, 0 ); > rows[ i ] = scanline; > } > > // iterate on pixels in row > for (int col = 0; col < ySize; ++col) > { > // get pixel value from bands > float pixel[bandCount]; > for ( int r = 0; r < bandCount; ++r ) > { > // get value in (row, col) from band r > double pixel[r] = rows[ r ][ col ]; > } > // do something with this pixel > } > } > > Is this correct approach? Or maybe there is another more correct way > to do this? > > Also I'm not sure where I should free memory allocated with CPLMalloc(). > After reading pixels and before reading next rows or at end when > all rows processed? > > I'm not a big C++ programmer, so any help is very appreciated > > Thanks From monicabuescu1985 at gmail.com Wed Mar 16 18:12:30 2011 From: monicabuescu1985 at gmail.com (Monica Buescu) Date: Wed Mar 16 18:12:32 2011 Subject: [gdal-dev] Reproject Globcover Message-ID: Greetings I pretend to reproject a known JRC product called GLOBCOVER to UTM WGS84 (zone for France) using gdalwarp keeping spatial resolution (300m) and null_values. Can anyone give me a suggestion on how to reproject it using gdal? Bellow is the gdalinfo information Driver: GTiff/GeoTIFF Files: d:\data\Local\GLobcover\1.tif Size is 18720, 17640 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235630016, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-11.001388887062376,83.001388888883284) Pixel Size = (0.002777777777808,-0.002777777777780) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -11.0013889, 83.0013889) ( 11d 0'5.00"W, 83d 0'5.00"N) Lower Left ( -11.0013889, 34.0013889) ( 11d 0'5.00"W, 34d 0'5.00"N) Upper Right ( 40.9986111, 83.0013889) ( 40d59'55.00"E, 83d 0'5.00"N) Lower Right ( 40.9986111, 34.0013889) ( 40d59'55.00"E, 34d 0'5.00"N) Center ( 14.9986111, 58.5013889) ( 14d59'55.00"E, 58d30'5.00"N) Band 1 Block=18720x1 Type=Byte, ColorInterp=Gray NoData Value=0 Metadata: BAND=CL6 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110316/2f39f49d/attachment.html From bcclaywell at gmail.com Wed Mar 16 19:05:09 2011 From: bcclaywell at gmail.com (Brian Claywell) Date: Wed Mar 16 19:05:11 2011 Subject: [gdal-dev] Reproject Globcover In-Reply-To: References: Message-ID: On Wed, Mar 16, 2011 at 5:12 PM, Monica Buescu wrote: > I pretend to reproject a known JRC product called GLOBCOVER to UTM WGS84 > (zone for France) using gdalwarp keeping spatial resolution (300m) and > null_values. Can anyone give me a suggestion on how to reproject it using > gdal? Try: gdalwarp -t_srs "EPSG:32631" -tr 300 300 -dstnodata 0 EPSG 32631 is WGS84 UTM zone 31N. See http://spatialreference.org/ref/epsg/32631/ -b -- Brian Claywell bcclaywell@gmail.com From Chris.Barker at noaa.gov Wed Mar 16 20:15:50 2011 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed Mar 16 20:15:55 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: <20110316101110.307410@gmx.net> References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> <20110316101110.307410@gmx.net> Message-ID: <4D8152B6.2080108@noaa.gov> > thanks for the hints. So a sort of Union operation seems to be necessary. I need to check how fast that is with OGR on larger shapefiles (I want to store in PostGIS just the footprint, not the full geometry collection). The Convex Hull could be a good alternative to a simplified boundary. it depends on your shapes -- if you have a very concave shape, a convex hull can be a poor representation. You might try simplifying before the Union - that would make the Union faster. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From chaitanya.ch at gmail.com Thu Mar 17 00:27:02 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 17 00:27:04 2011 Subject: [gdal-dev] Where is this nmake.opt file located? In-Reply-To: <1300213626.S.9162.2837.F.H.TkNoYWl0YW55YSBrdW1hciBDSABSZTogW2dkYWwtZGV2XSBXaGVyZSBpcyB0aGlzIG5tYWtlLm9wdCBmaWw_.f4-234-188.forward.old.1300303315.32631@webmail.rediffmail.com> References: <1300213626.S.9162.2837.F.H.TkNoYWl0YW55YSBrdW1hciBDSABSZTogW2dkYWwtZGV2XSBXaGVyZSBpcyB0aGlzIG5tYWtlLm9wdCBmaWw_.f4-234-188.forward.old.1300303315.32631@webmail.rediffmail.com> Message-ID: Natasha, After you install the GDAL and GDAL-Oracle packages, you can access the command line applications in the OSGeo4W Shell command window. http://trac.osgeo.org/osgeo4w/#QuickStartforOSGeo4WUsers You can find the info on connecting to Oracle Spatial in the GDAL website. For vector data access: http://www.gdal.org/ogr/drv_oci.html For raster data access: http://www.gdal.org/frmt_georaster.html On Thu, Mar 17, 2011 at 12:51 AM, natasha chatterjee < natashachatterjee@rediffmail.com> wrote: > > Thanks > I installed Osgeo4w but now I am not getting how to connect > GDAL with Oracle spatial.Please tell me the process and what > are the prerequisites to bechecked.(How to proceed?) > > Kindly help me. > > Regards > Natasha > > Tynaks > On Tue, 15 Mar 2011 23:57:06 +0530 wrote > > >Natasha, > > nmake.opt file is for when you compile the source. It is in the root > directory of the GDAL source tree. > > > If you intend to use Oracle Spatial with GDAL on Windows, you are better > off with OSGeo4W than FWTools. It provides oracle support as a separate > plugin. http://trac.osgeo.org/osgeo4w/ > > > On Tue, Mar 15, 2011 at 10:52 PM, natasha chatterjee wrote: > > > > Hi All > > I am using FWTools.Can anyone tell me where is this > > nmake.opt file located on our system?if its not there then > > how to get it?(As i want to configure oracle spatial with > > GDAL) > > > > please reply soon. > > > > Thanks and regards > > Natasha > > > > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > -- > Best regards, > Chaitanya kumar CH. > > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E > > > > > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/bad577a2/attachment.html From chaitanya.ch at gmail.com Thu Mar 17 00:46:06 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 17 00:46:09 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: <20110316101110.307410@gmx.net> References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> <20110316101110.307410@gmx.net> Message-ID: Armin, Cascaded Union works pretty much like Union except that it is optimized to work on more than two geometries. Both OGR and PostGIS uses the GEOS library to perform this. Read this blog entry by Paul Ramsey: http://blog.cleverelephant.ca/2009/01/must-faster-unions-in-postgis-14.html On Wed, Mar 16, 2011 at 3:41 PM, Armin Burger wrote: > Chaitanya > > thanks for the hints. So a sort of Union operation seems to be necessary. I > need to check how fast that is with OGR on larger shapefiles (I want to > store in PostGIS just the footprint, not the full geometry collection). The > ConvexHull could be a good alternative to a simplified boundary. > > I understand how the normal Union() works, it merges 2 geometries into a > new one. But I don't get it what UnionCascade() is doing. It applies a Union > on a single geometry and returns the new geometry, what is it actually > unioning/merging then? > > Regards, > Armin > > > -------- Original-Nachricht -------- > > Datum: Wed, 16 Mar 2011 10:06:57 +0530 > > Von: Chaitanya kumar CH > > An: armin.burger@gmx.net > > CC: Marius Jigmond , gdal-dev@lists.osgeo.org > > Betreff: Re: [gdal-dev] Calculate footprints of shapefiles > > > Armin, > > > > This can be done in either OGR or PostGIS. > > > > For OGR, refer to the OGRGeometry class reference, especially the > > ConvexHull(), Union() and UnionCascaded() functions. > > For PostGIS, ST_Boundary() and ST_Union(). > > > > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/662a7f66/attachment.html From manuelrainer at hotmail.com Thu Mar 17 02:54:32 2011 From: manuelrainer at hotmail.com (Manuel Rainer) Date: Thu Mar 17 02:54:35 2011 Subject: [gdal-dev] netCDF to Shapefile In-Reply-To: References: , , , Message-ID: thank you guys, a lot of useful information! finally, I'm tryin' what works best in my case. cheers manuel Date: Wed, 16 Mar 2011 12:05:18 +0100 Subject: Re: [gdal-dev] netCDF to Shapefile From: andreasft@gmail.com To: pcorti@gmail.com CC: manuelrainer@hotmail.com; gdal-dev@lists.osgeo.org I have done this but not to a shapefile direct, but into a postgis database. Use for loops to loop through the temporal dimension, then the lon and lat as sub loops. Then you create an insert string to input each line of data into the sql database. In our NetCDF we have 720x360 observations spatially and 1308 temporal dimension observations. Thats a lot of data! Andreas 2011/3/16 Paolo Corti On Wed, Mar 16, 2011 at 3:51 AM, Manuel Rainer wrote: > Hi, > > I would like to convert certain time slices (records) out of a netCDF file > to a Shapefile. > The netCDF file has 7> GB, so what is the best proceed to get an appropriate > performance? > I mean, should the data be cached (e.g. in an ASCII file, ...) > before writing a Shapefile or can the shp directly be generated? > Perhaps you have some experiences... Hi I don't know what you mean with performance (maybe the time needed to make the export or the subsequent access to them?), but as far as I remember shapefile has a file size limit of 2 Gb, I personally would avoid that approach. Here PostGis seems to well suit in the scenario, but if you don't have the possibility to access/create a PostGis infrastructure, I personally would give a try to Spatialite. If performance are really a concern, you could instead opt for a NoSQL database: CouchDb has a nice spatial module [0] as far as I have heard. You could use the shp2geocouch approach utility [1] (first export to json with ogr2ogr then json to couchdb) for loading your data. Please note that if you opt for the latest, I am not sure if you will have tools for symbology and map creation at this time, neither you can use the GDAL API. best regards Paolo [0] http://vmx.cx/blog/2009-11-17/geodata-and-couchdb.htm [1] https://github.com/maxogden/shp2geocouch/blob/master/bin/shp2geocouch -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @paolo_corti _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/50f29bbf/attachment.html From luisapena1979 at gmail.com Thu Mar 17 05:05:45 2011 From: luisapena1979 at gmail.com (=?ISO-8859-1?Q?Luisa_Pe=F1a?=) Date: Thu Mar 17 05:05:49 2011 Subject: [gdal-dev] Reproject USGS Landsat image Message-ID: Hi, I'm planning to reproject a Landsat image using gdalwarp but I have a question: - Besiodes the 7 bands, I also have an AUX file (for each band), an RRD for each file and a GCP. Is it possibvle to use gdalwarp to read this GCP file or is it useless since all the required information is already available in each band? Thanks Best regards, Luisa Pena -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/adefdb3c/attachment.html From WRoberts at csir.co.za Thu Mar 17 05:09:36 2011 From: WRoberts at csir.co.za (Wesley Roberts) Date: Thu Mar 17 05:25:25 2011 Subject: [gdal-dev] Rotate unreferenced tiff file by -90 degrees Message-ID: <4D81EBF0020000730002FDA4@pta-emo.csir.co.za> Dear gdal'ers I am working with TRMM rainfall data from an HDF5 file (converted from hdf4 to hdf5). I am able to use gdal_translate to extract the gridded data from the HDF file using the following command. gdal_translate -of GTiff "HDF5:"3A25.071201.6A.h5"://DATA_GRANULE/PlanetaryGrid2/e_surfRainMean2" test.tif Gdal_translate works a treat and writes out the test.tif file perfectly, however, the file is unreferenced and needs to be rotated by -90 degrees. Is it possible to do this using gdal_translate or do I need to make use of gdalwarp as well? My tiff world file needs to look something like this 0.500000 0.0000000 0.0000000 -0.500000 -179.750000 36.750000 Am I correct in assuming that a suitable proj4 statement might do the trick, wrt assigning projection info and defining rotation? If so can someone point me towards a document explaining the various proj4 declaration parameters, or give me some advice on how to go about getting the data properly referenced. I can complete the task using ENVI but I would far rather write a bash script to get it all done in four or five lines of code. Thanking you in advance Wesley Wesley Roberts PhD. Researcher: Earth Observation Natural Resources & the Environment (NRE) CSIR Tel: +27 (0)21 888-2490 Fax: +27 (0)21 888-2693 skype: roberts-w -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From alexander.bruy at gmail.com Thu Mar 17 07:49:32 2011 From: alexander.bruy at gmail.com (Alexander Bruy) Date: Thu Mar 17 07:54:24 2011 Subject: [gdal-dev] Get pixel values from all bands In-Reply-To: <92c573d1655ac662a5ed17b5fbc370ce.squirrel@loskot.net> References: <20110316222128.b943f4e3.alexander.bruy@gmail.com> <92c573d1655ac662a5ed17b5fbc370ce.squirrel@loskot.net> Message-ID: <20110317134932.7923c4e6.alexander.bruy@gmail.com> Thanks Mateusz, just tested and all works fine -- Alexander Bruy From armin.burger at gmx.net Thu Mar 17 08:21:51 2011 From: armin.burger at gmx.net (Armin Burger) Date: Thu Mar 17 08:21:56 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> <20110316101110.307410@gmx.net> Message-ID: <20110317122151.119150@gmx.net> Chaitanya I can understand how the UnionCascade works in PostDIS since it's an aggregate function. I just don't understand how I should use it in OGR. The documentation has a single line UnionCascaded(self) -> Geometry So it returns a geometry from another geometry, but I would need a returned geometry from a *list* of input geometries, not from a single one. So I don't have a clue if this is possible in OGR. Another option could be the "Collect" function, but this seems to be only implemented in the C libraries, not in the Python bindings. Looks like geometry collections are not available in OGR for Python at all. Armin -------- Original-Nachricht -------- > Datum: Thu, 17 Mar 2011 10:16:06 +0530 > Von: Chaitanya kumar CH > An: Armin Burger > CC: gdal-dev@lists.osgeo.org, mariusjigmond@hotmail.com > Betreff: Re: [gdal-dev] Calculate footprints of shapefiles > Armin, > > Cascaded Union works pretty much like Union except that it is optimized to > work on more than two geometries. > Both OGR and PostGIS uses the GEOS library to perform this. > > Read this blog entry by Paul Ramsey: > http://blog.cleverelephant.ca/2009/01/must-faster-unions-in-postgis-14.html > > On Wed, Mar 16, 2011 at 3:41 PM, Armin Burger > wrote: > > > Chaitanya > > > > thanks for the hints. So a sort of Union operation seems to be > necessary. I > > need to check how fast that is with OGR on larger shapefiles (I want to > > store in PostGIS just the footprint, not the full geometry collection). > The > > ConvexHull could be a good alternative to a simplified boundary. > > > > I understand how the normal Union() works, it merges 2 geometries into a > > new one. But I don't get it what UnionCascade() is doing. It applies a > Union > > on a single geometry and returns the new geometry, what is it actually > > unioning/merging then? > > > > Regards, > > Armin -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From chaitanya.ch at gmail.com Thu Mar 17 09:13:18 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 17 09:13:20 2011 Subject: [gdal-dev] Calculate footprints of shapefiles In-Reply-To: <20110317122151.119150@gmx.net> References: <4D7FFF90.6050104@gmx.net> <4D800A14.9080802@gmx.net> <20110316101110.307410@gmx.net> <20110317122151.119150@gmx.net> Message-ID: Armin, I don't know if it works on geometry collection but it certainly works on a MultiPolygon. In return, you will get either a Polygon or a MultiPolygon depending on the union being connected or not. On Thu, Mar 17, 2011 at 5:51 PM, Armin Burger wrote: > Chaitanya > > I can understand how the UnionCascade works in PostDIS since it's an > aggregate function. I just don't understand how I should use it in OGR. The > documentation has a single line > UnionCascaded(self) -> Geometry > > So it returns a geometry from another geometry, but I would need a returned > geometry from a *list* of input geometries, not from a single one. So I > don't have a clue if this is possible in OGR. > > Another option could be the "Collect" function, but this seems to be only > implemented in the C libraries, not in the Python bindings. Looks like > geometry collections are not available in OGR for Python at all. > > Armin > > > -------- Original-Nachricht -------- > > Datum: Thu, 17 Mar 2011 10:16:06 +0530 > > Von: Chaitanya kumar CH > > An: Armin Burger > > CC: gdal-dev@lists.osgeo.org, mariusjigmond@hotmail.com > > Betreff: Re: [gdal-dev] Calculate footprints of shapefiles > > > Armin, > > > > Cascaded Union works pretty much like Union except that it is optimized > to > > work on more than two geometries. > > Both OGR and PostGIS uses the GEOS library to perform this. > > > > Read this blog entry by Paul Ramsey: > > > http://blog.cleverelephant.ca/2009/01/must-faster-unions-in-postgis-14.html > > > > On Wed, Mar 16, 2011 at 3:41 PM, Armin Burger > > wrote: > > > > > Chaitanya > > > > > > thanks for the hints. So a sort of Union operation seems to be > > necessary. I > > > need to check how fast that is with OGR on larger shapefiles (I want to > > > store in PostGIS just the footprint, not the full geometry collection). > > The > > > ConvexHull could be a good alternative to a simplified boundary. > > > > > > I understand how the normal Union() works, it merges 2 geometries into > a > > > new one. But I don't get it what UnionCascade() is doing. It applies a > > Union > > > on a single geometry and returns the new geometry, what is it actually > > > unioning/merging then? > > > > > > Regards, > > > Armin > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/0ac54562/attachment.html From warmerdam at pobox.com Thu Mar 17 09:34:24 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 17 09:34:26 2011 Subject: [gdal-dev] Rotate unreferenced tiff file by -90 degrees In-Reply-To: <4D81EBF0020000730002FDA4@pta-emo.csir.co.za> References: <4D81EBF0020000730002FDA4@pta-emo.csir.co.za> Message-ID: <4D820DE0.4050305@pobox.com> On 11-03-17 05:09 AM, Wesley Roberts wrote: > Dear gdal'ers > > I am working with TRMM rainfall data from an HDF5 file (converted from hdf4 > to hdf5). I am able to use gdal_translate to extract the gridded data from > the HDF file using the following command. > > gdal_translate -of GTiff > "HDF5:"3A25.071201.6A.h5"://DATA_GRANULE/PlanetaryGrid2/e_surfRainMean2" > test.tif > > Gdal_translate works a treat and writes out the test.tif file perfectly, > however, the file is unreferenced and needs to be rotated by -90 degrees. Is > it possible to do this using gdal_translate or do I need to make use of > gdalwarp as well? My tiff world file needs to look something like this > > 0.500000 0.0000000 0.0000000 -0.500000 -179.750000 36.750000 > > Am I correct in assuming that a suitable proj4 statement might do the trick, > wrt assigning projection info and defining rotation? If so can someone point > me towards a document explaining the various proj4 declaration parameters, > or give me some advice on how to go about getting the data properly > referenced. Wesley, I think the easiest approach is to prepare a worldfile representing the current georeferencing in east-up or west-up orientation. Then use gdalwarp to transform it to north up. gdalwarp input.tif output.tif For "east up" I think the world file might look something like: 0.0 0.5 0.5 0.0 top-left-x top-left-y You might need to fiddle around with the orientation a bit to get it right. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From klassen.js at gmail.com Thu Mar 17 10:21:26 2011 From: klassen.js at gmail.com (Jim Klassen) Date: Thu Mar 17 10:21:30 2011 Subject: [gdal-dev] GDAL Ruby Bindings Message-ID: <89ADC47B-59E4-4B70-BCDD-7BEA7368DF09@gmail.com> I have updated the Ruby bindings so that they will build against Ruby 1.9 and the changes are in trunk. I am looking for people to test and give me feedback. If it works well for people, the changes may make it into a 1.8.x release. Details are available at the following URLs: http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby http://trac.osgeo.org/gdal/ticket/3999 Jim Klassen From zoltans at geograph.co.za Thu Mar 17 10:49:58 2011 From: zoltans at geograph.co.za (Zoltan Szecsei) Date: Thu Mar 17 10:50:48 2011 Subject: [gdal-dev] Rotate unreferenced tiff file by -90 degrees In-Reply-To: <4D820DE0.4050305@pobox.com> References: <4D81EBF0020000730002FDA4@pta-emo.csir.co.za> <4D820DE0.4050305@pobox.com> Message-ID: <4D821F96.9000603@geograph.co.za> On 2011-03-17 15:34, Frank Warmerdam wrote: > On 11-03-17 05:09 AM, Wesley Roberts wrote: >> Dear gdal'ers >> >> I am working with TRMM rainfall data from an HDF5 file (converted >> from hdf4 >> to hdf5). I am able to use gdal_translate to extract the gridded data >> from >> the HDF file using the following command. >> >> gdal_translate -of GTiff >> "HDF5:"3A25.071201.6A.h5"://DATA_GRANULE/PlanetaryGrid2/e_surfRainMean2" >> test.tif >> >> Gdal_translate works a treat and writes out the test.tif file perfectly, >> however, the file is unreferenced and needs to be rotated by -90 >> degrees. Is >> it possible to do this using gdal_translate or do I need to make use of >> gdalwarp as well? My tiff world file needs to look something like this >> >> 0.500000 0.0000000 0.0000000 -0.500000 -179.750000 36.750000 >> >> Am I correct in assuming that a suitable proj4 statement might do the >> trick, >> wrt assigning projection info and defining rotation? If so can >> someone point >> me towards a document explaining the various proj4 declaration >> parameters, >> or give me some advice on how to go about getting the data properly >> referenced. > > Wesley, > > I think the easiest approach is to prepare a worldfile representing the > current georeferencing in east-up or west-up orientation. Then use > gdalwarp to transform it to north up. > > gdalwarp input.tif output.tif > > For "east up" I think the world file might look something like: > > 0.0 > 0.5 > 0.5 > 0.0 > top-left-x > top-left-y > > You might need to fiddle around with the orientation a bit to get it > right. > > Best regards, But presumable the pixel sizes (1st & 4th) would not be zero? -- =========================================== Zoltan Szecsei PrGISc [PGP0031] Geograph (Pty) Ltd. P.O. Box 7, Muizenberg 7950, South Africa. 65 Main Road, Muizenberg 7945 Western Cape, South Africa. 34? 6'16.35"S 18?28'5.62"E Tel: +27-21-7884897 Mobile: +27-83-6004028 Fax: +27-86-6115323 www.geograph.co.za =========================================== ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3510 - Release Date: 03/16/11 From warmerdam at pobox.com Thu Mar 17 11:19:33 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 17 11:19:39 2011 Subject: [gdal-dev] Rotate unreferenced tiff file by -90 degrees In-Reply-To: <4D821F96.9000603@geograph.co.za> References: <4D81EBF0020000730002FDA4@pta-emo.csir.co.za> <4D820DE0.4050305@pobox.com> <4D821F96.9000603@geograph.co.za> Message-ID: <4D822685.3010203@pobox.com> On 11-03-17 10:49 AM, Zoltan Szecsei wrote: >> For "east up" I think the world file might look something like: >> >> 0.0 >> 0.5 >> 0.5 >> 0.0 >> top-left-x >> top-left-y >> >> You might need to fiddle around with the orientation a bit to get it >> right. >> >> Best regards, > > But presumable the pixel sizes (1st & 4th) would not be zero? Zoltan, For east-up or west-up I believe that the 1st and 4th elements in the world file *should* be zero and the 2nd and 3rd will be the pixel size though I may be mixed up about the signs. More detail on the meaning of the world file is available at: http://en.wikipedia.org/wiki/World_file Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From brian at wildsong.biz Thu Mar 17 11:36:24 2011 From: brian at wildsong.biz (Brian Wilson) Date: Thu Mar 17 11:36:46 2011 Subject: [gdal-dev] openjpeg build configuration Message-ID: I am trying to build 1.8.0 on Linux with openjpeg support. I can easily build and install openjpeg from source (oropenjpeg_v1_4_sources_r697) into /usr/local ./configure --with-openjpeg ./configure --with-openjpeg=/usr/local both result in OpenJPEG support: no I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure nothing was cached. I can see this test in configure output checking for opj_decode_tile_data in -lopenjpeg... no which does not look promising. Is there a version compat problem? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/ecd2c145/attachment.html From even.rouault at mines-paris.org Thu Mar 17 12:23:18 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 17 12:23:26 2011 Subject: [gdal-dev] openjpeg build configuration In-Reply-To: References: Message-ID: <1300378998.4d823576e206f@webmail.free.fr> Selon Brian Wilson : Please read carefully the first lines of http://gdal.org/frmt_jp2openjpeg.html for the explanation (and solution) > I am trying to build 1.8.0 on Linux with openjpeg support. > I can easily build and install openjpeg from source > (oropenjpeg_v1_4_sources_r697) into /usr/local > > ./configure --with-openjpeg > ./configure --with-openjpeg=/usr/local > > both result in > > OpenJPEG support: no > > I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure > nothing was cached. > I can see this test in configure output > > checking for opj_decode_tile_data in -lopenjpeg... no > > which does not look promising. Is there a version compat problem? > > Brian > From chaitanya.ch at gmail.com Thu Mar 17 12:27:34 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 17 12:27:37 2011 Subject: [gdal-dev] openjpeg build configuration In-Reply-To: References: Message-ID: Brian, GDAL's JP2OpenJPEG driver is based on version 2 of OpenJPEG library. http://www.gdal.org/frmt_jp2openjpeg.html On Thu, Mar 17, 2011 at 9:06 PM, Brian Wilson wrote: > I am trying to build 1.8.0 on Linux with openjpeg support. > I can easily build and install openjpeg from source > (oropenjpeg_v1_4_sources_r697) into /usr/local > > ./configure --with-openjpeg > ./configure --with-openjpeg=/usr/local > > both result in > > OpenJPEG support: no > > I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure > nothing was cached. > I can see this test in configure output > > checking for opj_decode_tile_data in -lopenjpeg... no > > which does not look promising. Is there a version compat problem? > > Brian > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110317/00b19df0/attachment.html From julien.michel at cnes.fr Thu Mar 17 12:28:19 2011 From: julien.michel at cnes.fr (Julien Michel) Date: Thu Mar 17 12:34:02 2011 Subject: [gdal-dev] openjpeg build configuration In-Reply-To: <1300378998.4d823576e206f@webmail.free.fr> References: <1300378998.4d823576e206f@webmail.free.fr> Message-ID: <4D8236A3.8080508@cnes.fr> I hop on the thread since I am interested in openjpeg support too. It seems than those lines you pointed out are quite outdated, because openjpeg 1.4 released january 2011 provides tile-level reading. Is there any chance to build the gdal driver with openjpeg 1.4 ? Many thanks for your help, Best regards, Julien Michel Le 17/03/2011 17:23, Even Rouault a ?crit : > Selon Brian Wilson: > > Please read carefully the first lines of http://gdal.org/frmt_jp2openjpeg.html > for the explanation (and solution) > >> I am trying to build 1.8.0 on Linux with openjpeg support. >> I can easily build and install openjpeg from source >> (oropenjpeg_v1_4_sources_r697) into /usr/local >> >> ./configure --with-openjpeg >> ./configure --with-openjpeg=/usr/local >> >> both result in >> >> OpenJPEG support: no >> >> I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure >> nothing was cached. >> I can see this test in configure output >> >> checking for opj_decode_tile_data in -lopenjpeg... no >> >> which does not look promising. Is there a version compat problem? >> >> Brian >> > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Julien MICHEL CNES - DCT/SI/AP - BPI 1219 18, avenue Edouard Belin 31401 Toulouse Cedex 09 - France Tel: +33 561 282 894 - Fax: +33 561 283 109 From even.rouault at mines-paris.org Thu Mar 17 13:23:40 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 17 13:23:49 2011 Subject: [gdal-dev] openjpeg build configuration In-Reply-To: <4D8236A3.8080508@cnes.fr> References: <1300378998.4d823576e206f@webmail.free.fr> <4D8236A3.8080508@cnes.fr> Message-ID: <1300382620.4d82439c8a255@webmail.free.fr> Selon Julien Michel : Julien, I've just diff'ed openjpeg.h of 1.3 and 1.4 and couldn't see much difference between the 2. What make you believe that 1.4 supports tile access ? The JP2OpenJPEG driver in particularly needs the opj_set_decode_area(), opj_read_tile_header() and opj_decode_tile_data() API that are only found in v2 branch openjpeg.h Best regards, Even > I hop on the thread since I am interested in openjpeg support too. It > seems than those lines you pointed out are quite outdated, because > openjpeg 1.4 released january 2011 provides tile-level reading. Is there > any chance to build the gdal driver with openjpeg 1.4 ? > > Many thanks for your help, > > Best regards, > > Julien Michel > > Le 17/03/2011 17:23, Even Rouault a ?crit : > > Selon Brian Wilson: > > > > Please read carefully the first lines of > http://gdal.org/frmt_jp2openjpeg.html > > for the explanation (and solution) > > > >> I am trying to build 1.8.0 on Linux with openjpeg support. > >> I can easily build and install openjpeg from source > >> (oropenjpeg_v1_4_sources_r697) into /usr/local > >> > >> ./configure --with-openjpeg > >> ./configure --with-openjpeg=/usr/local > >> > >> both result in > >> > >> OpenJPEG support: no > >> > >> I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure > >> nothing was cached. > >> I can see this test in configure output > >> > >> checking for opj_decode_tile_data in -lopenjpeg... no > >> > >> which does not look promising. Is there a version compat problem? > >> > >> Brian > >> > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > -- > Julien MICHEL > CNES - DCT/SI/AP - BPI 1219 > 18, avenue Edouard Belin > 31401 Toulouse Cedex 09 - France > Tel: +33 561 282 894 - Fax: +33 561 283 109 > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From jorge.arevalo at deimos-space.com Thu Mar 17 13:31:39 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Thu Mar 17 13:35:29 2011 Subject: [gdal-dev] download.osgeo.org down? Message-ID: I can't access the page since yesterday. Someone else? -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From even.rouault at mines-paris.org Thu Mar 17 14:27:24 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 17 14:27:54 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: References: Message-ID: <201103171927.24645.even.rouault@mines-paris.org> Le jeudi 17 mars 2011 18:31:39, Jorge Ar?valo a ?crit : > I can't access the page since yesterday. Someone else? Works for me and http://www.downforeveryoneorjustme.com/download.osgeo.org From jorge.arevalo at deimos-space.com Thu Mar 17 14:37:13 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Thu Mar 17 14:41:10 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: <201103171927.24645.even.rouault@mines-paris.org> References: <201103171927.24645.even.rouault@mines-paris.org> Message-ID: 2011/3/17 Even Rouault : > Le jeudi 17 mars 2011 18:31:39, Jorge Ar?valo a ?crit : >> I can't access the page since yesterday. Someone else? > > Works for me and http://www.downforeveryoneorjustme.com/download.osgeo.org > Thanks for the info! -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From mwtoews at gmail.com Fri Mar 18 01:31:00 2011 From: mwtoews at gmail.com (Mike Toews) Date: Fri Mar 18 01:31:24 2011 Subject: [gdal-dev] Adding field to Shapefile via Python Message-ID: In a Python script, I am updating an exiting shapefile with data by adding a column. However, my changes don't seem to be saved. Here is what I have: from osgeo import ogr obs_file = 'myfile.shp' source = ogr.Open(obs_file, 1) layer = source.GetLayer() layer_defn = layer.GetLayerDefn() new_field = ogr.FieldDefn('MYFLD', ogr.OFTInteger) layer_defn.AddFieldDefn(new_field) source = None However, when I check the resulting file, I do not see the new field. I have also tried inserting the following (before "source=None") feature = layer.GetNextFeature() feature.GetField('EXIST') # an existing float field with data feature.SetField('EXIST', 111.1) # works feature.SetField('MYFLD', 123) # does nothing layer.SetFeature(feature) Which successfully updates the data in the existing field, but not the added field. Where did I go wrong? Thanks in advance. -Mike From mike at stamen.com Fri Mar 18 01:41:26 2011 From: mike at stamen.com (Michal Migurski) Date: Fri Mar 18 01:41:33 2011 Subject: [gdal-dev] Need help generating output with alpha channels using Python API In-Reply-To: <4D80EC4F.6050900@pobox.com> References: <4D80EC4F.6050900@pobox.com> Message-ID: <4D430B61-E472-46F8-9D11-74954229F55D@stamen.com> On Mar 16, 2011, at 9:58 AM, Frank Warmerdam wrote: > On 11-03-14 12:50 PM, Michal Migurski wrote: >> Hello, >> >> I'm having some difficulties understanding how to get GDAL to generate >> images with usable alpha channels. I have 3-channel RGB input JPEG image, >> delivered to GDAL as a VRT with a projection and ground control points, >> which I'm warping to an output that's no longer rectangular, leaving >> background areas exposed. Here is an example output: >> >> http://things.teczno.com/gnomotile.png >> >> The black parts are intended to be transparent, but I haven't been able to >> understand how to make that work. Here's the relevant part of my Python >> code: >> >> http://dpaste.com/hold/500308/ >> >> I've tried to switch to a four channel output which gets me what I think are >> CMYK channels. I've tried to use SetNoDataValue on the destination bands to >> make the background purple so it can be easily knocked out. I've tried to >> create the GTiff output dataset using the ALPHA=YES creation option, but it >> seemingly doesn't make a difference. None of these ideas has worked - does >> anyone have any ideas on how the Python API can be used to create >> transparent output? > > Mike, > > I would have thought preinitializing the destination dataset to a marker > value should have done the trick. I'm not sure what you mean by using > SetNoDatavalue(). Are you aware that this just records metadata with the > band indicating what the nodata value should be? I figured that out after a while, but was casting about for a solution and trying anything that seemed potentially useful. > Normally I would suggest adding an alpha band on the output and ensuring it > is used. But I see GDALReprojectImage() does not make it easy to do this > particularly the way it is bound in Python which does not allow one to > pass in the warp options structure. What I ended up doing was adding an alpha band to the original VRT, by keeping a white PNG around and using it to augment the existing RGB bands from the JPEG source files. This worked well, the results are as I'd expect, with the side effect that I'm now building up the VRT files from strings instead of shelling out to gdal_translate as I was doing before. I'm satisfied with the outcome, and after figuring out the difference between RGBA and ARGB I'm getting correct-looking images with aliased alpha channel output. Here's a sample VRT: http://dpaste.com/hold/512864/ > Another approach might be for the me to modify GDALReprojectImage to > utilize an alpha band properly if it exists on the destination image. > I can do this in trunk if that would be helpful to you. A more featureful ReprojectImage would definitely be helpful in the future, though for now I think I've gotten to an outcome that works well enough. Thanks for an excellent library! -mike. ---------------------------------------------------------------- michal migurski- mike@stamen.com 415.558.1610 From chaitanya.ch at gmail.com Fri Mar 18 01:45:34 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Fri Mar 18 01:45:37 2011 Subject: [gdal-dev] Adding field to Shapefile via Python In-Reply-To: References: Message-ID: Mike, A new field cannot be added to a feature definition while there are any features based on that feature definition. See the docs for OGRFeatureDefn::AddFieldDefn() http://www.gdal.org/ogr/classOGRFeatureDefn.html#40e681d8464b42f1a1fac655f16ac3dd On Fri, Mar 18, 2011 at 11:01 AM, Mike Toews wrote: > In a Python script, I am updating an exiting shapefile with data by > adding a column. However, my changes don't seem to be saved. Here is > what I have: > > from osgeo import ogr > obs_file = 'myfile.shp' > > source = ogr.Open(obs_file, 1) > layer = source.GetLayer() > layer_defn = layer.GetLayerDefn() > > new_field = ogr.FieldDefn('MYFLD', ogr.OFTInteger) > layer_defn.AddFieldDefn(new_field) > > source = None > > However, when I check the resulting file, I do not see the new field. > > I have also tried inserting the following (before "source=None") > > feature = layer.GetNextFeature() > feature.GetField('EXIST') # an existing float field with data > feature.SetField('EXIST', 111.1) # works > feature.SetField('MYFLD', 123) # does nothing > layer.SetFeature(feature) > > Which successfully updates the data in the existing field, but not the > added field. > > Where did I go wrong? Thanks in advance. > > -Mike > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110318/78794183/attachment.html From gwenael.le-noc at wanadoo.fr Fri Mar 18 03:13:29 2011 From: gwenael.le-noc at wanadoo.fr (Gwenael LE NOC) Date: Fri Mar 18 03:13:33 2011 Subject: [gdal-dev] Selecting a specific driver Message-ID: <30614156.57091.1300432409959.JavaMail.www@wwinf1g26> Hello everybody, is there a way to explicitly specify the driver to use when opening an image? In fact, I have a Jpeg2000 image that opens well with the MrSID driver, but not with other Jpeg2000 drivers... sadly, the MrSID driver is not chosen by default. I saw that GDALOpenInternal allowed to select allowed drivers, but it is not accesible out of GDAL ... Is there an other way? Thanks Gwen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110318/c476afed/attachment.html From jukka.rahkonen at mmmtike.fi Fri Mar 18 06:24:57 2011 From: jukka.rahkonen at mmmtike.fi (Jukka Rahkonen) Date: Fri Mar 18 06:25:10 2011 Subject: [gdal-dev] Re: Selecting a specific driver References: <30614156.57091.1300432409959.JavaMail.www@wwinf1g26> Message-ID: Gwenael LE NOC wanadoo.fr> writes: > > Hello everybody,is there a way to explicitly specify the driver to use when opening an image?In fact, I have a Jpeg2000 image that opens well with the MrSID driver, but not with other Jpeg2000 drivers... sadly, the MrSID driver is not chosen by default.I saw that GDALOpenInternal allowed to select allowed drivers, but it is not accesible out of GDAL ...Is there an other way?ThanksGwen Hi, At least it is possible to skip one driver by setting GDAL_SKIP= environment variable for the driver to be skipped. There can be many JPEG2000 drivers configured but I do not know if it is possible to skip several drivers by giving a list. -Jukka Rahkonen- From niccolo at rigacci.org Fri Mar 18 07:50:09 2011 From: niccolo at rigacci.org (Niccolo Rigacci) Date: Fri Mar 18 08:11:30 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: References: Message-ID: <20110318115009.GC21754@rigacci.org> On Thu, Mar 17, 2011 at 06:31:39PM +0100, Jorge Ar?valo wrote: > I can't access the page since yesterday. Someone else? On the GFOSS.it mailing list (Italian users) was noticed the same problem a wewk ago. Still not resolved. It seems a routing problem between providers. An Italian provider know to be broken: INTERB-MNT (Interbusiness, the largest Italian ISP provider) Also the Orange provider from Romania was reported to be broken. Can someone on the download.osgeo.org network check the reverse route? A ping should suffice, an example hosts to check against: 88.57.16.26 (my gateway on INTERB-MNT) -- Niccolo Rigacci Firenze - Italy From warmerdam at pobox.com Fri Mar 18 09:03:48 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 18 09:03:54 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: <20110318115009.GC21754@rigacci.org> References: <20110318115009.GC21754@rigacci.org> Message-ID: <4D835834.7@pobox.com> On 11-03-18 07:50 AM, Niccolo Rigacci wrote: > Can someone on the download.osgeo.org network check the reverse > route? A ping should suffice, an example hosts to check against: > > 88.57.16.26 (my gateway on INTERB-MNT) Niccolo, I can confirm the above IP cannot be pinged from download.osgeo.org, but can be from Montreal. I will note there is a download mirror at http://download2.osgeo.org/ I would suggest we leave other dicussion of download.osgeo.org to the OSGEO System Administration Committee mailing list. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From gwenael.le-noc at wanadoo.fr Fri Mar 18 09:15:32 2011 From: gwenael.le-noc at wanadoo.fr (Gwen) Date: Fri Mar 18 09:15:33 2011 Subject: [gdal-dev] Re: Selecting a specific driver In-Reply-To: References: <30614156.57091.1300432409959.JavaMail.www@wwinf1g26> Message-ID: <1300454132330-6184487.post@n2.nabble.com> Accroding to GDALDriverManager doc (http://www.gdal.org/classGDALDriverManager.html#6b571113d0ee5ac074a572bc4ae3df74) : "All drivers specified in the space delimited list in the GDAL_SKIP environment variable will be deregistered and destroyed." It therefore seems possible to specify multiple drivers to skip, and thanks to GDALDriverManager, to unload them dynamically (and possibly to reload them after loading the image. Thanks a lot ! Gwen -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Selecting-a-specific-driver-tp6183624p6184487.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From jgr007 at gmail.com Fri Mar 18 16:00:12 2011 From: jgr007 at gmail.com (Jeff Ruby) Date: Fri Mar 18 16:03:20 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? Message-ID: Hi, I've built a TMS structure using gdal2tiles. I'd like to access the files directly not via a webserver. It appears the WMS TMS minidriver may be an option and I'd like to know if supports reference to a local drive\path. Thanks much, -Jeff From even.rouault at mines-paris.org Fri Mar 18 16:11:20 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 18 16:12:01 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? In-Reply-To: References: Message-ID: <201103182111.20865.even.rouault@mines-paris.org> Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a ?crit : > Hi, > > I've built a TMS structure using gdal2tiles. I'd like to access the > files directly not via a webserver. > > It appears the WMS TMS minidriver may be an option and I'd like to > know if supports reference to a local drive\path. Yes, use file://a_directory_name > > Thanks much, > -Jeff > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From mike at stamen.com Fri Mar 18 17:52:59 2011 From: mike at stamen.com (Michal Migurski) Date: Fri Mar 18 17:53:01 2011 Subject: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ? Message-ID: <25777C64-79EE-4D0C-899A-9CE61BDCCFD7@stamen.com> Hi, I'm seeing some weird behaviors related to virtual raster datasets opened simultaneously from multiple processes. I hope I can explain so that this makes sense. Here's an excerpt of my python code: http://dpaste.com/hold/515217/ Line 8 is where I make a change to the dataset: source_ds.SetProjection(source_ds.GetGCPProjection()) I do that so that the projection for the ground control points is available for a later call to gdal.ReprojectImage(); it wasn't working until I started to use SetProjection() in this way. All of this is being called from the context of a multi-process web server, running as unprivileged user "www-data" under Ubuntu (this is important later). My web server error log fills up with these: ERROR 1: Failed to write .vrt file in FlushCache(). My assumption here is that because the unprivileged user can't write to the dataset file, gdal throws off an error to complain that it can't flush the dataset cache back to the original file. So far, this is just an annoyance, but one that I would expect to go away when I switched from gdal.Open() to gdal.OpenShared() with the read-only flag, like this: gdal.OpenShared(src_path, gdal.GA_ReadOnly) Still getting the errors. Meanwhile, I made a switch in web servers, from an Apache-based CGI environment to the multi-worker WSGI server Gunicorn. When I initially ran my code under Gunicorn using my normal, privileged user account, I immediately started to see failures from gdal.Open and gdal.OpenShared, specifically the assertion errors on line 4 of the dpaste above. I tried to place exclusive file locks (using fcntl.flock) around each access to a given VRT dataset, but this didn't seem to help at all. There were frequent, unpredictable errors with opening data sets in a multi-process environment *until* I switched from the privileged user to the unprivileged user. Once I did that, everything began to work normally, but I got all the old "ERROR 1" reports again. It seems to me that gdal.OpenShared() with the read-only flag isn't doing what it promises, and that it's trying to write back to the files, potentially modifying them even as competing processes are accessing them. Is it possible that the overlapping processes in my privileged user scenario are seeing temporarily-empty VRT files? I'm also confused by the lack of a gdal.Close() function or something similar, and by the fact that I can't seem to make a change to a dataset in memory without gdal attempting to push that change back to disk via FlushCache(). What's the right thing to do here? Make temporary copies of small VRT data sets prior to each use so they can be safely written to and disposed of? Build a wrapper class that encapsulates copying and disposal? Figure out some way to make gdal release datasets when asked, or open them in real read-only mode? Any advice greatly appreciated! -mike. ---------------------------------------------------------------- michal migurski- mike@stamen.com 415.558.1610 From even.rouault at mines-paris.org Fri Mar 18 18:14:48 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 18 18:15:28 2011 Subject: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ? In-Reply-To: <25777C64-79EE-4D0C-899A-9CE61BDCCFD7@stamen.com> References: <25777C64-79EE-4D0C-899A-9CE61BDCCFD7@stamen.com> Message-ID: <201103182314.48645.even.rouault@mines-paris.org> Michal, For a reason I'm unclear (might be just historical and not desired behaviour ?), the VRT driver will try to rewrite the VRT if it has been modified. There's however a workaround to avoid the error to pop at the closing. You can empty the description of the dataset with source_ds.SetDescription('') Open() or OpenShared() will not change anything about that. In python, you close a dataset by dropping the reference to the object, for example by assigning None to it. I'm not clear why you have errors with your new webserver, but if you use a multi-threaded one, did you make sure you have built GDAL with thread support (./configure --with-threads) ? (This is now the default since GDAL 1.8.0) Best regards, Even > Hi, > > I'm seeing some weird behaviors related to virtual raster datasets opened > simultaneously from multiple processes. I hope I can explain so that this > makes sense. Here's an excerpt of my python code: > > http://dpaste.com/hold/515217/ > > Line 8 is where I make a change to the dataset: > > source_ds.SetProjection(source_ds.GetGCPProjection()) > > I do that so that the projection for the ground control points is available > for a later call to gdal.ReprojectImage(); it wasn't working until I > started to use SetProjection() in this way. All of this is being called > from the context of a multi-process web server, running as unprivileged > user "www-data" under Ubuntu (this is important later). My web server > error log fills up with these: > > ERROR 1: Failed to write .vrt file in FlushCache(). > > My assumption here is that because the unprivileged user can't write to the > dataset file, gdal throws off an error to complain that it can't flush the > dataset cache back to the original file. So far, this is just an > annoyance, but one that I would expect to go away when I switched from > gdal.Open() to gdal.OpenShared() with the read-only flag, like this: > > gdal.OpenShared(src_path, gdal.GA_ReadOnly) > > Still getting the errors. > > Meanwhile, I made a switch in web servers, from an Apache-based CGI > environment to the multi-worker WSGI server Gunicorn. When I initially ran > my code under Gunicorn using my normal, privileged user account, I > immediately started to see failures from gdal.Open and gdal.OpenShared, > specifically the assertion errors on line 4 of the dpaste above. I tried > to place exclusive file locks (using fcntl.flock) around each access to a > given VRT dataset, but this didn't seem to help at all. There were > frequent, unpredictable errors with opening data sets in a multi-process > environment *until* I switched from the privileged user to the > unprivileged user. Once I did that, everything began to work normally, but > I got all the old "ERROR 1" reports again. > > It seems to me that gdal.OpenShared() with the read-only flag isn't doing > what it promises, and that it's trying to write back to the files, > potentially modifying them even as competing processes are accessing them. > Is it possible that the overlapping processes in my privileged user > scenario are seeing temporarily-empty VRT files? I'm also confused by the > lack of a gdal.Close() function or something similar, and by the fact that > I can't seem to make a change to a dataset in memory without gdal > attempting to push that change back to disk via FlushCache(). > > What's the right thing to do here? Make temporary copies of small VRT data > sets prior to each use so they can be safely written to and disposed of? > Build a wrapper class that encapsulates copying and disposal? Figure out > some way to make gdal release datasets when asked, or open them in real > read-only mode? > > Any advice greatly appreciated! > > -mike. > > ---------------------------------------------------------------- > michal migurski- mike@stamen.com > 415.558.1610 > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From mike at stamen.com Fri Mar 18 18:59:00 2011 From: mike at stamen.com (Michal Migurski) Date: Fri Mar 18 18:59:03 2011 Subject: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ? In-Reply-To: <201103182314.48645.even.rouault@mines-paris.org> References: <25777C64-79EE-4D0C-899A-9CE61BDCCFD7@stamen.com> <201103182314.48645.even.rouault@mines-paris.org> Message-ID: Thanks Even, very helpful! Gunicorn is not multi-thread, but it's multi-process, so there's going to be concurrent connections to a data set even though I'm not performing any threaded functions. I'll try what you suggest, dropping the object reference to see what happens. -mike. On Mar 18, 2011, at 3:14 PM, Even Rouault wrote: > Michal, > > For a reason I'm unclear (might be just historical and not desired behaviour > ?), the VRT driver will try to rewrite the VRT if it has been modified. > > There's however a workaround to avoid the error to pop at the closing. You can > empty the description of the dataset with source_ds.SetDescription('') > > Open() or OpenShared() will not change anything about that. > > In python, you close a dataset by dropping the reference to the object, for > example by assigning None to it. > > I'm not clear why you have errors with your new webserver, but if you use a > multi-threaded one, did you make sure you have built GDAL with thread support > (./configure --with-threads) ? (This is now the default since GDAL 1.8.0) > > Best regards, > > Even > >> Hi, >> >> I'm seeing some weird behaviors related to virtual raster datasets opened >> simultaneously from multiple processes. I hope I can explain so that this >> makes sense. Here's an excerpt of my python code: >> >> http://dpaste.com/hold/515217/ >> >> Line 8 is where I make a change to the dataset: >> >> source_ds.SetProjection(source_ds.GetGCPProjection()) >> >> I do that so that the projection for the ground control points is available >> for a later call to gdal.ReprojectImage(); it wasn't working until I >> started to use SetProjection() in this way. All of this is being called >> from the context of a multi-process web server, running as unprivileged >> user "www-data" under Ubuntu (this is important later). My web server >> error log fills up with these: >> >> ERROR 1: Failed to write .vrt file in FlushCache(). >> >> My assumption here is that because the unprivileged user can't write to the >> dataset file, gdal throws off an error to complain that it can't flush the >> dataset cache back to the original file. So far, this is just an >> annoyance, but one that I would expect to go away when I switched from >> gdal.Open() to gdal.OpenShared() with the read-only flag, like this: >> >> gdal.OpenShared(src_path, gdal.GA_ReadOnly) >> >> Still getting the errors. >> >> Meanwhile, I made a switch in web servers, from an Apache-based CGI >> environment to the multi-worker WSGI server Gunicorn. When I initially ran >> my code under Gunicorn using my normal, privileged user account, I >> immediately started to see failures from gdal.Open and gdal.OpenShared, >> specifically the assertion errors on line 4 of the dpaste above. I tried >> to place exclusive file locks (using fcntl.flock) around each access to a >> given VRT dataset, but this didn't seem to help at all. There were >> frequent, unpredictable errors with opening data sets in a multi-process >> environment *until* I switched from the privileged user to the >> unprivileged user. Once I did that, everything began to work normally, but >> I got all the old "ERROR 1" reports again. >> >> It seems to me that gdal.OpenShared() with the read-only flag isn't doing >> what it promises, and that it's trying to write back to the files, >> potentially modifying them even as competing processes are accessing them. >> Is it possible that the overlapping processes in my privileged user >> scenario are seeing temporarily-empty VRT files? I'm also confused by the >> lack of a gdal.Close() function or something similar, and by the fact that >> I can't seem to make a change to a dataset in memory without gdal >> attempting to push that change back to disk via FlushCache(). >> >> What's the right thing to do here? Make temporary copies of small VRT data >> sets prior to each use so they can be safely written to and disposed of? >> Build a wrapper class that encapsulates copying and disposal? Figure out >> some way to make gdal release datasets when asked, or open them in real >> read-only mode? >> >> Any advice greatly appreciated! >> >> -mike. >> >> ---------------------------------------------------------------- >> michal migurski- mike@stamen.com >> 415.558.1610 >> >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > ---------------------------------------------------------------- michal migurski- mike@stamen.com 415.558.1610 From mike at stamen.com Sat Mar 19 00:00:17 2011 From: mike at stamen.com (Michal Migurski) Date: Sat Mar 19 00:00:19 2011 Subject: [gdal-dev] Open(), OpenShared(), errors, FlushCache(), and no Close() ? In-Reply-To: References: <25777C64-79EE-4D0C-899A-9CE61BDCCFD7@stamen.com> <201103182314.48645.even.rouault@mines-paris.org> Message-ID: A thing I ended up writing to deal with gdal's desire to write to the VRT files: http://dpaste.com/hold/516167/ -mike. On Mar 18, 2011, at 3:59 PM, Michal Migurski wrote: > Thanks Even, very helpful! > > Gunicorn is not multi-thread, but it's multi-process, so there's going to be concurrent connections to a data set even though I'm not performing any threaded functions. I'll try what you suggest, dropping the object reference to see what happens. > > -mike. > > On Mar 18, 2011, at 3:14 PM, Even Rouault wrote: > >> Michal, >> >> For a reason I'm unclear (might be just historical and not desired behaviour >> ?), the VRT driver will try to rewrite the VRT if it has been modified. >> >> There's however a workaround to avoid the error to pop at the closing. You can >> empty the description of the dataset with source_ds.SetDescription('') >> >> Open() or OpenShared() will not change anything about that. >> >> In python, you close a dataset by dropping the reference to the object, for >> example by assigning None to it. >> >> I'm not clear why you have errors with your new webserver, but if you use a >> multi-threaded one, did you make sure you have built GDAL with thread support >> (./configure --with-threads) ? (This is now the default since GDAL 1.8.0) >> >> Best regards, >> >> Even >> >>> Hi, >>> >>> I'm seeing some weird behaviors related to virtual raster datasets opened >>> simultaneously from multiple processes. I hope I can explain so that this >>> makes sense. Here's an excerpt of my python code: >>> >>> http://dpaste.com/hold/515217/ >>> >>> Line 8 is where I make a change to the dataset: >>> >>> source_ds.SetProjection(source_ds.GetGCPProjection()) >>> >>> I do that so that the projection for the ground control points is available >>> for a later call to gdal.ReprojectImage(); it wasn't working until I >>> started to use SetProjection() in this way. All of this is being called >>> from the context of a multi-process web server, running as unprivileged >>> user "www-data" under Ubuntu (this is important later). My web server >>> error log fills up with these: >>> >>> ERROR 1: Failed to write .vrt file in FlushCache(). >>> >>> My assumption here is that because the unprivileged user can't write to the >>> dataset file, gdal throws off an error to complain that it can't flush the >>> dataset cache back to the original file. So far, this is just an >>> annoyance, but one that I would expect to go away when I switched from >>> gdal.Open() to gdal.OpenShared() with the read-only flag, like this: >>> >>> gdal.OpenShared(src_path, gdal.GA_ReadOnly) >>> >>> Still getting the errors. >>> >>> Meanwhile, I made a switch in web servers, from an Apache-based CGI >>> environment to the multi-worker WSGI server Gunicorn. When I initially ran >>> my code under Gunicorn using my normal, privileged user account, I >>> immediately started to see failures from gdal.Open and gdal.OpenShared, >>> specifically the assertion errors on line 4 of the dpaste above. I tried >>> to place exclusive file locks (using fcntl.flock) around each access to a >>> given VRT dataset, but this didn't seem to help at all. There were >>> frequent, unpredictable errors with opening data sets in a multi-process >>> environment *until* I switched from the privileged user to the >>> unprivileged user. Once I did that, everything began to work normally, but >>> I got all the old "ERROR 1" reports again. >>> >>> It seems to me that gdal.OpenShared() with the read-only flag isn't doing >>> what it promises, and that it's trying to write back to the files, >>> potentially modifying them even as competing processes are accessing them. >>> Is it possible that the overlapping processes in my privileged user >>> scenario are seeing temporarily-empty VRT files? I'm also confused by the >>> lack of a gdal.Close() function or something similar, and by the fact that >>> I can't seem to make a change to a dataset in memory without gdal >>> attempting to push that change back to disk via FlushCache(). >>> >>> What's the right thing to do here? Make temporary copies of small VRT data >>> sets prior to each use so they can be safely written to and disposed of? >>> Build a wrapper class that encapsulates copying and disposal? Figure out >>> some way to make gdal release datasets when asked, or open them in real >>> read-only mode? >>> >>> Any advice greatly appreciated! >>> >>> -mike. >>> >>> ---------------------------------------------------------------- >>> michal migurski- mike@stamen.com >>> 415.558.1610 >>> >>> >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > ---------------------------------------------------------------- > michal migurski- mike@stamen.com > 415.558.1610 > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ---------------------------------------------------------------- michal migurski- mike@stamen.com 415.558.1610 From mwtoews at gmail.com Sun Mar 20 18:47:44 2011 From: mwtoews at gmail.com (Mike Toews) Date: Sun Mar 20 18:48:08 2011 Subject: [gdal-dev] Adding field to Shapefile via Python In-Reply-To: References: Message-ID: Ok, I found the issue. Rather than adding a new field def'n: layer_defn.AddFieldDefn(new_field) it needs to instead be created on the layer: layer.CreateField(new_field) The documentation is misleading, as I thought I couldn't add a field to an existing shapefile if there were features in it. I would recommend adding a "See also" link from AddFieldDefn to: http://www.gdal.org/ogr/ogr__api_8h.html#ab585ef1166c61c4819f7fd46ee4a275 -Mike On 18 March 2011 18:45, Chaitanya kumar CH wrote: > > Mike, > > A new field cannot be added to a feature definition while there are any features based on that feature definition. > See the docs for OGRFeatureDefn::AddFieldDefn() > http://www.gdal.org/ogr/classOGRFeatureDefn.html#40e681d8464b42f1a1fac655f16ac3dd > > On Fri, Mar 18, 2011 at 11:01 AM, Mike Toews wrote: >> >> In a Python script, I am updating an exiting shapefile with data by >> adding a column. However, my changes don't seem to be saved. Here is >> what I have: >> >> from osgeo import ogr >> obs_file = 'myfile.shp' >> >> source = ogr.Open(obs_file, 1) >> layer = source.GetLayer() >> layer_defn = layer.GetLayerDefn() >> >> new_field = ogr.FieldDefn('MYFLD', ogr.OFTInteger) >> layer_defn.AddFieldDefn(new_field) >> >> source = None >> >> However, when I check the resulting file, I do not see the new field. >> >> I have also tried inserting the following (before "source=None") >> >> feature = layer.GetNextFeature() >> feature.GetField('EXIST') # an existing float field with data >> feature.SetField('EXIST', 111.1) # works >> feature.SetField('MYFLD', 123) # does nothing >> layer.SetFeature(feature) >> >> Which successfully updates the data in the existing field, but not the >> added field. >> >> Where did I go wrong? Thanks in advance. >> >> -Mike >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E From even.rouault at mines-paris.org Sun Mar 20 19:05:30 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 20 19:05:41 2011 Subject: [gdal-dev] Adding field to Shapefile via Python In-Reply-To: References: Message-ID: <201103210005.30942.even.rouault@mines-paris.org> Le dimanche 20 mars 2011 23:47:44, Mike Toews a ?crit : > Ok, I found the issue. Rather than adding a new field def'n: > layer_defn.AddFieldDefn(new_field) > > it needs to instead be created on the layer: > layer.CreateField(new_field) > > The documentation is misleading, as I thought I couldn't add a field > to an existing shapefile if there were features in it. I would > recommend adding a "See also" link from AddFieldDefn to: > http://www.gdal.org/ogr/ogr__api_8h.html#ab585ef1166c61c4819f7fd46ee4a275 > Agreed, done in http://trac.osgeo.org/gdal/changeset/21999 From Sebastien.Favre at spotimage.fr Mon Mar 21 06:29:15 2011 From: Sebastien.Favre at spotimage.fr (Favre, Sebastien) Date: Mon Mar 21 06:29:19 2011 Subject: [gdal-dev] KML conversion and attributes Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- Ce courrier ?lectronique et toutes les pi?ces ?ventuellement jointes qu?il contient sont CONFIDENTIELS et destin?s exclusivement ? l?usage de leur destinataire. Si une erreur de transmission ou une adresse erron?e a mal dirig?e ce courrier, merci d?en informer l?exp?diteur en lui faisant une r?ponse par courrier ?lectronique d?s r?ception. Si vous n??tes pas le destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en faire ?tat, le distribuer, le copier, l?imprimer ou en r?v?ler le contenu ? une tierce partie. Ce courrier ?lectronique est ? usage strictement informatif et ne saurait engager de quelque mani?re que ce soit SPOT IMAGE SA, ni ses filiales. This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. From tjeffery at gmail.com Mon Mar 21 08:28:24 2011 From: tjeffery at gmail.com (Tom Jeffery) Date: Mon Mar 21 08:28:27 2011 Subject: [gdal-dev] Getting unique values from a raster band Message-ID: What is the proper way to extract all the unique values contained in a raster Band object? I had initially assumed that if a RasterAttributeTable object existed, it would contain a "Value" column, but I have come across instances where the only column in the table is a "Histogram" field containing the counts of each pixel value, but not the value itself. Currently, I check for the existence of the table, check to see if it has a Value column, and if not, inspect each pixel value to get the unique set. The pixel scanning fallback method is quite slow, however, and when I view the same rasters in ArcCatalog and bring up the "Table" view, it is able to instantly display the typical Value / Count table. Is there some trick I'm missing here on how to get these values? Thanks very much! Tom Jeffery -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110321/5f45f927/attachment.html From warmerdam at pobox.com Mon Mar 21 09:24:44 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 21 09:24:48 2011 Subject: [gdal-dev] Getting unique values from a raster band In-Reply-To: References: Message-ID: <4D87519C.4010609@pobox.com> On 11-03-21 08:28 AM, Tom Jeffery wrote: > What is the proper way to extract all the unique values contained in a raster > Band object? I had initially assumed that if a RasterAttributeTable object > existed, it would contain a "Value" column, but I have come across instances > where the only column in the table is a "Histogram" field containing the counts > of each pixel value, but not the value itself. > > Currently, I check for the existence of the table, check to see if it has a > Value column, and if not, inspect each pixel value to get the unique set. The > pixel scanning fallback method is quite slow, however, and when I view the same > rasters in ArcCatalog and bring up the "Table" view, it is able to instantly > display the typical Value / Count table. Is there some trick I'm missing here > on how to get these values? Tom, I believe that ArcGIS is using the GetHistogram() method on the band which can also find the histogram stored in other ways than a RasterAttributeTable. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From sfkeller at gmail.com Mon Mar 21 10:12:02 2011 From: sfkeller at gmail.com (Stefan Keller) Date: Mon Mar 21 10:12:04 2011 Subject: [gdal-dev] KML conversion and attributes In-Reply-To: References: Message-ID: Did you check the doc. at http://www.gdal.org/ogr/drv_kml.html ? Yours, S. 2011/3/21 Favre, Sebastien : > Hello to all, > > > > I try to convert the following KML file into Shapefile format. > > > > > > > > 110m_lakes > > > > ??????????????? > > ??????????????? > > ??????????????? > > ??????????????? > > ??????????????? > > ??????????????? > > > > ? > > ??????????????? 0 > > ??????????????? Lake > > ? > > ??????????????? > > ?????????????????????????????? 0 > > ?????????????????????????????? name="Description">Lake > > ?????????????????????????????? Lake > Baikal > > ?????????????????????????????? 0 > > ?????????????????????????????? POLYGON > > ??????????????? > > > 106.57998579307912,52.799981594445541 > 106.53998823448521,52.939998887740373 107.0800069519353,53.180010077519981 > 107.2999935242018,53.379997870489532 107.59997521365611,53.519989325568218 > 108.03994835818912,53.859968573616456 108.37997928266967,54.259995835987837 > 109.05270307824526,55.027597561251326 109.19346967980832,55.535602728896592 > 109.50699059452313,55.730913804743722 109.92980716353523,55.712956244522303 > 109.70000206913326,54.980003567110515 109.66000451053935,54.719993598033952 > 109.47996382043448,54.339990953175658 109.31997358605884,53.819996853238692 > 109.22003136600637,53.619983222052994 108.99999311730755,53.780025132860928 > 108.60001753136845,53.439994208380398 108.800005324338,53.379997870489532 > 108.76000776574409,53.200008856816936 108.45997439985749,53.140012518926071 > 108.17999148970011,52.799981594445541 107.79996300662566,52.579995022179034 > 107.31999230349876,52.420004787803393 106.64003380740229,52.320010891318617 > 106.10001508995219,52.039976304728967 105.740037062607,51.759993394571595 > 105.24001590375084,51.520008043008133 104.81998986208251,51.460011705117267 > 104.30002160036167,51.500009263711178 103.76000288291161,51.600003160195953 > 103.62001142783291,51.73999461527464 103.85999677939637,51.85998729105637 > 104.39996382041414,51.85998729105637 105.05997521364597,52.000004584351203 > 105.48000125531431,52.280013332724707 105.98002241417046,52.519998684288169 > 106.26000532432784,52.619992580772944 > 106.57998579307912,52.799981594445541 > > ? > > > > > > I use the command line for that : ogr2ogr -f "ESRI Shapefile" lake.shp > lake.kml > > The problem is I only get the attributes Name and Descriptio (after trunk) > in the output Shapefile. > > Attributes ScaleRank, Name12 and Name2 are missing. > > Do you have any explanation ? > > > > Please note,? I have installed the LIBKML driver In GDAL/OGR (thanks to > Frank for its help) : > > > > D:\Data\ >ogr2ogr --formats > > Supported Formats: > > ? -> "ESRI Shapefile" (read/write) > > ? -> "MapInfo File" (read/write) > > ? -> "UK .NTF" (readonly) > > ? -> "SDTS" (readonly) > > ? -> "TIGER" (read/write) > > ? -> "S57" (read/write) > > ? -> "DGN" (read/write) > > ? -> "VRT" (readonly) > > ? -> "REC" (readonly) > > ? -> "Memory" (read/write) > > ? -> "BNA" (read/write) > > ? -> "CSV" (read/write) > > ? -> "GML" (read/write) > > ? -> "GPX" (read/write) > > ? -> "LIBKML" (read/write) > > ? -> "KML" (read/write) > > ? -> "GeoJSON" (read/write) > > ? -> "GMT" (read/write) > > ? -> "ODBC" (read/write) > > ? -> "PGeo" (readonly) > > ? -> "MSSQLSpatial" (read/write) > > ? -> "PCIDSK" (read/write) > > ? -> "XPlane" (readonly) > > ? -> "AVCBin" (readonly) > > ? -> "AVCE00" (readonly) > > ? -> "DXF" (read/write) > > ? -> "Geoconcept" (read/write) > > ? -> "GeoRSS" (read/write) > > ? -> "GPSTrackMaker" (read/write) > > ? -> "VFK" (readonly) > > ? -> "PGDump" (read/write) > > ? -> "GPSBabel" (read/write) > > ? -> "SUA" (readonly) > > ? -> "OpenAir" (readonly) > > ? -> "PDS" (readonly) > > ? -> "HTF" (readonly) > > ? -> "AeronavFAA" (readonly) > > > > Thanks in advance for your help. > > > > S?bastien > > > > Ce courrier ?lectronique et toutes les pi?ces ?ventuellement jointes qu?il > contient sont CONFIDENTIELS et destin?s exclusivement ? l?usage de leur > destinataire. Si une erreur de transmission ou une adresse erron?e a mal > dirig?e ce courrier, merci d?en informer l?exp?diteur en lui faisant une > r?ponse par courrier ?lectronique d?s r?ception. Si vous n??tes pas le > destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en > faire ?tat, le distribuer, le copier, l?imprimer ou en r?v?ler le contenu ? > une tierce partie. > Ce courrier ?lectronique est ? usage strictement informatif et ne saurait > engager de quelque mani?re que ce soit SPOT IMAGE SA, ni ses filiales. > > This e-mail and any attachments hereto are CONFIDENTIAL and intended solely > for the use of the addressee. If you have received this e-mail in error > please send it back to the person that sent it to you. > If you have received it in error, please notify the sender by return email. > If you are not the addressee of this email, you must not use, keep, > disseminate, copy, print or otherwise deal with it. > This email is for information only and will not bind SPOT IMAGE SA in any > contract or obligation, nor its subsidiaries. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From jorge.arevalo at deimos-space.com Mon Mar 21 11:25:08 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Mon Mar 21 11:25:31 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: <4D835834.7@pobox.com> References: <20110318115009.GC21754@rigacci.org> <4D835834.7@pobox.com> Message-ID: On Fri, Mar 18, 2011 at 2:03 PM, Frank Warmerdam wrote: > On 11-03-18 07:50 AM, Niccolo Rigacci wrote: >> >> Can someone on the download.osgeo.org network check the reverse >> route? A ping should suffice, an example hosts to check against: >> >> 88.57.16.26 (my gateway on INTERB-MNT) > > Niccolo, > > I can confirm the above IP cannot be pinged from download.osgeo.org, > but can be from Montreal. ?I will note there is a download mirror at > http://download2.osgeo.org/ > > I would suggest we leave other dicussion of download.osgeo.org to the > OSGEO System Administration Committee mailing list. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up ? | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush ? ?| Geospatial Programmer for Rent > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > Hi, Still unavailable from my network, in Spain. Same problem with trac.osgeo.org since today. And http://www.downforeveryoneorjustme.com/trac.osgeo.org Says trac is down... Should we report this to http://lists.osgeo.org/mailman/listinfo/sac ? -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From warmerdam at pobox.com Mon Mar 21 11:48:56 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 21 11:49:02 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: References: <20110318115009.GC21754@rigacci.org> <4D835834.7@pobox.com> Message-ID: <4D877368.3090206@pobox.com> > Hi, > > Still unavailable from my network, in Spain. Same problem with > trac.osgeo.org since today. And > > http://www.downforeveryoneorjustme.com/trac.osgeo.org > > Says trac is down... > > Should we report this to http://lists.osgeo.org/mailman/listinfo/sac ? Jorge, The Trac/SVN VM was down for circa 30 minutes this morning, but should be working fine again now. This problem was unrelated to the download.osgeo.org issue. For GDAL or other OSGeo systems problems I would encourage the following sequence: 1) Mention it in the #osgeo channel on IRC if you notice a problem. 2) wait 10-15 minutes for a response or for a transient problem to go away. 3) Submit a trac ticket at http://trac.osgeo.org/osgeo (with component set to "Systems Admin") and details on the issue. Email about the ticket will be sent to the sac mailing list. Obviously problems with trac can't be reported via trac in which case email to the sac@lists.osgeo.org mailing list would be good. Note that you need to be subscribed to the list to post to it. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From Sebastien.Favre at spotimage.fr Mon Mar 21 12:11:36 2011 From: Sebastien.Favre at spotimage.fr (Favre, Sebastien) Date: Mon Mar 21 12:11:40 2011 Subject: [gdal-dev] KML conversion and attributes In-Reply-To: References: Message-ID: Hello Stefan, Yes I checked that page and notice there were limitations specifically on attributes conversion. This is why I looked at : http://www.gdal.org/ogr/drv_libkml.html thinking attributes handling would be better. I have managed to install the driver but conversion are not better. I have certainly missed something... S?bastien -----Message d'origine----- De?: Stefan Keller [mailto:sfkeller@gmail.com] Envoy??: lundi 21 mars 2011 15:12 ??: Favre, Sebastien Cc?: gdal-dev@lists.osgeo.org Objet?: Re: [gdal-dev] KML conversion and attributes Did you check the doc. at http://www.gdal.org/ogr/drv_kml.html ? Yours, S. 2011/3/21 Favre, Sebastien : > Hello to all, > > > > I try to convert the following KML file into Shapefile format. > > > > > > > > 110m_lakes > > > > ??????????????? > > ??????????????? type="string"> > > ??????????????? type="int"> > > ??????????????? type="string"> > > ??????????????? > > ??????????????? > > > > ? > > ??????????????? 0 > > ??????????????? Lake > > ? > > ??????????????? > > ?????????????????????????????? 0 > > ?????????????????????????????? name="Description">Lake > > ?????????????????????????????? Lake > Baikal > > ?????????????????????????????? 0 > > ?????????????????????????????? name="Name2">POLYGON > > ??????????????? > > > 106.57998579307912, > 52.799981594445541 > 106.53998823448521,52.939998887740373 > 107.0800069519353,53.180010077519981 > 107.2999935242018,53.379997870489532 > 107.59997521365611,53.519989325568218 > 108.03994835818912,53.859968573616456 > 108.37997928266967,54.259995835987837 > 109.05270307824526,55.027597561251326 > 109.19346967980832,55.535602728896592 > 109.50699059452313,55.730913804743722 > 109.92980716353523,55.712956244522303 > 109.70000206913326,54.980003567110515 > 109.66000451053935,54.719993598033952 > 109.47996382043448,54.339990953175658 > 109.31997358605884,53.819996853238692 > 109.22003136600637,53.619983222052994 > 108.99999311730755,53.780025132860928 > 108.60001753136845,53.439994208380398 > 108.800005324338,53.379997870489532 > 108.76000776574409,53.200008856816936 > 108.45997439985749,53.140012518926071 > 108.17999148970011,52.799981594445541 > 107.79996300662566,52.579995022179034 > 107.31999230349876,52.420004787803393 > 106.64003380740229,52.320010891318617 > 106.10001508995219,52.039976304728967 > 105.740037062607,51.759993394571595 > 105.24001590375084,51.520008043008133 > 104.81998986208251,51.460011705117267 > 104.30002160036167,51.500009263711178 > 103.76000288291161,51.600003160195953 > 103.62001142783291,51.73999461527464 > 103.85999677939637,51.85998729105637 > 104.39996382041414,51.85998729105637 > 105.05997521364597,52.000004584351203 > 105.48000125531431,52.280013332724707 > 105.98002241417046,52.519998684288169 > 106.26000532432784,52.619992580772944 > 106.57998579307912,52.799981594445541 rBoundaryIs> > > ? > > > > > > I use the command line for that : ogr2ogr -f "ESRI Shapefile" lake.shp > lake.kml > > The problem is I only get the attributes Name and Descriptio (after > trunk) in the output Shapefile. > > Attributes ScaleRank, Name12 and Name2 are missing. > > Do you have any explanation ? > > > > Please note,? I have installed the LIBKML driver In GDAL/OGR (thanks > to Frank for its help) : > > > > D:\Data\ >ogr2ogr --formats > > Supported Formats: > > ? -> "ESRI Shapefile" (read/write) > > ? -> "MapInfo File" (read/write) > > ? -> "UK .NTF" (readonly) > > ? -> "SDTS" (readonly) > > ? -> "TIGER" (read/write) > > ? -> "S57" (read/write) > > ? -> "DGN" (read/write) > > ? -> "VRT" (readonly) > > ? -> "REC" (readonly) > > ? -> "Memory" (read/write) > > ? -> "BNA" (read/write) > > ? -> "CSV" (read/write) > > ? -> "GML" (read/write) > > ? -> "GPX" (read/write) > > ? -> "LIBKML" (read/write) > > ? -> "KML" (read/write) > > ? -> "GeoJSON" (read/write) > > ? -> "GMT" (read/write) > > ? -> "ODBC" (read/write) > > ? -> "PGeo" (readonly) > > ? -> "MSSQLSpatial" (read/write) > > ? -> "PCIDSK" (read/write) > > ? -> "XPlane" (readonly) > > ? -> "AVCBin" (readonly) > > ? -> "AVCE00" (readonly) > > ? -> "DXF" (read/write) > > ? -> "Geoconcept" (read/write) > > ? -> "GeoRSS" (read/write) > > ? -> "GPSTrackMaker" (read/write) > > ? -> "VFK" (readonly) > > ? -> "PGDump" (read/write) > > ? -> "GPSBabel" (read/write) > > ? -> "SUA" (readonly) > > ? -> "OpenAir" (readonly) > > ? -> "PDS" (readonly) > > ? -> "HTF" (readonly) > > ? -> "AeronavFAA" (readonly) > > > > Thanks in advance for your help. > > > > S?bastien > > > > Ce courrier ?lectronique et toutes les pi?ces ?ventuellement jointes > qu?il contient sont CONFIDENTIELS et destin?s exclusivement ? l?usage > de leur destinataire. Si une erreur de transmission ou une adresse > erron?e a mal dirig?e ce courrier, merci d?en informer l?exp?diteur en > lui faisant une r?ponse par courrier ?lectronique d?s r?ception. Si > vous n??tes pas le destinataire de ce courrier, vous ne devez pas > l?utiliser, le conserver, en faire ?tat, le distribuer, le copier, > l?imprimer ou en r?v?ler le contenu ? une tierce partie. > Ce courrier ?lectronique est ? usage strictement informatif et ne > saurait engager de quelque mani?re que ce soit SPOT IMAGE SA, ni ses filiales. > > This e-mail and any attachments hereto are CONFIDENTIAL and intended > solely for the use of the addressee. If you have received this e-mail > in error please send it back to the person that sent it to you. > If you have received it in error, please notify the sender by return email. > If you are not the addressee of this email, you must not use, keep, > disseminate, copy, print or otherwise deal with it. > This email is for information only and will not bind SPOT IMAGE SA in > any contract or obligation, nor its subsidiaries. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > Ce courrier ?lectronique et toutes les pi?ces ?ventuellement jointes qu?il contient sont CONFIDENTIELS et destin?s exclusivement ? l?usage de leur destinataire. Si une erreur de transmission ou une adresse erron?e a mal dirig?e ce courrier, merci d?en informer l?exp?diteur en lui faisant une r?ponse par courrier ?lectronique d?s r?ception. Si vous n??tes pas le destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en faire ?tat, le distribuer, le copier, l?imprimer ou en r?v?ler le contenu ? une tierce partie. Ce courrier ?lectronique est ? usage strictement informatif et ne saurait engager de quelque mani?re que ce soit SPOT IMAGE SA, ni ses filiales. This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. From jorge.arevalo at deimos-space.com Mon Mar 21 12:16:28 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Mon Mar 21 12:16:52 2011 Subject: [gdal-dev] download.osgeo.org down? In-Reply-To: <4D877368.3090206@pobox.com> References: <20110318115009.GC21754@rigacci.org> <4D835834.7@pobox.com> <4D877368.3090206@pobox.com> Message-ID: 2011/3/21 Frank Warmerdam : >> Hi, >> >> Still unavailable from my network, in Spain. Same problem with >> trac.osgeo.org since today. And >> >> http://www.downforeveryoneorjustme.com/trac.osgeo.org >> >> Says trac is down... >> >> Should we report this to http://lists.osgeo.org/mailman/listinfo/sac ? > > Jorge, > > The Trac/SVN VM was down for circa 30 minutes this morning, but should be > working fine again now. This problem was unrelated to the download.osgeo.org > issue. > > For GDAL or other OSGeo systems problems I would encourage the following > sequence: > > 1) Mention it in the #osgeo channel on IRC if you notice a problem. > 2) wait 10-15 minutes for a response or for a transient problem to go away. > 3) Submit a trac ticket at http://trac.osgeo.org/osgeo (with component > set to "Systems Admin") and details on the issue. ?Email about the ticket > will be sent to the sac mailing list. > > Obviously problems with trac can't be reported via trac in which case > email to the sac@lists.osgeo.org mailing list would be good. ?Note that > you need to be subscribed to the list to post to it. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up ? | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush ? ?| Geospatial Programmer for Rent > > Hi Frank, Ok, trac working for me. Thanks for the instructions! Best regards, -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From rush at winkey.org Mon Mar 21 13:40:35 2011 From: rush at winkey.org (brian) Date: Mon Mar 21 13:40:36 2011 Subject: [gdal-dev] KML conversion and attributes In-Reply-To: References: Message-ID: <1300729235.28726.17.camel@winkey.org> Sbastien try removeing the and from the kml if you want seperate schemas for different layers you need seperate documents not seperate folders Brian rush@octopi ~ $ ogrinfo -al testy.kml INFO: Open of `testy.kml' using driver `LIBKML' successful. Layer name: testy Geometry: Unknown (any) Feature Count: 1 Extent: (103.620011, 51.460012) - (109.929807, 55.730914) Layer SRS WKT: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] Name: String (0.0) description: String (0.0) timestamp: DateTime (0.0) begin: DateTime (0.0) end: DateTime (0.0) altitudeMode: String (0.0) tessellate: Integer (0.0) extrude: Integer (0.0) visibility: Integer (0.0) Name: String (0.0) Description: String (0.0) ScaleRank: Integer (0.0) FeatureCla: String (0.0) Name1: String (0.0) Name2: String (0.0) OGRFeature(testy):1 Name (String) = 0 description (String) = Lake timestamp (DateTime) = (null) begin (DateTime) = (null) end (DateTime) = (null) altitudeMode (String) = (null) tessellate (Integer) = -1 extrude (Integer) = -1 visibility (Integer) = -1 Name (String) = (null) Description (String) = (null) ScaleRank (Integer) = 0 FeatureCla (String) = (null) Name1 (String) = 0 Name2 (String) = POLYGON Style = POLYGON ((106.579985793079118 52.799981594445541,106.539988234485207 52.939998887740373,107.080006951935303 53.180010077519981,107.299993524201795 53.379997870489532,107.599975213656109 53.519989325568218,108.039948358189122 53.859968573616456,108.37997928266966 6 54.259995835987837,109.052703078245258 55.027597561251326,109.193469679808317 55.535602728896592,109.506990594523131 55.730913804743722,109.92980716353523 55.712956244522303,109.700002069133262 54.980003567110515,109.660004510539352 54.719993598033952,109.479963 820434477 54.339990953175658,109.319973586058836 53.819996853238692,109.220031366006367 53.619983222052994,108.999993117307554 53.780025132860928,108.600017531368451 53.439994208380398,108.800005324338002 53.379997870489532,108.760007765744092 53.200008856816936,1 08.459974399857487 53.140012518926071,108.179991489700114 52.799981594445541,107.79996300662566 52.579995022179034,107.319992303498765 52.420004787803393,106.64003380740229 52.320010891318617,106.100015089952194 52.039976304728967,105.740037062607001 51.7599933945 71595,105.240015903750844 51.520008043008133,104.819989862082508 51.460011705117267,104.300021600361674 51.500009263711178,103.760002882911607 51.600003160195953,103.620011427832907 51.73999461527464,103.859996779396369 51.85998729105637,104.399963820414143 51.859 98729105637,105.05997521364597 52.000004584351203,105.480001255314306 52.280013332724707,105.980022414170463 52.519998684288169,106.260005324327835 52.619992580772944,106.579985793079118 52.799981594445541)) On Mon, 2011-03-21 at 10:29 +0000, Favre, Sebastien wrote: > Hello to all, > > > > I try to convert the following KML file into Shapefile format. > > > > > > > > 110m_lakes > > > > > > type="string"> > > type="int"> > > type="string"> > > > > > > > > > > 0 > > Lake > > > > > > 0 > > name="Description">Lake > > Lake > Baikal > > 0 > > name="Name2">POLYGON > > > > > 106.57998579307912,52.799981594445541 106.53998823448521,52.939998887740373 107.0800069519353,53.180010077519981 107.2999935242018,53.379997870489532 107.59997521365611,53.519989325568218 108.03994835818912,53.859968573616456 108.37997928266967,54.259995835987837 109.05270307824526,55.027597561251326 109.19346967980832,55.535602728896592 109.50699059452313,55.730913804743722 109.92980716353523,55.712956244522303 109.70000206913326,54.980003567110515 109.66000451053935,54.719993598033952 109.47996382043448,54.339990953175658 109.31997358605884,53.819996853238692 109.22003136600637,53.619983222052994 108.99999311730755,53.780025132860928 108.60001753136845,53.439994208380398 108.800005324338,53.379997870489532 108.76000776574409,53.200008856816936 108.45997439985749,53.140012518926071 108.17999148970011,52.799981594445541 107.79996300662566,52.579995022179034 107.31999230349876,52.420004787803393 106.64003380740229,52.320010891318617 106.10001508995219,52.039976304728967 105.740037062607,51.759993394571595 105.24001590375084,51.520008043008133 104.81998986208251,51.460011705117267 104.30002160036167,51.500009263711178 103.76000288291161,51.600003160195953 103.62001142783291,51.73999461527464 103.85999677939637,51.85998729105637 104.39996382041414,51.85998729105637 105.05997521364597,52.000004584351203 105.48000125531431,52.280013332724707 105.98002241417046,52.519998684288169 106.26000532432784,52.619992580772944 106.57998579307912,52.799981594445541 > > > > > > > > I use the command line for that : ogr2ogr -f "ESRI Shapefile" lake.shp > lake.kml > > The problem is I only get the attributes Name and Descriptio (after > trunk) in the output Shapefile. > > Attributes ScaleRank, Name12 and Name2 are missing. > > Do you have any explanation ? > > > > Please note, I have installed the LIBKML driver In GDAL/OGR (thanks > to Frank for its help) : > > > > D:\Data\ >ogr2ogr --formats > > Supported Formats: > > -> "ESRI Shapefile" (read/write) > > -> "MapInfo File" (read/write) > > -> "UK .NTF" (readonly) > > -> "SDTS" (readonly) > > -> "TIGER" (read/write) > > -> "S57" (read/write) > > -> "DGN" (read/write) > > -> "VRT" (readonly) > > -> "REC" (readonly) > > -> "Memory" (read/write) > > -> "BNA" (read/write) > > -> "CSV" (read/write) > > -> "GML" (read/write) > > -> "GPX" (read/write) > > -> "LIBKML" (read/write) > > -> "KML" (read/write) > > -> "GeoJSON" (read/write) > > -> "GMT" (read/write) > > -> "ODBC" (read/write) > > -> "PGeo" (readonly) > > -> "MSSQLSpatial" (read/write) > > -> "PCIDSK" (read/write) > > -> "XPlane" (readonly) > > -> "AVCBin" (readonly) > > -> "AVCE00" (readonly) > > -> "DXF" (read/write) > > -> "Geoconcept" (read/write) > > -> "GeoRSS" (read/write) > > -> "GPSTrackMaker" (read/write) > > -> "VFK" (readonly) > > -> "PGDump" (read/write) > > -> "GPSBabel" (read/write) > > -> "SUA" (readonly) > > -> "OpenAir" (readonly) > > -> "PDS" (readonly) > > -> "HTF" (readonly) > > -> "AeronavFAA" (readonly) > > > > Thanks in advance for your help. > > > > Sbastien > > > > > Ce courrier lectronique et toutes les pices ventuellement jointes qu?il contient sont CONFIDENTIELS et destins exclusivement l?usage de leur destinataire. Si une erreur de transmission ou une adresse errone a mal dirige ce courrier, merci d?en informer l?expditeur en lui faisant une rponse par courrier lectronique ds rception. Si vous n?tes pas le destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en faire tat, le distribuer, le copier, l?imprimer ou en rvler le contenu une tierce partie. > Ce courrier lectronique est usage strictement informatif et ne saurait engager de quelque manire que ce soit SPOT IMAGE SA, ni ses filiales. > > This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. > If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. > This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From rush at winkey.org Mon Mar 21 13:52:53 2011 From: rush at winkey.org (brian) Date: Mon Mar 21 13:52:54 2011 Subject: [gdal-dev] KML conversion and attributes Message-ID: <1300729973.28726.28.camel@winkey.org> Can someone forward my reply to Sbastien seems spotimage bounces my mails Thanks Brian From natashachatterjee at rediffmail.com Mon Mar 21 15:16:28 2011 From: natashachatterjee at rediffmail.com (natasha chatterjee) Date: Mon Mar 21 15:24:10 2011 Subject: [gdal-dev] how to build java with GDAL Message-ID: <20110321191628.16843.qmail@f4mail-235-243.rediffmail.com> Hi All Can anyone guide me in building java with gdal.what are the requirements.do i necessarily need Osgeo4W or without it also one can proceed.(I have gone through the link http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions) but still i need to know the process as i later want to connect the build with Oracle spatial. Does the code of ogr2ogr.java from http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ helps in converting oracle spatial to shapefile? Please help me out. Regards Natasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110321/82b47139/attachment.html From pcorti at gmail.com Mon Mar 21 15:38:49 2011 From: pcorti at gmail.com (Paolo Corti) Date: Mon Mar 21 15:39:32 2011 Subject: [gdal-dev] how to build java with GDAL In-Reply-To: <20110321191628.16843.qmail@f4mail-235-243.rediffmail.com> References: <20110321191628.16843.qmail@f4mail-235-243.rediffmail.com> Message-ID: Hi Natasha > http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions) > but still i need to know the process as i later want to connect > the build with Oracle spatial. > that instructions worked very well for me some weeks ago when building GDAL 1.7 (but also GDAL 1.8) Java 1.6 bindings (on Debian and RHEL). > Does the code of ogr2ogr.java from > http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ > helps in converting oracle spatial to shapefile? > > that is a sample provided with the other ones, intended to prove as a sample on how to write with GDAL Java bindings API the same widespread tool ogr2ogr (written in C), commonly used in the context of GDAL command line tools for vectorial migration tasks [0]. This is the primary tool in the FOSS4G panorama for making conversion between vectorial formats. You will be able to import/export from oracle spatial and shapefile with it (and a plethora of other formats), but you will need to compile GDAL with OCI support [1]. You may use that Java version, but it would be more indicated (and updated) the original ogr2ogr version best regards Paolo [0] http://www.gdal.org/ogr2ogr.html [1] http://forums.oracle.com/forums/thread.jspa?messageID=4570333 -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @paolo_corti -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110321/3c58f0e3/attachment.html From jgr007 at gmail.com Mon Mar 21 15:42:37 2011 From: jgr007 at gmail.com (Jeff Ruby) Date: Mon Mar 21 15:44:56 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? In-Reply-To: <201103182111.20865.even.rouault@mines-paris.org> References: <201103182111.20865.even.rouault@mines-paris.org> Message-ID: Hmmm...it doesn't seem to work for me. I get the following error: 0ERROR 1: GDALWMS: Unable to download block 0, 0. URL: file:///c:/temp/7/0/0 HTTP status code: 0, error: Couldn't open file /c:/temp/7/0/0. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 All my tiles are in c:\temp. Below is my xml file: file:///c:/temp/${z}/${x}/${y} EPSG:32618 224270.0 3731360.0 226811.0 3728689.0 25088 26624 49 52 7 EPSG:32618 25088 26624 3 On Fri, Mar 18, 2011 at 4:11 PM, Even Rouault wrote: > Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a ?crit : >> Hi, >> >> I've built a TMS structure using gdal2tiles. ?I'd like to access the >> files directly not via a webserver. >> >> It appears the WMS TMS minidriver may be an option and I'd like to >> know if supports reference to a local drive\path. > > Yes, use file://a_directory_name > >> >> Thanks much, >> -Jeff >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From even.rouault at mines-paris.org Mon Mar 21 15:48:07 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 21 15:48:18 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? In-Reply-To: References: <201103182111.20865.even.rouault@mines-paris.org> Message-ID: <201103212048.07678.even.rouault@mines-paris.org> Le lundi 21 mars 2011 20:42:37, Jeff Ruby a ?crit : > Hmmm...it doesn't seem to work for me. I get the following error: > > 0ERROR 1: GDALWMS: Unable to download block 0, 0. > URL: file:///c:/temp/7/0/0 > HTTP status code: 0, error: Couldn't open file /c:/temp/7/0/0. --> The error message shows that it tries to open "/c:/temp/7/0/0", note the leading slash. The reason is your URL below where you have the 2 slashes of file:// plus one additional slash. Try removing it. > ERROR 1: IReadBlock failed at X offset 0, Y offset 0 > ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 > > > All my tiles are in c:\temp. Below is my xml file: > > > > file:///c:/temp/${z}/${x}/${y} > EPSG:32618 > > > 224270.0 > 3731360.0 > 226811.0 > 3728689.0 > 25088 > 26624 > 49 > 52 > 7 > > EPSG:32618 > 25088 > 26624 > 3 > > > > On Fri, Mar 18, 2011 at 4:11 PM, Even Rouault > > wrote: > > Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a ?crit : > >> Hi, > >> > >> I've built a TMS structure using gdal2tiles. I'd like to access the > >> files directly not via a webserver. > >> > >> It appears the WMS TMS minidriver may be an option and I'd like to > >> know if supports reference to a local drive\path. > > > > Yes, use file://a_directory_name > > > >> Thanks much, > >> -Jeff > >> _______________________________________________ > >> gdal-dev mailing list > >> gdal-dev@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From jgr007 at gmail.com Mon Mar 21 16:03:50 2011 From: jgr007 at gmail.com (Jeff Ruby) Date: Mon Mar 21 16:09:31 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? In-Reply-To: <201103212048.07678.even.rouault@mines-paris.org> References: <201103182111.20865.even.rouault@mines-paris.org> <201103212048.07678.even.rouault@mines-paris.org> Message-ID: I get the same result if I use file://c:/temp/7/0/0 I've also every permutation I can think of, but none seemed to work. BTW, I'm trying run gdal_translate: gdal_translate my.xml my.tif I don't think I mentioned that previously. Thanks much for your responses, Even. On Mon, Mar 21, 2011 at 3:48 PM, Even Rouault wrote: > Le lundi 21 mars 2011 20:42:37, Jeff Ruby a ?crit : >> Hmmm...it doesn't seem to work for me. ?I get the following error: >> >> 0ERROR 1: GDALWMS: Unable to download block 0, 0. >> ? URL: file:///c:/temp/7/0/0 >> ? HTTP status code: 0, error: Couldn't open file /c:/temp/7/0/0. > > --> The error message shows that it tries to open "/c:/temp/7/0/0", note the > leading slash. The reason is your URL below where you have the 2 slashes of > file:// plus one additional slash. Try removing it. > >> ERROR 1: IReadBlock failed at X offset 0, Y offset 0 >> ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 >> >> >> All my tiles are in c:\temp. ?Below is my xml file: >> >> >> ? >> ? ? file:///c:/temp/${z}/${x}/${y} >> ? ? EPSG:32618 >> ? >> ? >> ? ? 224270.0 >> ? ? 3731360.0 >> ? ? 226811.0 >> ? ? 3728689.0 >> ? ? 25088 >> ? ? 26624 >> ? ? 49 >> ? ? 52 >> ? ? 7 >> ? >> ? EPSG:32618 >> ? 25088 >> ? 26624 >> ? 3 >> ? >> >> >> On Fri, Mar 18, 2011 at 4:11 PM, Even Rouault >> >> wrote: >> > Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a ?crit : >> >> Hi, >> >> >> >> I've built a TMS structure using gdal2tiles. ?I'd like to access the >> >> files directly not via a webserver. >> >> >> >> It appears the WMS TMS minidriver may be an option and I'd like to >> >> know if supports reference to a local drive\path. >> > >> > Yes, use file://a_directory_name >> > >> >> Thanks much, >> >> -Jeff >> >> _______________________________________________ >> >> gdal-dev mailing list >> >> gdal-dev@lists.osgeo.org >> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From even.rouault at mines-paris.org Mon Mar 21 16:46:08 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 21 16:46:19 2011 Subject: [gdal-dev] Does WMS TMS minidriver support a local path for ? In-Reply-To: References: <201103212048.07678.even.rouault@mines-paris.org> Message-ID: <201103212146.08952.even.rouault@mines-paris.org> Le lundi 21 mars 2011 21:03:50, Jeff Ruby a ?crit : Well, I see I answered a bit too fast in my first answer. I blindly assumed that Curl would behave exactly the same way with file:// or http:// URL, but actually it doesn't. I have push a change in trunk, in http://trac.osgeo.org/gdal/changeset/22007 , to make file:// URL work. Tested lightly. > I get the same result if I use file://c:/temp/7/0/0 > > I've also every permutation I can think of, but none seemed to work. > BTW, I'm trying run gdal_translate: > > gdal_translate my.xml my.tif > > I don't think I mentioned that previously. > > Thanks much for your responses, Even. > > On Mon, Mar 21, 2011 at 3:48 PM, Even Rouault > > wrote: > > Le lundi 21 mars 2011 20:42:37, Jeff Ruby a ?crit : > >> Hmmm...it doesn't seem to work for me. I get the following error: > >> > >> 0ERROR 1: GDALWMS: Unable to download block 0, 0. > >> URL: file:///c:/temp/7/0/0 > >> HTTP status code: 0, error: Couldn't open file /c:/temp/7/0/0. > > > > --> The error message shows that it tries to open "/c:/temp/7/0/0", note > > the leading slash. The reason is your URL below where you have the 2 > > slashes of file:// plus one additional slash. Try removing it. > > > >> ERROR 1: IReadBlock failed at X offset 0, Y offset 0 > >> ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 > >> > >> > >> All my tiles are in c:\temp. Below is my xml file: > >> > >> > >> > >> file:///c:/temp/${z}/${x}/${y} > >> EPSG:32618 > >> > >> > >> 224270.0 > >> 3731360.0 > >> 226811.0 > >> 3728689.0 > >> 25088 > >> 26624 > >> 49 > >> 52 > >> 7 > >> > >> EPSG:32618 > >> 25088 > >> 26624 > >> 3 > >> > >> > >> > >> On Fri, Mar 18, 2011 at 4:11 PM, Even Rouault > >> > >> wrote: > >> > Le vendredi 18 mars 2011 21:00:12, Jeff Ruby a ?crit : > >> >> Hi, > >> >> > >> >> I've built a TMS structure using gdal2tiles. I'd like to access the > >> >> files directly not via a webserver. > >> >> > >> >> It appears the WMS TMS minidriver may be an option and I'd like to > >> >> know if supports reference to a local drive\path. > >> > > >> > Yes, use file://a_directory_name > >> > > >> >> Thanks much, > >> >> -Jeff > >> >> _______________________________________________ > >> >> gdal-dev mailing list > >> >> gdal-dev@lists.osgeo.org > >> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From Sebastien.Favre at spotimage.fr Tue Mar 22 04:40:26 2011 From: Sebastien.Favre at spotimage.fr (Favre, Sebastien) Date: Tue Mar 22 04:40:32 2011 Subject: [gdal-dev] KML conversion and attributes In-Reply-To: <1300729235.28726.17.camel@winkey.org> References: <1300729235.28726.17.camel@winkey.org> Message-ID: Hello Brian, Thank you for your response. I have correctly received your first email ! I have tried to remove and without success : the output Shapefile does not contain ScaleRank, FeatureCla, Name1 and Name2 attributes. Did you manage to generate a Shapefile with the extra attributes ? S?bastien -----Message d'origine----- De?: gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] De la part de brian Envoy??: lundi 21 mars 2011 18:41 ??: Favre, Sebastien Cc?: gdal-dev@lists.osgeo.org Objet?: Re: [gdal-dev] KML conversion and attributes Sbastien try removeing the and from the kml if you want seperate schemas for different layers you need seperate documents not seperate folders Brian rush@octopi ~ $ ogrinfo -al testy.kml INFO: Open of `testy.kml' using driver `LIBKML' successful. Layer name: testy Geometry: Unknown (any) Feature Count: 1 Extent: (103.620011, 51.460012) - (109.929807, 55.730914) Layer SRS WKT: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] Name: String (0.0) description: String (0.0) timestamp: DateTime (0.0) begin: DateTime (0.0) end: DateTime (0.0) altitudeMode: String (0.0) tessellate: Integer (0.0) extrude: Integer (0.0) visibility: Integer (0.0) Name: String (0.0) Description: String (0.0) ScaleRank: Integer (0.0) FeatureCla: String (0.0) Name1: String (0.0) Name2: String (0.0) OGRFeature(testy):1 Name (String) = 0 description (String) = Lake timestamp (DateTime) = (null) begin (DateTime) = (null) end (DateTime) = (null) altitudeMode (String) = (null) tessellate (Integer) = -1 extrude (Integer) = -1 visibility (Integer) = -1 Name (String) = (null) Description (String) = (null) ScaleRank (Integer) = 0 FeatureCla (String) = (null) Name1 (String) = 0 Name2 (String) = POLYGON Style = POLYGON ((106.579985793079118 52.799981594445541,106.539988234485207 52.939998887740373,107.080006951935303 53.180010077519981,107.299993524201795 53.379997870489532,107.599975213656109 53.519989325568218,108.039948358189122 53.859968573616456,108.37997928266966 6 54.259995835987837,109.052703078245258 55.027597561251326,109.193469679808317 55.535602728896592,109.506990594523131 55.730913804743722,109.92980716353523 55.712956244522303,109.700002069133262 54.980003567110515,109.660004510539352 54.719993598033952,109.479963 820434477 54.339990953175658,109.319973586058836 53.819996853238692,109.220031366006367 53.619983222052994,108.999993117307554 53.780025132860928,108.600017531368451 53.439994208380398,108.800005324338002 53.379997870489532,108.760007765744092 53.200008856816936,1 08.459974399857487 53.140012518926071,108.179991489700114 52.799981594445541,107.79996300662566 52.579995022179034,107.319992303498765 52.420004787803393,106.64003380740229 52.320010891318617,106.100015089952194 52.039976304728967,105.740037062607001 51.7599933945 71595,105.240015903750844 51.520008043008133,104.819989862082508 51.460011705117267,104.300021600361674 51.500009263711178,103.760002882911607 51.600003160195953,103.620011427832907 51.73999461527464,103.859996779396369 51.85998729105637,104.399963820414143 51.859 98729105637,105.05997521364597 52.000004584351203,105.480001255314306 52.280013332724707,105.980022414170463 52.519998684288169,106.260005324327835 52.619992580772944,106.579985793079118 52.799981594445541)) On Mon, 2011-03-21 at 10:29 +0000, Favre, Sebastien wrote: > Hello to all, > > > > I try to convert the following KML file into Shapefile format. > > > > > > > > 110m_lakes > > > > > > type="string"> > > type="int"> > > type="string"> > > > > > > > > > > 0 > > Lake > > > > > > 0 > > name="Description">Lake > > Lake > Baikal > > 0 > > name="Name2">POLYGON > > > > > 106.57998579307912,52.799981594445541 106.53998823448521,52.939998887740373 107.0800069519353,53.180010077519981 107.2999935242018,53.379997870489532 107.59997521365611,53.519989325568218 108.03994835818912,53.859968573616456 108.37997928266967,54.259995835987837 109.05270307824526,55.027597561251326 109.19346967980832,55.535602728896592 109.50699059452313,55.730913804743722 109.92980716353523,55.712956244522303 109.70000206913326,54.980003567110515 109.66000451053935,54.719993598033952 109.47996382043448,54.339990953175658 109.31997358605884,53.819996853238692 109.22003136600637,53.619983222052994 108.99999311730755,53.780025132860928 108.60001753136845,53.439994208380398 108.800005324338,53.379997870489532 108.76000776574409,53.200008856816936 108.45997439985749,53.140012518926071 108.17999148970011,52.799981594445541 107.79996300662566,52.579995022179034 107.31999230349876,52.420004787803393 106.64003380740229,52.320010891318617 106.10001508995219,52.039976304728967 105.740037062607,51.759993394571595 105.24001590375084,51.520008043008133 104.81998986208251,51.460011705117267 104.30002160036167,51.500009263711178 103.76000288291161,51.600003160195953 103.62001142783291,51.73999461527464 103.85999677939637,51.85998729105637 104.39996382041414,51.85998729105637 105.05997521364597,52.000004584351203 105.48000125531431,52.280013332724707 105.98002241417046,52.519998684288169 106.26000532432784,52.619992580772944 106.57998579307912,52.799981594445541 > > > > > > > > I use the command line for that : ogr2ogr -f "ESRI Shapefile" lake.shp > lake.kml > > The problem is I only get the attributes Name and Descriptio (after > trunk) in the output Shapefile. > > Attributes ScaleRank, Name12 and Name2 are missing. > > Do you have any explanation ? > > > > Please note, I have installed the LIBKML driver In GDAL/OGR (thanks > to Frank for its help) : > > > > D:\Data\ >ogr2ogr --formats > > Supported Formats: > > -> "ESRI Shapefile" (read/write) > > -> "MapInfo File" (read/write) > > -> "UK .NTF" (readonly) > > -> "SDTS" (readonly) > > -> "TIGER" (read/write) > > -> "S57" (read/write) > > -> "DGN" (read/write) > > -> "VRT" (readonly) > > -> "REC" (readonly) > > -> "Memory" (read/write) > > -> "BNA" (read/write) > > -> "CSV" (read/write) > > -> "GML" (read/write) > > -> "GPX" (read/write) > > -> "LIBKML" (read/write) > > -> "KML" (read/write) > > -> "GeoJSON" (read/write) > > -> "GMT" (read/write) > > -> "ODBC" (read/write) > > -> "PGeo" (readonly) > > -> "MSSQLSpatial" (read/write) > > -> "PCIDSK" (read/write) > > -> "XPlane" (readonly) > > -> "AVCBin" (readonly) > > -> "AVCE00" (readonly) > > -> "DXF" (read/write) > > -> "Geoconcept" (read/write) > > -> "GeoRSS" (read/write) > > -> "GPSTrackMaker" (read/write) > > -> "VFK" (readonly) > > -> "PGDump" (read/write) > > -> "GPSBabel" (read/write) > > -> "SUA" (readonly) > > -> "OpenAir" (readonly) > > -> "PDS" (readonly) > > -> "HTF" (readonly) > > -> "AeronavFAA" (readonly) > > > > Thanks in advance for your help. > > > > Sbastien > > > > > Ce courrier lectronique et toutes les pices ventuellement jointes qu'il contient sont CONFIDENTIELS et destins exclusivement l'usage de leur destinataire. Si une erreur de transmission ou une adresse errone a mal dirige ce courrier, merci d'en informer l'expditeur en lui faisant une rponse par courrier lectronique ds rception. Si vous n'tes pas le destinataire de ce courrier, vous ne devez pas l'utiliser, le conserver, en faire tat, le distribuer, le copier, l'imprimer ou en rvler le contenu une tierce partie. > Ce courrier lectronique est usage strictement informatif et ne saurait engager de quelque manire que ce soit SPOT IMAGE SA, ni ses filiales. > > This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. > If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. > This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. > _______________________________________________ > 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 -------------- next part -------------- Ce courrier ?lectronique et toutes les pi?ces ?ventuellement jointes qu?il contient sont CONFIDENTIELS et destin?s exclusivement ? l?usage de leur destinataire. Si une erreur de transmission ou une adresse erron?e a mal dirig?e ce courrier, merci d?en informer l?exp?diteur en lui faisant une r?ponse par courrier ?lectronique d?s r?ception. Si vous n??tes pas le destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en faire ?tat, le distribuer, le copier, l?imprimer ou en r?v?ler le contenu ? une tierce partie. Ce courrier ?lectronique est ? usage strictement informatif et ne saurait engager de quelque mani?re que ce soit SPOT IMAGE SA, ni ses filiales. This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. From ahh34 at cam.ac.uk Tue Mar 22 08:09:16 2011 From: ahh34 at cam.ac.uk (Alex Hagen-Zanker) Date: Tue Mar 22 08:28:11 2011 Subject: [gdal-dev] Does gdal support rotated pole projections? Message-ID: <4D88916C.2020107@cam.ac.uk> Dear All, Some climate projection data uses a rotated pole projection for gridded data. Is there any way in which I can get GDAL to work with this data? In particular I would like to burn vector data from other projections into this grid using gdal_rasterize. Using Google I find posts of similar problems in several forums. It appears that proj.4 uses "proj=ob_tran, etc" but GDAL does not support this? Thanks, Alex Projection description: http://ukclimateprojections-ui.defra.gov.uk/ui/docs/grids/prob_land_25km_rotated/index.php Earlier discussion: http://osdir.com/ml/gis.gdal.devel/2005-06/msg00054.html From rush at winkey.org Tue Mar 22 12:43:31 2011 From: rush at winkey.org (brian) Date: Tue Mar 22 12:43:33 2011 Subject: [gdal-dev] KML conversion and attributes In-Reply-To: References: <1300729235.28726.17.camel@winkey.org> Message-ID: <1300812211.1728.18.camel@winkey.org> Sbastien, Yes i was able to create the shape file. I see the libkml in your --formats output So that appears to be good Perhaps you could paste back the output of ogrinfo -al testy.kml? Brian On Tue, 2011-03-22 at 08:40 +0000, Favre, Sebastien wrote: > Hello Brian, > > Thank you for your response. I have correctly received your first email ! > I have tried to remove and without success : the output Shapefile does not contain ScaleRank, FeatureCla, Name1 and Name2 attributes. > Did you manage to generate a Shapefile with the extra attributes ? > > Sbastien > > -----Message d'origine----- > De : gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] De la part de brian > Envoy : lundi 21 mars 2011 18:41 > : Favre, Sebastien > Cc : gdal-dev@lists.osgeo.org > Objet : Re: [gdal-dev] KML conversion and attributes > > Sbastien > > > try removeing the and from the kml > > if you want seperate schemas for different layers you need seperate documents not seperate folders > > > > Brian > > > rush@octopi ~ $ ogrinfo -al testy.kml > INFO: Open of `testy.kml' > using driver `LIBKML' successful. > > Layer name: testy > Geometry: Unknown (any) > Feature Count: 1 > Extent: (103.620011, 51.460012) - (109.929807, 55.730914) Layer SRS WKT: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > TOWGS84[0,0,0,0,0,0,0], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9108"]], > AUTHORITY["EPSG","4326"]] > Name: String (0.0) > description: String (0.0) > timestamp: DateTime (0.0) > begin: DateTime (0.0) > end: DateTime (0.0) > altitudeMode: String (0.0) > tessellate: Integer (0.0) > extrude: Integer (0.0) > visibility: Integer (0.0) > Name: String (0.0) > Description: String (0.0) > ScaleRank: Integer (0.0) > FeatureCla: String (0.0) > Name1: String (0.0) > Name2: String (0.0) > OGRFeature(testy):1 > Name (String) = 0 > description (String) = Lake > timestamp (DateTime) = (null) > begin (DateTime) = (null) > end (DateTime) = (null) > altitudeMode (String) = (null) > tessellate (Integer) = -1 > extrude (Integer) = -1 > visibility (Integer) = -1 > Name (String) = (null) > Description (String) = (null) > ScaleRank (Integer) = 0 > FeatureCla (String) = (null) > Name1 (String) = 0 > Name2 (String) = POLYGON > Style = > POLYGON ((106.579985793079118 52.799981594445541,106.539988234485207 > 52.939998887740373,107.080006951935303 > 53.180010077519981,107.299993524201795 > 53.379997870489532,107.599975213656109 > 53.519989325568218,108.039948358189122 > 53.859968573616456,108.37997928266966 > 6 54.259995835987837,109.052703078245258 > 55.027597561251326,109.193469679808317 > 55.535602728896592,109.506990594523131 > 55.730913804743722,109.92980716353523 > 55.712956244522303,109.700002069133262 > 54.980003567110515,109.660004510539352 54.719993598033952,109.479963 > 820434477 54.339990953175658,109.319973586058836 > 53.819996853238692,109.220031366006367 > 53.619983222052994,108.999993117307554 > 53.780025132860928,108.600017531368451 > 53.439994208380398,108.800005324338002 > 53.379997870489532,108.760007765744092 53.200008856816936,1 > 08.459974399857487 53.140012518926071,108.179991489700114 > 52.799981594445541,107.79996300662566 > 52.579995022179034,107.319992303498765 > 52.420004787803393,106.64003380740229 > 52.320010891318617,106.100015089952194 > 52.039976304728967,105.740037062607001 51.7599933945 > 71595,105.240015903750844 51.520008043008133,104.819989862082508 > 51.460011705117267,104.300021600361674 > 51.500009263711178,103.760002882911607 > 51.600003160195953,103.620011427832907 > 51.73999461527464,103.859996779396369 > 51.85998729105637,104.399963820414143 51.859 > 98729105637,105.05997521364597 52.000004584351203,105.480001255314306 > 52.280013332724707,105.980022414170463 > 52.519998684288169,106.260005324327835 > 52.619992580772944,106.579985793079118 52.799981594445541)) > > > On Mon, 2011-03-21 at 10:29 +0000, Favre, Sebastien wrote: > > Hello to all, > > > > > > > > I try to convert the following KML file into Shapefile format. > > > > > > > > > > > > > > > > 110m_lakes > > > > > > > > > > > > > type="string"> > > > > > type="int"> > > > > > type="string"> > > > > > > > > > > > > > > > > > > > > 0 > > > > Lake > > > > > > > > > > > > 0 > > > > > name="Description">Lake > > > > Lake > > Baikal > > > > 0 > > > > > name="Name2">POLYGON > > > > > > > > > > 106.57998579307912,52.799981594445541 106.53998823448521,52.939998887740373 107.0800069519353,53.180010077519981 107.2999935242018,53.379997870489532 107.59997521365611,53.519989325568218 108.03994835818912,53.859968573616456 108.37997928266967,54.259995835987837 109.05270307824526,55.027597561251326 109.19346967980832,55.535602728896592 109.50699059452313,55.730913804743722 109.92980716353523,55.712956244522303 109.70000206913326,54.980003567110515 109.66000451053935,54.719993598033952 109.47996382043448,54.339990953175658 109.31997358605884,53.819996853238692 109.22003136600637,53.619983222052994 108.99999311730755,53.780025132860928 108.60001753136845,53.439994208380398 108.800005324338,53.379997870489532 108.76000776574409,53.200008856816936 108.45997439985749,53.140012518926071 108.17999148970011,52.799981594445541 107.79996300662566,52.579995022179034 107.31999230349876,52.420004787803393 106.64003380740229,52.320010891318617 106.10001508995219,52.039976304728967 105.740037062607,51.759993394571595 105.24001590375084,51.520008043008133 104.81998986208251,51.460011705117267 104.30002160036167,51.500009263711178 103.76000288291161,51.600003160195953 103.62001142783291,51.73999461527464 103.85999677939637,51.85998729105637 104.39996382041414,51.85998729105637 105.05997521364597,52.000004584351203 105.48000125531431,52.280013332724707 105.98002241417046,52.519998684288169 106.26000532432784,52.619992580772944 106.57998579307912,52.799981594445541 > > > > > > > > > > > > > > > > I use the command line for that : ogr2ogr -f "ESRI Shapefile" lake.shp > > lake.kml > > > > The problem is I only get the attributes Name and Descriptio (after > > trunk) in the output Shapefile. > > > > Attributes ScaleRank, Name12 and Name2 are missing. > > > > Do you have any explanation ? > > > > > > > > Please note, I have installed the LIBKML driver In GDAL/OGR (thanks > > to Frank for its help) : > > > > > > > > D:\Data\ >ogr2ogr --formats > > > > Supported Formats: > > > > -> "ESRI Shapefile" (read/write) > > > > -> "MapInfo File" (read/write) > > > > -> "UK .NTF" (readonly) > > > > -> "SDTS" (readonly) > > > > -> "TIGER" (read/write) > > > > -> "S57" (read/write) > > > > -> "DGN" (read/write) > > > > -> "VRT" (readonly) > > > > -> "REC" (readonly) > > > > -> "Memory" (read/write) > > > > -> "BNA" (read/write) > > > > -> "CSV" (read/write) > > > > -> "GML" (read/write) > > > > -> "GPX" (read/write) > > > > -> "LIBKML" (read/write) > > > > -> "KML" (read/write) > > > > -> "GeoJSON" (read/write) > > > > -> "GMT" (read/write) > > > > -> "ODBC" (read/write) > > > > -> "PGeo" (readonly) > > > > -> "MSSQLSpatial" (read/write) > > > > -> "PCIDSK" (read/write) > > > > -> "XPlane" (readonly) > > > > -> "AVCBin" (readonly) > > > > -> "AVCE00" (readonly) > > > > -> "DXF" (read/write) > > > > -> "Geoconcept" (read/write) > > > > -> "GeoRSS" (read/write) > > > > -> "GPSTrackMaker" (read/write) > > > > -> "VFK" (readonly) > > > > -> "PGDump" (read/write) > > > > -> "GPSBabel" (read/write) > > > > -> "SUA" (readonly) > > > > -> "OpenAir" (readonly) > > > > -> "PDS" (readonly) > > > > -> "HTF" (readonly) > > > > -> "AeronavFAA" (readonly) > > > > > > > > Thanks in advance for your help. > > > > > > > > Sbastien > > > > > > > > > > Ce courrier lectronique et toutes les pices ventuellement jointes qu'il contient sont CONFIDENTIELS et destins exclusivement l'usage de leur destinataire. Si une erreur de transmission ou une adresse errone a mal dirige ce courrier, merci d'en informer l'expditeur en lui faisant une rponse par courrier lectronique ds rception. Si vous n'tes pas le destinataire de ce courrier, vous ne devez pas l'utiliser, le conserver, en faire tat, le distribuer, le copier, l'imprimer ou en rvler le contenu une tierce partie. > > Ce courrier lectronique est usage strictement informatif et ne saurait engager de quelque manire que ce soit SPOT IMAGE SA, ni ses filiales. > > > > This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. > > If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. > > This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. > > _______________________________________________ > > 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 > > Ce courrier lectronique et toutes les pices ventuellement jointes qu?il contient sont CONFIDENTIELS et destins exclusivement l?usage de leur destinataire. Si une erreur de transmission ou une adresse errone a mal dirige ce courrier, merci d?en informer l?expditeur en lui faisant une rponse par courrier lectronique ds rception. Si vous n?tes pas le destinataire de ce courrier, vous ne devez pas l?utiliser, le conserver, en faire tat, le distribuer, le copier, l?imprimer ou en rvler le contenu une tierce partie. > Ce courrier lectronique est usage strictement informatif et ne saurait engager de quelque manire que ce soit SPOT IMAGE SA, ni ses filiales. > > This e-mail and any attachments hereto are CONFIDENTIAL and intended solely for the use of the addressee. If you have received this e-mail in error please send it back to the person that sent it to you. > If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it. > This email is for information only and will not bind SPOT IMAGE SA in any contract or obligation, nor its subsidiaries. > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From luisapena1979 at gmail.com Tue Mar 22 17:36:44 2011 From: luisapena1979 at gmail.com (=?ISO-8859-1?Q?Luisa_Pe=F1a?=) Date: Tue Mar 22 17:36:48 2011 Subject: [gdal-dev] Reproject Landsat USGS image Message-ID: Greetings I have sent an message a couple of days ago ( http://lists.osgeo.org/pipermail/gdal-dev/2011-March/028124.html) about this I used gdalwarp with this formulation gdalpwarp -t_srs -tr 30 30 input.tif output.tif Well it works fine but It seems to be with a deviation of half pixel on Latitude and half pixel on Longitude when compared with a similar operation in ARCGis Maybe I'm missing some parameter that might be relevant. Any suggestion? Thanks Luisa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110322/7cc6a3f8/attachment.html From ksshannon at gmail.com Tue Mar 22 17:40:27 2011 From: ksshannon at gmail.com (Kyle Shannon) Date: Tue Mar 22 17:40:44 2011 Subject: [gdal-dev] Reproject Landsat USGS image In-Reply-To: References: Message-ID: What version of gdal are you using? # ============================ Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels & Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshannon@fs.fed.us # ============================ On Tue, Mar 22, 2011 at 15:36, Luisa Pe?a wrote: > Greetings > > I have sent an message a couple of days ago ( > http://lists.osgeo.org/pipermail/gdal-dev/2011-March/028124.html) about > this > I used gdalwarp with this formulation > gdalpwarp -t_srs -tr 30 30 input.tif output.tif > Well it works fine but It seems to be with a deviation of half pixel on > Latitude and half pixel on Longitude when compared with a similar operation > in ARCGis > > Maybe I'm missing some parameter that might be relevant. Any suggestion? > > Thanks > Luisa > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110322/9c7b62f1/attachment.html From luisapena1979 at gmail.com Wed Mar 23 04:41:41 2011 From: luisapena1979 at gmail.com (=?ISO-8859-1?Q?Luisa_Pe=F1a?=) Date: Wed Mar 23 04:41:47 2011 Subject: [gdal-dev] Reproject Landsat USGS image In-Reply-To: References: Message-ID: For now GDAL15 (the one that comes with winGRASS GIS) and GDAL16 binary. Why? (I have sent this to the wrong mailing list) > Why? > > > > 2011/3/22 Kyle Shannon > >> What version of gdal are you using? >> >> # ============================ >> Kyle Shannon >> Physical Science Technician >> RMRS Fire Sciences Lab >> Fire, Fuels & Smoke - RWU 4405 >> 5775 Highway 10 W. >> Missoula, MT 59808 >> (406)829-6954 >> kshannon@fs.fed.us >> # ============================ >> >> >> On Tue, Mar 22, 2011 at 15:36, Luisa Pe?a wrote: >> >>> Greetings >>> >>> I have sent an message a couple of days ago ( >>> http://lists.osgeo.org/pipermail/gdal-dev/2011-March/028124.html) about >>> this >>> I used gdalwarp with this formulation >>> gdalpwarp -t_srs -tr 30 30 input.tif output.tif >>> Well it works fine but It seems to be with a deviation of half pixel on >>> Latitude and half pixel on Longitude when compared with a similar operation >>> in ARCGis >>> >>> Maybe I'm missing some parameter that might be relevant. Any suggestion? >>> >>> Thanks >>> Luisa >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110323/dbba3cd4/attachment-0001.html From szekerest at gmail.com Wed Mar 23 05:32:58 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 23 05:33:01 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 Message-ID: Hi All, I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent change (in 2-3 days). Any ideas about the reason? Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110323/7d9f7df2/attachment.html From even.rouault at mines-paris.org Wed Mar 23 08:53:57 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 23 08:54:18 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: Message-ID: <1300884837.4d89ed6589b06@webmail.free.fr> Selon Tamas Szekeres : Tamas, Indeed there have been recent changes. You might want to drop a note about that to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest fixes from Kirk and me, I no longer see problems under Linux however. I don't know which version of the GeoDSDK you are using. But, at least under Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff (due to the addition of new fields in geo_normalize.h) that cause crashes. But the libgeotiff change is a bit older than the MrSID driver one, so it would be surprising that Kirk changes have an impact on that. Under Linux, using version 8 solves that issue. If you revert only the changes of the MrSID driver (to what it was before r21974), what happens ? Best regards, Even > Hi All, > > I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds > of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent > change (in 2-3 days). > > Any ideas about the reason? > > Best regards, > > Tamas > From szekerest at gmail.com Wed Mar 23 11:36:01 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 23 11:36:04 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: <1300884837.4d89ed6589b06@webmail.free.fr> References: <1300884837.4d89ed6589b06@webmail.free.fr> Message-ID: Even, According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was still OK, and r21988 was already wrong. Best regards, Tamas 2011/3/23 Even Rouault > Selon Tamas Szekeres : > > Tamas, > > Indeed there have been recent changes. You might want to drop a note about > that > to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest > fixes > from Kirk and me, I no longer see problems under Linux however. > > I don't know which version of the GeoDSDK you are using. But, at least > under > Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff > (due > to the addition of new fields in geo_normalize.h) that cause crashes. But > the > libgeotiff change is a bit older than the MrSID driver one, so it would be > surprising that Kirk changes have an impact on that. Under Linux, using > version > 8 solves that issue. If you revert only the changes of the MrSID driver (to > what > it was before r21974), what happens ? > > Best regards, > > Even > > > Hi All, > > > > I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 > builds > > of http://vbkto.dyndns.org/sdk/. This problem may be related due to a > recent > > change (in 2-3 days). > > > > Any ideas about the reason? > > > > Best regards, > > > > Tamas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110323/925aae30/attachment.html From kmckelvey at lizardtech.com Wed Mar 23 11:47:03 2011 From: kmckelvey at lizardtech.com (Kirk McKelvey) Date: Wed Mar 23 11:48:34 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: <1300884837.4d89ed6589b06@webmail.free.fr>, Message-ID: Strange, nothing happened to the driver code in that range. I will bring up a 64-bit build and see if I can debug it. Am I correct that your 32-bit builds are passing this test? ________________________________________ De : gdal-dev-bounces@lists.osgeo.org [gdal-dev-bounces@lists.osgeo.org] de la part de Tamas Szekeres [szekerest@gmail.com] Date d'envoi : mercredi 23 mars 2011 08:36 ? : Even Rouault Cc : gdal-dev Objet : Re: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 Even, According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was still OK, and r21988 was already wrong. Best regards, Tamas 2011/3/23 Even Rouault > Selon Tamas Szekeres >: Tamas, Indeed there have been recent changes. You might want to drop a note about that to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest fixes from Kirk and me, I no longer see problems under Linux however. I don't know which version of the GeoDSDK you are using. But, at least under Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff (due to the addition of new fields in geo_normalize.h) that cause crashes. But the libgeotiff change is a bit older than the MrSID driver one, so it would be surprising that Kirk changes have an impact on that. Under Linux, using version 8 solves that issue. If you revert only the changes of the MrSID driver (to what it was before r21974), what happens ? Best regards, Even > Hi All, > > I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds > of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent > change (in 2-3 days). > > Any ideas about the reason? > > Best regards, > > Tamas > From szekerest at gmail.com Wed Mar 23 12:20:07 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 23 12:20:11 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: <1300884837.4d89ed6589b06@webmail.free.fr> Message-ID: 2011/3/23 Kirk McKelvey > Am I correct that your 32-bit builds are passing this test? > Yes, that is the case. Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110323/b009430c/attachment.html From obe at IVV-AACHEN.DE Wed Mar 23 12:29:48 2011 From: obe at IVV-AACHEN.DE (Felix Obermaier) Date: Wed Mar 23 12:44:52 2011 Subject: [gdal-dev] Ogr Problem with ReleaseResultSet Message-ID: <941E09AD62CA6F41913924A35EA3985E092C4F4063@ivv-mx.ivv-aachen.de> Hello everyone, I'm using OGR via its csharp bindings and accessing a MapInfo Table (TAB) using OGR's DataSource.ExecuteSQL function. The call is somewhat like. _ogrLayer = _ogrDatasource.ExecuteSQL( @"SELECT CAST(OGR_STYLE AS character(255) AS LABEL " + "FROM LAYER WHERE OGR_STYLE LIKE 'LABEL%'", null, String.Empty) _ogrLayer is a class scope variable, and remains assigned throughout the livecycle of the class. I know that I'm supposed to release this layer calling _ogrDatasource.ReleaseResultSet(_ogrLayer); but if I do so in the finalizer or an IDisposable.Dispose() function, I -sometimes- get an exception: System.ApplicationException wurde nicht behandelt. Message=Pointer 'hDS' is NULL in 'OGR_DS_ReleaseResultSet'. Source=ogr_csharp StackTrace: bei OSGeo.OGR.DataSource.ReleaseResultSet(Layer layer) bei SharpMap.Data.Providers.Ogr.ReleaseOgrLayer() bei SharpMap.Data.Providers.Ogr.Dispose(Boolean disposing) bei SharpMap.Data.Providers.Ogr.Dispose() bei SharpMap.Data.Providers.Ogr.Finalize() InnerException: Am I allowed to call _ogrLayer.SetSpatialPredicate(...) on a layer created with ExecuteSQL(...)? Thanks in advance Felix Obermaier ------------------------------------------ Ingenieurgruppe IVV GmbH & Co. KG Dipl.-Ing. Felix Obermaier Oppenhoffallee 171 52066 Aachen Telefon: +49 (241) 94691-39 Telefax: +49 (241) 531622 eMail: obe@ivv-aachen.de Internet: http://www.ivv-aachen.de Sitz der Gesellschaft: Aachen Amtsgericht Aachen HRA 6212 GF: Bauassessor Dr.-Ing. Dieter H?lsken IVV-Management GmbH Amtsgericht Aachen HRB 12543 From dan.putler at sauder.ubc.ca Wed Mar 23 19:33:44 2011 From: dan.putler at sauder.ubc.ca (Dan Putler) Date: Wed Mar 23 19:33:48 2011 Subject: [gdal-dev] Integer overflow issue in ogr2ogr Message-ID: <4D8A8358.5010705@sauder.ubc.ca> All, I'm working with the topological faces from the 2010 Tiger shapefile data. Some of the faces are huge in Alaska (over 2147483647 meters^2, which exceeds the size of a signed 32 bit integer). In the block face attribute table the area of each face is given. When I process a file with these large areas with ogr2ogr, the resulting attribute table has area values that have been converted from the large value to -2147483648 (the largest, in absolute value, possible negative value of a 32 bit signed integer). I'm using GDAL 1.7.3 on Ubuntu 10.4 64 bit which I obtained from the Ubuntu GIS repository (1.8.0 has not made it to the Ubuntu GIS repository yet). My question really is whether there is a work around, say processing the file beforehand in a way that converts the large integers to double precision values. Dan From dan.putler at sauder.ubc.ca Wed Mar 23 20:34:30 2011 From: dan.putler at sauder.ubc.ca (Dan Putler) Date: Wed Mar 23 20:34:34 2011 Subject: [gdal-dev] Integer overflow issue in ogr2ogr In-Reply-To: <4D8A8358.5010705@sauder.ubc.ca> References: <4D8A8358.5010705@sauder.ubc.ca> Message-ID: <4D8A9196.7010005@sauder.ubc.ca> Given that someone else may run into the same problem in the near future, I decided to answer my own question, so it can be found in a web search. The problem only occurs for seven county equivalents (likely census areas) in Alaska. I solved the problem by reading the dbf portion of the shapefile into R using the read.dbf function of the foreign library, and then just overwrote the original attribute table for the problematic shapefiles. This changes the number of decimal places in the dbf header, and ogr2ogr then treats it as a floating point number, not an integer, solving the problem. On 03/23/2011 04:33 PM, Dan Putler wrote: > All, > > I'm working with the topological faces from the 2010 Tiger shapefile > data. Some of the faces are huge in Alaska (over 2147483647 meters^2, > which exceeds the size of a signed 32 bit integer). In the block face > attribute table the area of each face is given. When I process a file > with these large areas with ogr2ogr, the resulting attribute table has > area values that have been converted from the large value to -2147483648 > (the largest, in absolute value, possible negative value of a 32 bit > signed integer). I'm using GDAL 1.7.3 on Ubuntu 10.4 64 bit which I > obtained from the Ubuntu GIS repository (1.8.0 has not made it to the > Ubuntu GIS repository yet). My question really is whether there is a > work around, say processing the file beforehand in a way that converts > the large integers to double precision values. > > Dan > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From emilio.detorres at fueca.es Thu Mar 24 04:35:00 2011 From: emilio.detorres at fueca.es (Emilio de Torres =?ISO-8859-1?Q?Fern=E1ndez?=) Date: Thu Mar 24 05:01:04 2011 Subject: [gdal-dev] GeoTIFF to Shapefile Message-ID: <1300955700.1722.11.camel@fueca95> Hello, I have GeoTIFF files and need to get a shapefile with the contour of each one. The aim of this conversion is to display on a world map the areas which I have satellite images using a WMS service with MapServer. What free tool can I use? Best regards. From daniele.romagnoli at geo-solutions.it Thu Mar 24 05:13:34 2011 From: daniele.romagnoli at geo-solutions.it (Daniele Romagnoli) Date: Thu Mar 24 05:13:36 2011 Subject: [gdal-dev] GeoTIFF to Shapefile In-Reply-To: <1300955700.1722.11.camel@fueca95> References: <1300955700.1722.11.camel@fueca95> Message-ID: Hi Emilio, I think you could use the gdaltindex tool: http://www.gdal.org/gdaltindex.html Hope this helps. Regards, Daniele 2011/3/24 Emilio de Torres Fern?ndez > Hello, > > I have GeoTIFF files and need to get a shapefile with the contour of > each one. The aim of this conversion is to display on a world map the > areas which I have satellite images using a WMS service with MapServer. > > What free tool can I use? > > Best regards. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ------------------------------------------------------- Ing. Daniele Romagnoli GeoSolutions S.A.S. Software Engineer Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 328 0559267 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://it.linkedin.com/in/danieleromagnoli ------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110324/72a5e387/attachment.html From jluis at ualg.pt Thu Mar 24 11:18:47 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 11:19:06 2011 Subject: [gdal-dev] accessing zip files by URL Message-ID: <4D8B60D7.2020008@ualg.pt> Hi, How do we access to a compressed files by URL? We can do that, can't we? As an example I try this (on Windows) gdalinfo /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip ERROR 4: `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip' does not exist in the file system, and is not recognised as a supported dataset name. and this gdalinfo /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip but the error message is similar. The idea is to fetch the data directly into GMT, but first I need to understand well how it works. Thanks Joaquim Luis From chaitanya.ch at gmail.com Thu Mar 24 13:30:57 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 24 13:30:59 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8B60D7.2020008@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> Message-ID: Joaguim, I think /vsizip/vsicurl/http://path.to/the/file.zip works. You have to initialize the zip file and remote file handlers using VSIInstallCurlFileHandler() and VSIInstallZipFileHandler() Refer: http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip On Thu, Mar 24, 2011 at 8:48 PM, Joaquim Luis wrote: > Hi, > > How do we access to a compressed files by URL? We can do that, can't we? > > As an example I try this (on Windows) > > gdalinfo /vsizip/C:\ > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > ERROR 4: `/vsizip/C:\ > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip' > does not exist in the file system, > and is not recognised as a supported dataset name. > > and this > > gdalinfo /vsizip// > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > > but the error message is similar. > > The idea is to fetch the data directly into GMT, but first I need to > understand well how it works. > > Thanks > > Joaquim Luis > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110324/9a1823c7/attachment.html From even.rouault at mines-paris.org Thu Mar 24 13:45:14 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 13:45:20 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8B60D7.2020008@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> Message-ID: <201103241845.14152.even.rouault@mines-paris.org> Joaquim, The correct syntax would be : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip/W020N90.DEM or just : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip because the zip file only contains one single file (W020N90.DEM) ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL (even if you download it and unzip the file). It's just a RAW file, that neads an header to tell the dimension, georeferencing, datatype etc, so the above won't directly work. You can for example create a VRT that refers to the raw file : -20, 8.3333333333300008e-03, 0, 90, 0, -8.3333333333300008e-03 -9999 /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip MSB I've deduced this VRT from the http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file that sits next to the .dem.zip file. It's a shame that they didn't put the .hdr and the .dem file inside the same zip. It would have they been possible to open it directly... With the SRTM3 in HGT format, you can directly do : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E006.hgt.zip Best regards, Even > Hi, > > How do we access to a compressed files by URL? We can do that, can't we? > > As an example I try this (on Windows) > > gdalinfo > /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.de > m.zip ERROR 4: > `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d > em.zip' does not exist in the file system, > and is not recognised as a supported dataset name. > > and this > > gdalinfo > /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem. > zip > > but the error message is similar. > > The idea is to fetch the data directly into GMT, but first I need to > understand well how it works. > > Thanks > > Joaquim Luis > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Thu Mar 24 13:51:25 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 13:51:31 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: References: <4D8B60D7.2020008@ualg.pt> Message-ID: <201103241851.25327.even.rouault@mines-paris.org> Le jeudi 24 mars 2011 18:30:57, Chaitanya kumar CH a ?crit : > Joaguim, > > I think /vsizip/vsicurl/http://path.to/the/file.zip works. > > You have to initialize the zip file and remote file handlers using > VSIInstallCurlFileHandler() and VSIInstallZipFileHandler() Actually, they are automagically called when needed (i.e. when the first access to the VSI Virtual File API is done), so no need to explicitely call them. > > Refer: http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip > > On Thu, Mar 24, 2011 at 8:48 PM, Joaquim Luis wrote: > > Hi, > > > > How do we access to a compressed files by URL? We can do that, can't we? > > > > As an example I try this (on Windows) > > > > gdalinfo /vsizip/C:\ > > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > > ERROR 4: `/vsizip/C:\ > > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip' > > does not exist in the file system, > > and is not recognised as a supported dataset name. > > > > and this > > > > gdalinfo /vsizip// > > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > > > > but the error message is similar. > > > > The idea is to fetch the data directly into GMT, but first I need to > > understand well how it works. > > > > Thanks > > > > Joaquim Luis > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev From jluis at ualg.pt Thu Mar 24 14:03:57 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 14:04:26 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <201103241845.14152.even.rouault@mines-paris.org> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> Message-ID: <4D8B878D.3060506@ualg.pt> Even, Chaitanya Thanks for hint. I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it hasn't any mention to the need of using "vsicurl" I was about to do the tests you did, so thank you also for that. The point here is not to read that file in particular. I just wanted to use one as example and one that is not a *.tar.gz that the docs say it won't work. Ok, I have enough information to make it possible to read some compressed files sitting somewhere in the web and have the data land directly in the internals of GMT. Thanks Joaquim > Joaquim, > > The correct syntax would be : > > gdalinfo > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip/W020N90.DEM > > or just : > > gdalinfo > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > > because the zip file only contains one single file (W020N90.DEM) > > ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL > (even if you download it and unzip the file). It's just a RAW file, that neads > an header to tell the dimension, georeferencing, datatype etc, so the above > won't directly work. > > You can for example create a VRT that refers to the raw file : > > > -20, 8.3333333333300008e-03, 0, 90, 0, > -8.3333333333300008e-03 > > -9999 > relativetoVRT="0">/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem.zip > MSB > > > > I've deduced this VRT from the > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file that > sits next to the .dem.zip file. > > It's a shame that they didn't put the .hdr and the .dem file inside the same > zip. It would have they been possible to open it directly... > > With the SRTM3 in HGT format, you can directly do : > > gdalinfo > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E006.hgt.zip > > Best regards, > > Even > >> Hi, >> >> How do we access to a compressed files by URL? We can do that, can't we? >> >> As an example I try this (on Windows) >> >> gdalinfo >> /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.de >> m.zip ERROR 4: >> `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d >> em.zip' does not exist in the file system, >> and is not recognised as a supported dataset name. >> >> and this >> >> gdalinfo >> /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem. >> zip >> >> but the error message is similar. >> >> The idea is to fetch the data directly into GMT, but first I need to >> understand well how it works. >> >> Thanks >> >> Joaquim Luis >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From even.rouault at mines-paris.org Thu Mar 24 14:15:39 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 14:15:44 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8B878D.3060506@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> <4D8B878D.3060506@ualg.pt> Message-ID: <201103241915.39079.even.rouault@mines-paris.org> Le jeudi 24 mars 2011 19:03:57, Joaquim Luis a ?crit : > Even, Chaitanya > > Thanks for hint. > > I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it > hasn't any mention to the need of using "vsicurl" Yes I am aware that it is lightly documented. I've added recently a few pointers though : - in the GDALOpen() doc : http://gdal.org/gdal_8h.html#e97be045eb4701183ad332ffce29745b which points to : http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 Which mentions : "This special file handler can be combined with other virtual filesystems handlers, such as /vsizip. For example, /vsizip//vsicurl/path/to/remote/file.zip/path/inside/zip" Perhaps a more didactic page would be needed in the wiki. Any taker :-) ? I remind that the wiki is open in writing for everyone with an osgeo id... > > I was about to do the tests you did, so thank you also for that. > The point here is not to read that file in particular. I just wanted to > use one as example and one that is not a *.tar.gz that the docs say it > won't work. Ah... well actually reading in a .tar or a .tar.gz is now supported ( http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems that I have changed my mind since. But seeking will still be very slow of course (especially if you combine with /vsicurl !). Ok, I'm going to rectify the page about that point. > Ok, I have enough information to make it possible to read some > compressed files sitting somewhere in the web and have the data land > directly in the internals of GMT. > > Thanks > > Joaquim > > > Joaquim, > > > > The correct syntax would be : > > > > gdalinfo > > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 > > 0n90.dem.zip/W020N90.DEM > > > > or just : > > > > gdalinfo > > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 > > 0n90.dem.zip > > > > because the zip file only contains one single file (W020N90.DEM) > > > > ... But the W020N90.DEM inside the zip file isn't directly recognized by > > GDAL (even if you download it and unzip the file). It's just a RAW file, > > that neads an header to tell the dimension, georeferencing, datatype > > etc, so the above won't directly work. > > > > You can for example create a VRT that refers to the raw file : > > > > > > > > -20, 8.3333333333300008e-03, 0, 90, 0, > > > > -8.3333333333300008e-03 > > > > > > > > -9999 > > > > > relativetoVRT="0">/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/ > > SRTM30/w020n90/w020n90.dem.zip > > > > MSB > > > > > > > > > > > > I've deduced this VRT from the > > http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip > > file that sits next to the .dem.zip file. > > > > It's a shame that they didn't put the .hdr and the .dem file inside the > > same zip. It would have they been possible to open it directly... > > > > With the SRTM3 in HGT format, you can directly do : > > > > gdalinfo > > /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E0 > > 06.hgt.zip > > > > Best regards, > > > > Even > > > >> Hi, > >> > >> How do we access to a compressed files by URL? We can do that, can't we? > >> > >> As an example I try this (on Windows) > >> > >> gdalinfo > >> /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 > >> .de m.zip ERROR 4: > >> `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n9 > >> 0.d em.zip' does not exist in the file system, > >> and is not recognised as a supported dataset name. > >> > >> and this > >> > >> gdalinfo > >> /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d > >> em. zip > >> > >> but the error message is similar. > >> > >> The idea is to fetch the data directly into GMT, but first I need to > >> understand well how it works. > >> > >> Thanks > >> > >> Joaquim Luis > >> _______________________________________________ > >> gdal-dev mailing list > >> gdal-dev@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From michael.smith at usace.army.mil Thu Mar 24 14:16:28 2011 From: michael.smith at usace.army.mil (Smith, Michael D ERDC-CRREL-NH) Date: Thu Mar 24 14:17:22 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8B878D.3060506@ualg.pt> Message-ID: Joaquim, For .tar.gz, you can use /vsitar Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers Hanover, NH On 3/24/11 2:03 PM, "Joaquim Luis" wrote: > Even, Chaitanya > > Thanks for hint. > > I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it > hasn't any mention to the need of using "vsicurl" > > I was about to do the tests you did, so thank you also for that. > The point here is not to read that file in particular. I just wanted to > use one as example and one that is not a *.tar.gz that the docs say it > won't work. > Ok, I have enough information to make it possible to read some > compressed files sitting somewhere in the web and have the data land > directly in the internals of GMT. > > Thanks > > Joaquim > >> Joaquim, >> >> The correct syntax would be : >> >> gdalinfo >> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 >> .dem.zip/W020N90.DEM >> >> or just : >> >> gdalinfo >> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 >> .dem.zip >> >> because the zip file only contains one single file (W020N90.DEM) >> >> ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL >> (even if you download it and unzip the file). It's just a RAW file, that >> neads >> an header to tell the dimension, georeferencing, datatype etc, so the above >> won't directly work. >> >> You can for example create a VRT that refers to the raw file : >> >> >> -20, 8.3333333333300008e-03, 0, 90, 0, >> -8.3333333333300008e-03 >> >> -9999 >> > relativetoVRT="0">/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM >> 30/w020n90/w020n90.dem.zip >> MSB >> >> >> >> I've deduced this VRT from the >> http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file >> that >> sits next to the .dem.zip file. >> >> It's a shame that they didn't put the .hdr and the .dem file inside the same >> zip. It would have they been possible to open it directly... >> >> With the SRTM3 in HGT format, you can directly do : >> >> gdalinfo >> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E006.h >> gt.zip >> >> Best regards, >> >> Even >> >>> Hi, >>> >>> How do we access to a compressed files by URL? We can do that, can't we? >>> >>> As an example I try this (on Windows) >>> >>> gdalinfo >>> /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.de >>> m.zip ERROR 4: >>> `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d >>> em.zip' does not exist in the file system, >>> and is not recognised as a supported dataset name. >>> >>> and this >>> >>> gdalinfo >>> /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem. >>> zip >>> >>> but the error message is similar. >>> >>> The idea is to fetch the data directly into GMT, but first I need to >>> understand well how it works. >>> >>> Thanks >>> >>> Joaquim Luis >>> _______________________________________________ >>> 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 From jluis at ualg.pt Thu Mar 24 14:21:32 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 14:21:38 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <201103241915.39079.even.rouault@mines-paris.org> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> <4D8B878D.3060506@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> Message-ID: <4D8B8BAC.8000003@ualg.pt> Great, thanks Joaquim > Le jeudi 24 mars 2011 19:03:57, Joaquim Luis a ?crit : >> Even, Chaitanya >> >> Thanks for hint. >> >> I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it >> hasn't any mention to the need of using "vsicurl" > Yes I am aware that it is lightly documented. I've added recently a few > pointers though : > > - in the GDALOpen() doc : > http://gdal.org/gdal_8h.html#e97be045eb4701183ad332ffce29745b > > which points to : > http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 > > Which mentions : > > "This special file handler can be combined with other virtual filesystems > handlers, such as /vsizip. For example, > /vsizip//vsicurl/path/to/remote/file.zip/path/inside/zip" > > Perhaps a more didactic page would be needed in the wiki. Any taker :-) ? I > remind that the wiki is open in writing for everyone with an osgeo id... > >> I was about to do the tests you did, so thank you also for that. >> The point here is not to read that file in particular. I just wanted to >> use one as example and one that is not a *.tar.gz that the docs say it >> won't work. > Ah... well actually reading in a .tar or a .tar.gz is now supported ( > http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems > that I have changed my mind since. But seeking will still be very slow of > course (especially if you combine with /vsicurl !). Ok, I'm going to rectify > the page about that point. > >> Ok, I have enough information to make it possible to read some >> compressed files sitting somewhere in the web and have the data land >> directly in the internals of GMT. >> Thanks >> >> Joaquim >> >>> Joaquim, >>> >>> The correct syntax would be : >>> >>> gdalinfo >>> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 >>> 0n90.dem.zip/W020N90.DEM >>> >>> or just : >>> >>> gdalinfo >>> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w02 >>> 0n90.dem.zip >>> >>> because the zip file only contains one single file (W020N90.DEM) >>> >>> ... But the W020N90.DEM inside the zip file isn't directly recognized by >>> GDAL (even if you download it and unzip the file). It's just a RAW file, >>> that neads an header to tell the dimension, georeferencing, datatype >>> etc, so the above won't directly work. >>> >>> You can for example create a VRT that refers to the raw file : >>> >>> >>> >>> -20, 8.3333333333300008e-03, 0, 90, 0, >>> >>> -8.3333333333300008e-03 >>> >>> >>> >>> -9999 >>> >> >>> relativetoVRT="0">/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/ >>> SRTM30/w020n90/w020n90.dem.zip >>> >>> MSB >>> >>> >>> >>> >>> >>> I've deduced this VRT from the >>> http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip >>> file that sits next to the .dem.zip file. >>> >>> It's a shame that they didn't put the .hdr and the .dem file inside the >>> same zip. It would have they been possible to open it directly... >>> >>> With the SRTM3 in HGT format, you can directly do : >>> >>> gdalinfo >>> /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E0 >>> 06.hgt.zip >>> >>> Best regards, >>> >>> Even >>> >>>> Hi, >>>> >>>> How do we access to a compressed files by URL? We can do that, can't we? >>>> >>>> As an example I try this (on Windows) >>>> >>>> gdalinfo >>>> /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 >>>> .de m.zip ERROR 4: >>>> `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n9 >>>> 0.d em.zip' does not exist in the file system, >>>> and is not recognised as a supported dataset name. >>>> >>>> and this >>>> >>>> gdalinfo >>>> /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d >>>> em. zip >>>> >>>> but the error message is similar. >>>> >>>> The idea is to fetch the data directly into GMT, but first I need to >>>> understand well how it works. >>>> >>>> Thanks >>>> >>>> Joaquim Luis >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev > From even.rouault at mines-paris.org Thu Mar 24 14:30:17 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 14:30:23 2011 Subject: [gdal-dev] Integer overflow issue in ogr2ogr In-Reply-To: <4D8A8358.5010705@sauder.ubc.ca> References: <4D8A8358.5010705@sauder.ubc.ca> Message-ID: <201103241930.17549.even.rouault@mines-paris.org> Le jeudi 24 mars 2011 00:33:44, Dan Putler a ?crit : > All, > > I'm working with the topological faces from the 2010 Tiger shapefile > data. Some of the faces are huge in Alaska (over 2147483647 meters^2, > which exceeds the size of a signed 32 bit integer). In the block face > attribute table the area of each face is given. When I process a file > with these large areas with ogr2ogr, the resulting attribute table has > area values that have been converted from the large value to -2147483648 > (the largest, in absolute value, possible negative value of a 32 bit > signed integer). I'm using GDAL 1.7.3 on Ubuntu 10.4 64 bit which I > obtained from the Ubuntu GIS repository (1.8.0 has not made it to the > Ubuntu GIS repository yet). My question really is whether there is a > work around, say processing the file beforehand in a way that converts > the large integers to double precision values. Yes this is a well known problem that has been recorded in multiple tickets... A possible solution would be the adoption of a 64bit integer type. There's a pending (not yet implemented) RFC to deal about that : http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64 A possible workaround would be to edit the header of the DBF file to alter the field definition and set a non 0 value for the number of decimals. In which case OGR will recognize it as a double value (but you could potential have precision loss). > > Dan > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From jluis at ualg.pt Thu Mar 24 18:47:06 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 18:47:18 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <201103241915.39079.even.rouault@mines-paris.org> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> <4D8B878D.3060506@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> Message-ID: <4D8BC9EA.4010801@ualg.pt> > Ah... well actually reading in a .tar or a .tar.gz is now supported ( > http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems > that I have changed my mind since. But seeking will still be very slow of > course (especially if you combine with /vsicurl !). Ok, I'm going to rectify > the page about that point. Even, Still one further point on this matter. This works fine with the promised slowness (fair enough) gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/W020N90.DEM but the file name is case dependent. I mean, this doesn't work gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem I'm not sure what is the right thing to do here but as a Win (and occasional Mac or Linus) user I guess that I was expecting no case dependency. Joaquim From even.rouault at mines-paris.org Thu Mar 24 19:13:36 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 19:13:43 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8BC9EA.4010801@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> <4D8BC9EA.4010801@ualg.pt> Message-ID: <201103250013.36332.even.rouault@mines-paris.org> > > Even, > > Still one further point on this matter. This works fine with the > promised slowness (fair enough) > > gdalinfo > /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t > ar.gz/W020N90.DEM > > but the file name is case dependent. I mean, this doesn't work > > gdalinfo > /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t > ar.gz/w020n90.dem > > I'm not sure what is the right thing to do here but as a Win (and > occasional Mac or Linus) user I guess that I was expecting no case > dependency. GDAL's behaviour with the case sensitivity in a virtual file path is completely OS independant. Actually filenames in archives are case sensitive. I have just made a .tar.gz with 2 filenames that only differ by their case : $ tar tvzf aa.tar.gz -rw-r--r-- even/even 2 2011-03-24 23:54 Aa -rw-r--r-- even/even 3 2011-03-24 23:54 aa And the same with a zip file : $ unzip -l aa.zip Archive: aa.zip Length Date Time Name --------- ---------- ----- ---- 2 2011-03-24 23:54 Aa 3 2011-03-24 23:54 aa --------- ------- 5 2 files Admitedly a windows user will not be very happy when he uncompresses those archives in a "real" filesystem ;-) I will also note that URLs are also case sensitive. http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz is a valid URL, but http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gZ is not So I'm not sure that there's really a point in making the lookup of filenames inside the archive case insensitive. > > Joaquim From jluis at ualg.pt Thu Mar 24 19:37:05 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 19:37:36 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <2C0F249C-93A6-4F22-AF9B-3D72124D4CC8@nokia.com> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> <4D8B878D.3060506@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> <4D8BC9EA.4010801@ualg.pt> <2C0F249C-93A6-4F22-AF9B-3D72124D4CC8@nokia.com> Message-ID: <4D8BD5A1.60108@ualg.pt> > GDAL can not fix the fact that: > > http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem > > is a 404. > > -- Chris > Sure, the browsers are not yet GDAL compliant and cannot see directly inside compressed files. From jluis at ualg.pt Thu Mar 24 19:37:38 2011 From: jluis at ualg.pt (Joaquim Luis) Date: Thu Mar 24 19:37:47 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <201103250013.36332.even.rouault@mines-paris.org> References: <4D8B60D7.2020008@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> <4D8BC9EA.4010801@ualg.pt> <201103250013.36332.even.rouault@mines-paris.org> Message-ID: <4D8BD5C2.605@ualg.pt> I understand all that and even though I'm a win user I always try to be very careful with case names (basically, I avoid upper cases). But while it is easy to see the case of the real file (I know that urls are case sensitive) it's not so easy so clear to know what's inside a compressed file on the internet because if you know it it means one already have it in the local file system. Since is up to gdal to read the contents of the compressed file and get its data (NOT the file itself) it seams to me that there would be no danger in being case insensitive. But this is really a minor point (once you know why it didn't work on the first time), I know. Joaquim >> Even, >> >> Still one further point on this matter. This works fine with the >> promised slowness (fair enough) >> >> gdalinfo >> /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t >> ar.gz/W020N90.DEM >> >> but the file name is case dependent. I mean, this doesn't work >> >> gdalinfo >> /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.t >> ar.gz/w020n90.dem >> >> I'm not sure what is the right thing to do here but as a Win (and >> occasional Mac or Linus) user I guess that I was expecting no case >> dependency. > GDAL's behaviour with the case sensitivity in a virtual file path is completely > OS independant. > > Actually filenames in archives are case sensitive. I have just made a .tar.gz > with 2 filenames that only differ by their case : > > $ tar tvzf aa.tar.gz > -rw-r--r-- even/even 2 2011-03-24 23:54 Aa > -rw-r--r-- even/even 3 2011-03-24 23:54 aa > > And the same with a zip file : > > $ unzip -l aa.zip > Archive: aa.zip > Length Date Time Name > --------- ---------- ----- ---- > 2 2011-03-24 23:54 Aa > 3 2011-03-24 23:54 aa > --------- ------- > 5 2 files > > Admitedly a windows user will not be very happy when he uncompresses those > archives in a "real" filesystem ;-) > > I will also note that URLs are also case sensitive. > > http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz is a valid > URL, but http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gZ is > not > > So I'm not sure that there's really a point in making the lookup of filenames > inside the archive case insensitive. > >> Joaquim > From even.rouault at mines-paris.org Thu Mar 24 19:55:13 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 24 19:55:20 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8BD5C2.605@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> <201103250013.36332.even.rouault@mines-paris.org> <4D8BD5C2.605@ualg.pt> Message-ID: <201103250055.13186.even.rouault@mines-paris.org> Le vendredi 25 mars 2011 00:37:38, Joaquim Luis a ?crit : > I understand all that and even though I'm a win user I always try to be > very careful with case names (basically, I avoid upper cases). But while > it is easy to see the case of the real file (I know that urls are case > sensitive) it's not so easy so clear to know what's inside a compressed > file on the internet because if you know it it means one already have it > in the local file system. Actually you don't need to download the file to know its content. Just a bit of C/Python/Java/C#/Perl magic. For example, with python : from osgeo import gdal print gdal.ReadDir('/vsizip/vsicurl/http://www.aprsworld.net/gisdata/world/world.zip') Answer : ['world.dbf', 'world.shp', 'world.shx'] (For a .tar.gz, unfortunately getting the list of files means in practice that GDAL will have to download the whole .tar.gz) From christopher.schmidt at nokia.com Thu Mar 24 19:12:25 2011 From: christopher.schmidt at nokia.com (christopher.schmidt@nokia.com) Date: Thu Mar 24 20:07:28 2011 Subject: [gdal-dev] accessing zip files by URL In-Reply-To: <4D8BC9EA.4010801@ualg.pt> References: <4D8B60D7.2020008@ualg.pt> <201103241845.14152.even.rouault@mines-paris.org> <4D8B878D.3060506@ualg.pt> <201103241915.39079.even.rouault@mines-paris.org> <4D8BC9EA.4010801@ualg.pt> Message-ID: <2C0F249C-93A6-4F22-AF9B-3D72124D4CC8@nokia.com> On Mar 24, 2011, at 6:47 PM, ext Joaquim Luis wrote: > >> Ah... well actually reading in a .tar or a .tar.gz is now supported ( >> http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems >> that I have changed my mind since. But seeking will still be very slow of >> course (especially if you combine with /vsicurl !). Ok, I'm going to rectify >> the page about that point. > > Even, > > Still one further point on this matter. This works fine with the promised slowness (fair enough) > > gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/W020N90.DEM > > but the file name is case dependent. I mean, this doesn't work > > gdalinfo /vsitar/vsicurl/http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem > > I'm not sure what is the right thing to do here but as a Win (and occasional Mac or Linus) user I guess that I was expecting no case dependency. "Tough luck"? The world is case dependent. Filenames on Linux (and sometimes on Mac) are case dependent, and HTTP servers are usually case dependent. GDAL can not fix the fact that: http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem is a 404. -- Chris > Joaquim > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From motta.luiz at gmail.com Fri Mar 25 09:38:01 2011 From: motta.luiz at gmail.com (Luiz Motta) Date: Fri Mar 25 09:38:07 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together Message-ID: Devs, I would like have the subset of data, by filters of field (-select) and attributes(-where), using OGR2OGR. My enviroment is: - Windows XP - GDAL from OSGEO4W - Version: GDAL 1.8.0, released 2011/01/12 At the moment, i can only make subset(field and attribute) by call separate of OGR2OGR. Has one manner to use options "select" and "where" in the same call OGR2OGR ? Next, my tests to make subsets: 1) Source data: http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip 2) Show info: 2.1) Summary ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 2.2) Subset features (see -where) ogrinfo -q -geom=NO -where "ano = '2009' and class_name = 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more 3) Subset data 3.1) Filter by field(-select) and attribute(-where) -> Empty data output ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_select_where.shp Prodes2009_23367.shp ogrinfo -so filter_select_where.shp filter_select_where * Feature Count = 0 3.2) Filter by field(-select) ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp Prodes2009_23367.shp ogrinfo -so filter_select.shp filter_select 3.3) Filter by attribute(-where) ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp ogrinfo -so filter_where.shp filter_where Regards, Luiz Motta From cnieman at dmsolutions.ca Fri Mar 25 09:46:54 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 09:46:56 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8C9C73.2010400@dmsolutions.ca> References: <4D8C9C73.2010400@dmsolutions.ca> Message-ID: <4D8C9CCE.9090107@dmsolutions.ca> Sorry, wrong order for the source and destination files. Should be output.shp then input.shp C On 03/25/2011 09:45 AM, Christy Nieman wrote: > Hello, > > You can indeed use both -select and -where together together. For > example > > ogr2ogr -select field1,field2,field3 -where "field1 = value OR field2 > = anotherValue" input.shp output.shp > > Best regards, > Christy > > On 03/25/2011 09:38 AM, Luiz Motta wrote: >> Devs, >> >> I would like have the subset of data, by filters of field (-select) >> and attributes(-where), using OGR2OGR. >> >> My enviroment is: >> - Windows XP >> - GDAL from OSGEO4W >> - Version: GDAL 1.8.0, released 2011/01/12 >> >> At the moment, i can only make subset(field and attribute) by call >> separate of OGR2OGR. >> >> Has one manner to use options "select" and "where" in the same call >> OGR2OGR ? >> >> Next, my tests to make subsets: >> >> 1) Source data: >> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >> >> >> 2) Show info: >> 2.1) Summary >> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >> 2.2) Subset features (see -where) >> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more >> >> 3) Subset data >> >> 3.1) Filter by field(-select) and attribute(-where) -> Empty data >> output >> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >> Prodes2009_23367.shp >> ogrinfo -so filter_select_where.shp filter_select_where >> * Feature Count = 0 >> >> 3.2) Filter by field(-select) >> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >> Prodes2009_23367.shp >> ogrinfo -so filter_select.shp filter_select >> >> 3.3) Filter by attribute(-where) >> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >> ogrinfo -so filter_where.shp filter_where >> >> Regards, >> Luiz Motta >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From cnieman at dmsolutions.ca Fri Mar 25 09:45:23 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 09:53:04 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: References: Message-ID: <4D8C9C73.2010400@dmsolutions.ca> Hello, You can indeed use both -select and -where together together. For example ogr2ogr -select field1,field2,field3 -where "field1 = value OR field2 = anotherValue" input.shp output.shp Best regards, Christy On 03/25/2011 09:38 AM, Luiz Motta wrote: > Devs, > > I would like have the subset of data, by filters of field (-select) > and attributes(-where), using OGR2OGR. > > My enviroment is: > - Windows XP > - GDAL from OSGEO4W > - Version: GDAL 1.8.0, released 2011/01/12 > > At the moment, i can only make subset(field and attribute) by call > separate of OGR2OGR. > > Has one manner to use options "select" and "where" in the same call OGR2OGR ? > > Next, my tests to make subsets: > > 1) Source data: > http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip > > 2) Show info: > 2.1) Summary > ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 > 2.2) Subset features (see -where) > ogrinfo -q -geom=NO -where "ano = '2009' and class_name = > 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more > > 3) Subset data > > 3.1) Filter by field(-select) and attribute(-where) -> Empty data output > ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and > class_name = 'DESFLORESTAMENTO'" filter_select_where.shp > Prodes2009_23367.shp > ogrinfo -so filter_select_where.shp filter_select_where > * Feature Count = 0 > > 3.2) Filter by field(-select) > ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp > Prodes2009_23367.shp > ogrinfo -so filter_select.shp filter_select > > 3.3) Filter by attribute(-where) > ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = > 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp > ogrinfo -so filter_where.shp filter_where > > Regards, > Luiz Motta > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From cnieman at dmsolutions.ca Fri Mar 25 09:56:44 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 09:57:01 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8C9CCE.9090107@dmsolutions.ca> References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> Message-ID: <4D8C9F1C.9000402@dmsolutions.ca> And apparently I'm half asleep this morning. Didn't see your examples of what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data and got 754 features returned with an older version of GDAL (1.7 I believe), but 0 with 1.8 also. On 03/25/2011 09:46 AM, Christy Nieman wrote: > Sorry, wrong order for the source and destination files. Should be > output.shp then input.shp > > C > > On 03/25/2011 09:45 AM, Christy Nieman wrote: >> Hello, >> >> You can indeed use both -select and -where together together. For >> example >> >> ogr2ogr -select field1,field2,field3 -where "field1 = value OR field2 >> = anotherValue" input.shp output.shp >> >> Best regards, >> Christy >> >> On 03/25/2011 09:38 AM, Luiz Motta wrote: >>> Devs, >>> >>> I would like have the subset of data, by filters of field (-select) >>> and attributes(-where), using OGR2OGR. >>> >>> My enviroment is: >>> - Windows XP >>> - GDAL from OSGEO4W >>> - Version: GDAL 1.8.0, released 2011/01/12 >>> >>> At the moment, i can only make subset(field and attribute) by call >>> separate of OGR2OGR. >>> >>> Has one manner to use options "select" and "where" in the same call >>> OGR2OGR ? >>> >>> Next, my tests to make subsets: >>> >>> 1) Source data: >>> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >>> >>> >>> 2) Show info: >>> 2.1) Summary >>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >>> 2.2) Subset features (see -where) >>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more >>> >>> 3) Subset data >>> >>> 3.1) Filter by field(-select) and attribute(-where) -> Empty data >>> output >>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >>> Prodes2009_23367.shp >>> ogrinfo -so filter_select_where.shp filter_select_where >>> * Feature Count = 0 >>> >>> 3.2) Filter by field(-select) >>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >>> Prodes2009_23367.shp >>> ogrinfo -so filter_select.shp filter_select >>> >>> 3.3) Filter by attribute(-where) >>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >>> ogrinfo -so filter_where.shp filter_where >>> >>> Regards, >>> Luiz Motta >>> _______________________________________________ >>> 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 From motta.luiz at gmail.com Fri Mar 25 10:17:58 2011 From: motta.luiz at gmail.com (Luiz Motta) Date: Fri Mar 25 10:18:01 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8C9F1C.9000402@dmsolutions.ca> References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> <4D8C9F1C.9000402@dmsolutions.ca> Message-ID: Thank's Christy. The idea is report this problem, or verify , if i am using correct form the OGR2OGR. Luiz 2011/3/25 Christy Nieman : > And apparently I'm half asleep this morning. ?Didn't see your examples of > what you've tried. ?Sorry. ?I tried your 3.1 ogr2ogr with your data and got > 754 features returned with an older version of GDAL (1.7 I believe), but 0 > with 1.8 also. > > On 03/25/2011 09:46 AM, Christy Nieman wrote: >> >> Sorry, wrong order for the source and destination files. ?Should be >> output.shp then input.shp >> >> C >> >> On 03/25/2011 09:45 AM, Christy Nieman wrote: >>> >>> Hello, >>> >>> You can indeed use both -select and -where together together. ?For >>> example >>> >>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR field2 = >>> anotherValue" input.shp output.shp >>> >>> Best regards, >>> Christy >>> >>> On 03/25/2011 09:38 AM, Luiz Motta wrote: >>>> >>>> Devs, >>>> >>>> I would like have the subset of data, by filters of field (-select) >>>> and attributes(-where), using OGR2OGR. >>>> >>>> My enviroment is: >>>> - Windows XP >>>> - GDAL from OSGEO4W >>>> - Version: GDAL 1.8.0, released 2011/01/12 >>>> >>>> At the moment, i can only make subset(field and attribute) by call >>>> separate of OGR2OGR. >>>> >>>> Has one manner to use options ?"select" and "where" in the same call >>>> OGR2OGR ?? >>>> >>>> Next, my tests ?to make subsets: >>>> >>>> 1) Source data: >>>> >>>> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >>>> >>>> 2) Show info: >>>> 2.1) Summary >>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >>>> 2.2) Subset features (see -where) >>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >>>> 'DESFLORESTAMENTO'" ?Prodes2009_23367.shp Prodes2009_23367 | more >>>> >>>> 3) Subset data >>>> >>>> 3.1) Filter by field(-select) and attribute(-where) -> ?Empty data >>>> output >>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >>>> Prodes2009_23367.shp >>>> ogrinfo -so filter_select_where.shp filter_select_where >>>> * Feature Count = 0 >>>> >>>> 3.2) Filter by field(-select) >>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >>>> Prodes2009_23367.shp >>>> ogrinfo -so filter_select.shp filter_select >>>> >>>> 3.3) Filter by attribute(-where) >>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >>>> ogrinfo -so filter_where.shp filter_where >>>> >>>> Regards, >>>> Luiz Motta >>>> _______________________________________________ >>>> 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 > From cnieman at dmsolutions.ca Fri Mar 25 10:50:43 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 10:50:47 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> <4D8C9F1C.9000402@dmsolutions.ca> Message-ID: <4D8CABC3.9090600@dmsolutions.ca> Sorry, I wanted to provide more info, but I wanted to compile 1.8.0 before expanding on this (I was running a trunk version from before 1.8.0's release). I was going to suggest that you could use the -sql parameter with an sql query, however I was unable to get this to work with 1.8.0 either, though it worked in 1.7.x. I also wanted to read through the release notes to see if there was something obvious I missed, but didn't see anything. Anyone else encountered this problem? On 03/25/2011 10:17 AM, Luiz Motta wrote: > Thank's Christy. > > The idea is report this problem, or verify , if i am using correct > form the OGR2OGR. > > Luiz > > > > 2011/3/25 Christy Nieman: >> And apparently I'm half asleep this morning. Didn't see your examples of >> what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data and got >> 754 features returned with an older version of GDAL (1.7 I believe), but 0 >> with 1.8 also. >> >> On 03/25/2011 09:46 AM, Christy Nieman wrote: >>> Sorry, wrong order for the source and destination files. Should be >>> output.shp then input.shp >>> >>> C >>> >>> On 03/25/2011 09:45 AM, Christy Nieman wrote: >>>> Hello, >>>> >>>> You can indeed use both -select and -where together together. For >>>> example >>>> >>>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR field2 = >>>> anotherValue" input.shp output.shp >>>> >>>> Best regards, >>>> Christy >>>> >>>> On 03/25/2011 09:38 AM, Luiz Motta wrote: >>>>> Devs, >>>>> >>>>> I would like have the subset of data, by filters of field (-select) >>>>> and attributes(-where), using OGR2OGR. >>>>> >>>>> My enviroment is: >>>>> - Windows XP >>>>> - GDAL from OSGEO4W >>>>> - Version: GDAL 1.8.0, released 2011/01/12 >>>>> >>>>> At the moment, i can only make subset(field and attribute) by call >>>>> separate of OGR2OGR. >>>>> >>>>> Has one manner to use options "select" and "where" in the same call >>>>> OGR2OGR ? >>>>> >>>>> Next, my tests to make subsets: >>>>> >>>>> 1) Source data: >>>>> >>>>> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >>>>> >>>>> 2) Show info: >>>>> 2.1) Summary >>>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >>>>> 2.2) Subset features (see -where) >>>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >>>>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more >>>>> >>>>> 3) Subset data >>>>> >>>>> 3.1) Filter by field(-select) and attribute(-where) -> Empty data >>>>> output >>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >>>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >>>>> Prodes2009_23367.shp >>>>> ogrinfo -so filter_select_where.shp filter_select_where >>>>> * Feature Count = 0 >>>>> >>>>> 3.2) Filter by field(-select) >>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >>>>> Prodes2009_23367.shp >>>>> ogrinfo -so filter_select.shp filter_select >>>>> >>>>> 3.3) Filter by attribute(-where) >>>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >>>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >>>>> ogrinfo -so filter_where.shp filter_where >>>>> >>>>> Regards, >>>>> Luiz Motta >>>>> _______________________________________________ >>>>> 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 >> From luisapena1979 at gmail.com Fri Mar 25 11:01:32 2011 From: luisapena1979 at gmail.com (=?ISO-8859-1?Q?Luisa_Pe=F1a?=) Date: Fri Mar 25 11:02:08 2011 Subject: [gdal-dev] Reproject Landsat USGS image In-Reply-To: References: Message-ID: Back again on this I have talked with Markus Neteler and he told me that if I use gdalwarp with NN method, I will get a pixel shift and he suggested me to use bilinear method. The problem with bilinear is that my pixel values are changed (based on bilinear method) So is there any method to keep the pixels values and without any pixel position shift? Thanks Best regards, Luisa 2011/3/23 Luisa Pe?a > For now GDAL15 (the one that comes with winGRASS GIS) and GDAL16 binary. > Why? > (I have sent this to the wrong mailing list) > > >> Why? >> >> >> >> 2011/3/22 Kyle Shannon >> >>> What version of gdal are you using? >>> >>> # ============================ >>> Kyle Shannon >>> Physical Science Technician >>> RMRS Fire Sciences Lab >>> Fire, Fuels & Smoke - RWU 4405 >>> 5775 Highway 10 W. >>> Missoula, MT 59808 >>> (406)829-6954 >>> kshannon@fs.fed.us >>> # ============================ >>> >>> >>> On Tue, Mar 22, 2011 at 15:36, Luisa Pe?a wrote: >>> >>>> Greetings >>>> >>>> I have sent an message a couple of days ago ( >>>> http://lists.osgeo.org/pipermail/gdal-dev/2011-March/028124.html) about >>>> this >>>> I used gdalwarp with this formulation >>>> gdalpwarp -t_srs -tr 30 30 input.tif output.tif >>>> Well it works fine but It seems to be with a deviation of half pixel on >>>> Latitude and half pixel on Longitude when compared with a similar operation >>>> in ARCGis >>>> >>>> Maybe I'm missing some parameter that might be relevant. Any suggestion? >>>> >>>> Thanks >>>> Luisa >>>> >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110325/2dd0252b/attachment-0001.html From cnieman at dmsolutions.ca Fri Mar 25 11:03:21 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 11:03:23 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8CABC3.9090600@dmsolutions.ca> References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> <4D8C9F1C.9000402@dmsolutions.ca> <4D8CABC3.9090600@dmsolutions.ca> Message-ID: <4D8CAEB9.2010106@dmsolutions.ca> Aha. And sorry for kind of spamming the list. I've been looking into this between working on something else. with -sql in 1.8.0: ogr2ogr -f "ESRI Shapefile" -sql "select ano from Prodes2009_23367 where ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_select_where7.shp Prodes2009_23367.shp the ' around 2009 wasn't required when I tried in 1.7.x In 1.7.x you could have just the ano field in -select, but in 1.8.0 it seems you need both fields included in the -where, so: ogr2ogr -f "ESRI Shapefile" -select ano,class_name -where "ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp Prodes2009_23367.shp Maybe one of the developers could explain this change? Christy On 03/25/2011 10:50 AM, Christy Nieman wrote: > Sorry, I wanted to provide more info, but I wanted to compile 1.8.0 > before expanding on this (I was running a trunk version from before > 1.8.0's release). I was going to suggest that you could use the -sql > parameter with an sql query, however I was unable to get this to work > with 1.8.0 either, though it worked in 1.7.x. I also wanted to read > through the release notes to see if there was something obvious I > missed, but didn't see anything. Anyone else encountered this problem? > > On 03/25/2011 10:17 AM, Luiz Motta wrote: >> Thank's Christy. >> >> The idea is report this problem, or verify , if i am using correct >> form the OGR2OGR. >> >> Luiz >> >> >> >> 2011/3/25 Christy Nieman: >>> And apparently I'm half asleep this morning. Didn't see your >>> examples of >>> what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data >>> and got >>> 754 features returned with an older version of GDAL (1.7 I believe), >>> but 0 >>> with 1.8 also. >>> >>> On 03/25/2011 09:46 AM, Christy Nieman wrote: >>>> Sorry, wrong order for the source and destination files. Should be >>>> output.shp then input.shp >>>> >>>> C >>>> >>>> On 03/25/2011 09:45 AM, Christy Nieman wrote: >>>>> Hello, >>>>> >>>>> You can indeed use both -select and -where together together. For >>>>> example >>>>> >>>>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR >>>>> field2 = >>>>> anotherValue" input.shp output.shp >>>>> >>>>> Best regards, >>>>> Christy >>>>> >>>>> On 03/25/2011 09:38 AM, Luiz Motta wrote: >>>>>> Devs, >>>>>> >>>>>> I would like have the subset of data, by filters of field (-select) >>>>>> and attributes(-where), using OGR2OGR. >>>>>> >>>>>> My enviroment is: >>>>>> - Windows XP >>>>>> - GDAL from OSGEO4W >>>>>> - Version: GDAL 1.8.0, released 2011/01/12 >>>>>> >>>>>> At the moment, i can only make subset(field and attribute) by call >>>>>> separate of OGR2OGR. >>>>>> >>>>>> Has one manner to use options "select" and "where" in the same call >>>>>> OGR2OGR ? >>>>>> >>>>>> Next, my tests to make subsets: >>>>>> >>>>>> 1) Source data: >>>>>> >>>>>> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >>>>>> >>>>>> >>>>>> 2) Show info: >>>>>> 2.1) Summary >>>>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >>>>>> 2.2) Subset features (see -where) >>>>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >>>>>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more >>>>>> >>>>>> 3) Subset data >>>>>> >>>>>> 3.1) Filter by field(-select) and attribute(-where) -> Empty data >>>>>> output >>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >>>>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >>>>>> Prodes2009_23367.shp >>>>>> ogrinfo -so filter_select_where.shp filter_select_where >>>>>> * Feature Count = 0 >>>>>> >>>>>> 3.2) Filter by field(-select) >>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >>>>>> Prodes2009_23367.shp >>>>>> ogrinfo -so filter_select.shp filter_select >>>>>> >>>>>> 3.3) Filter by attribute(-where) >>>>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >>>>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >>>>>> ogrinfo -so filter_where.shp filter_where >>>>>> >>>>>> Regards, >>>>>> Luiz Motta >>>>>> _______________________________________________ >>>>>> 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 >>> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Fri Mar 25 13:17:27 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 25 13:17:36 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8CAEB9.2010106@dmsolutions.ca> References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> <4D8C9F1C.9000402@dmsolutions.ca> <4D8CABC3.9090600@dmsolutions.ca> <4D8CAEB9.2010106@dmsolutions.ca> Message-ID: <1301073447.4d8cce27344b0@webmail.free.fr> Selon Christy Nieman : > Aha. And sorry for kind of spamming the list. I've been looking into > this between working on something else. > > with -sql in 1.8.0: > ogr2ogr -f "ESRI Shapefile" -sql "select ano from Prodes2009_23367 where > ano = '2009' and class_name = 'DESFLORESTAMENTO'" > filter_select_where7.shp Prodes2009_23367.shp > > the ' around 2009 wasn't required when I tried in 1.7.x This part is expected. In OGR 1.8.0 the SQL engine has been rewritten and is a bit more strict regarding to SQL compliance, so quoting around literal values is now required. > > In 1.7.x you could have just the ano field in -select, but in 1.8.0 it > seems you need both fields included in the -where, so: > ogr2ogr -f "ESRI Shapefile" -select ano,class_name -where "ano = '2009' > and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp > Prodes2009_23367.shp > > Maybe one of the developers could explain this change? This one sounds like a bug due to the use of the new IgnoreFields capability, that seems to be used a bit too agressively. Could you file a GDAL Track ticket for that issue ? Thanks I didn't try but could you try the following ? ogr2ogr -f "ESRI Shapefile" -sql "select ano where ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp Prodes2009_23367.shp I *think* this would work. Best regards, Even > > Christy > > On 03/25/2011 10:50 AM, Christy Nieman wrote: > > Sorry, I wanted to provide more info, but I wanted to compile 1.8.0 > > before expanding on this (I was running a trunk version from before > > 1.8.0's release). I was going to suggest that you could use the -sql > > parameter with an sql query, however I was unable to get this to work > > with 1.8.0 either, though it worked in 1.7.x. I also wanted to read > > through the release notes to see if there was something obvious I > > missed, but didn't see anything. Anyone else encountered this problem? > > > > On 03/25/2011 10:17 AM, Luiz Motta wrote: > >> Thank's Christy. > >> > >> The idea is report this problem, or verify , if i am using correct > >> form the OGR2OGR. > >> > >> Luiz > >> > >> > >> > >> 2011/3/25 Christy Nieman: > >>> And apparently I'm half asleep this morning. Didn't see your > >>> examples of > >>> what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data > >>> and got > >>> 754 features returned with an older version of GDAL (1.7 I believe), > >>> but 0 > >>> with 1.8 also. > >>> > >>> On 03/25/2011 09:46 AM, Christy Nieman wrote: > >>>> Sorry, wrong order for the source and destination files. Should be > >>>> output.shp then input.shp > >>>> > >>>> C > >>>> > >>>> On 03/25/2011 09:45 AM, Christy Nieman wrote: > >>>>> Hello, > >>>>> > >>>>> You can indeed use both -select and -where together together. For > >>>>> example > >>>>> > >>>>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR > >>>>> field2 = > >>>>> anotherValue" input.shp output.shp > >>>>> > >>>>> Best regards, > >>>>> Christy > >>>>> > >>>>> On 03/25/2011 09:38 AM, Luiz Motta wrote: > >>>>>> Devs, > >>>>>> > >>>>>> I would like have the subset of data, by filters of field (-select) > >>>>>> and attributes(-where), using OGR2OGR. > >>>>>> > >>>>>> My enviroment is: > >>>>>> - Windows XP > >>>>>> - GDAL from OSGEO4W > >>>>>> - Version: GDAL 1.8.0, released 2011/01/12 > >>>>>> > >>>>>> At the moment, i can only make subset(field and attribute) by call > >>>>>> separate of OGR2OGR. > >>>>>> > >>>>>> Has one manner to use options "select" and "where" in the same call > >>>>>> OGR2OGR ? > >>>>>> > >>>>>> Next, my tests to make subsets: > >>>>>> > >>>>>> 1) Source data: > >>>>>> > >>>>>> > http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip > >>>>>> > >>>>>> > >>>>>> 2) Show info: > >>>>>> 2.1) Summary > >>>>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 > >>>>>> 2.2) Subset features (see -where) > >>>>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = > >>>>>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more > >>>>>> > >>>>>> 3) Subset data > >>>>>> > >>>>>> 3.1) Filter by field(-select) and attribute(-where) -> Empty data > >>>>>> output > >>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and > >>>>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp > >>>>>> Prodes2009_23367.shp > >>>>>> ogrinfo -so filter_select_where.shp filter_select_where > >>>>>> * Feature Count = 0 > >>>>>> > >>>>>> 3.2) Filter by field(-select) > >>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp > >>>>>> Prodes2009_23367.shp > >>>>>> ogrinfo -so filter_select.shp filter_select > >>>>>> > >>>>>> 3.3) Filter by attribute(-where) > >>>>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = > >>>>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp > >>>>>> ogrinfo -so filter_where.shp filter_where > >>>>>> > >>>>>> Regards, > >>>>>> Luiz Motta > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > > _______________________________________________ > > 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 > From cnieman at dmsolutions.ca Fri Mar 25 13:35:28 2011 From: cnieman at dmsolutions.ca (Christy Nieman) Date: Fri Mar 25 13:35:30 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <1301073447.4d8cce27344b0@webmail.free.fr> References: <4D8C9C73.2010400@dmsolutions.ca> <4D8C9CCE.9090107@dmsolutions.ca> <4D8C9F1C.9000402@dmsolutions.ca> <4D8CABC3.9090600@dmsolutions.ca> <4D8CAEB9.2010106@dmsolutions.ca> <1301073447.4d8cce27344b0@webmail.free.fr> Message-ID: <4D8CD260.8060404@dmsolutions.ca> Even, Thanks for the explanations. I've created ticket #4015 (http://trac.osgeo.org/gdal/ticket/4015) with regards to the necessity to include all fields used in the -where clause in -select. Luiz, Thanks for noticing this! It'd have caused me many problems had I switched to using 1.8.0 before this was noticed. Christy On 03/25/2011 01:17 PM, Even Rouault wrote: > Selon Christy Nieman: > >> Aha. And sorry for kind of spamming the list. I've been looking into >> this between working on something else. >> >> with -sql in 1.8.0: >> ogr2ogr -f "ESRI Shapefile" -sql "select ano from Prodes2009_23367 where >> ano = '2009' and class_name = 'DESFLORESTAMENTO'" >> filter_select_where7.shp Prodes2009_23367.shp >> >> the ' around 2009 wasn't required when I tried in 1.7.x > This part is expected. In OGR 1.8.0 the SQL engine has been rewritten and is a > bit more strict regarding to SQL compliance, so quoting around literal values is > now required. > >> In 1.7.x you could have just the ano field in -select, but in 1.8.0 it >> seems you need both fields included in the -where, so: >> ogr2ogr -f "ESRI Shapefile" -select ano,class_name -where "ano = '2009' >> and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp >> Prodes2009_23367.shp >> >> Maybe one of the developers could explain this change? > This one sounds like a bug due to the use of the new IgnoreFields capability, > that seems to be used a bit too agressively. Could you file a GDAL Track ticket > for that issue ? Thanks > > I didn't try but could you try the following ? > > ogr2ogr -f "ESRI Shapefile" -sql "select ano where ano = '2009' and class_name = > 'DESFLORESTAMENTO'" filter_select_where10.shp Prodes2009_23367.shp > > I *think* this would work. > > Best regards, > > Even > >> Christy >> >> On 03/25/2011 10:50 AM, Christy Nieman wrote: >>> Sorry, I wanted to provide more info, but I wanted to compile 1.8.0 >>> before expanding on this (I was running a trunk version from before >>> 1.8.0's release). I was going to suggest that you could use the -sql >>> parameter with an sql query, however I was unable to get this to work >>> with 1.8.0 either, though it worked in 1.7.x. I also wanted to read >>> through the release notes to see if there was something obvious I >>> missed, but didn't see anything. Anyone else encountered this problem? >>> >>> On 03/25/2011 10:17 AM, Luiz Motta wrote: >>>> Thank's Christy. >>>> >>>> The idea is report this problem, or verify , if i am using correct >>>> form the OGR2OGR. >>>> >>>> Luiz >>>> >>>> >>>> >>>> 2011/3/25 Christy Nieman: >>>>> And apparently I'm half asleep this morning. Didn't see your >>>>> examples of >>>>> what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data >>>>> and got >>>>> 754 features returned with an older version of GDAL (1.7 I believe), >>>>> but 0 >>>>> with 1.8 also. >>>>> >>>>> On 03/25/2011 09:46 AM, Christy Nieman wrote: >>>>>> Sorry, wrong order for the source and destination files. Should be >>>>>> output.shp then input.shp >>>>>> >>>>>> C >>>>>> >>>>>> On 03/25/2011 09:45 AM, Christy Nieman wrote: >>>>>>> Hello, >>>>>>> >>>>>>> You can indeed use both -select and -where together together. For >>>>>>> example >>>>>>> >>>>>>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR >>>>>>> field2 = >>>>>>> anotherValue" input.shp output.shp >>>>>>> >>>>>>> Best regards, >>>>>>> Christy >>>>>>> >>>>>>> On 03/25/2011 09:38 AM, Luiz Motta wrote: >>>>>>>> Devs, >>>>>>>> >>>>>>>> I would like have the subset of data, by filters of field (-select) >>>>>>>> and attributes(-where), using OGR2OGR. >>>>>>>> >>>>>>>> My enviroment is: >>>>>>>> - Windows XP >>>>>>>> - GDAL from OSGEO4W >>>>>>>> - Version: GDAL 1.8.0, released 2011/01/12 >>>>>>>> >>>>>>>> At the moment, i can only make subset(field and attribute) by call >>>>>>>> separate of OGR2OGR. >>>>>>>> >>>>>>>> Has one manner to use options "select" and "where" in the same call >>>>>>>> OGR2OGR ? >>>>>>>> >>>>>>>> Next, my tests to make subsets: >>>>>>>> >>>>>>>> 1) Source data: >>>>>>>> >>>>>>>> >> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp.zip >>>>>>>> >>>>>>>> 2) Show info: >>>>>>>> 2.1) Summary >>>>>>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 >>>>>>>> 2.2) Subset features (see -where) >>>>>>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = >>>>>>>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more >>>>>>>> >>>>>>>> 3) Subset data >>>>>>>> >>>>>>>> 3.1) Filter by field(-select) and attribute(-where) -> Empty data >>>>>>>> output >>>>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and >>>>>>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp >>>>>>>> Prodes2009_23367.shp >>>>>>>> ogrinfo -so filter_select_where.shp filter_select_where >>>>>>>> * Feature Count = 0 >>>>>>>> >>>>>>>> 3.2) Filter by field(-select) >>>>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp >>>>>>>> Prodes2009_23367.shp >>>>>>>> ogrinfo -so filter_select.shp filter_select >>>>>>>> >>>>>>>> 3.3) Filter by attribute(-where) >>>>>>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = >>>>>>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp >>>>>>>> ogrinfo -so filter_where.shp filter_where >>>>>>>> >>>>>>>> Regards, >>>>>>>> Luiz Motta >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>> _______________________________________________ >>> 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 >> > From even.rouault at mines-paris.org Fri Mar 25 15:40:48 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 25 15:40:57 2011 Subject: [gdal-dev] OGR2OGR options -select and -where together In-Reply-To: <4D8CD260.8060404@dmsolutions.ca> References: <1301073447.4d8cce27344b0@webmail.free.fr> <4D8CD260.8060404@dmsolutions.ca> Message-ID: <201103252040.48892.even.rouault@mines-paris.org> Le vendredi 25 mars 2011 18:35:28, Christy Nieman a ?crit : > Even, > Thanks for the explanations. I've created ticket #4015 > (http://trac.osgeo.org/gdal/ticket/4015) with regards to the necessity > to include all fields used in the -where clause in -select. Thanks. I've commited a fix that will go in 1.8.1. I confirm the workaround I suggested with the -sql works with 1.8.0, except that I got it wrong in my previous mail because I forgot the "from ${tablename}" in the -sql expression. So the correct syntax is : ogr2ogr -sql "select ano from Prodes2009_23367 where ano = '2009' and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp Prodes2009_23367.shp Note I've removed the -f "ESRI Shapefile". It's useless. I've just checked that Shapefile has been the default output format of ogr2ogr since its first version :-) At that time, ogr2ogr.cpp was a nice simple code of only 280 line long, now it has reached 2224 lines ... So I definitely recommand the reading of http://trac.osgeo.org/gdal/browser/trunk/ogr/ogr2ogr.cpp?rev=974 to people who want to understand the gist of ogr2ogr ;-) > > Luiz, > Thanks for noticing this! It'd have caused me many problems had I > switched to using 1.8.0 before this was noticed. > > Christy > > On 03/25/2011 01:17 PM, Even Rouault wrote: > > Selon Christy Nieman: > >> Aha. And sorry for kind of spamming the list. I've been looking into > >> this between working on something else. > >> > >> with -sql in 1.8.0: > >> ogr2ogr -f "ESRI Shapefile" -sql "select ano from Prodes2009_23367 where > >> ano = '2009' and class_name = 'DESFLORESTAMENTO'" > >> filter_select_where7.shp Prodes2009_23367.shp > >> > >> the ' around 2009 wasn't required when I tried in 1.7.x > > > > This part is expected. In OGR 1.8.0 the SQL engine has been rewritten and > > is a bit more strict regarding to SQL compliance, so quoting around > > literal values is now required. > > > >> In 1.7.x you could have just the ano field in -select, but in 1.8.0 it > >> seems you need both fields included in the -where, so: > >> ogr2ogr -f "ESRI Shapefile" -select ano,class_name -where "ano = '2009' > >> and class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp > >> Prodes2009_23367.shp > >> > >> Maybe one of the developers could explain this change? > > > > This one sounds like a bug due to the use of the new IgnoreFields > > capability, that seems to be used a bit too agressively. Could you file > > a GDAL Track ticket for that issue ? Thanks > > > > I didn't try but could you try the following ? > > > > ogr2ogr -f "ESRI Shapefile" -sql "select ano where ano = '2009' and > > class_name = 'DESFLORESTAMENTO'" filter_select_where10.shp > > Prodes2009_23367.shp > > > > I *think* this would work. > > > > Best regards, > > > > Even > > > >> Christy > >> > >> On 03/25/2011 10:50 AM, Christy Nieman wrote: > >>> Sorry, I wanted to provide more info, but I wanted to compile 1.8.0 > >>> before expanding on this (I was running a trunk version from before > >>> 1.8.0's release). I was going to suggest that you could use the -sql > >>> parameter with an sql query, however I was unable to get this to work > >>> with 1.8.0 either, though it worked in 1.7.x. I also wanted to read > >>> through the release notes to see if there was something obvious I > >>> missed, but didn't see anything. Anyone else encountered this problem? > >>> > >>> On 03/25/2011 10:17 AM, Luiz Motta wrote: > >>>> Thank's Christy. > >>>> > >>>> The idea is report this problem, or verify , if i am using correct > >>>> form the OGR2OGR. > >>>> > >>>> Luiz > >>>> > >>>> 2011/3/25 Christy Nieman: > >>>>> And apparently I'm half asleep this morning. Didn't see your > >>>>> examples of > >>>>> what you've tried. Sorry. I tried your 3.1 ogr2ogr with your data > >>>>> and got > >>>>> 754 features returned with an older version of GDAL (1.7 I believe), > >>>>> but 0 > >>>>> with 1.8 also. > >>>>> > >>>>> On 03/25/2011 09:46 AM, Christy Nieman wrote: > >>>>>> Sorry, wrong order for the source and destination files. Should be > >>>>>> output.shp then input.shp > >>>>>> > >>>>>> C > >>>>>> > >>>>>> On 03/25/2011 09:45 AM, Christy Nieman wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> You can indeed use both -select and -where together together. For > >>>>>>> example > >>>>>>> > >>>>>>> ogr2ogr -select field1,field2,field3 -where "field1 = value OR > >>>>>>> field2 = > >>>>>>> anotherValue" input.shp output.shp > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Christy > >>>>>>> > >>>>>>> On 03/25/2011 09:38 AM, Luiz Motta wrote: > >>>>>>>> Devs, > >>>>>>>> > >>>>>>>> I would like have the subset of data, by filters of field > >>>>>>>> (-select) and attributes(-where), using OGR2OGR. > >>>>>>>> > >>>>>>>> My enviroment is: > >>>>>>>> - Windows XP > >>>>>>>> - GDAL from OSGEO4W > >>>>>>>> - Version: GDAL 1.8.0, released 2011/01/12 > >>>>>>>> > >>>>>>>> At the moment, i can only make subset(field and attribute) by call > >>>>>>>> separate of OGR2OGR. > >>>>>>>> > >>>>>>>> Has one manner to use options "select" and "where" in the same > >>>>>>>> call OGR2OGR ? > >>>>>>>> > >>>>>>>> Next, my tests to make subsets: > >> > >>>>>>>> 1) Source data: > >> http://www.dpi.inpe.br/prodesdigital/dadosn/2009/PDigital2009_23367_shp. > >> zip > >> > >>>>>>>> 2) Show info: > >>>>>>>> 2.1) Summary > >>>>>>>> ogrinfo -so Prodes2009_23367.shp Prodes2009_23367 > >>>>>>>> 2.2) Subset features (see -where) > >>>>>>>> ogrinfo -q -geom=NO -where "ano = '2009' and class_name = > >>>>>>>> 'DESFLORESTAMENTO'" Prodes2009_23367.shp Prodes2009_23367 | more > >>>>>>>> > >>>>>>>> 3) Subset data > >>>>>>>> > >>>>>>>> 3.1) Filter by field(-select) and attribute(-where) -> Empty > >>>>>>>> data output > >>>>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" -where "ano = '2009' and > >>>>>>>> class_name = 'DESFLORESTAMENTO'" filter_select_where.shp > >>>>>>>> Prodes2009_23367.shp > >>>>>>>> ogrinfo -so filter_select_where.shp filter_select_where > >>>>>>>> * Feature Count = 0 > >>>>>>>> > >>>>>>>> 3.2) Filter by field(-select) > >>>>>>>> ogr2ogr -f "ESRI Shapefile" -select "ano" filter_select.shp > >>>>>>>> Prodes2009_23367.shp > >>>>>>>> ogrinfo -so filter_select.shp filter_select > >>>>>>>> > >>>>>>>> 3.3) Filter by attribute(-where) > >>>>>>>> ogr2ogr -f "ESRI Shapefile" -where "ano = '2009' and class_name = > >>>>>>>> 'DESFLORESTAMENTO'" filter_where.shp Prodes2009_23367.shp > >>>>>>>> ogrinfo -so filter_where.shp filter_where > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Luiz Motta > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>> > >>> _______________________________________________ > >>> 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 From marvin.offiah at googlemail.com Fri Mar 25 19:14:35 2011 From: marvin.offiah at googlemail.com (MarvinCO) Date: Fri Mar 25 19:14:37 2011 Subject: [gdal-dev] GDAL/OGR Java bindings very slow in reading point coordinates of feature geometries Message-ID: <1301094875367-6209461.post@n2.nabble.com> I have noticed that copying all points of a polygon (of a polygon feature) can be very costly in my implementation. This must be due to the fact that there is only one method for doing this: org.gdal.ogr.Geometry.GetPoint() This means that at every invocation of GetPoint, Java has to make a single access to the native GDAL/OGR library, only to get a single point. I cannot imagine that the original C++ version of GDAL/OGR does not provide methods for reading points much faster, e.g. something like GetPoints() to read all points of the polygon in one single command into an array of doubles. I mean, why else are the points read much faster if I read them, e.g. with Quantum GIS, which uses the original C++ GDAL/OGR? Are such methods simply missing in the Java bindings? Or what else could one do to speed this up? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-OGR-Java-bindings-very-slow-in-reading-point-coordinates-of-feature-geometries-tp6209461p6209461.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From even.rouault at mines-paris.org Fri Mar 25 19:45:21 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 25 19:45:31 2011 Subject: [gdal-dev] GDAL/OGR Java bindings very slow in reading point coordinates of feature geometries In-Reply-To: <1301094875367-6209461.post@n2.nabble.com> References: <1301094875367-6209461.post@n2.nabble.com> Message-ID: <201103260045.21902.even.rouault@mines-paris.org> Le samedi 26 mars 2011 00:14:35, MarvinCO a ?crit : > I have noticed that copying all points of a polygon (of a polygon > feature) can be very costly in my implementation. This must be due to > the fact that there is only one method for doing this: > > org.gdal.ogr.Geometry.GetPoint() > > This means that at every invocation of GetPoint, Java has to make a > single access to the native GDAL/OGR library, only to get a single > point. Yes, if you must get many points, I can imagine that the penalty to go through JNI for each point can be quite high. > > I cannot imagine that the original C++ version of GDAL/OGR does not > provide methods for reading points much faster, e.g. something like > GetPoints() to read all points of the polygon in one single command > into an array of doubles. In C++, there's indeed a OGRLineString::getPoints() method that returns the coordinate array. > > I mean, why else are the points read much faster if I read them, e.g. > with Quantum GIS, which uses the original C++ GDAL/OGR? Reviewing quickly the OGR provider of QGIS, I can see that they get the geometry as WKB, and I imagine that they have a wkb decoder somewhere else > > Are such methods simply missing in the Java bindings? Yes, getPoints() hasn't yet been mapped to the SWIG bindings, but that would certainly be a valuable addition. Could you file an enhancement request ticket in GDAL Trac ? > Or what else > could one do to speed this up? Well, in the meantime you could use Geometry.ExportToWkb() method to get the Wkb representation of the geometry and parse it on Java side. You could for example the WKBReader from the JTS to do that... or do it at hand if you don't want to add a new dependency, but that's a bit more involved. > > -- > View this message in context: > http://osgeo-org.1803224.n2.nabble.com/GDAL-OGR-Java-bindings-very-slow-in > -reading-point-coordinates-of-feature-geometries-tp6209461p6209461.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From marvin.offiah at googlemail.com Sat Mar 26 09:59:43 2011 From: marvin.offiah at googlemail.com (MarvinCO) Date: Sat Mar 26 09:59:48 2011 Subject: [gdal-dev] Re: GDAL/OGR Java bindings very slow in reading point coordinates of feature geometries In-Reply-To: <201103260045.21902.even.rouault@mines-paris.org> References: <1301094875367-6209461.post@n2.nabble.com> <201103260045.21902.even.rouault@mines-paris.org> Message-ID: <1301147983986-6210544.post@n2.nabble.com> Thanks, Even, I have just filed an enhancement request ticket for the getPoints() method in GDAL Trac, meanwhile I will use the Wkb workaround. I didn't know there is such a workaround, but I'll be looking forward to trying it. Thanks Marvin -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-OGR-Java-bindings-very-slow-in-reading-point-coordinates-of-feature-geometries-tp6209461p6210544.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From szekerest at gmail.com Sun Mar 27 11:06:05 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Sun Mar 27 11:06:10 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: <1300884837.4d89ed6589b06@webmail.free.fr> Message-ID: I did some investigations related to the Win64 problem, but I have no clues how to get further with this problem. I've used Unified_DSDK_8.0_win64-vc9 and the MSVC 2008x64 compiler and even the following code is causing heap corruption when running the mrsid autotest: LTIOFileStream *ltiofs = new LTIOFileStream(); if ( ltiofs ) delete ltiofs; // heap corruption here HEAP[python.exe]: Invalid Address specified to RtlFreeHeap( 00000000025E0000, 0000000001E97610 ) Windows has triggered a breakpoint in python.exe. This issue seems to be related to the changes r21974 Best regards, Tamas 2011/3/23 Kirk McKelvey > Strange, nothing happened to the driver code in that range. I will bring > up a 64-bit build and see if I can debug it. Am I correct that your 32-bit > builds are passing this test? > ________________________________________ > De : gdal-dev-bounces@lists.osgeo.org [gdal-dev-bounces@lists.osgeo.org] > de la part de Tamas Szekeres [szekerest@gmail.com] > Date d'envoi : mercredi 23 mars 2011 08:36 > ? : Even Rouault > Cc : gdal-dev > Objet : Re: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 > > Even, > > According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was > still OK, and r21988 was already wrong. > > Best regards, > > Tamas > > > > 2011/3/23 Even Rouault even.rouault@mines-paris.org>> > Selon Tamas Szekeres >: > > Tamas, > > Indeed there have been recent changes. You might want to drop a note about > that > to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest > fixes > from Kirk and me, I no longer see problems under Linux however. > > I don't know which version of the GeoDSDK you are using. But, at least > under > Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff > (due > to the addition of new fields in geo_normalize.h) that cause crashes. But > the > libgeotiff change is a bit older than the MrSID driver one, so it would be > surprising that Kirk changes have an impact on that. Under Linux, using > version > 8 solves that issue. If you revert only the changes of the MrSID driver (to > what > it was before r21974), what happens ? > > Best regards, > > Even > > > Hi All, > > > > I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 > builds > > of http://vbkto.dyndns.org/sdk/. This problem may be related due to a > recent > > change (in 2-3 days). > > > > Any ideas about the reason? > > > > Best regards, > > > > Tamas > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110327/630f222a/attachment.html From makmanalp at wpi.edu Sun Mar 27 18:45:41 2011 From: makmanalp at wpi.edu (Akmanalp, Mehmet A) Date: Sun Mar 27 18:46:03 2011 Subject: [gdal-dev] ITRF issues Message-ID: Hello, I have a Trimble Ag252 GPS [0] and an OmniStar HP subscription for corrections [1] for our robotics project [2]. According to that link [1], OmniStar uses ITRF2005, which I'm having trouble getting to work on python-gdal in Ubuntu 10.10. I'm converting the lat / long pair we get from the GPS device into UTM easting / northing so we can localize our robot and compare our current position from the starting position by simply using addition / subtraction / the pythagorean theorem. I'm using code similar to the following to convert (slightly simplified): -------------- snip ------------------- ellipsoid = "WGS84" # or could be EPSG:4919 etc utm = osgeo.osr.SpatialReference() utm.SetWellKnownGeogCS(ellipsoid) ll = osgeo.osr.SpatialReference() ll.SetWellKnownGeogCS(ellipsoid) zone = int(math.floor((lon + 180.0) / 6.0) + 1.0) utm.SetProjCS("UTM %d / %s" % (zone, ellipsoid)) utm.SetUTM(zone) trans = osgeo.osr.CoordinateTransformation(ll, utm) trans.TransformPoint(lat, lon, 0.0) -------------- snip ------------------- When I grep inside /usr/share/gdal16/, I can find some references to ITRF but no definition. When I look up ITRF on spatialreference.org, I find EPSG numbers 4385 [3] and 4919[4] for ITRF2000 but I get this error: "ERROR 6: EPSG PCS/GCS code 4919 not found in EPSG support files. Is this a valid EPSG coordinate system?" Same with 4896 for ITRF2005. When I grep inside /usr/share/gdal16/ for ITRS, I find "6896,International Terrestrial Reference Frame 2005,geodetic," in gdal_datum.csv. This seems to be what I'm looking for, but I have no clue how to use it. How would I go about doing this? I've also read that "new realizations of WGS84" are at about 10cm from ITRF [5], but is the WGS84 that GDAL uses one of the ones referred to in that document? Also, it doesn't specify which ITRF looks like ITRF90, which is old. Even though I could fall back to using WGS84, I'd prefer not to since it seems that it'd defeat the purpose of using a +-10cm corrections service, and I don't know if our application could tolerate much more than +-50cm. We are, however, generating a *local* map that's based on the origin position we start the robot at, so coordinates that were *uniformly* shifted over would not be a problem. Is that the case with regards to ITRF2005 vs WGS84? Thanks, -- ~ mali (http://constant.inople.net/) [0] http://trl.trimble.com/dscgi/ds.py/Get/File-159152/AgGPS252_100A_UserGuide_55510-00-ENG.pdf [1] http://www.omnistar.com/faq.html#accuracy [2] http://www.igvc-wpi.org/ [3] http://spatialreference.org/ref/epsg/4385/ [4] http://spatialreference.org/ref/epsg/4919/ [5] ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110327/05e77e26/attachment.html From luisapena1979 at gmail.com Mon Mar 28 05:10:00 2011 From: luisapena1979 at gmail.com (=?ISO-8859-1?Q?Luisa_Pe=F1a?=) Date: Mon Mar 28 05:10:02 2011 Subject: [gdal-dev] Reproject Landsat USGS image In-Reply-To: References: Message-ID: Hello I got a reply to my message stating that " GDAL ignores a flag in the GEOTIF specification that says whether the coordinates are for the center or the lower-left of each pixel. " Is this true? It's exacly what I am obtaining and what Markus Neteler explained me (about the useage of NN method) Can anyone confirm me? Thanks Luisa 2011/3/25 Luisa Pe?a > Back again on this > > I have talked with Markus Neteler and he told me that if I use gdalwarp > with NN method, I will get a pixel shift and he suggested me to use > bilinear method. The problem with bilinear is that my pixel values are > changed (based on bilinear method) > So is there any method to keep the pixels values and without any pixel > position shift? > Thanks > > Best regards, > Luisa > > > 2011/3/23 Luisa Pe?a > >> For now GDAL15 (the one that comes with winGRASS GIS) and GDAL16 binary. >> Why? >> (I have sent this to the wrong mailing list) >> >> >>> Why? >>> >>> >>> >>> 2011/3/22 Kyle Shannon >>> >>>> What version of gdal are you using? >>>> >>>> # ============================ >>>> Kyle Shannon >>>> Physical Science Technician >>>> RMRS Fire Sciences Lab >>>> Fire, Fuels & Smoke - RWU 4405 >>>> 5775 Highway 10 W. >>>> Missoula, MT 59808 >>>> (406)829-6954 >>>> kshannon@fs.fed.us >>>> # ============================ >>>> >>>> >>>> On Tue, Mar 22, 2011 at 15:36, Luisa Pe?a wrote: >>>> >>>>> Greetings >>>>> >>>>> I have sent an message a couple of days ago ( >>>>> http://lists.osgeo.org/pipermail/gdal-dev/2011-March/028124.html) >>>>> about this >>>>> I used gdalwarp with this formulation >>>>> gdalpwarp -t_srs -tr 30 30 input.tif output.tif >>>>> Well it works fine but It seems to be with a deviation of half pixel on >>>>> Latitude and half pixel on Longitude when compared with a similar operation >>>>> in ARCGis >>>>> >>>>> Maybe I'm missing some parameter that might be relevant. Any >>>>> suggestion? >>>>> >>>>> Thanks >>>>> Luisa >>>>> >>>>> _______________________________________________ >>>>> gdal-dev mailing list >>>>> gdal-dev@lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110328/b841248c/attachment.html From kmckelvey at lizardtech.com Mon Mar 28 10:01:04 2011 From: kmckelvey at lizardtech.com (Kirk McKelvey) Date: Mon Mar 28 10:01:09 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: <1300884837.4d89ed6589b06@webmail.free.fr> Message-ID: Tamas, I believe this was happening because of a known issue allocating DLL objects on the heap. I have made the stream objects into member variables to work around this problem on the trunk (r22052). Let me know if your tests continue to fail. Kirk. From: Tamas Szekeres [mailto:szekerest@gmail.com] Sent: dimanche 27 mars 2011 10:06 To: Kirk McKelvey Cc: Even Rouault; gdal-dev Subject: Re: RE : [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 I did some investigations related to the Win64 problem, but I have no clues how to get further with this problem. I've used Unified_DSDK_8.0_win64-vc9 and the MSVC 2008x64 compiler and even the following code is causing heap corruption when running the mrsid autotest: LTIOFileStream *ltiofs = new LTIOFileStream(); if ( ltiofs ) delete ltiofs; // heap corruption here HEAP[python.exe]: Invalid Address specified to RtlFreeHeap( 00000000025E0000, 0000000001E97610 ) Windows has triggered a breakpoint in python.exe. This issue seems to be related to the changes r21974 Best regards, Tamas 2011/3/23 Kirk McKelvey > Strange, nothing happened to the driver code in that range. I will bring up a 64-bit build and see if I can debug it. Am I correct that your 32-bit builds are passing this test? ________________________________________ De : gdal-dev-bounces@lists.osgeo.org [gdal-dev-bounces@lists.osgeo.org] de la part de Tamas Szekeres [szekerest@gmail.com] Date d'envoi : mercredi 23 mars 2011 08:36 ? : Even Rouault Cc : gdal-dev Objet : Re: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 Even, According to the buildlog at http://vbkto.dyndns.org/sdk/ r21980 was still OK, and r21988 was already wrong. Best regards, Tamas 2011/3/23 Even Rouault >> Selon Tamas Szekeres >>: Tamas, Indeed there have been recent changes. You might want to drop a note about that to Kirk in ticket http://trac.osgeo.org/gdal/ticket/4002 . After latest fixes from Kirk and me, I no longer see problems under Linux however. I don't know which version of the GeoDSDK you are using. But, at least under Linux, there's an ABI incompatibility of GeoSDSK v7 with latest libgeotiff (due to the addition of new fields in geo_normalize.h) that cause crashes. But the libgeotiff change is a bit older than the MrSID driver one, so it would be surprising that Kirk changes have an impact on that. Under Linux, using version 8 solves that issue. If you revert only the changes of the MrSID driver (to what it was before r21974), what happens ? Best regards, Even > Hi All, > > I'm experiencing permanent crash in the mrsid_1 autotest on the Win64 builds > of http://vbkto.dyndns.org/sdk/. This problem may be related due to a recent > change (in 2-3 days). > > Any ideas about the reason? > > Best regards, > > Tamas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110328/b522cb38/attachment-0001.html From katrineggert1980 at gmail.com Mon Mar 28 12:02:04 2011 From: katrineggert1980 at gmail.com (katrin eggert) Date: Mon Mar 28 12:02:11 2011 Subject: [gdal-dev] GDAL18 binary for Windows Message-ID: Greetings I saw that a new GDAL18 was launched and it's available for windows. I would like to know if it's already available a GDAL binary that I can run without need of OSGEO or anything like that (just like you have done for GDAL15). Thanks Kat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110328/55a89792/attachment.html From rigal at rapideye.de Mon Mar 28 12:07:07 2011 From: rigal at rapideye.de (Matthieu Rigal) Date: Mon Mar 28 12:07:27 2011 Subject: [gdal-dev] Re: strange behaviour of the python bindings in a seldom case In-Reply-To: <201103281753.47324.rigal@rapideye.de> References: <201103281753.47324.rigal@rapideye.de> Message-ID: <201103281807.08154.rigal@rapideye.de> Hi all, Sorry for the unnecessary mail to the already very full contribution list... It also crashes after a second call to any other module... So somehow, my accessor let any python module run 2 commands and crash at the third... o_O Still very strange, but on my side, no problem with GDAL here... Sorry again, Regards, Matthieu On Monday 28 March 2011 17:53:47 Matthieu Rigal wrote: > Dear GDAL heroes, > > I have encountered a very strange behaviour of the python bindings. I am > using version 1.7.3 with Python 2.6 on a OpenSuse 11 64bits. > > We developped an in-house C++ python accessor and I get a segmentation > fault at a very bizarre place. > > I am launching following minimal python script : > #!/usr/local/bin/python > import sys > from osgeo import gdal, ogr > print sys.argv > > if I launch it from this minimal shell script, everything goes fine : > python sample1.py 1 > python sample1.py 2 > > But if I launch it through our C++ accessor, I got systematically a > "segmentation fault" WHEN CALLING THE SCRIPT A SECOND TIME, that is located > at the import step. > > Stranger, if I replace the double load "gdal, ogr", by gdal or ogr, the > scripts are working as many as I want !!! (gdal+osr crashes also, whereas > ogr+osr does not !) > > It crashes only at the second run when loading gdal AND ogr... and trying > to repeat the error via a shellscript or via inline commands does not > point the same problems... > > I tried to use the sys.modules.items() to see if still some modules were > present, I tried to use the reload() for the modules and I could not solve > the problem... > > The fact that it is crashing only from our launcher could indicate that > here comes the error from, but I could not find anything... maybe I could > run a "clean loaded module" command on the C++/Python interface, which I > did not found now... > (The C++/interface is a part of a much bigger processing pacakage, > therefore I can not give easily a sample) > > But also, the fact that this only occurs with >1 osgeo packages (I tried > several other ones) indicates that there might be a problem on this side, > or am I wrong ? > > Any help or hint on something I could have forgotten would be appreciated ! > > Best Regards, > Matthieu Rigal -- Matthieu Rigal Product Development RapidEye AG Tel: +49-(0)3381-89 04 331 Molkenmarkt 30 Fax: +49-(0)3381-89 04 101 14776 Brandenburg/Havel Germany http://www.rapideye.de RapidEye AG Molkenmarkt 30 14776 Brandenburg an der Havel Germany Follow us on Twitter! www.twitter.com/rapideye_ag Head Office/Sitz der Gesellschaft: Brandenburg an der Havel Management Board/Vorstand: Wolfgang G. Biedermann, Frederik Jung-Rothenhaeusler Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: Juergen Breitkopf Commercial Register/Handelsregister Potsdam HRB 17 796 Tax Number/Steuernummer: 048/100/00053 VAT-Ident-Number/Ust.-ID: DE 199331235 DIN EN ISO 9001 certified ************************************************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. The information in this e-mail is intended for the named recipients only. It may contain privileged and confidential information. If you have received this communication in error, any use, copying or dissemination of its contents is strictly prohibited. Please erase all copies of the message along with any included attachments and notify RapidEye AG or the sender immediately by telephone at the number indicated on this page. From jorge.arevalo at deimos-space.com Mon Mar 28 12:07:25 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Mon Mar 28 12:08:46 2011 Subject: [gdal-dev] GDAL18 binary for Windows In-Reply-To: References: Message-ID: On Mon, Mar 28, 2011 at 6:02 PM, katrin eggert wrote: > Greetings > I saw that a new GDAL18 was launched and it's available for windows. I would > like to know if it's already available a GDAL binary that I can run without > need of OSGEO or anything like that (just like you have done for GDAL15). > Thanks > Kat > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > Hello, You can use binaries from here http://vbkto.dyndns.org/sdk/. Best regards, -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From rigal at rapideye.de Mon Mar 28 11:53:47 2011 From: rigal at rapideye.de (Matthieu Rigal) Date: Mon Mar 28 12:15:57 2011 Subject: [gdal-dev] strange behaviour of the python bindings in a seldom case Message-ID: <201103281753.47324.rigal@rapideye.de> Dear GDAL heroes, I have encountered a very strange behaviour of the python bindings. I am using version 1.7.3 with Python 2.6 on a OpenSuse 11 64bits. We developped an in-house C++ python accessor and I get a segmentation fault at a very bizarre place. I am launching following minimal python script : #!/usr/local/bin/python import sys from osgeo import gdal, ogr print sys.argv if I launch it from this minimal shell script, everything goes fine : python sample1.py 1 python sample1.py 2 But if I launch it through our C++ accessor, I got systematically a "segmentation fault" WHEN CALLING THE SCRIPT A SECOND TIME, that is located at the import step. Stranger, if I replace the double load "gdal, ogr", by gdal or ogr, the scripts are working as many as I want !!! (gdal+osr crashes also, whereas ogr+osr does not !) It crashes only at the second run when loading gdal AND ogr... and trying to repeat the error via a shellscript or via inline commands does not point the same problems... I tried to use the sys.modules.items() to see if still some modules were present, I tried to use the reload() for the modules and I could not solve the problem... The fact that it is crashing only from our launcher could indicate that here comes the error from, but I could not find anything... maybe I could run a "clean loaded module" command on the C++/Python interface, which I did not found now... (The C++/interface is a part of a much bigger processing pacakage, therefore I can not give easily a sample) But also, the fact that this only occurs with >1 osgeo packages (I tried several other ones) indicates that there might be a problem on this side, or am I wrong ? Any help or hint on something I could have forgotten would be appreciated ! Best Regards, Matthieu Rigal RapidEye AG Molkenmarkt 30 14776 Brandenburg an der Havel Germany Follow us on Twitter! www.twitter.com/rapideye_ag Head Office/Sitz der Gesellschaft: Brandenburg an der Havel Management Board/Vorstand: Wolfgang G. Biedermann, Frederik Jung-Rothenhaeusler Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: Juergen Breitkopf Commercial Register/Handelsregister Potsdam HRB 17 796 Tax Number/Steuernummer: 048/100/00053 VAT-Ident-Number/Ust.-ID: DE 199331235 DIN EN ISO 9001 certified ************************************************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. The information in this e-mail is intended for the named recipients only. It may contain privileged and confidential information. If you have received this communication in error, any use, copying or dissemination of its contents is strictly prohibited. Please erase all copies of the message along with any included attachments and notify RapidEye AG or the sender immediately by telephone at the number indicated on this page. From szekerest at gmail.com Mon Mar 28 15:05:37 2011 From: szekerest at gmail.com (Tamas Szekeres) Date: Mon Mar 28 15:05:39 2011 Subject: [gdal-dev] GDAL autotest (mrsid_1) crashing on Win64 In-Reply-To: References: <1300884837.4d89ed6589b06@webmail.free.fr> Message-ID: 2011/3/28 Kirk McKelvey > Tamas, > > > > I believe this was happening because of a known issue allocating DLL > objects on the heap. I have made the stream objects into member variables > to work around this problem on the trunk (r22052). Let me know if your > tests continue to fail. > > Kirk, Thanks for your efforts, the problem appears to be fixed by now. Best regards Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110328/fa0aa407/attachment.html From antonio.rocha at deimos.com.pt Tue Mar 29 05:58:36 2011 From: antonio.rocha at deimos.com.pt (=?ISO-8859-1?Q?Ant=F3nio_Rocha?=) Date: Tue Mar 29 05:57:34 2011 Subject: [gdal-dev] Re: [GRASS-dev] Error with r.to.vect- Solved? In-Reply-To: References: <4D89DF49.6020801@deimos.com.pt> <4D91A110.7080105@deimos.com.pt> <4D91AB0B.706@deimos.com.pt> Message-ID: <4D91AD4C.8010100@deimos.com.pt> Hello Markus Thanks. Just one final question: Is there a way to know which is the limit for vector? My idea is to check if raster, to be converted, is too big to be converted before I try to convert? THanks Markus Neteler wrote: > Hi Ant?nio > (cc Martin) > > you can get winGRASS 7 here: > http://wingrass.fsv.cvut.cz/grass70/ > > but I dunno if LFS is enabled in that built. Maybe Martin > can tell us. > > cheers > Markus > > 2011/3/29 Ant?nio Rocha : > >> Hi Markus >> >> The problem is that I'm running in Windows and in GRASS6.4.0stable release. >> So, there is no solution for Windows? >> Thanks >> Antonio >> >> Markus Neteler wrote: >> >>> 2011/3/29 Ant?nio Rocha : >>> >>> >>>> Hello Markus >>>> Unfortunely, I get this error when I run other datasets. In this case, a >>>> landCover with all CELLS and spatial resolution of 30. The problem is >>>> that >>>> North carolina sample is too small. >>>> r.to.vect -v input=FULL@PERMANENT output=FULL feature=area >>>> I get this: >>>> Default driver / database set to: >>>> driver: dbf >>>> database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ >>>> Extracting areas... >>>> Building topology for vector map ... >>>> R4243000ERROR: G_realloc: unable to allocate 16976004 bytes at >>>> struct_alloc.c:133 >>>> >>>> >>> You mean that it is too big :) >>> The file in question is lib/vector/diglib/struct_alloc.c >>> >>> Please try GRASS 7 instead of GRASS 6 which offers large file support >>> for vector data (to some extent). >>> >>> You need to configure it with this options >>> --enable-largefile enable support for large files (LFS) >>> >>> and compile it. Or use the weekly Linux binary snapshot which >>> has LFS enabled. >>> >>> Markus >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 5995 (20110329) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >>> >>> >>> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature >> database 5995 (20110329) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5995 (20110329) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5995 (20110329) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From antonio.rocha at deimos.com.pt Tue Mar 29 06:44:49 2011 From: antonio.rocha at deimos.com.pt (=?ISO-8859-1?Q?Ant=F3nio_Rocha?=) Date: Tue Mar 29 06:43:48 2011 Subject: [gdal-dev] Re: Warping ECMWF's grib file In-Reply-To: <4D91B7EF.4040903@deimos.com.pt> References: <4D8351FA.6070406@deimos.com.pt> <4D91B7EF.4040903@deimos.com.pt> Message-ID: <4D91B821.4060204@deimos.com.pt> Driver: GRIB/GRIdded Binary (.grb) Files: c:\Test_areas\area8.grib Size is 15, 5 Coordinate System is: GEOGCS["Coordinate System imported from GRIB file", DATUM["unknown", SPHEROID["Sphere",6367470,0]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]] Origin = (169.500000000000000,6.000000000000000) Pixel Size = (1.500000000000000,-1.500000000000000) Corner Coordinates: Upper Left ( 169.5000000, 6.0000000) (169d30' 0.00"E, 6d 0' 0.00"N) Lower Left ( 169.5000000, -1.5000000) (169d30' 0.00"E, 1d30' 0.00"S) Upper Right ( 192.000, 6.000) (192d 0' 0.00"E, 6d 0' 0.00"N) Lower Right ( 192.000, -1.500) (192d 0' 0.00"E, 1d30' 0.00"S) Center ( 180.7500000, 2.2500000) (180d45' 0.00"E, 2d15' 0.00"N) So it seems some kind of a conflict with the coordinates. Right? Any tip on how to solve it? Thanks Ant?nio Rocha wrote: > Greetings > > I have a GRIB file with longitude between 170 and 190 (attached to > this email) and, when I try to warp it to Geotiff the outcome cannot > be displayed. > Can anyone give me a tip on how to warp this file? (the problem is not > the grib but the longitude coordinates) > > Thankls > Antonio > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5996 (20110329) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From katrineggert1980 at gmail.com Tue Mar 29 06:53:17 2011 From: katrineggert1980 at gmail.com (katrin eggert) Date: Tue Mar 29 06:53:20 2011 Subject: [gdal-dev] Re: GDAL18 binary for Windows In-Reply-To: References: Message-ID: Jorge have me this link: http://vbkto.dyndns.org/sdk/ but these are not ready-to-use GDAL like this one: http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip So is there any update of these ready to use gdal versions? Thanks Kat 2011/3/28 katrin eggert > Greetings > > I saw that a new GDAL18 was launched and it's available for windows. I > would like to know if it's already available a GDAL binary that I can run > without need of OSGEO or anything like that (just like you have done for > GDAL15). > Thanks > Kat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110329/8dc73764/attachment.html From jorge.arevalo at deimos-space.com Tue Mar 29 06:57:51 2011 From: jorge.arevalo at deimos-space.com (=?ISO-8859-1?Q?Jorge_Ar=E9valo?=) Date: Tue Mar 29 06:58:17 2011 Subject: [gdal-dev] Re: GDAL18 binary for Windows In-Reply-To: References: Message-ID: Hi, The link I sent contains ready-to-use GDAL installers. The installer simply copy the GDAL binaries at their locations, like gdalwin32exe160. I think you should be able to use them in the same way. On Tue, Mar 29, 2011 at 12:53 PM, katrin eggert wrote: > > Jorge have me this link:?http://vbkto.dyndns.org/sdk/ but these are not > ready-to-use GDAL like this > one:?http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip > So is there any update of these ready to use gdal versions? > Thanks > Kat > 2011/3/28 katrin eggert >> >> Greetings >> I saw that a new GDAL18 was launched and it's available for windows. I >> would like to know if it's already available a GDAL binary that I can run >> without need of OSGEO or anything like that (just like you have done for >> GDAL15). >> Thanks >> Kat > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Jorge Ar?valo Internet & Mobilty Division, DEIMOS jorge.arevalo@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g From emilio.detorres at fueca.es Tue Mar 29 07:24:29 2011 From: emilio.detorres at fueca.es (Emilio de Torres =?ISO-8859-1?Q?Fern=E1ndez?=) Date: Tue Mar 29 07:24:32 2011 Subject: [gdal-dev] RGB bands Message-ID: <1301397869.1701.25.camel@fueca95> Hello, I have a GeoTIFF image with 5 bands and I need to transform it to a GeoTIFF with these values: - Red = band 3. - Green = band 2. - Blue = band 1. How can I do that? Would I need to delete bands 4 and 5? Best regards. From chaitanya.ch at gmail.com Tue Mar 29 07:43:39 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 29 07:44:47 2011 Subject: [gdal-dev] RGB bands In-Reply-To: <1301397869.1701.25.camel@fueca95> References: <1301397869.1701.25.camel@fueca95> Message-ID: Emilio, You can create a new GeoTIFF with just the three bands you need using gdal_translate utility with the -b option. http://www.gdal.org/gdal_translate.html 2011/3/29 Emilio de Torres Fern?ndez > Hello, > > I have a GeoTIFF image with 5 bands and I need to transform it to a > GeoTIFF with these values: > - Red = band 3. > - Green = band 2. > - Blue = band 1. > > How can I do that? Would I need to delete bands 4 and 5? > > Best regards. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110329/d6790051/attachment.html From warmerdam at pobox.com Tue Mar 29 12:13:26 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 29 12:13:30 2011 Subject: [gdal-dev] Re: Warping ECMWF's grib file In-Reply-To: <4D91B821.4060204@deimos.com.pt> References: <4D8351FA.6070406@deimos.com.pt> <4D91B7EF.4040903@deimos.com.pt> <4D91B821.4060204@deimos.com.pt> Message-ID: <4D920526.20402@pobox.com> On 11-03-29 06:44 AM, Ant?nio Rocha wrote: > Driver: GRIB/GRIdded Binary (.grb) > Files: c:\Test_areas\area8.grib > Size is 15, 5 > Coordinate System is: > GEOGCS["Coordinate System imported from GRIB file", > DATUM["unknown", > SPHEROID["Sphere",6367470,0]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433]] > Origin = (169.500000000000000,6.000000000000000) > Pixel Size = (1.500000000000000,-1.500000000000000) > Corner Coordinates: > Upper Left ( 169.5000000, 6.0000000) (169d30' 0.00"E, 6d 0' 0.00"N) > Lower Left ( 169.5000000, -1.5000000) (169d30' 0.00"E, 1d30' 0.00"S) > Upper Right ( 192.000, 6.000) (192d 0' 0.00"E, 6d 0' 0.00"N) > Lower Right ( 192.000, -1.500) (192d 0' 0.00"E, 1d30' 0.00"S) > Center ( 180.7500000, 2.2500000) (180d45' 0.00"E, 2d15' 0.00"N) > > So it seems some kind of a conflict with the coordinates. Right? Any tip on how > to solve it? > Thanks > > Ant?nio Rocha wrote: >> Greetings >> >> I have a GRIB file with longitude between 170 and 190 (attached to this >> email) and, when I try to warp it to Geotiff the outcome cannot be displayed. >> Can anyone give me a tip on how to warp this file? (the problem is not the >> grib but the longitude coordinates) Antonio, The first email did not come through, likely due to a large attachment. Can you make the file you tried available by http, and post the exact command you used to transform it? There are various complexities with files crossing the dateline but I'd like to have the real file and command to test before trying to respond. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From izzybitsie at gmail.com Tue Mar 29 12:22:10 2011 From: izzybitsie at gmail.com (Dori) Date: Tue Mar 29 12:22:12 2011 Subject: [gdal-dev] gdal_translate gif->gtiff warning Message-ID: Hi, I am trying to convert this GIF https://picasaweb.google.com/izzybitsie/GDALImage?feat=directlinkto gtiff. I used this command after assuming projection was lcc: *gdal_translate -of GTiff -a_srs '+proj=lcc +lon_0=-95 +lat_0=25 lat_1=25' -a_ullr $ulx $uly $lrx $lry ../maps/my_image.gif ../maps/my_image.tif * If I try to view the image using ImageMagick I can see it but I get a warning about TiffReadDirectory field tag 42112 encountered. If I try to view the same image with a proprietary software then, I get the same warning but I am not able to see the image. I used GDAL 1.6.0dev, FWTools 2.0.6, released 2008/02/03. The info for my_image.tif: Input file size is 864, 526 0...10...20...30...40...50...60...70...80...90...100 - done. [isidora@SJC1871DVML PY]$ display [isidora@SJC1871DVML PY]$ gdalinfo my_image.tif Driver: GTiff/GeoTIFF Files: my_image.tif Size is 864, 526 Coordinate System is: PROJCS["unnamed", GEOGCS["WGS 84", DATUM["unknown", SPHEROID["unnamed",6378137,298.2572235629972]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Lambert_Conformal_Conic_1SP"], PARAMETER["latitude_of_origin",25], PARAMETER["central_meridian",-95], PARAMETER["scale_factor",1], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (-135.000000000000000,44.000000000000000) Pixel Size = (0.070601851851852,-0.045627376425856) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-135.0000000, 44.0000000) ( 95d 0'4.81"W, 25d 0'1.43"N) Lower Left (-135.0000000, 20.0000000) ( 95d 0'4.81"W, 25d 0'0.65"N) Upper Right ( -74.0000000, 44.0000000) ( 95d 0'2.64"W, 25d 0'1.43"N) Lower Right ( -74.0000000, 20.0000000) ( 95d 0'2.64"W, 25d 0'0.65"N) Center (-104.5000000, 32.0000000) ( 95d 0'3.73"W, 25d 0'1.04"N) Band 1 Block=864x9 Type=Byte, ColorInterp=Palette Metadata: GIF_BACKGROUND=0 Color Table (RGB with 256 entries) 0: 0,0,0,255 1: 0,255,255,255 2: 153,153,102,255 3: 204,204,204,255 4: 255,0,0,255 5: 51,153,204,255 6: 51,204,51,255 7: 255,255,255,255 8: 255,255,0,255 9: 0,0,255,255 10: 0,0,0,255 11: 0,0,0,255 12: 0,0,0,255 13: 0,0,0,255 14: 0,0,0,255 15: 0,0,0,255 16: 0,0,0,255 17: 0,0,0,255 18: 0,0,0,255 19: 0,0,0,255 20: 0,0,0,255 21: 0,0,0,255 22: 0,0,0,255 23: 0,0,0,255 24: 0,0,0,255 ....... and the color table keeps going here I cannot upload this image to Picasa, but if needed I'll look for a file server. Q1: is there any easy way to find out if this warning is caused because I am using the wrong projection? Q2: Does the command I am using look OK? Q3: How do I get rid of the warning to try viewing the image with the proprietary software? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110329/902dba40/attachment.html From warmerdam at pobox.com Tue Mar 29 12:32:20 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 29 12:32:24 2011 Subject: [gdal-dev] gdal_translate gif->gtiff warning In-Reply-To: References: Message-ID: <4D920994.3010007@pobox.com> On 11-03-29 12:22 PM, Dori wrote: > Hi, > I am trying to convert this GIF > https://picasaweb.google.com/izzybitsie/GDALImage?feat=directlink > to gtiff. > I used this command after assuming projection was lcc: > *gdal_translate -of GTiff -a_srs '+proj=lcc +lon_0=-95 +lat_0=25 lat_1=25' > -a_ullr $ulx $uly $lrx $lry ../maps/my_image.gif ../maps/my_image.tif * > > If I try to view the image using ImageMagick I can see it but I get a warning > about TiffReadDirectory field tag 42112 encountered. If I try to view the same > image with a proprietary software then, I get the same warning but I am not > able to see the image. ... > Q1: is there any easy way to find out if this warning is caused because I am > using the wrong projection? Dori, Tag 42112 is a custom GDAL tag for storing metadata and is unrelated to the projection. > Q2: Does the command I am using look OK? The command looks plausible but from the output file it is clear you are assigning corner coordinates that are lat/long, not LCC projected meter coordinates. You will likely need to first reproject the lat/long corners into projected coordinates before you can assign them with -a_ullr. You could use the PROJ.4 cs2cs command or the gdaltransform command to accomplish the reprojection from lat/long to projected coordiantes. > Q3: How do I get rid of the warning to try viewing the image with the > proprietary software? You can avoid the warning by using the commandline option: -co PROFILE=GEOTIFF This instructs GDAL to avoid adding any tags not in the GeoTIFF standard. However, I suspect the warning isn't actually what is interfering with use of the image. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From pradeepkumar.penchala at iiitb.net Tue Mar 29 14:10:44 2011 From: pradeepkumar.penchala at iiitb.net (PradeepKumar Penchala) Date: Tue Mar 29 14:10:46 2011 Subject: [gdal-dev] Issue with Configure for cross compiling GDAL and make Message-ID: Hello, When I am running make command, I am getting some errors at the end of its execution: make[1]: Entering directory `/home/gise/Desktop/Pradeep/gdal-1.8.0/apps' /bin/sh /home/gise/Desktop/Pradeep/gdal-1.8.0/libtool --mode=link g++ gdalinfo.lo /home/gise/Desktop/Pradeep/gdal-1.8.0/libgdal.la -o gdalinfo libtool: link: g++ .libs/gdalinfo.o -o .libs/gdalinfo /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so -Wl,-rpath -Wl,/external/gdal/lib /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_read_info@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_tRNS@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_PLTE@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_text@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_packing@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_write_rows@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_error_fn@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_image_width@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_interlace_type@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_read_rows@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_IHDR@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_write_fn@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_write_end@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_bit_depth@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_create_read_struct@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_read_image@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_channels@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_create_write_struct@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_color_type@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_write_info@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_PLTE@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_destroy_write_struct@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_get_image_height@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_compression_level@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_destroy_read_struct@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_error@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `inflateCopy@ZLIB_1.2.0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_read_fn@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_set_tRNS@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_create_info_struct@PNG12_0' /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference to `png_sig_cmp@PNG12_0' collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/home/gise/Desktop/Pradeep/gdal-1.8.0/apps' make: *** [apps-target] Error 2 Can you please help me out in resolving this issue. -- Thanks and Regards, Pradeep GISE Lab, IIT Bombay 9769598197 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110329/bb14fe29/attachment-0001.html From chaitanya.ch at gmail.com Tue Mar 29 14:34:51 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 29 14:34:54 2011 Subject: [gdal-dev] Issue with Configure for cross compiling GDAL and make In-Reply-To: References: Message-ID: Pradeep, These kind of errors resolve themselves if you run it after a "make clean" or on a new copy of the source. On Tue, Mar 29, 2011 at 11:40 PM, PradeepKumar Penchala < pradeepkumar.penchala@iiitb.net> wrote: > Hello, > > When I am running make command, I am getting some errors at the end of its > execution: > > make[1]: Entering directory `/home/gise/Desktop/Pradeep/gdal-1.8.0/apps' > /bin/sh /home/gise/Desktop/Pradeep/gdal-1.8.0/libtool --mode=link g++ > gdalinfo.lo /home/gise/Desktop/Pradeep/gdal-1.8.0/libgdal.la -o gdalinfo > libtool: link: g++ .libs/gdalinfo.o -o .libs/gdalinfo > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so -Wl,-rpath > -Wl,/external/gdal/lib > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_read_info@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_tRNS@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_PLTE@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_text@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_packing@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_write_rows@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_error_fn@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_image_width@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_interlace_type@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_read_rows@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_IHDR@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_write_fn@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_write_end@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_bit_depth@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_create_read_struct@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_read_image@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_channels@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_create_write_struct@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_color_type@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_write_info@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_PLTE@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_destroy_write_struct@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_get_image_height@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_compression_level@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_destroy_read_struct@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_error@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `inflateCopy@ZLIB_1.2.0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_read_fn@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_set_tRNS@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_create_info_struct@PNG12_0' > /home/gise/Desktop/Pradeep/gdal-1.8.0/.libs/libgdal.so: undefined reference > to `png_sig_cmp@PNG12_0' > collect2: ld returned 1 exit status > make[1]: *** [gdalinfo] Error 1 > make[1]: Leaving directory `/home/gise/Desktop/Pradeep/gdal-1.8.0/apps' > make: *** [apps-target] Error 2 > > Can you please help me out in resolving this issue. > > -- > Thanks and Regards, > Pradeep > GISE Lab, > IIT Bombay > 9769598197 > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110330/5acec108/attachment.html From slava.lapo at gmail.com Tue Mar 29 15:38:47 2011 From: slava.lapo at gmail.com (slava_l) Date: Tue Mar 29 15:38:48 2011 Subject: [gdal-dev] OGR S57 write support Message-ID: <1301427527818-6220605.post@n2.nabble.com> Good day everyone! I am a new OGR user, using S57 driver to write some data (like soundings and isobaths). Could somebody help me to find any docs or provide some example how to write isobath into the file? I can't find any docs neither over the Internet nor at the GDAL.org Actually, I made S57 file but it's definitely does not match S57 IHO standard. I don't understand how could I make correct Eage record and fill FOID and some other fields. Thanks in advance! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/OGR-S57-write-support-tp6220605p6220605.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Tue Mar 29 17:31:42 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 29 17:31:48 2011 Subject: [gdal-dev] OGR S57 write support In-Reply-To: <1301427527818-6220605.post@n2.nabble.com> References: <1301427527818-6220605.post@n2.nabble.com> Message-ID: <4D924FBE.6000400@pobox.com> On 11-03-29 03:38 PM, slava_l wrote: > Good day everyone! > > I am a new OGR user, using S57 driver to write some data (like soundings and > isobaths). > Could somebody help me to find any docs or provide some example how to write > isobath into the file? > I can't find any docs neither over the Internet nor at the GDAL.org > > Actually, I made S57 file but it's definitely does not match S57 IHO > standard. I don't understand how could I make correct Eage record and fill > FOID and some other fields. Slava, Producing S-57 files is quite involved. The default support in ogr2ogr really depends on you having the data already in exactly the S-57 data model. This can work when transforming from S-57 to S-57 but otherwise is very very difficult. Are you hoping to write S-57 files with ogr2ogr? A script? A C++ program? I did once write a small c++ program to write files with just soundings but I can't seem to find the source code now. Normally a task like this would either require a serious S-57 expert or you would need to contract someone like me to assist and it would be somewhat expensive. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From bkpark at ucdavis.edu Tue Mar 29 18:17:17 2011 From: bkpark at ucdavis.edu (Bborie Park) Date: Tue Mar 29 18:24:01 2011 Subject: [gdal-dev] Using MEM driver to output to an gtiff in /vsimem/ Message-ID: <4D925A6D.6070609@ucdavis.edu> Hi, What I'm attempting to do is write some code to do the following: PostGIS Raster -> GDAL MEM -> user specified GDAL output format in /vsimem/ (e.g. GTiff) -> return contents of the output file to user I'm able to successfully create a MEM dataset with raw band data specified using the DATAPOINTER creation option and the GDALRasterIO() function from a PostGIS Raster. I've been successful outputting the MEM dataset using CreateCopy() to a GTiff stored on the filesystem (e.g. /tmp/out.tif), such as... rtn_ds = GDALCreateCopy( rtn_drv, "/tmp/out.tif", src_ds, FALSE, options, NULL, NULL ); What does not seem to work is if I use CreateCopy with a /vsimem/ path. rtn_ds = GDALCreateCopy( rtn_drv, "/vsimem/out.tif", src_ds, FALSE, options, NULL, NULL ); rtn = VSIGetMemFileBuffer("/vsimem/out.tif", &j, FALSE); When I read /vsimem/out.tif back out to pass back to the end-user, the contents are significantly shorter than what it should be. From what I can tell, the contents outputted are just the tiff header information and none of the band data. Is there something different about outputting a raster to a filesystem rather than /vsimem/ when working with a MEM raster with external band data? Thanks, Bborie -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkpark@ucdavis.edu From bkpark at ucdavis.edu Tue Mar 29 18:33:05 2011 From: bkpark at ucdavis.edu (Bborie Park) Date: Tue Mar 29 18:33:07 2011 Subject: [gdal-dev] Using MEM driver to output to an gtiff in /vsimem/ In-Reply-To: <4D925A6D.6070609@ucdavis.edu> References: <4D925A6D.6070609@ucdavis.edu> Message-ID: <4D925E21.4080404@ucdavis.edu> On 03/29/2011 03:17 PM, Bborie Park wrote: > Hi, > > What I'm attempting to do is write some code to do the following: > > PostGIS Raster -> GDAL MEM -> user specified GDAL output format in > /vsimem/ (e.g. GTiff) -> return contents of the output file to user > > I'm able to successfully create a MEM dataset with raw band data > specified using the DATAPOINTER creation option and the GDALRasterIO() > function from a PostGIS Raster. I've been successful outputting the MEM > dataset using CreateCopy() to a GTiff stored on the filesystem (e.g. > /tmp/out.tif), such as... > > rtn_ds = GDALCreateCopy( > rtn_drv, > "/tmp/out.tif", > src_ds, > FALSE, > options, > NULL, > NULL > ); > > What does not seem to work is if I use CreateCopy with a /vsimem/ path. > > rtn_ds = GDALCreateCopy( > rtn_drv, > "/vsimem/out.tif", > src_ds, > FALSE, > options, > NULL, > NULL > ); > > rtn = VSIGetMemFileBuffer("/vsimem/out.tif", &j, FALSE); > > When I read /vsimem/out.tif back out to pass back to the end-user, the > contents are significantly shorter than what it should be. From what I > can tell, the contents outputted are just the tiff header information > and none of the band data. > > Is there something different about outputting a raster to a filesystem > rather than /vsimem/ when working with a MEM raster with external band > data? > > Thanks, > Bborie > Sorry all. One hour after I sent the prior email, I add a GDALFlushCache() and everything works. *sigh* -bborie -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkpark@ucdavis.edu From even.rouault at mines-paris.org Tue Mar 29 18:35:59 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 29 18:36:07 2011 Subject: [gdal-dev] Using MEM driver to output to an gtiff in /vsimem/ In-Reply-To: <4D925A6D.6070609@ucdavis.edu> References: <4D925A6D.6070609@ucdavis.edu> Message-ID: <201103300035.59673.even.rouault@mines-paris.org> Le mercredi 30 mars 2011 00:17:17, Bborie Park a ?crit : > Hi, > > What I'm attempting to do is write some code to do the following: > > PostGIS Raster -> GDAL MEM -> user specified GDAL output format in > /vsimem/ (e.g. GTiff) -> return contents of the output file to user > > I'm able to successfully create a MEM dataset with raw band data > specified using the DATAPOINTER creation option and the GDALRasterIO() > function from a PostGIS Raster. I've been successful outputting the MEM > dataset using CreateCopy() to a GTiff stored on the filesystem (e.g. > /tmp/out.tif), such as... > > rtn_ds = GDALCreateCopy( > rtn_drv, > "/tmp/out.tif", > src_ds, > FALSE, > options, > NULL, > NULL > ); > > What does not seem to work is if I use CreateCopy with a /vsimem/ path. > > rtn_ds = GDALCreateCopy( > rtn_drv, > "/vsimem/out.tif", > src_ds, > FALSE, > options, > NULL, > NULL > ); --> Here, you must close the dataset so it to be properly flushed before getting the buffer. > > rtn = VSIGetMemFileBuffer("/vsimem/out.tif", &j, FALSE); > > When I read /vsimem/out.tif back out to pass back to the end-user, the > contents are significantly shorter than what it should be. From what I > can tell, the contents outputted are just the tiff header information > and none of the band data. > > Is there something different about outputting a raster to a filesystem > rather than /vsimem/ when working with a MEM raster with external band > data? > > Thanks, > Bborie From bkpark at ucdavis.edu Tue Mar 29 18:39:27 2011 From: bkpark at ucdavis.edu (Bborie Park) Date: Tue Mar 29 18:39:30 2011 Subject: [gdal-dev] Using MEM driver to output to an gtiff in /vsimem/ In-Reply-To: <201103300035.59673.even.rouault@mines-paris.org> References: <4D925A6D.6070609@ucdavis.edu> <201103300035.59673.even.rouault@mines-paris.org> Message-ID: <4D925F9F.9050205@ucdavis.edu> >> What does not seem to work is if I use CreateCopy with a /vsimem/ path. >> >> rtn_ds = GDALCreateCopy( >> rtn_drv, >> "/vsimem/out.tif", >> src_ds, >> FALSE, >> options, >> NULL, >> NULL >> ); > > --> Here, you must close the dataset so it to be properly flushed before > getting the buffer. > Thanks Even! That simple solution works for me. -bborie -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkpark@ucdavis.edu From bkpark at ucdavis.edu Tue Mar 29 18:56:52 2011 From: bkpark at ucdavis.edu (Bborie Park) Date: Tue Mar 29 18:56:54 2011 Subject: [gdal-dev] Outputting to /vsimem/ Message-ID: <4D9263B4.8080406@ucdavis.edu> Hi, I'm wondering as to scope of /vsimem/ in the situation of more than one GDAL processes running simultaneously. Say for example GDAL process #1 is making use of /vsimem/dump.dat. Now, if GDAL process #2 is looking to create and make use of a file at path /vsimem/dump.dat. Does each process have its own /vsimem/ or is /vsimem/ shared amongst processes? Thanks, Bborie -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkpark@ucdavis.edu From even.rouault at mines-paris.org Tue Mar 29 19:04:46 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 29 19:04:54 2011 Subject: [gdal-dev] Outputting to /vsimem/ In-Reply-To: <4D9263B4.8080406@ucdavis.edu> References: <4D9263B4.8080406@ucdavis.edu> Message-ID: <201103300104.46420.even.rouault@mines-paris.org> Le mercredi 30 mars 2011 00:56:52, Bborie Park a ?crit : > Hi, > > I'm wondering as to scope of /vsimem/ in the situation of more than one > GDAL processes running simultaneously. > > Say for example GDAL process #1 is making use of /vsimem/dump.dat. Now, > if GDAL process #2 is looking to create and make use of a file at path > /vsimem/dump.dat. Does each process have its own /vsimem/ or is > /vsimem/ shared amongst processes? Each process has its own /vsimem/ . (But all threads of a same process share the same /vsimem/ virtual file system) > > Thanks, > Bborie From warmerdam at pobox.com Tue Mar 29 20:03:21 2011 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 29 20:03:25 2011 Subject: [gdal-dev] Reproject Landsat USGS image In-Reply-To: References: Message-ID: <4D927349.9050303@pobox.com> On 11-03-28 05:10 AM, Luisa Pe?a wrote: > Hello > > I got a reply to my message stating that " GDAL ignores a flag in the GEOTIF > specification that says whether the coordinates are for the center or the > lower-left of each pixel. " > Is this true? It's exacly what I am obtaining and what Markus Neteler explained > me (about the useage of NN method) > > Can anyone confirm me? Luisa, Prior to GDAL 1.8 the "PixelIsPoint" information was not considered to affect the Geotransform. This was corrected in 1.8 and is described in this RFC: http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Note that this does not have a different result depending on the warper resampling kernel used. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From slava.lapo at gmail.com Wed Mar 30 03:40:17 2011 From: slava.lapo at gmail.com (slava_l) Date: Wed Mar 30 03:40:18 2011 Subject: [gdal-dev] Re: OGR S57 write support In-Reply-To: <4D924FBE.6000400@pobox.com> References: <1301427527818-6220605.post@n2.nabble.com> <4D924FBE.6000400@pobox.com> Message-ID: <1301470817753-6222185.post@n2.nabble.com> Frank, thanks for the quick response. I hope to write c++ program. Unfortunately, I have raw data in text format. But could it help if I create (using ENC Designer) some template S57 file containing only one isobath. Then open it and complement with required data using "clone" and filling by new spatial data? I have a copy of IHO standart and (theoretically) a person to ask question about S57, but currently it's also a problem to understand how to use OGR library considering S57 format. So, if you find that example, I would be very thankful to you. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/OGR-S57-write-support-tp6220605p6222185.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From emilio.detorres at fueca.es Wed Mar 30 03:44:04 2011 From: emilio.detorres at fueca.es (Emilio de Torres =?ISO-8859-1?Q?Fern=E1ndez?=) Date: Wed Mar 30 03:44:08 2011 Subject: [gdal-dev] RGB bands In-Reply-To: References: <1301397869.1701.25.camel@fueca95> Message-ID: <1301471044.1754.6.camel@fueca95> Thanks Chaitanya, I did $ gdal_translate src.tif dst.tif -b 3 -b 2 -b 1 co PHOTOMETRIC=RGB to create the new GeoTIFF with the order of the bands modified and the color interpretation assigned to them. Best regards. El mar, 29-03-2011 a las 17:13 +0530, Chaitanya kumar CH escribi?: > Emilio, > > You can create a new GeoTIFF with just the three bands you need using > gdal_translate utility with the -b option. > http://www.gdal.org/gdal_translate.html > > 2011/3/29 Emilio de Torres Fern?ndez > Hello, > > I have a GeoTIFF image with 5 bands and I need to transform it > to a > GeoTIFF with these values: > - Red = band 3. > - Green = band 2. > - Blue = band 1. > > How can I do that? Would I need to delete bands 4 and 5? > > Best regards. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Best regards, > Chaitanya kumar CH. > /t?a???nj?/ /k?m?r/ > +91-9494447584 > 17.2416N 80.1426E From chaitanya.ch at gmail.com Wed Mar 30 13:38:25 2011 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Wed Mar 30 13:38:27 2011 Subject: [gdal-dev] Re: conversion of oracle spatial to shapefile In-Reply-To: <20110330120410.52896.qmail@f4mail-235-130.rediffmail.com> References: <20110330120410.52896.qmail@f4mail-235-130.rediffmail.com> Message-ID: Natasha, Even maintains the Java bindings for GDAL. You can find some utilities written in Java at http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps These include ogr2ogr.java too. On Wed, Mar 30, 2011 at 5:34 PM, natasha chatterjee < natashachatterjee@rediffmail.com> wrote: > > Hello > > I need to write a java code > to convert oracle spatial data to shapefile.Please guide how > to go about it.(Can you provide me a basic code which uses > java with gdal libraries so that i'll get an idea of how java > is using gdal libraries) > > OGR2OGR api is there but how it can be used in writing the code? > > Please respond back soon.I need your help. > > Thanks &Regards > Natasha > > -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +91-9494447584 17.2416N 80.1426E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110330/64fa1a67/attachment.html From even.rouault at mines-paris.org Wed Mar 30 16:18:27 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 30 16:18:34 2011 Subject: [gdal-dev] Re: OGR/Spatialite patches In-Reply-To: <4D9307D1.1000403@lqt.it> References: <4D9307D1.1000403@lqt.it> Message-ID: <201103302218.27223.even.rouault@mines-paris.org> Hi Alessandro, (CC'ing gdal-dev - and resending it since first reply was blocked due to too many recipients) Impressive work ! My remarks and questions: 1) Could you confirm that all this work might be included under the usual GDAL X/MIT licence ? Due to the significant code addition for the 3D geometry support, you might want to add your copyright in the header of ogrsqlitelayer.cpp. 2) It would be really convenient to have different patches for the different issues that could be applied sequentially. Applying all this stuff in a single gulp will make bisection and analysis of the changes quite painfull. I've skimmed quickly through the whole diff and your README and I can see several patches, preferably in the following order (if possible) : 1) 3D geometry support 2) use the spatialite SQL functions and drop the manual workarounds to avoid using spatialite functions 3) general cleanup to remove the use of ancient sqlite API (that seem not to be directly related to spatialite support) I'd be in favor of dropping the stuff related to #ifdef SPATIALITE_AMALGAMATION for now. Or it might be traced under a different ticket 3) From your patch I can see that my efforts to produce a spatialite database without linking to spatialite were vain. I'm not that surprised however.... So the question is : is there really an interest in allowing the user to create a spatialite database without linking to spatialite if that database cannot be directly used by other spatialite-enabled software ant that the user must "repair" it afterwards with the procedure at the end of your README.txt. This really sounds to be compatible with only super power users... We might also want to be sure that no write/update/delete operations can happen to a spatialite database if it is opened with a driver not linked against libspatialite to avoid corrupting it. However I think it is still desirable to be able to read a spatialite database without requiring linking to spatialite. 4) We must be aware that using the ALTER TABLE ... ADD COLUMN ... stuff will produce databases (even regular SQLite ones) that will not be compatible with the latest FWTools for Windows that uses an ancient sqlite versions. Might not be a big deal however because I somehow remember that dropping a new version of sqlite3.dll in the bin directory make it work again. 5) Would you be willing to update/extend the autotest/ogr/ogr_sqlite.py test to ensure that it still passes and add some tests for all the new stuff, particularly the 3D geometry support. 6) From your README.TXT, can I assume that your changes have been tested against regular libsqlite3 (without linking to spatialite) with a spatialite database (and also a regular sqlite database not using spatialite geometries), and against libspatialite 2.3.1 and libspatialite 2.4.0 for spatialite databases ? 7) A minor code note : it could be interesting to replace the magic values for the geometry types by appropriate #define with symbolic names. 8) I've seen you have removed the tests to detect int overflows, for example "if( nPointCount < 0 || nPointCount > INT_MAX / (2 * 8))" has become "if( nPointCount < 0)". Could you justify it ? I still think that they are necessary to avoid issues in lines below if the nPointCount value is huge enough. 9) About your [3c] patch. Yes indeed this is a painfull issue with shapefiles (the format I mean, not the driver) where we cannot know in advance if it only contains LINESTRING or MULTILINESTRING. Currently the shapefile driver chooses to report the layer as having LINESTRING geometry type. Maybe Frank can comment about this. I imagine this was decided because some application software wouldn't know to deal with multi-geometry. But I can confirm that inserting such shapefiles with mixed linestring/multilinestring geometries into Postgis requires a -nlt flag to the ogr2ogr command line. To get back to your patch, I'm wondering what will happen if we try to insert a feature with a LINESTRING geometry into a layer created with the LINESTRING geometry type, that has been "promoted" to MULTILINESTRING by the driver ? Best regards, Even Le mercredi 30 mars 2011 12:37:05, Alessandro Furieri a ?crit : > Hi All, > > I know for sure that all you are strongly > interested in both SpatiaLite and GDAL/OGR: > so I'm glad to submit to your attention a > patch-set intended to enhance the OGR/spatialite > driver. > > - correcting several issues found into the current > implementation > - supporting the most recent features introduced > by v.2.4.0 [3D Geometries and so on] > > You'll find everything within the attached zipfile: > - source code > - svn diff > - detailed explanations on README.txt > > Please note: the current patch-set (although quite > thoroughly tested and debugged by myself) simply > represents a preliminary interim version. > I suppose some further (small) optimization would > be required before actually committing into the > SVN trunk. > Any suggestion, useful hint, criticism and testing > coming from you surely will be warmly welcome and > highly appreciated. > > bye > Sando From thomas.gocke at gmx.de Thu Mar 31 08:59:10 2011 From: thomas.gocke at gmx.de (Thomas Gocke) Date: Thu Mar 31 08:59:14 2011 Subject: [gdal-dev] TOWGS84 parameter units Message-ID: <20110331125910.69740@gmx.net> Hi, I have a question about the units of the parameters at the TOWGS84 WKT tag respectively OGRSpatialReference::SetTOWGS84(?) ESRI and ERDAS specify the TOWGS84 rx, ry and rz paramters in radians, whereas GDAL seems to be expecting them in arcseconds. DHDN for example is defined by ESRI and ERDAS with TOWGS84[598.1,73.7,418.2,-9.793000000000001e-007,-2.182e-007,1.19e-005,6.7e-006] which seems to give a wrong result in GDAL. If I change it to TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7] it looks right. Is arcseconds the recommended unit and ESRI and ERDAS don?t stick to the convention or should I always recalculate the TOWGS84 parameters and set them manually with OGRSpatialReference::SetTOWGS84(?) ? Thanks for helping, Thomas -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From antonio.rocha at deimos.com.pt Thu Mar 31 10:52:32 2011 From: antonio.rocha at deimos.com.pt (=?ISO-8859-1?Q?Ant=F3nio_Rocha?=) Date: Thu Mar 31 10:52:37 2011 Subject: [gdal-dev] Verify current GDAL_DATA Message-ID: <4D949530.7060709@deimos.com.pt> Greetings I'm running gdalwarp and I would like to know current GDAL_DATA. Is there any way, like gdalwarp.exe --config to retrieve that? Thanks Antonio __________ Information from ESET NOD32 Antivirus, version of virus signature database 6002 (20110331) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From pcorti at gmail.com Thu Mar 31 11:35:10 2011 From: pcorti at gmail.com (Paolo Corti) Date: Thu Mar 31 11:35:52 2011 Subject: [gdal-dev] Verify current GDAL_DATA In-Reply-To: <4D949530.7060709@deimos.com.pt> References: <4D949530.7060709@deimos.com.pt> Message-ID: 2011/3/31 Ant?nio Rocha : > Greetings > > I'm running gdalwarp and I would like to know current GDAL_DATA. Is there > any way, like gdalwarp.exe --config to retrieve that? > you just need to query the environmental variable. In windows: echo %GDAL_DATA% best regards P -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti From even.rouault at mines-paris.org Wed Mar 30 16:07:13 2011 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Apr 12 09:46:15 2011 Subject: [gdal-dev] Re: OGR/Spatialite patches In-Reply-To: <4D9307D1.1000403@lqt.it> References: <4D9307D1.1000403@lqt.it> Message-ID: <201103302207.13463.even.rouault@mines-paris.org> Hi Alessandro, (CC'ing gdal-dev) Impressive work ! My remarks and questions: 1) Could you confirm that all this work might be included under the usual GDAL X/MIT licence ? Due to the significant code addition for the 3D geometry support, you might want to add your copyright in the header of ogrsqlitelayer.cpp. 2) It would be really convenient to have different patches for the different issues that could be applied sequentially. Applying all this stuff in a single gulp will make bisection and analysis of the changes quite painfull. I've skimmed quickly through the whole diff and your README and I can see several patches, preferably in the following order (if possible) : 1) 3D geometry support 2) use the spatialite SQL functions and drop the manual workarounds to avoid using spatialite functions 3) general cleanup to remove the use of ancient sqlite API (that seem not to be directly related to spatialite support) I'd be in favor of dropping the stuff related to #ifdef SPATIALITE_AMALGAMATION for now. Or it might be traced under a different ticket 3) From your patch I can see that my efforts to produce a spatialite database without linking to spatialite were vain. I'm not that surprised however.... So the question is : is there really an interest in allowing the user to create a spatialite database without linking to spatialite if that database cannot be directly used by other spatialite-enabled software ant that the user must "repair" it afterwards with the procedure at the end of your README.txt. This really sounds to be compatible with only super power users... We might also want to be sure that no write/update/delete operations can happen to a spatialite database if it is opened with a driver not linked against libspatialite to avoid corrupting it. However I think it is still desirable to be able to read a spatialite database without requiring linking to spatialite. 4) We must be aware that using the ALTER TABLE ... ADD COLUMN ... stuff will produce databases (even regular SQLite ones) that will not be compatible with the latest FWTools for Windows that uses an ancient sqlite versions. Might not be a big deal however because I somehow remember that dropping a new version of sqlite3.dll in the bin directory make it work again. 5) Would you be willing to update/extend the autotest/ogr/ogr_sqlite.py test to ensure that it still passes and add some tests for all the new stuff, particularly the 3D geometry support. 6) From your README.TXT, can I assume that your changes have been tested against regular libsqlite3 (without linking to spatialite) with a spatialite database (and also a regular sqlite database not using spatialite geometries), and against libspatialite 2.3.1 and libspatialite 2.4.0 for spatialite databases ? 7) A minor code note : it could be interesting to replace the magic values for the geometry types by appropriate #define with symbolic names. 8) I've seen you have removed the tests to detect int overflows, for example "if( nPointCount < 0 || nPointCount > INT_MAX / (2 * 8))" has become "if( nPointCount < 0)". Could you justify it ? I still think that they are necessary to avoid issues in lines below if the nPointCount value is huge enough. 9) About your [3c] patch. Yes indeed this is a painfull issue with shapefiles (the format I mean, not the driver) where we cannot know in advance if it only contains LINESTRING or MULTILINESTRING. Currently the shapefile driver chooses to report the layer as having LINESTRING geometry type. Maybe Frank can comment about this. I imagine this was decided because some application software wouldn't know to deal with multi-geometry. But I can confirm that inserting such shapefiles with mixed linestring/multilinestring geometries into Postgis requires a -nlt flag to the ogr2ogr command line. To get back to your patch, I'm wondering what will happen if we try to insert a feature with a LINESTRING geometry into a layer created with the LINESTRING geometry type, that has been "promoted" to MULTILINESTRING by the driver ? Best regards, Even Le mercredi 30 mars 2011 12:37:05, Alessandro Furieri a ?crit : > Hi All, > > I know for sure that all you are strongly > interested in both SpatiaLite and GDAL/OGR: > so I'm glad to submit to your attention a > patch-set intended to enhance the OGR/spatialite > driver. > > - correcting several issues found into the current > implementation > - supporting the most recent features introduced > by v.2.4.0 [3D Geometries and so on] > > You'll find everything within the attached zipfile: > - source code > - svn diff > - detailed explanations on README.txt > > Please note: the current patch-set (although quite > thoroughly tested and debugged by myself) simply > represents a preliminary interim version. > I suppose some further (small) optimization would > be required before actually committing into the > SVN trunk. > Any suggestion, useful hint, criticism and testing > coming from you surely will be warmly welcome and > highly appreciated. > > bye > Sando