Re: [gdal-dev] Downsample with averaging?
Jay, The external overview files are created in TIFF format. I checked. However, most of the metadata will be lost. You can recover the metadata by using gdal_translate with -outsize 3.125% 3.125%. It will read the metadata from the original file and the pixels from the level 32 overview. Regarding the 2.1GB file: Check if the directory is not read-only and the disk has sufficient space. Run gdaladdo with the environment variable CPL_DEBUG set to YES and report the messages. You can also try gdalwarp multiple times with the resampling method set to something other than 'near' and 'bilinear'. However, I am not sure if this will give you want you want. On Tue, Feb 22, 2011 at 4:26 AM, Jay Jennings jennings@geoeye.comwrote: Unfortunately I can’t provide the file (it’s about 2.1 GB and not releasable), but below is the ‘gdalinfo’ dump for it. The problem may be related to size of the input, because the same command worked OK on a GeoTiff that is “only” 975 MB. BTW For the 975 GB run that succeeded, the created overview was named *.ovr rather than *.tif. Is this expected ? The guidance for ‘gdaladdo’ hints that the created *.ovr is actually a TIFF, but that’s not true here (I tried renaming it *.tif, but no TIFF reader could open it). Driver: GTiff/GeoTIFF Files: XX.tif Size is 25733, 27840 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 = (-100.375165330488004,29.624901844319002) Pixel Size = (0.04869286704,-0.04495684143) Metadata: TIFFTAG_DATETIME=2009:07:17 06:16:07 TIFFTAG_ARTIST=GeoEye TIFFTAG_COPYRIGHT=(C) COPYRIGHT GeoEye, All Rights Reserved TIFFTAG_MINSAMPLEVALUE=0 TIFFTAG_MAXSAMPLEVALUE=255 AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -100.3751653, 29.6249018) ( 100d22'30.60W, 29d37'29.65N) Lower Left ( -100.3751653, 29.4997420) ( 100d22'30.60W, 29d29'59.07N) Upper Right ( -100.2498639, 29.6249018) ( 100d14'59.51W, 29d37'29.65N) Lower Right ( -100.2498639, 29.4997420) ( 100d14'59.51W, 29d29'59.07N) Center ( -100.3125146, 29.5623219) ( 100d18'45.05W, 29d33'44.36N) Band 1 Block=512x512 Type=Byte, ColorInterp=Red Band 2 Block=512x512 Type=Byte, ColorInterp=Green Band 3 Block=512x512 Type=Byte, ColorInterp=Blue *From:* Chaitanya kumar CH [mailto:chaitanya...@gmail.com] *Sent:* Monday, February 21, 2011 4:19 PM *To:* Jay Jennings *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] Downsample with averaging? Jay, Can you provide a sample file that gives this error? On Tue, Feb 22, 2011 at 1:56 AM, Jay Jennings jennings@geoeye.com wrote: Hello list, (using GDAL 1.8.0) I am trying to create a 32:1 down-sampled overview of a GeoTiff satellite image. My first thought was gdal_translate, with args such as “-outsize 3.125% 3.125%”… which produces surprisingly high quality given the absence of a resampling option. However I’m looking for a downsampling scheme that creates a result pixel by averaging all relevant source pixels (I know, for 32:1 downsample, that means 1024 source pixels for each result pixel !) with the hope of an output that is not “speckled” or “grainy” insofar as possible. I also looked at gdaladdo, which does have the “-r average” resampling option… the guidance at gdal.org seems to suggest that it can produce a 32:1 GeoTIFF external overview with a command like this: gdaladdo -r average -ro X.tif 32 But that produces a surprising error message, namely: ERROR 4: `X.tif.ovr' does not exist in the file system, and is not recognised as a supported dataset name. Am I barking up the wrong tree with gdaladdo for this purpose ? Anybody have any suggestions for highest-quality down-sampling ? Thanks in advance. --Jay Jennings ___ 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
Re: [gdal-dev] Re: [Qgis-developer] Issue saving shapefiles with REAL15 values
Anita, First, let us isolate the source of this error. QGIS or GDAL/OGR. Use ogr2ogr to clip the part you did with QGIS. See the extents of the clipped shapefile using ogrinfo and use it with the ogr2ogr utility. http://www.gdal.org/ogr2ogr.html On Tue, Feb 22, 2011 at 6:07 PM, Anita Graser anitagra...@gmx.at wrote: Am 22.02.2011, 13:19 Uhr, schrieb Paolo Cavallini cavall...@faunalia.it: Il giorno mar, 22/02/2011 alle 13.16 +0100, Anita Graser ha scritto: I have a shapefile containing fields of type REAL15. I'd like to cut an area of interest out of this shapefile using QGIS Save as ... function. The resulting shapefile still has fields of type REAL15 but the contained values are botched, e.g. 1040603695 becomes -2147483648. I'm uncertain whether the problem lies with GDAL or QGIS' use of GDAL. Which versions? OSGeo4W r15203 with GDAL 1.8.0 It would be great if this problem could be resolved. Unfortunately, I can't share the original (commercial) dataset. You can extract just one record, and share that one. How? If I use QGIS, the values will be broken. Best wishes, Anita ___ 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
Re: [gdal-dev] Re: [Qgis-developer] Issue saving shapefiles with REAL15 values
Anita, Is it possible to send a small sample data to my email for testing? Doesn't matter if the ID field values are wrong. On Tue, Feb 22, 2011 at 9:21 PM, Anita Graser anitagra...@gmx.at wrote: Hi, I used the following ogr2ogr command: ogr2ogr -sql select * from nw where NAME = 'Am Johannesberg' new.shp nw.shp The resulting shp contains correct geometries, but the values in ID,N,15,0 fields are broken. I guess that shows that it's a GDAL/OGR problem. Thanks, best wishes, Anita Am 22.02.2011, 16:33 Uhr, schrieb Chaitanya kumar CH chaitanya.ch@ gmail.com: Anita, First, let us isolate the source of this error. QGIS or GDAL/OGR. Use ogr2ogr to clip the part you did with QGIS. See the extents of the clipped shapefile using ogrinfo and use it with the ogr2ogr utility. http://www.gdal.org/ogr2ogr.html ___ 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
Re: [gdal-dev] Mosaicking Orthos
Zoltan, The creation of 0394w.tif failed. Does the process have write permission on directory? I note that you did not specify the -of option for nearblack. In it's absence, nearblack creates the output file in Erdas Imagine format. On Sun, Feb 20, 2011 at 10:50 PM, Zoltan Szecsei zolt...@geograph.co.zawrote: Hi Chaitanya ( all), I tried your nearblack comment, and got: nearblack -white -o 0394w.tif 0394.tif Warning 1: TIFFFetchNormalTag:ASCII value for tag ImageDescription does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag ImageDescription does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag Software contains null byte in value; value incorrectly truncated during reading due to implementation limitati ERROR 4: Creation of file 0394w.tif failed. I think I am having trouble understanding the setting/using of nodata values. I have now also downloaded and compiled gdal 1.8.0 (but nearblack remained on v1.7.3) on ubuntu 10.04 LTS, and recreated my vrt, to no improvement. To recap: I have 179 3*8bit RGB band aerial images that have been orthorectified. The resulting skewness in the images has created white slivers in the corners, and I am presuming that these white slivers are recognised as nodata. (My first mistake?) I use the following to create a vrt: gdalbuildvrt -addalpha -hidenodata -srcnodata 255 255 255 -vrtnodata 0 0 0 -input_file_list files 177_untiled_orthos_nodata_180.vrt Thinking that the above will tell gdalbuildvrt that, for the input orthos, white should be recognised as 'nodata', and in the VRT, those white pixels should be converted to black, as nodata. Well, as you've guessed, it didn't happen this way, and I still have the white bits after mosaicking my VRT thus: gdal_translate -projwin -16000 -3520650 -13000 -3525650 177_untiled_orthos_nodata.vrt try1.tif I tried re-running gdalbuildvrt specifying -vrtnodata 255 255 255 (to match the input ortho files) and the outside border of my vrt turned white, but the slivers between the mosaicked orthos were still present. Please can someone show me the correct way to address this problem. I have included gdalinfo results for both an individual ortho, and for the vrt itself. Thanks regards, Zoltan ** *GDALINFO on indicidual ORTHO* geograph@gs0:~/vrt_177$ *gdalinfo --version* GDAL 1.8.0, released 2011/01/12 geograph@gs0:~/vrt_177$ geograph@gs0:~/vrt_177$ geograph@gs0:~/vrt_177$ geograph@gs0:~/vrt_177$ *gdalinfo /mnt/geo_lvm0/ngi_jobs/orthos_8bit/NGI_177_untiled_orthos/0003.tif* Warning 1: TIFFFetchNormalTag:ASCII value for tag ImageDescription does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag Software contains null byte in value; value incorrectly truncated during reading due to implementation limitations Mask Flags: PER_DATASET ALPHA Band 4 Block=128x128 Type=Byte, ColorInterp=Alpha geograph@gs0:~/vrt_177$ *** On 2011-02-16 19:39, Chaitanya kumar CH wrote: Zoltan, Have you tried the nearblack GDAL utility on the original 176 images? http://www.gdal.org/nearblack.html On Wed, Feb 16, 2011 at 5:25 PM, Zoltan Szecsei zolt...@geograph.co.zawrote: On 2011-02-16 12:20, Zoltan Szecsei wrote: Hi All, I've built a vrt with 176 images. I now need to mosaic this whole area into roughly 5 x 5 ortho images. How can I force the white edges into background of the overlapping orthos? I'm a little cautious of simply (finding a way to) making white transparent as it is only the white on the edges that need to be backgrounded. Hi again, Since the above post, I have tried different ways to set nodata, but to no avail - I still get the white edges: (see jpeg sent with my original post) gdalbuildvrt -addalpha -hidenodata -input_file_list files 177_untiled_orthos_nodata.vrt gdalbuildvrt -srcnodata 0 0 0 -addalpha -hidenodata -input_file_list files 177_untiled_orthos_blk.vrt gdalbuildvrt -srcnodata 255 255 255 -addalpha -hidenodata -input_file_list files 177_untiled_orthos_white.vrt How should I be masking out the nodata (or even white pixels) so that when I mosaic a bunch of tiffs together, I dont get the white stripes in the resulting image? Using GDAL 1.7.3, released 2010/11/10 on Ubuntu 10.04 Viewing with Quantum GIS - 1.6.0-Trunk on Ubuntu 10.04 (same box). ...but running the whole lot in xterms with Xming putty from my WinVista box. Regards, Zoltan -- === 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.35S 18°28'5.62E Tel: +27-21-7884897 Mobile: +27-83-6004028 Fax: +27-86-6115323 www.geograph.co.za
Re: [gdal-dev] Zero Pixel Values. Continuation...
Ramesh, Instead of 'pasting' a part of your code, could you attach your entire .cpp file along with the main() function and stuff? On Tue, Feb 22, 2011 at 9:49 AM, user gdal userofg...@gmail.com wrote: Dear Sir, Thanks a lot for reply about zero pixel values when I attempted to write into an output image file. Though I pasted the code I wrote for programmatically 'copying' the image, once again I am pasting the same below. Q. One thing I notice about your code is that you only appear to read and write the first scanline of the image. Is this intentional? Ans. No. I want to copy the whole image. Please see the function ReadNWrite(...). Am I reading only the first scanline? Oh my God! In the syntax of the function RasterIO of GDALDataset, it seems there is no parameter with scanline number. Can you please solve the problem for me. Before call of the function ReadNWrite, I wanted to 'prepare' the output image (see the function CreateOutputImg). The problem should be in the functions CreateOutputImg, ReadNWrite, Read and Write. Another worry is projection information, which I wanted to put in CreateOutputImg. I am sure there are some serious shortcomings in my attempt. How to set that correctly? Q. For the purposes of asking a question of the list it would be helpful if you could boil your program down to a minimum example including all the essentials. It will require extra work on your part, but will make it much easier for the many members of the list who might want to skim through the code to see if they have suggestions. Ans. I have made some more effort to make my difficulty more specific. Now I request all of you to kindly solve it and if possible, post in the website. Thanks once again. Yours sincerely, Ramesh The class's destructor closes the output dataset (outds) using GDALClose. Ramesh - ___ 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
Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
Derrick, I tested your sample data on ubuntu with gdal trunk and 1.8 versions. Check if you are linking to the right gdal library. Just run the command gdalinfo --version. Since the error is coming up only on your system, you have to help me perform the testing. Build with the --enable-debug configure option and run the program after setting the environment variable CPL_DEBUG to YES. If that doesn't show any info before segfaulting, run it under the gdb debugger. On Mon, Feb 21, 2011 at 9:28 AM, derrick.w...@csiro.au wrote: Hi Chaitanya I have downloaded and unpacked the tar.gz and compiled it in on a standard Debian box. Please find attached the config log for the installation. I have downloaded a precompiled windows executable (1.8.0) for comparison, and I am not having any issues with it though. Am I missing an include or something during my build/compile process? Please assist. Thanks. *Derrick Wong** * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* *From:* Chaitanya kumar CH [mailto:chaitanya...@gmail.com] *Sent:* Friday, 18 February 2011 7:56 PM *To:* Wong, Derrick (CESRE, Kensington) *Cc:* ksshan...@gmail.com; gdal-dev@lists.osgeo.org; Fraser, Ryan (CESRE, Kensington) *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0 Derrick, I was able to run gdalinfo and gdal_translate on your sample dataset without any error. Can you provide some more details like your platform and the settings you used to compile GDAL? On Fri, Feb 18, 2011 at 9:57 AM, derrick.w...@csiro.au wrote: Hi Kyle, Thanks for the reply. Gdalinfo on 1.8.0 gives me the same “Segmentation fault” error. Attached is the dump using 1.7.3 I have included a sample file and you can download it here: ftp://ftp.csiro.au/DerrickWong/sample/sample.nc *Derrick Wong * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* *From:* Kyle Shannon [mailto:ksshan...@gmail.com] *Sent:* Friday, 18 February 2011 11:32 AM *To:* Wong, Derrick (CESRE, Kensington) *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0 Derrick, Can you file a ticket and attach a sample data set? Do you have any other details? A gdalinfo of the netcdf file and another of one of the variables would be great. Thanks. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 19:54, derrick.w...@csiro.au wrote: Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting “Segmentation fault” errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. *Derrick Wong * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify
Re: [gdal-dev] Re: GCP list projection
Vadim, (0,1,0,0,0,1) is the default transform and will be returned even in case of an error. On Fri, Feb 18, 2011 at 2:09 PM, Vadim Shlyakhov vadp.d...@gmail.comwrote: Frank Warmerdam warmerdam at pobox.com writes: In theory it could make sense to have a dataset with a dataset level SRS and geotransform, and also GCPs with a different SRS. In some cases the GCPs are in a particular SRS (say lat/long) just because it is a convenient coordinate system to collect the GCPs, not because it is representative of the geometry of the image. Thanks Frank, That was actually my understanding. BSB and Ozi have their GCPs in long/lat, so I thought that a feature for such a case. So, if you have GCP SRS, you don't need SRS set at the dataset level, do you? BTW I've noticed if a dataset doesn't have a geotransform, then ds.GetGeoTransform() returns (0.0, 1.0, 0.0, 0.0, 0.0, 1.0). Is that a feature or a bug? ___ 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
Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
Derrick, I was able to run gdalinfo and gdal_translate on your sample dataset without any error. Can you provide some more details like your platform and the settings you used to compile GDAL? On Fri, Feb 18, 2011 at 9:57 AM, derrick.w...@csiro.au wrote: Hi Kyle, Thanks for the reply. Gdalinfo on 1.8.0 gives me the same “Segmentation fault” error. Attached is the dump using 1.7.3 I have included a sample file and you can download it here: ftp://ftp.csiro.au/DerrickWong/sample/sample.nc *Derrick Wong** * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* *From:* Kyle Shannon [mailto:ksshan...@gmail.com] *Sent:* Friday, 18 February 2011 11:32 AM *To:* Wong, Derrick (CESRE, Kensington) *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0 Derrick, Can you file a ticket and attach a sample data set? Do you have any other details? A gdalinfo of the netcdf file and another of one of the variables would be great. Thanks. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 19:54, derrick.w...@csiro.au wrote: Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting “Segmentation fault” errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. *Derrick Wong * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to reproject a geotiff using osgeo gdal python bindings
Bill, You can use the -tr option in gdalwarp utility[0] to set the resolution of the target raster. You can look at it's code[1]. [0] http://www.gdal.org/gdalwarp.html [1] http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalwarp.cpp On Fri, Feb 18, 2011 at 3:51 AM, William Hudspeth bhudsp...@edac.unm.eduwrote: Hello, I am trying to project a raster in lambert conformal conic projection to geographic dd wgs84. The cell resolution changes between the two, so I don't know what the final grid size is in the geographic raster. Does anyone have any complete examples of opening a geotiff in lambert, and writing the complete dataset out to geographic? Thanks Bill ___ 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
Re: [gdal-dev] open shapefile from server
Rashad, Read the documentation on VSIInstallCurlFileHandler() in the cpl_vsi.h file documentation. http://www.gdal.org/cpl__vsi_8h.html On Fri, Feb 18, 2011 at 6:38 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How can I open a shapefile and read the coordinates from it without downloading into client. just as mywebsite.com/shapefiles/myshape.shp and pass this to function as poDS = OGRSFDriverRegistrar::Open( http://mywebsite.com/shapefiles/myshape.shp;, FALSE ); Is it possible in gdal/ogr? I dont know if its an offtopic. If yes please ignore it. -- Thanks Regards Rashad ___ 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
Re: [gdal-dev] Mosaicking Orthos
Zoltan, Have you tried the nearblack GDAL utility on the original 176 images? http://www.gdal.org/nearblack.html On Wed, Feb 16, 2011 at 5:25 PM, Zoltan Szecsei zolt...@geograph.co.zawrote: On 2011-02-16 12:20, Zoltan Szecsei wrote: Hi All, I've built a vrt with 176 images. I now need to mosaic this whole area into roughly 5 x 5 ortho images. How can I force the white edges into background of the overlapping orthos? I'm a little cautious of simply (finding a way to) making white transparent as it is only the white on the edges that need to be backgrounded. Hi again, Since the above post, I have tried different ways to set nodata, but to no avail - I still get the white edges: (see jpeg sent with my original post) gdalbuildvrt -addalpha -hidenodata -input_file_list files 177_untiled_orthos_nodata.vrt gdalbuildvrt -srcnodata 0 0 0 -addalpha -hidenodata -input_file_list files 177_untiled_orthos_blk.vrt gdalbuildvrt -srcnodata 255 255 255 -addalpha -hidenodata -input_file_list files 177_untiled_orthos_white.vrt How should I be masking out the nodata (or even white pixels) so that when I mosaic a bunch of tiffs together, I dont get the white stripes in the resulting image? Using GDAL 1.7.3, released 2010/11/10 on Ubuntu 10.04 Viewing with Quantum GIS - 1.6.0-Trunk on Ubuntu 10.04 (same box). ...but running the whole lot in xterms with Xming putty from my WinVista box. Regards, Zoltan -- === 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.35S 18°28'5.62E 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: 1435/3446 - Release Date: 02/15/11 ___ 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
Re: [gdal-dev] convert shapefile to raster
Rashad, This would probably give you a Float64 type bands with the pixels valued at 255.0 Try setting the band type to Byte using the -ot option. On Sun, Feb 13, 2011 at 4:11 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How to convert shapefile to a raster image using gdal I tried gdal_rasterize -burn 255 -burn 0 -burn 0 -ts 100 100 -l ernakulam ernakulam.shp ekm.tif gdal_rasterize -A DIST -ts 100 100 -l ernakulam ernakulam.shp ekm.tif gdal_rasterize -A AREA -ts 100 100 -l ernakulam ernakulam.shp ekm.tif but still no output ogrinfo -al -so ernakulam.shp INFO: Open of `ernakulam.shp' using driver `ESRI Shapefile' successful. Layer name: ernakulam Geometry: Polygon Feature Count: 16 Extent: (76.168263, 9.788524) - (76.840498, 10.301794) Layer SRS WKT: (unknown) AREA: Real (20.15) PERIMETER: Real (20.15) INDIA_: Real (11.0) INDIA_ID: Real (11.0) STATE: String (20.0) DIST: String (20.0) TALUK: String (20.0) CENTROID_Y: Real (20.15) CENTROID_X: Real (20.15) i selected AREA -- Thanks Regards Rashad ___ 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
Re: [gdal-dev] gdal convert shape to raster
Rashad, Look at the examples in it's doc page. http://www.gdal.org/gdal_rasterize.html On Sat, Feb 12, 2011 at 8:22 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How to convert shapefile to raster using gdal or gdal_rasterize -- Thanks Regards Rashad ___ 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
Re: [gdal-dev] gdal convert shape to raster
Rashad, You did not send me raster you are writing to. If you are creating the raster with gdal_rasterize, remove the -b options. On Sat, Feb 12, 2011 at 8:47 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: gdal_rasterize -b 1 -b 2 -b 3 -burn 255 -burn 0 -burn 0 -l ernakulam data/ernakulam.shp gtopo30_shade.tif On Sat, Feb 12, 2011 at 8:30 PM, Chaitanya kumar CH chaitanya.ch@ gmail.com wrote: Send me a small shapefile you used along with the command you used on it. On Sat, Feb 12, 2011 at 8:27 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: i tried the examples but no output On Sat, Feb 12, 2011 at 8:26 PM, Chaitanya kumar CH chaitanya.ch@ gmail.com wrote: Rashad, Look at the examples in it's doc page. http://www.gdal.org/gdal_rasterize.html On Sat, Feb 12, 2011 at 8:22 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How to convert shapefile to raster using gdal or gdal_rasterize -- Thanks Regards Rashad ___ 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 -- Thanks Regards Rashad -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E -- Thanks Regards Rashad -- 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
Re: [gdal-dev] failing in making transparency
ahmet, One likely reason for the dark image is that your viewer is assuming a range of 0-65535 for the alpha values. Check the histogram of the output image. In the histogram for the second band, there should be a bunch of 0 valued pixels and 255 valued pixels. Please provide a small sample image if the problem persists. 2011/2/6 ahmet temiz ahmettemi...@gmail.com hello I want to make nodata areas transparent. here is what I did: 1. $gdalinfo -mm -noct duy_cat1.tif | grep -i 'nodata' NoData Value=65535 2. gdalwarp -srcnodata 65535 -dstalpha duy_cat1.tif duy_cat14.tif But, duy_cat14.tif looks full black here is info of outputfile(duy_cat14.tif): ~~ Driver: GTiff/GeoTIFF Files: duy_cat14.tif Size is 4677, 5527 Coordinate System is: PROJCS[UTM Zone 36, Northern Hemisphere, GEOGCS[, DATUM[unknown, SPHEROID[unnamed,6378388,297.0005]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,33], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (437192.936421879974660,4649982.939232329837978) Pixel Size = (20.004039786776190,-20.004039786776190) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 437192.936, 4649982.939) ( 32d14'30.03E, 41d59'55.01N) Lower Left ( 437192.936, 4539420.611) ( 32d15'11.54E, 41d 0'10.24N) Upper Right ( 530751.831, 4649982.939) ( 33d22'16.70E, 42d 0'1.87N) Lower Right ( 530751.831, 4539420.611) ( 33d21'56.38E, 41d 0'16.87N) Center ( 483972.383, 4594701.775) ( 32d48'28.68E, 41d30'10.99N) Band 1 Block=4677x1 Type=UInt16, ColorInterp=Palette Computed Min/Max=0.000,65449.000 Color Table (RGB with 65536 entries) Band 2 Block=4677x1 Type=UInt16, ColorInterp=Alpha Computed Min/Max=0.000,255.000 ~~~ could you tell me where the problem is ? regards -- Ahmet Temiz Jeoloji Müh. Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 ___ 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
Re: [gdal-dev] Geometric Correction and Resampling
Ramesh, Look at the GDAL command line utility list at http://www.gdal.org/gdal_utilities.html and decide on the functionality you want out of them. You can use their source code at http://trac.osgeo.org/gdal/browser/trunk/gdal/apps . On Tue, Feb 1, 2011 at 5:53 PM, user gdal userofg...@gmail.com wrote: Dear all, I need, using GDAL, a Geometric Correction and Resampling program for ERDAS img in C++/MFC. Can you please help me. If you don't have the source code, would you please mail me the detailed algorithm(s) to accomplish the task. With many thanks, Ramesh ___ 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
Re: [gdal-dev] Bogus gml:Face interpretation
strk, You are right. The sequence of the elements _can_ be specified explicitly using a sequence tag. Without that it will just be a guess work, especially if any of the rings have a common point. On Mon, Jan 31, 2011 at 3:38 PM, strk s...@keybit.net wrote: On Sun, Jan 30, 2011 at 01:51:08PM +0100, strk wrote: On Sun, Jan 30, 2011 at 01:24:08PM +0100, Even Rouault wrote: So we should implement detection of cycles to emit as many rings as necessary. Yes. This for each face. To add some more about the topic, I'm not sure the directedEdge tags should be ordered, so when detecting cycles the code might be better not rely on any specific ordering. Does anyone have evidence of requested ordering ? --Strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- 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
Re: [gdal-dev] Bogus gml:Face interpretation
strk, Thank you very much for pointing out the errors. I could blame it on the lack of enough sample data but that's just laziness. I should have read the specifications more throughly. I see your first point but I need to dig deeper for the second. Please file a ticket at http://trac.osgeo.org/gdal/newticket I would be grateful if you can provide some sample data. On Sun, Jan 30, 2011 at 4:39 PM, strk s...@keybit.net wrote: Hello, I'm writing GML output routines for Topologically-defined features in PostGIS and found what I think is a bug in how ogr interprets the gml:Face tag contents. Take this topology: n1 +-e1---. | | | F1 | | n3 | | ,-e2--+| | | || | | F2 || | | || | +--e7-'| | n4| | | `e2+ n2 It occurs to me that face F1 above is bounded by all edges, not just the exterior ones, so I'd put _all_ edges inside one gml:Face tag: Face id=F1 directedEdge orientation=- id=e1 / directedEdge orientation=- id=e2 / directedEdge id=e3 / directedEdge id=e4 / /Face This is expressed clearly in the OGC 03-105r1 document (GML-3.1.1, 2004) and 07-036 (GML-3.2.1, 2007) The non-dangling edges in the boundary of a face comprise one or more topological rings. Each such ring consists of directedEdges connected in a cycle, and is oriented with the face on its left. Now, when encountering such a GML snippet, ogr2ogr (GML driver) insists in considering all edges as being part of the same ring thus producing an invalid polygon as a result. It basically interprets a gml:Face tag as if it was a ring, which I belive is wrong. Another example of such invalid intepretation follows: +--+--+ | F1 | F2 | +--+--+ A surface/polygon formed by the two faces above (F1,F2) should be represented as: TopoSurface id=P1 directedFace Face id=F1/ /directedFace directedFace Face id=F2/ /directedFace /TopoSurface Whereas the resulting feature geometry should be a single-ring polygon: the topological _union_ of the two faces (I haven't tested this but I belive GDAL would get this wrong as well). On the PostGIS side, I've so far implemented the invalid representation for the sake of interoperability with GDAL, but being a new implementation I'd rather get it right from the start... Note that using the invalid (but GDAL-compatible) representation also has the negative effect of making it _impossible_ to map PostGIS(ISO) topologies to GML in a lossless way (PostGIS topology faces would have no direct corrispondence to gml:Face tags). I hope, with this mail, to get some feedback from the authors of the GML reading capabilities of GDAL to plan actions towards interoperability of the two systems and adherence to the standard (if possible). --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ 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
Re: [gdal-dev] OGR GetExtent()
Rashad, There is an example of usage of GetExtent() in the code for ogrinfo utility. http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/ogrinfo.cpp#L379 On Fri, Jan 28, 2011 at 6:35 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How to get the extent of an ogr data (shapefile). I need to read the xMin, yMin, xMax,yMax how to do that -- Rashad ___ 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
Re: [gdal-dev] Can I use ogr2ogr to postgresql with security?
Mike, OGR's postgresql/postgis driver makes the connection using PQconnectdb() method from the libpq library. You can set the option 'sslmode' to 'require', 'verify-ca' or 'verify-full' for a secure connection. Look for the documentation of PQconnectdb() for further details. On Fri, Jan 28, 2011 at 12:13 AM, Mike Axelrod mike.axel...@pictometry.comwrote: Does ogr2ogr (and ogrinfo) natively support secure connections to postgresql? I need to run ogrinfo and ogr2ogr where the target is a postgresql server elsewhere on the network (in a different domain) and secure the communication. Mike Mike Axelrod, Software Engineer Pictometry International Corp. Suite A, 100 Town Centre Drive, Rochester, NY 14623 Phone: 585-775-7711 E-mail: mike.axel...@pictometry.com Web: http://www.Pictometry.com/http://www.pictometry.com/ NOTICE: This message is covered by the Electronic Communications Privacy Act, Title 18, United States Code, Sections 2510-2521. This e-mail and any attached files are the exclusive property of Pictometry International Corp., are deemed privileged and confidential, and are intended solely for the use of the individual(s) or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or believe that you have received this message in error, please delete this e-mail and any attachments and notify the sender immediately. Any other use, re-creation, dissemination, forwarding or copying of this e-mail is strictly prohibited and may be unlawful. ___ 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
Re: [gdal-dev] Can I use ogr2ogr to postgresql with security?
Mike, To use SSL mode with OGR, your pqlib should be built with SSL support. On Fri, Jan 28, 2011 at 2:09 AM, Mike Axelrod mike.axel...@pictometry.comwrote: So it seems the build I’m using may not support ssl, I run ogrinfo with sslmode=prefer I connect ok, but when I set sslmode=require I get this error: --- Details... --- call to ogrinfo failed: ERROR 1: PQconnectdb failed. sslmode value require invalid when SSL support is not compiled in -- *From:* gdal-dev-boun...@lists.osgeo.org [mailto: gdal-dev-boun...@lists.osgeo.org] *On Behalf Of *Mike Axelrod *Sent:* Thursday, January 27, 2011 3:21 PM *To:* Chaitanya kumar CH *Cc:* gdal-dev@lists.osgeo.org *Subject:* RE: [gdal-dev] Can I use ogr2ogr to postgresql with security? Thank you, I’ll be trying that out as soon as I get our postgresql server configured with ssl. Do you know if the postgresql public key is required on the client side? I see references to a ~/.postgresql/postgresql.keybeing available to the client. But I’m not clear if this is required or an option. BTW I’m currently using the win32 SDK version of ogr2ogr that is distributed here = http://vbkto.dyndns.org/sdk/, I’m hoping these builds support SSL. Can anybody confirm? Mike -- *From:* Chaitanya kumar CH [mailto:chaitanya...@gmail.com] *Sent:* Thursday, January 27, 2011 2:56 PM *To:* Mike Axelrod *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] Can I use ogr2ogr to postgresql with security? Mike, OGR's postgresql/postgis driver makes the connection using PQconnectdb() method from the libpq library. You can set the option 'sslmode' to 'require', 'verify-ca' or 'verify-full' for a secure connection. Look for the documentation of PQconnectdb() for further details. On Fri, Jan 28, 2011 at 12:13 AM, Mike Axelrod mike.axel...@pictometry.com wrote: Does ogr2ogr (and ogrinfo) natively support secure connections to postgresql? I need to run ogrinfo and ogr2ogr where the target is a postgresql server elsewhere on the network (in a different domain) and secure the communication. Mike Mike Axelrod, Software Engineer Pictometry International Corp. Suite A, 100 Town Centre Drive, Rochester, NY 14623 Phone: 585-775-7711 E-mail: mike.axel...@pictometry.com Web: http://www.Pictometry.com/http://www.pictometry.com/ NOTICE: This message is covered by the Electronic Communications Privacy Act, Title 18, United States Code, Sections 2510-2521. This e-mail and any attached files are the exclusive property of Pictometry International Corp., are deemed privileged and confidential, and are intended solely for the use of the individual(s) or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or believe that you have received this message in error, please delete this e-mail and any attachments and notify the sender immediately. Any other use, re-creation, dissemination, forwarding or copying of this e-mail is strictly prohibited and may be unlawful. ___ 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 NOTICE: This message is covered by the Electronic Communications Privacy Act, Title 18, United States Code, Sections 2510-2521. This e-mail and any attached files are the exclusive property of Pictometry International Corp., are deemed privileged and confidential, and are intended solely for the use of the individual(s) or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or believe that you have received this message in error, please delete this e-mail and any attachments and notify the sender immediately. Any other use, re-creation, dissemination, forwarding or copying of this e-mail is strictly prohibited and may be unlawful. NOTICE: This message is covered by the Electronic Communications Privacy Act, Title 18, United States Code, Sections 2510-2521. This e-mail and any attached files are the exclusive property of Pictometry International Corp., are deemed privileged and confidential, and are intended solely for the use of the individual(s) or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or believe that you have received this message in error, please delete this e-mail and any attachments and notify the sender immediately. Any other use, re-creation, dissemination, forwarding or copying of this e-mail is strictly prohibited and may be unlawful. -- 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
Re: [gdal-dev] gdal_grid - cannot get interpolation to work
Werner, You swapped the X and Y extents in the command. On Thu, Jan 27, 2011 at 11:14 PM, Werner Reiche w.rei...@hotmail.comwrote: I'm trying to use gdal_grid to generate a .tiff file from a .csv file. The problem I am encountering is that output file always contains 'no-data' values. The command I am using is: gdal_grid -txe -51.428009 -43.153992 -tye 46.112598 51.347198 -outsize 1024 796 \ -a nearest:radius1=10.0:radius2=10.0:angle=0.0:nodata=0.0 \ -l rs2_file_1 -l rs2_file_2 -l rs2_file_3 \ -of GTiff -ot Byte rs2_file.vrt test.tiff I have also tried the following interpolation parameters: # Results in all black # -a nearest:radius1=1.0:radius2=1.0:angle=0.0:nodata=0.0 \ # -a average:radius1=1.0:radius2=1.0:angle=0.0:min_points=1:nodata=0.0 \ # -a invdist:radius1=1.0:radius2=1.0:angle=0.0:max_points=1:min_points=1:nodata=0.0 \ # Results in all one shade of grey (average of entire image) # -a invdist:radius1=0.0:radius2=0.0:angle=0.0:max_points=10:min_points=1:nodata=0.0 \ The .vrt and csv file used are shown below. rs2_file.vrt :: OGRVRTDataSource OGRVRTLayer name=rs2_file_1 SrcDataSourcers2_file_1.csv/SrcDataSource GeometryTypewkbPoint25D/GeometryType GeometryField encoding=PointFromColumns x=lon y=lat z=red/ /OGRVRTLayer OGRVRTLayer name=rs2_file_2 SrcDataSourcers2_file_2.csv/SrcDataSource GeometryTypewkbPoint25D/GeometryType GeometryField encoding=PointFromColumns x=lon y=lat z=green/ /OGRVRTLayer OGRVRTLayer name=rs2_file_3 SrcDataSourcers2_file_3.csv/SrcDataSource GeometryTypewkbPoint25D/GeometryType GeometryField encoding=PointFromColumns x=lon y=lat z=blue/ /OGRVRTLayer /OGRVRTDataSource rs2_file.vrt (partial) :: lat,lon,red,green,blue -51.428009,50.522499,0,0,143 -50.049011,50.720699,0,0,143 -48.660004,50.902401,0,159,255 -47.260010,51.067501,0,239,255 -45.851013,51.215900,255,255,15 -44.433014,51.347198,255,191,0 -50.433014,50.657600,255,255,0 -49.046997,50.844200,255,223,0 -47.649994,51.014301,255,159,0 -46.243988,51.167599,255,191,0 -44.829010,51.303799,255,255,15 -50.816010,50.593800,255,255,0 -49.433014,50.784698,255,175,0 -48.040009,50.959202,255,239,0 -46.635986,51.117100,255,191,0 -45.222992,51.257999,255,223,0 -51.197998,50.528301,255,175,0 -49.819000,50.724098,255,191,0 -48.428009,50.903500,255,223,0 -47.028015,51.066299,255,207,0 -45.618011,51.211800,255,255,0 -44.199005,51.340199,255,255,0 -50.203003,50.661999,223,255,47 -48.816010,50.845798,255,223,0 -47.417999,51.013000,255,191,0 -46.010986,51.163502,255,207,0 -44.595001,51.297001,255,255,15 -50.585999,50.598900,255,191,0 -49.201996,50.787601,255,255,0 ___ 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
Re: [gdal-dev] confused about using gdal_rasterize
Ahmet, Transparency can be easily set using the alpha channel in RGBA images. Use the -init option to set the background to transparent. Make sure this is equal to the value set as nodata. You can set the nodata value using the -a_nodata option. Make the rasterized areas visible by setting the alpha channel to 255 (or the maximum value of that data type). If you are burning the values using an attribute or the Z values, you will have to create the alpha channel as a separate image and combine the images. 2011/1/26 ahmet temiz ahmettemi...@gmail.com hello I am confused about using gdal_rasterize I want to rasterize a geological map (vector polygons) and having one attributes and making nodata areas as transparent. how can I do that ? regards -- Ahmet Temiz Jeoloji Müh. Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 ___ 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
Re: [gdal-dev] append features to shapefile
Rashad, Refer to the OGR API tutorial, especially the topic Writing to OGR. You can add features to already existing data source, including shapefiles. On Sat, Jan 22, 2011 at 12:31 AM, Mohammed Rashad mohammedrasha...@gmail.com wrote: How can I add features to a shapefile using OGR? -- Rashad ___ 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
Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff
Anna, Check a couple of GCPs to rule out bad data. If they are OK, file a ticket at http://trac.osgeo.org/gdal/newticket On Wed, Jan 19, 2011 at 1:23 PM, anna auge annaa...@web.de wrote: So it is a problem with gdalwarp and the GCPs ín the GeoTiff. Do you have any hints how to go on with this problem? Cheers, Anna -- *Von:* Nikolaos Hatzopoulos nhat...@gmail.com *Gesendet:* 19.01.2011 01:33:43 *An:* anna auge annaa...@web.de *Betreff:* Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff You are right, I notice that there isn't any difference from the band_1.tiff and band_1_warp.tiff --Nikos Hatzopoulos On Mon, Jan 17, 2011 at 8:15 AM, anna auge annaa...@web.de wrote: Hi all, I am trying to convert modis level 1B data (type SWATH) to geotiff following these steps. 1) Examining the HDF gdalinfo d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf gdalinfo HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB 2) Extracting the 1. band of the subdataset MODIS_SWATH_Type_L1B:EV_1KM_RefSB gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB d:\modis\1b\band_1.tiff 4) Warping the image to WGS84 gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:\modis\1b\band_1_warp.tiff The example dataset, which i am using, can be downloaded here ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf And now to my problem: I get always an certain shift ( http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which is avoided if i am using the Georeference MODIS option in ENVI ( http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/). I also tried a few workarounds, f.g. http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but nothing worked properly. As far as I understand gdal supports Modis L1B SWATH, so what I am doing wrong? Any help is appreciated. Regards Anna P.S. I am using FWTools 2.4.7 on Windows WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! *http://produkte.web.de/go/DSL_Doppel_Flatrate/2*http://produkte.web.de/go/DSL_Doppel_Flatrate/2 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: *http://produkte.web.de/go/webdefreephone*http://produkte.web.de/go/webdefreephone ___ 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
Re: [gdal-dev] set dbf header date to current date on modification
Dave, Can you file an enhancement ticket and attach the patch to it? ( http://trac.osgeo.org/gdal/newticket) On Wed, Jan 19, 2011 at 11:12 PM, Dave Fuhry dfu...@gmail.com wrote: Patch to ogr/ogrsf_frmts/shape/dbfopen.c attached, which sets the dbf header's date to the current date on modification. Old code had the dbf header's date hardcoded to 07/26/95. Tested on Linux. Hope it can make its way into OGR. -Dave ___ 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
Re: [gdal-dev] Problem with ogrinfo and KML files
Massimo, Check if your configure script recognised the expat library. This is what I got for ogrinfo -al -so a.kml: Had to open data source read-only. INFO: Open of `a.kml' using driver `KML' successful. Layer name: Paths Geometry: 3D Line String Feature Count: 1 Extent: (-112.265697, 36.079550) - (-112.254928, 36.086496) 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) On Tue, Jan 18, 2011 at 7:15 PM, massimo costantini massimo.costant...@gmail.com wrote: KML is in the list of supported formats. the error is: Unable to open datasource `comuni2001.kml' with the following drivers. ... - KML ... i tryed on this: ?xml version=1.0 encoding=UTF-8? kml xmlns=http://www.opengis.net/kml/2.2; Document namePaths/name /LineString /Placemark /Document /kml and on a KML file created by ogr2ogr from a shape file On Tue, Jan 18, 2011 at 2:36 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Massimo, Do you see KML in the list of formats shown when you run the command ogrinfo --formats? What was the error message you got? Can you provide a sample file? On Tue, Jan 18, 2011 at 6:54 PM, massimo costantini massimo.costant...@gmail.com wrote: Hi, I've try to analize KML files with ogrinfo but it seems to not recognize the format. Gdal is compiled with expat support. Someone can tell me the reason and the solution for this problem? thanks Massimo Costantini ___ 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
Re: [gdal-dev] Grib2 band to Geo Tiff
James,
You can use the GDALDriver::CreateCopy() method to translate a dataset if
you don't plan to perform any reprojection during translation.
If you don't need the intermediate geotiff file, you can look at the
ogr2ogr.py [0] script to perform the reprojection and translation in one go.
[0]
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/ogr2ogr.py
On Wed, Jan 19, 2011 at 6:56 AM, manzione
james.j.manzi...@usace.army.milwrote:
Greetings and thank you for looking at my post,
I am converting a Grib2 file into a geo tiff file and then reprojecting it
in python. When I reproject the tiff file it states it is unable to
compute a transformation between pixel/line and georeferenced coordinates
for my converted tiff file because there is no affine transformation and
no
GCPs.
I ran some tests and am under the assumption that my script is not
embedding
any georefferencing information into the tiff file. Any suggestions on how
to do this? I am new to gdal and could use the help. Below is my code for
the conversion.
Thank you in advance for your advice,
-James
Script:
dataset = gdal.Open( Rpath, GA_ReadOnly )
xsize = dataset.RasterXSize
ysize = dataset.RasterYSize
pixels = xsize * ysize
num_bands = dataset.RasterCount
for band_num in range(1, num_bands + 1):
band = dataset.GetRasterBand(band_num)
meta = band.GetMetadata()
bandName = str(meta['GRIB_COMMENT'].split()[0])
tiffImagePath = str(pngPath + bandName + '.tiff')
ct = color_table(str(table))
buf = dataset.ReadRaster( 0, 0, xsize, ysize, None, None, None, [
band_num ] )
outBand = tiff.Create( tiffImagePath, xsize, ysize, 1, GDT_Byte)
if outBand is None:
sys.exit(1)
outBand.GetRasterBand(1).SetRasterColorTable(ct)
outbuf = []
for offset in range(0, pixels):
val = int(struct.unpack_from('d', buf, offset * 8)[0])
if val 255: val = 255
if val 0: val = 0
outbuf.append('%c' % val)
buffo = ''.join(outbuf)
outBand.WriteRaster( 0, 0, xsize, ysize, buffo, xsize, ysize,
GDT_Byte )
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Grib2-band-to-Geo-Tiff-tp5937919p5937919.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
--
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
Re: [gdal-dev] Importing and exporting shapefiles in mySQL with OGR
Markus, Run the ogrinfo utility on the MySQL database created from the shapefile and the original MySQL database and compare them. You should be able to build a command according to the differences. On Mon, Jan 17, 2011 at 12:55 PM, Dr. Markus Müller markus.u.muel...@zoho.com wrote: Dear listers, I am trying to get shapefiles in and out of a mySQL database using OGR. I found some example commands for importing and succeeded in doing this. But getting the syntax together to get a spatial dataset out of mySQL db seems to be over my head. Can anybody supply an example command to convert from mySQL to shape? Or is it just not possible to export geodata from mySQL into shapefiles using OGR? Thanx and best regards Markus ___ 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
Re: [gdal-dev] OGR read polygon
Rashad,
Polygons are made of one or more linear rings. A linear ring can be read
pretty much the same as a linestring.
http://www.gdal.org/ogr/classOGRGeometry.html
On Sun, Jan 16, 2011 at 12:55 PM, Mohammed Rashad
mohammedrasha...@gmail.com wrote:
but i can read points and lines directly without wkb. problem is in reading
polygon
if( poGeometry != NULL
wkbFlatten(poGeometry-getGeometryType()) == wkbLineString
)
{
OGRLineString *poPoint = (OGRLineString *) poGeometry;
for(int i=0;ipoPoint-getNumPoints();i++)
{
cout poPoint-getX(i) :: poPoint-getY(i) endl;
}
}
On Sun, Jan 16, 2011 at 12:50 PM, Chaitanya kumar CH chaitanya.ch@
gmail.com wrote:
Rashad,
Refer to http://www.opengeospatial.org/standards/sfa for the official
specification.
You can use the wkb format for more clarity, but at the cost of more
computation.
On Sun, Jan 16, 2011 at 11:56 AM, Mohammed Rashad
mohammedrasha...@gmail.com wrote:
how to read a polygon from wkbPolygon geometry type. how read its set of
points or points that make up the polygon
--
Rashad
___
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
--
Rashad
___
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
Re: [gdal-dev] OGR read polygon
Rashad, Refer to http://www.opengeospatial.org/standards/sfa for the official specification. You can use the wkb format for more clarity, but at the cost of more computation. On Sun, Jan 16, 2011 at 11:56 AM, Mohammed Rashad mohammedrasha...@gmail.com wrote: how to read a polygon from wkbPolygon geometry type. how read its set of points or points that make up the polygon -- Rashad ___ 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
Re: [gdal-dev] [ogr] Unexplained third dimension in linear ring
Alex,
But, for now, the addPoint() method does not check the dimension of the
point being passed and forces the geometry to 3D. You can overcome this by
calling the method like this:
ring-addPoint( poPoint-getX(), poPoint-getY() );
This sounds like a reasonable feature. Please file a ticket at
http://trac.osgeo.org/gdal/newticket for this. Since this change has a
potential to introduce errors in existing applications, this may not be
released before gdal1.9
On Fri, Jan 14, 2011 at 8:45 PM, Alex Hagen-Zanker ah...@cam.ac.uk wrote:
Dear all,
I am using OGR 1.7.3 to create polygons in C++.
The polygons end up as Polygon ZM instead of Polygon.
The problem seems to be that adding a 2D OGRPoint to a 2D OGRLinearRing
results in a 3D OGRLinearRing.
Can somebody explain?
Thanks, Alex
//test.cpp
#include ogr_geometry.h
#include iostream
int main()
{
OGRLinearRing* ring = ( OGRLinearRing* )
OGRGeometryFactory::createGeometry( wkbLinearRing );
OGRPoint* point = ( OGRPoint* ) OGRGeometryFactory::createGeometry(
wkbPoint );
point-setX( 1.0 );
point-setY( 1.0 );
std::cout Point before: point-getCoordinateDimension() D
std::endl;
std::cout Ring before: ring-getCoordinateDimension() D
std::endl;
ring-addPoint(point);
std::cout Ring after: ring-getCoordinateDimension() D
std::endl;
return 1;
}
Output:
Point before: 2D
Ring before: 2D
Ring after: 3D
--
Alex Hagen-Zanker
___
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
Re: [gdal-dev] [ogr] Unexplained third dimension in linear ring
Alex,
I thought of pretty much the same modification. But it could potentially
break some software. It may be added in 1.8 which is in the process of being
released but I doubt it. Please file the ticket.
On Fri, Jan 14, 2011 at 9:27 PM, Alex Hagen-Zanker ah...@cam.ac.uk wrote:
The problem seems to be that adding a 2D OGRPoint to a 2D OGRLinearRing
results in a 3D OGRLinearRing.
Sorry to bother you with this, I found it myself.
It is the following function in ogrlinestring.cpp that looks like a bug to
me:
void OGRLineString::setPoint( int iPoint, double xIn, double yIn, double
zIn )
{
if( getCoordinateDimension() == 2 )
Make3D();
if( iPoint = nPointCount )
setNumPoints( iPoint+1 );
paoPoints[iPoint].x = xIn;
paoPoints[iPoint].y = yIn;
if( zIn != 0.0 )
{
Make3D();
padfZ[iPoint] = zIn;
}
else if( getCoordinateDimension() == 3 )
{
padfZ[iPoint] = 0.0;
}
}
How about changing it to this:
void OGRLineString::setPoint( int iPoint, double xIn, double yIn, double
zIn )
{
if( iPoint = nPointCount )
setNumPoints( iPoint+1 );
paoPoints[iPoint].x = xIn;
paoPoints[iPoint].y = yIn;
if( zIn != 0.0 getCoordinateDimension() 3 )
Make3D();
if( getCoordinateDimension() == 3 )
padfZ[iPoint] = zln;
}
___
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
Re: [gdal-dev] python: read pixel from raster
Sebastian, Refer the GDAL raster API tutorial at http://www.gdal.org/gdal_tutorial.html It describes how to read a line of pixels using the ReadRaster() function in Python. You can change the arguments to read just one pixel. Look at the documentation for GDALRasterBand::RasterIO() which is essentially the same in C++. On Wed, Jan 12, 2011 at 9:27 PM, Sebastian E. Ovide sebastian.ov...@gmail.com wrote: Hi All, what would be the simpler way to read a pixel value from a raster using python ? something like pixelvalue=read(x,y) where x,y and in the raster coordinate system thanks -- Sebastian E. Ovide ___ 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
Re: [gdal-dev] Problems with passing parameters into gdalwrap in Python
James, Instead of passing the arguments as array elements, try to pass the arguments in the same string, separated by a space. http://trac.osgeo.org/gdal/browser/trunk/autotest/warp/warp.py#L481 On Thu, Jan 13, 2011 at 3:06 AM, manzione james.j.manzi...@usace.army.milwrote: Greetings All, I am a student who has been having a difficult time passing in source parameters into gdalwrap in Python, and would truly appreciate any insight that great minds like you might have on my simple problem. First off, I am attempting to reproject a Tiff image that was generated from a Grib2 rasterband by using the subprocess.call(cmd) method. My cmd statement is as follows: cmd = [gdalwarp, -t_srs, EPSG:4326, in_Src, target_Src] The in_Src parameter represents the input source file, and the target_Src parameter is an empty temporary file. I've seen (and tried) a lot of examples where instead of calling an object in the cmd line they call a string that references the name of the image file. Example: subprocess.call([gdalwarp, -t_srs, EPSG:4326, input.tif, output.tif]) However each time I attempt this technique gdalwarp returns an error message that states that it cannot locate the source file. I've tried replacing the names with path locations and yet I still get the same error returned. If someone would be kind enough to show me how to get over this issue I would be incredibly grateful! Thank you in advance, -James -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problems-with-passing-parameters-into-gdalwrap-in-Python-tp5916192p5916192.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 -- 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
Re: [gdal-dev] installing GDAL for pythonwin: can import and use gdal, but not gdaltransform
James, gdaltransform and some other command line utilities are a part of the GDAL project. It comes with the GDAL library. You should be able to use it from the commandline after setting some env variables. LD_LIBRARY_PATH should direct to the folder contain the GDAL library. GDAL_DATA to the gdal's data folder. You might also need to set the PATH variable to the gdal apps folder. OSGeo4W and FWTools packages do these things automatically. On Tue, Jan 11, 2011 at 3:06 AM, manzione james.j.manzi...@usace.army.milwrote: Greetings all, I have been able to successfully download and use GDAL 1.7.3 in PythonWin, but am not able to use gdaltransform. I understand that gdaltransform is an executable that requires additional installation steps before it can be implemented. Can someone please provide me a link to where I can download gdaltransform.exe and documentation on how to set it up I would be truly grateful. Thank in advance for your time in response! -James -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/installing-GDAL-for-pythonwin-can-import-and-use-gdal-but-not-gdaltransform-tp5908686p5908686.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 -- 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
Re: [gdal-dev] Strange printed lines for binary gdalinfo16 in Windows
António, Tamas Szekeres provided a selection of GDAL and MapServer binaries at http://vbkto.dyndns.org/sdk/ 2011/1/10 António Rocha antonio.ro...@deimos.com.pt Hi Thanks for the information. Where can I get a newer verasion of GDAL-BIn for Windows? THanks Chaitanya kumar CH wrote: António, This is not a bug. This is the debugging information printed by the grib driver. The code to print this has been commented out by Even a while ago. Try a later version of GDAL for less verbosity. __ Information from ESET NOD32 Antivirus, version of virus signature database 5772 (20110109) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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
Re: [gdal-dev] to create transparent image
Ahmet, Use the gdal_rasterize utility with a combination of the command line options -a_nodata and -init with the same value. To achieve transparency with the alpha band, give a fourth value for the -burn option and make sure to include the fourth band with the -b option. 2011/1/7 ahmet temiz ahmettemi...@gmail.com hello Could you possibly give me an idea to create a transparent image from a shape file ? how can I do that ? regards -- Ahmet Temiz Jeoloji Müh. Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 ___ 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
Re: [gdal-dev] Strange printed lines for binary gdalinfo16 in Windows
António, This is not a bug. This is the debugging information printed by the grib driver. The code to print this has been commented out by Even a while ago. Try a later version of GDAL for less verbosity. 2011/1/7 António Rocha antonio.ro...@deimos.com.pt Greetings I have just downloaded from here http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip, GDAL16 for Windows. When I do gdalinfo.exe for a GRIB file before it prints the header of the file it prints: ID 1 Class 14 Type 9 Stream 1025 Ver 0001, Octet-50 0, Octet-51 0 SectLen 52 repeatedly (nearly 1400). Is this a bug? Because I imagine that this is not an expected print... Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5766 (20110107) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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
Re: [gdal-dev] ogr shapefile viewer
Rashad, I assume you are looking for a simple viewer for non-changing shapefiles. You can use the GDAL library and the code from the gdal_rasterize utility. On Thu, Jan 6, 2011 at 11:17 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: On Thu, Jan 6, 2011 at 11:09 PM, Christopher Barker chris.bar...@noaa.gov wrote: On 1/6/11 9:19 AM, Mohammed Rashad wrote: Instead of looking for code, I'd rather suggest to sit down and think what you need. I assure you, all you need you have in OGR tutorial on gdal.org/ogr http://gdal.org/ogr website. The only thing you need more is to pass vector data/point to rendering API you want to use. yes Mateusz Loskot, i need this part. passing the vector data/point to a rendering API. It's still not clear quite what you want. If you just want to look at shape files, I'd use an off-the-shelf desktop GIS, there are lots, QGIS is pretty nice. You can also render shapefiles with mapnik or mapserver -- both are highly customizable and produce very nice output. If you want a library you can embed in your own app, and maybe customize, that's a different story. I need a c++ library to just display an OGR shapefile. i need to embed this C++ library in my application that what I need. Is that clear? If you need any further details i will provide. For Python you could use wxPython and my wx.lib.floatcanvas. It doesn't understand shape files, but with OGR reading them, it's very easy to throw points, lines and polygons on the canvas, and be able to zoom and pan around to look at them. We've also got the maproom project: https://bitbucket.org/dhelfman/maproom/overview It's a bit stalled out now, but will be revived. It is designed to be a general purpose lib and application for interactive map data viewing and manipulation. It doesn't actually support shape files at the moment, but it does use GDAL/OGR and has support for points and polygons, so not hard to write a new plugin for shape. It's also using OpenGL for speedy rendering. HTH, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Rashad ___ 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
Re: [gdal-dev] gdal_polygonize.py binding error
Xiaodong, Check again after setting the environment variable PYTHONPATH to the path to the new python bindings. On Fri, Jan 7, 2011 at 12:55 AM, Xiaodong Zhang xiaodong.zha...@und.eduwrote: Hi, I just updated the older version of gdal (1.4.2) with the latest version of gdal (1.7.3) on x64 RedHat. Got an error when using gdal_polygonize.py for a test image gdal_polyzonize.py t2.tif -f ESRI Shapefile pt2 gdal.Polyzonize() not available. You are likely using old gen bindings or an older version of the next gen bindings. I found the previous threads on this issue, but could not find an answer. Any idea? Thanks Xiaodong ___ 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
Re: [gdal-dev] Re: PCIDSK .pix feature attribute information not visible in geomatica.
Shashi, Did you try the ogr2ogr utility? On Mon, Jan 3, 2011 at 8:22 PM, shashishaw shashis...@gmail.com wrote: Hi, I'm still not able to get past this problem. Can someone suggest any pointers as to which aspect of the conversion should I look into.. Any help is appreciated. Thanks, Shashi -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/PCIDSK-pix-feature-attribute-information-not-visible-in-geomatica-tp5871388p5880861.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 -- 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
Re: [gdal-dev] Deleting fields OGR
Håvard, You can create a copy of the dataset while skipping the field. For shapefiles you won't have to mention the .shp file. Opening just the .dbf file will be enough. Similar thing can be done using ogr2ogr by specifying the -select option without the specified field's name. http://www.gdal.org/ogr2ogr.html 2011/1/1 Håvard Wahl Kongsgård haavard.kongsga...@gmail.com OK; what it the best alternative method in Python etc. to delete shapefile fields? Using the shapefile functions in R (via python is one alternative). 2011/1/1 Even Rouault even.roua...@mines-paris.org Le samedi 01 janvier 2011 19:08:23, Håvard Wahl Kongsgård a écrit : Hi, in gdal/ogr is there a function to delete fields(like CreateField())? Not yet, but this has been discussed in http://trac.osgeo.org/gdal/ticket/2671 ___ 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
Re: [gdal-dev] Deleting fields OGR
Håvard, Currently there is no option for this in ogr2ogr but this looks like a usable feature. You can file a ticket at http://trac.osgeo.org/gdal/newticket for this enhancement. 2011/1/2 Håvard Wahl Kongsgård haavard.kongsga...@gmail.com With ogr2ogr is it also possible to deselect(reverse selecting) fields? 2011/1/1 Chaitanya kumar CH chaitanya...@gmail.com Håvard, You can create a copy of the dataset while skipping the field. For shapefiles you won't have to mention the .shp file. Opening just the .dbf file will be enough. Similar thing can be done using ogr2ogr by specifying the -select option without the specified field's name. http://www.gdal.org/ogr2ogr.html 2011/1/1 Håvard Wahl Kongsgård haavard.kongsga...@gmail.com OK; what it the best alternative method in Python etc. to delete shapefile fields? Using the shapefile functions in R (via python is one alternative). 2011/1/1 Even Rouault even.roua...@mines-paris.org Le samedi 01 janvier 2011 19:08:23, Håvard Wahl Kongsgård a écrit : Hi, in gdal/ogr is there a function to delete fields(like CreateField())? Not yet, but this has been discussed in http://trac.osgeo.org/gdal/ticket/2671 ___ 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 -- Håvard Wahl Kongsgård Peace Research Institute Oslo (PRIO) http://havard.security-review.net/ -- Håvard Wahl Kongsgård Peace Research Institute Oslo (PRIO) http://havard.security-review.net/ ___ 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
Re: [gdal-dev] to get postgis-polygon object using resultset in Java
Ahmet,
If you are querying the postgis database directly, you can use ST_AsText()
or ST_AsBinary() to get the geometry in the WKT or the WKB format and use
OGRGeometry::importFromWkt() or OGRGeometry::importFromWkb() respectively to
load them into the OGR objects. This question is actually for the postgis
list.
2010/12/28 ahmet temiz ahmettemi...@gmail.com
hello
how can I get postgis-polygon object using Resultset in Java ?
like this way :
ResultSet rs = stmt.executeQuery(qstr);
while (rs.next()) {
gdal.Geometry geo=
}
regards
--
Ahmet Temiz
Jeoloji Müh.
Planlama ve Zarar Azaltma Dairesi Başkanlığı
Bilgi ve CBS grubu
Eskişehir Yolu 10. km.
Lodumlu / Ankara
Tel : 0 312 2872680 / 1535
___
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
Re: Re: [gdal-dev] to get postgis-polygon object using resultset in Java
Ahmet,
You might want to work with WKT while debugging and switch to WKB later.
Did you use ST_AsBinary(geometry column) in the SQL query string?
On Tue, Dec 28, 2010 at 3:08 PM, ahmettemi...@gmail.com wrote:
thank you
while (rs.next()) {
//g1 =
com.vividsolutions.jts.geom.Geometry.wkbReader.read(WKBReader.hexToBytes(rs.getString(1)));
g1 = org.gdal.ogr.Geometry.CreateFromWkb(rs.getBytes(1));
if (g1 != null) {
System.out.println( g1.GetGeometryType());
}
}
g1 returns null.
can you tell me what the wrong is ?
regards
28 Ara 2010 10:49 tarihinde, Chaitanya kumar CH chaitanya...@gmail.com
şunu yazdı:
Ahmet,
If you are querying the postgis database directly, you can use
ST_AsText() or ST_AsBinary() to get the geometry in the WKT or the WKB
format and use OGRGeometry::importFromWkt()
or OGRGeometry::importFromWkb() respectively to load them into the OGR
objects. This question is actually for the postgis list.
2010/12/28 ahmet temiz ahmettemi...@gmail.com
hello
how can I get postgis-polygon object using Resultset in Java ?
like this way :
ResultSet rs = stmt.executeQuery(qstr);
while (rs.next()) {
gdal.Geometry geo=
}
regards
--
Ahmet Temiz
Jeoloji Müh.
Planlama ve Zarar Azaltma Dairesi Başkanlığı
Bilgi ve CBS grubu
Eskişehir Yolu 10. km.
Lodumlu / Ankara
Tel : 0 312 2872680 / 1535
___
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem with gdalwarp in 1.7
Seth,
You can obtain the WKT of the geometries in a vector data source by using
ogrinfo with the -al option.
(http://www.gdal.org/ogrinfo.html)
On Sun, Nov 21, 2010 at 6:20 PM, geographika geograph...@gmail.com wrote:
On 19/11/2010 18:04, Frank Warmerdam wrote:
geographika wrote:
Hi,
I have upgraded from GDAL 1.6 (32bit Windows) to 1.7 (64 bit Windows) and
the following command no longer works:
C:\mapserver\bin\gdal\apps\gdalwarp C:\Data\Rasters\MiscSuit.tif
C:\RasterClips\mytest.tif -cutline c:\RasterClips\hello.json -te
118008.672141 177232.164284 138695.761666 206164.398565 -dstnodata -
I get the following message in the command prompt:
Creating output file that is 414P x 579L.
Processing input file C:\Data\Rasters\MiscSuit.tif.
for band 1, destination nodata value has been clamped to 0, the
original value being out of range.
ERROR 1: Failed to parse CUTLINE geometry wkt.
The CUTLINE is valid GeoJSON (but would clearly be invalid WKT) and
produces the correct results in 1.6.
The ogr formats lists GeoJSON as read/write.
I am using 64-bit builds of GDAL taken from http://vbkto.dyndns.org/sdk/
I have also tried using the development version of GDAL 1.8dev but get
the same message. If I do not use a CUTLINE the gdalwarp completes
successfully but the new image does not contain any data from my original
image (all cells are NoData).
Seth,
Can you make the .json file available? Does it work with OGR? Try
ogrinfo on it.
Hmm, tracking through the code the LoadCutline() function in gdalwarp.cpp
will read from the OGR datasource and convert the geometry to WKT which is
attached to the cutline property of the warp. Later GDALWarpOperation::
Initialize() turns that into a polygon object and that is where the
message
is coming from. So I am *suspecting* improper WKT of some type is getting
produced somehow. We will really need to see the WKT that is causing the
error to know more.
If you are comfortable rebuilding things then try changing:
const char *pszCutlineWKT =
CSLFetchNameValue( psOptions-papszWarpOptions, CUTLINE );
if( pszCutlineWKT )
{
in the file gdal/alg/gdalwarpoperation.cpp to something like:
const char *pszCutlineWKT =
CSLFetchNameValue( psOptions-papszWarpOptions, CUTLINE );
if( pszCutlineWKT )
{
printf( WKT = %s\n, pszCutlineWKT );
Best regards,
Thanks very much for your reply Frank.
I have uploaded the GeoJSON to
http://geographika.co.uk/downloads/test.json
Running ogrinfo C:\test.json on the file produces the following results:
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `C:\RasterClips\hello.json'
using driver `GeoJSON' successful.
1: OGRGeoJSON (Polygon)
Is it possible to use the ogr2ogr to convert GeoJSON to WKT to check if
this is successful? WKT is not in the list of formats at
http://www.gdal.org/ogr/ogr_formats.html
Compiling a 64bit version of GDAL is on my list of things to learn, so I
will try your second suggestion then.
The gdalwarp with the same GeoJSON works in 1.6 but it does throw up the
warning that:
the source raster dataset and the input vector layer do not have the same
SRS. Results will be probably incorrect.
Regards,
Seth
___
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
Re: [gdal-dev] gdalwarper --formats inconsistent with -of flag?
Sam, I too noticed this problem. I'm not sure of the reason other than the error message. You can get this done in two steps. First use gdalwarp to change the image size to 256x256 using bilinear resampling into a GTiff format image. Then use gdal_translate it from GTiff to PNG. On Fri, Nov 19, 2010 at 1:24 PM, ariasg...@gmx.de wrote: Hello, I have issues generating pngs out of gdalwarper. I did the following: $ gdalwarper.exe --formats One of the lines was: PNG (rwv): Portable Network Graphics So reading and writing png works! Here complete list dump http://pastebin.com/ZRS2nZir Then I tried gdalwarp.exe -ts 256 256 -of PNG -r bilinear utm32.tif d:/thumb_gdal.png and it failed with: Output driver `PNG' not recognised or does not support direct output file creation. The following format drivers are configured. Then it dumped a list of supported extension and no PNG was found. Here is the list: http://pastebin.com/wsD3rD7f Why is there an inconsistency between them? (GDAL 1.7.1, Win XP) -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ 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
Re: [gdal-dev] error compiling gdal 1.6.3 in rhel 5 64bits
gdal_wrap.cpp:1765: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1765: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1765: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1765: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1765: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1766: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1766: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1766: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1766: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1766: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1767: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1767: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1768: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1768: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1768: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1768: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1768: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:2022: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2022: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2022: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:2022: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:2022: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:2023: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2023: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2023: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:2023: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:2023: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:2024: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2024: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2025: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2025: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:2025: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:2025: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:2025: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:3596: error: redefinition of ‘pval _wrap_propget_MajorObject’ gdal_wrap.cpp:1069: error: se declaró ‘pval _wrap_propget_MajorObject’ previamente aquí gdal_wrap.cpp:3596: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:3596: error: ‘property_reference’ no se declaró en este ámbito make[2]: *** [gdal_wrap.o] Error 1 make[1]: *** [build] Error 2 make: *** [swig-modules] Error 2 How can I solve this problem? Is possible to solve it with another version of gdal or installing other libraries. Thanks in advance -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/error-compiling-gdal-1-6-3-in-rhel-5-64bits-tp5750785p5750785.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 -- 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
Re: [gdal-dev] error compiling gdal 1.6.3 in rhel 5 64bits
javiricca, Also, can you tell the command arguments you used for the configure script. On Thu, Nov 18, 2010 at 6:28 PM, Chaitanya kumar CH chaitanya...@gmail.comwrote: javiricca, Check if you have 'php5-dev' package installed. I too got similar (but not same) errors when it was not installed. While you are doing that also check for 'php-config' package. On Thu, Nov 18, 2010 at 1:55 PM, javiricca fjri...@gmail.com wrote: Hello, I'll trying to compile gdal in rhel 5 64 bits and I've getting some errors. gdal_wrap.cpp:1067: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1067: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1067: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1067: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1067: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1068: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1068: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1068: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1068: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1068: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1069: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1069: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1070: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1070: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1070: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1070: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1070: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1105: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1105: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1105: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1105: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1105: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1106: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1106: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1106: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1106: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1106: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1107: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1107: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1108: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1108: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1108: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1108: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1108: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1120: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1120: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1120: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1120: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1120: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1121: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1121: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1121: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1121: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1121: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1122: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1122: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1123: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1123: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1123: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1123: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1123: error: se trata la lista de expresiones initializer como una expresión compuesta gdal_wrap.cpp:1142: error: ‘zend_property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1142: error: ‘property_reference’ no se declaró en este ámbito gdal_wrap.cpp:1142: error: expected primary-expression before ‘*’ token gdal_wrap.cpp:1142: error: ‘value’ no se declaró en este ámbito gdal_wrap.cpp:1142: error: se trata
Re: [gdal-dev] KernelFilteredSource and nodata
Ken, KernelFilteredSource is derived from SimpleSource. It does not support setting a nodata value to the source band. Make sure your source image has a nodata value. You can set it using gdal_translate with the -a_nodata option. On Fri, Nov 19, 2010 at 2:10 AM, Boss, Ken (DNR) ken.b...@state.mn.uswrote: Chaitanya-- Thanks much for your response. I don't think that I described my problem effectively. Let me restate it and see if we are talking about the same thing. Here is a .vrt file that I think should accomplish what I am after: VRTDataset rasterYSize='690' rasterXSize='575' SRSEPSG:26915/SRS GeoTransform19, 1000, 0, 4795000, 0, 1000/GeoTransform VRTRasterBand band='1' dataType='Byte' KernelFilteredSource SourceFilenameD:/MyFiles/aptana_workspace/fire-webpage-mgmt/data/tmp_images/interpolated.tif/SourceFilename SourceBand1/SourceBand NoDataValue255/NoDataValue Kernel normalized=1 Size5/Size Coefs0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04/Coefs /Kernel /KernelFilteredSource /VRTRasterBand /VRTDataset I believe this file to be saying that interpolated.tif uses a value of 255 for nodata, and that the kernel is to be normalized - that is, it should: o ignore any nodata pixels within the kernel window when operating on a valid pixel o adjust the coefficients to sum to one for the number of valid pixels in the window when operating on a valid pixel o do nothing at all when centered on a nodata pixel I would expect then that any pixels that go in as nodata should come out as nodata, and that pixels with valid data values that are near nodata pixels should not be influenced by them. However, the outputs are not what I expect. The averaging is applied to both nodata and valid pixels alike. Have I set this up correctly, and is there a bug somewhere, or (more likely) is my vrt improperly constructed? Thanks for your help, --Ken -Original Message- From: Chaitanya kumar CH [mailto:chaitanya...@gmail.com] Sent: Wednesday, November 17, 2010 11:11 PM To: Boss, Ken (DNR) Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] KernelFilteredSource and nodata Ken, The current kernel filter does not ignore the boundaries of nodata pixels. But it does normalize the kernel after ignoring the nodata pixels in the kernel, if the 'normalized' attribute is set to 1. You can raise a ticket to request for this feature at http://trac.osgeo.org/gdal/newticket On Thu, Nov 18, 2010 at 6:08 AM, Boss, Ken (DNR) ken.b...@state.mn.us wrote: Hello list-- I am attempting to filter a raster using gdal_translate (v 1.7) and a vrt with a KernelFilteredSource. The input raster contains large areas of nodata values. I would like the filter to ignore those areas. I have tried various combinations of NoDataValue, HideNoDataValue, NODATA and Kernel normalized='1', but have not been able to prevent the filter from applying itself at data/nodata boundaries. My current VRT and gdal_translate command lines are below. Can anyone tell me what I am doing wrong? Thanks, Ken Boss Minnesota DNR = kernel_filter.vrt === VRTDataset rasterYSize='690' rasterXSize='575' SRSEPSG:26915/SRS GeoTransform19, 1000, 0, 4795000, 0, 1000/GeoTransform VRTRasterBand band='1' dataType='Byte' KernelFilteredSource SourceFilenameinterpolated.tif/SourceFilename SourceBand1/SourceBand NoDataValue255/NoDataValue HideNoDataValue1/HideNoDataValue Kernel normalized='1' Size5/Size Coefs0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04/Coefs /Kernel /KernelFilteredSource /VRTRasterBand /VRTDataset = gdal_translate -of GTiff -ot Byte -a_srs EPSG:26915 kernel_filter.vrt kernel_filtered.tif ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] KernelFilteredSource and nodata
Ken, The current kernel filter does not ignore the boundaries of nodata pixels. But it does normalize the kernel after ignoring the nodata pixels in the kernel, if the 'normalized' attribute is set to 1. You can raise a ticket to request for this feature at http://trac.osgeo.org/gdal/newticket On Thu, Nov 18, 2010 at 6:08 AM, Boss, Ken (DNR) ken.b...@state.mn.uswrote: Hello list-- I am attempting to filter a raster using gdal_translate (v 1.7) and a vrt with a KernelFilteredSource. The input raster contains large areas of nodata values. I would like the filter to ignore those areas. I have tried various combinations of NoDataValue, HideNoDataValue, NODATA and Kernel normalized='1', but have not been able to prevent the filter from applying itself at data/nodata boundaries. My current VRT and gdal_translate command lines are below. Can anyone tell me what I am doing wrong? Thanks, Ken Boss Minnesota DNR = kernel_filter.vrt === VRTDataset rasterYSize='690' rasterXSize='575' SRSEPSG:26915/SRS GeoTransform19, 1000, 0, 4795000, 0, 1000/GeoTransform VRTRasterBand band='1' dataType='Byte' KernelFilteredSource SourceFilenameinterpolated.tif/SourceFilename SourceBand1/SourceBand NoDataValue255/NoDataValue HideNoDataValue1/HideNoDataValue Kernel normalized='1' Size5/Size Coefs0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04/Coefs /Kernel /KernelFilteredSource /VRTRasterBand /VRTDataset = gdal_translate -of GTiff -ot Byte -a_srs EPSG:26915 kernel_filter.vrt kernel_filtered.tif ___ 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
Re: [gdal-dev] rasterlite creation error
Neil,
OGR's SQLite driver can read a SpatiaLite database without the SpatiaLite
library. The library is needed only for the extra features like indexes,
functions, etc. So, you probably don't have SpatiaLite configured right.
On Wed, Nov 17, 2010 at 10:11 AM, Neil Best nb...@ci.uchicago.edu wrote:
What does this mean?
$ gdal_translate -of Rasterlite /data/grass/global/cusa/cellhd/agc_crop
cusa.db -co DRIVER=PNG
Input file size is 695, 298
ERROR 1: In ExecuteSQL(): sqlite3_prepare(SELECT
AddGeometryColumn('cusa_metadata', 'geometry', -1, 'POLYGON', \
2)):
no such function: AddGeometryColumn
ERROR 1: Check that the OGR SQLite driver has Spatialite support
Both GDAL and OGR report that SQLite is a supported format. I am able to
ogrinfo world.sqlite from the SpatiaLite site, but not SRTM.sqlite. Any
ideas? Something wrong with my SQLite libraries or my paths?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/rasterlite-creation-error-tp5746493p5746493.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
--
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
Re: [gdal-dev] Problem with autotest SVN repository
Jean-Claude, That is a data file with Chinese characters in the filename. Try to add support for that language in your system. My system displays the filename correctly as xx中文.中文. I did not do anything to add the support so I can't help there. On Tue, Nov 9, 2010 at 6:38 PM, Jean-Claude Repetto jrepe...@free.frwrote: Hello, I'm trying to download the autotest source code from the SVN repository, but I have a problem with a file name encoded in UTF-8 : $ svn checkout https://svn.osgeo.org/gdal/trunk/autotest gdal-autotest svn: Can't convert string from 'UTF-8' to native encoding: svn: gdal-autotest/gcore/data/xx?\228?\184?\173?\230?\150?\135.?\228?\184?\173?\230?\150?\135 These are my language parameters : $ locale LANG=fr_FR.UTF-8 LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=fr_FR.UTF-8 LC_TIME=fr_FR.UTF-8 LC_COLLATE=C LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8 LC_PAPER=fr_FR.UTF-8 LC_NAME=fr_FR.UTF-8 LC_ADDRESS=fr_FR.UTF-8 LC_TELEPHONE=fr_FR.UTF-8 LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=fr_FR.UTF-8 LC_ALL= How can I solve this problem ? Thanks, Jean-Claude ___ 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
Re: [gdal-dev] An error in building overviews for
Zhenyu,
Even says that HFA driver supports overview creation. Try the gdaladdo
utility like he said.
http://www.gdal.org/gdaladdo.html
On Thu, Nov 11, 2010 at 8:45 PM, Zhenyu Lu luzhenyu1...@gmail.com wrote:
Hi, Chaitanya:
Thanks for the answers!
It's really helpful. So suppose there is .img file, it has overviews been
created using other software. We can use it anyway?
Like we can directly use band=band.GetOverview(overview), even the syntax
that dataset.BuildOverviews doesn't work?
2010/11/11 Chaitanya kumar CH chaitanya...@gmail.com
Zhenyu,
GDAL's HFA driver doesn't support creation of overviews. It can only read
them.
On Thu, Nov 11, 2010 at 9:16 AM, Zhenyu Lu luzhenyu1...@gmail.comwrote:
Hi, all:
I'm having an error while using function Dataset.BuildOverviews in my
code.
The error message is BuildOverviews() not supported for this dataset.
However, when I used the .tif file the BuildOverviews worked just fine.
The
code is:
int[] pOverviewList = { overView*2};
int[] pBandList = new int[dataset.RasterCount];
int err = dataset.BuildOverviews(NEAREST, pOverviewList);
if (err != (int)CPLErr.CE_None)
return null;
I'm using GDAL1.5.2 and C#2.0. Is it because the HFA driver doesn't
support
overview? Or is it a bug? Can anyone pointed out where is my problem?
Thanks a
lot!
--
Zhenyu Lu
SUNY-ESF
___
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
--
Zhenyu Lu
SUNY-ESF
--
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
Re: [gdal-dev] An error in building overviews for
Zhenyu,
GDAL's HFA driver doesn't support creation of overviews. It can only read
them.
On Thu, Nov 11, 2010 at 9:16 AM, Zhenyu Lu luzhenyu1...@gmail.com wrote:
Hi, all:
I'm having an error while using function Dataset.BuildOverviews in my code.
The error message is BuildOverviews() not supported for this dataset.
However, when I used the .tif file the BuildOverviews worked just fine.
The
code is:
int[] pOverviewList = { overView*2};
int[] pBandList = new int[dataset.RasterCount];
int err = dataset.BuildOverviews(NEAREST, pOverviewList);
if (err != (int)CPLErr.CE_None)
return null;
I'm using GDAL1.5.2 and C#2.0. Is it because the HFA driver doesn't support
overview? Or is it a bug? Can anyone pointed out where is my problem?
Thanks a
lot!
--
Zhenyu Lu
SUNY-ESF
___
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
Re: [gdal-dev] gdal_merge / negative size
Ghislain,
It may be counter intuitive to have smaller y-coordinate for lower lines but
you will have to take the pixel size into account.
Consider what would happen if you want to stitch such images together and
you try to reverse all the y coordinates.
On Tue, Nov 2, 2010 at 12:34 AM, Ghislain Picard
ghislain.pic...@lgge.obs.ujf-grenoble.fr wrote:
Hi All,
I have an image having y-coordinate increasing in the downward direction.
To display the image, the pixel size is -1000 on the y-axis (see ENVI
header file below). This works perfectly except in gdal_merge when use to
clip the raster (using QGis GdalTools(s plugin for instance).
For instance:
gdal_merge.py -ul_lr
95926.7879548 490702.415307 2036599.49812 -1014610.25721
fails because the output image size calculated by gdal_merge is negative.
Inverting the y-coordinates like this:
gdal_merge.py -ul_lr
95926.7879548 -1014610.25721 2036599.49812 490702.415307
works but it is counter-intuitive as the lower-right point should have a
smaller y-coordinate than the upper-left point.
It seems the size calculated by gdal_merge does not account for the sign of
the pixel size.
Ghislain
ENVI
description = {
File Imported into ENVI.}
samples = 5601
lines = 5601
bands = 1
header offset = 0
file type = ENVI Standard
data type = 4
interleave = bsq
sensor type = Unknown
byte order = 0
no data = 0
wavelength units = Unknown
map info = {Polar Stereographic, 1, 1, -2800500, -2800500, 1000,
-1000,WGS-84}
projection info = {31, 6378137, 6356752.314245179, -71, 0, 0, 0,WGS-84,
Polar Stereographic}
___
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
Re: [gdal-dev] NoData vs metadata confusion
Oyvind, GDAL handles nodata values band by band, whereas in MrSID all the bands of the particular pixel location must match the nodata values for that pixel to be considered nodata. Currently nodata values are ignored in this driver. I don't know if anything is planned for future releases. On Thu, Oct 28, 2010 at 4:21 PM, Oyvind Idland oyvind.idl...@gmail.comwrote: Hello, stumbled across a problem when reading MrSid: The MrSid dataset contains 3 bands, R/G/B. None of the 3 bands gives me a GetNoDataValue(), however, the metadata contains IMAGE__NO_DATA_VALUE=255,255,255. Does this mean, that I have to check for both cases ? The version is GDAL 1.7.2. Regards, Oyvind Idland ___ 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
Re: [gdal-dev] Reading GML
Paul, 1.7 doesn't support some geometry types that 1.8 does. GDAL1.8 is yet to be released. You have to build it yourselves. You can find a nightly snapshot of the source code for the trunk (1.8) at http://trac.osgeo.org/gdal/wiki/DownloadSource#NightlySnapshots Build hints: http://trac.osgeo.org/gdal/wiki/BuildHints On Wed, Oct 20, 2010 at 2:45 PM, Paul Meems bontepaar...@gmail.com wrote: Hi all, I have a GML which I want to convert to shapefile. I've started with checking the file with ogrinfo (v1.7.2). It returns Unrecognised geometry type Surface. After searching a bit it seems GDAL v1.8 might read the GML properly. So I'm looking for the binaries of GDAL v1.8. At Tamas his site I can download the v1.7.2 version but I can't find the v1.8 binaries. Does anybody know where I can download that version or do I need to build them myself? Thanks, Paul The Netherlands ___ 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
Re: [gdal-dev] Re: how to say gdalwarp to use nadgrid by default
Eloi, You can find the files at gdal/data/pcs.csv and gdal/data/gcs.csv You may also want to refer to http://www.gdal.org/ogr/osr_tutorial.html On Sun, Oct 17, 2010 at 5:18 PM, Eloi Ribeiro eloi.ribe...@gmail.comwrote: In other words, When I ask GDAL for: *gdalwarp -s_srs EPSG:23030 -t_srs EPSG:4258 rast_23030.tif rast_4258.tif* GDAL knows that 'EPSG:23030' means '+proj=utm +zone=30 +ellps=intl +units=m +no_defs'. So my question is: From witch file GDAL gets that information from? Cheers, Eloi Ribeiro GIS Analyst 39,45º -4,40º http://eloiribeiro.wordpress.com On Mon, Oct 11, 2010 at 14:55, Eloi Ribeiro eloi.ribe...@gmail.comwrote: Hi all, I would like that every time a I use gdalwarp for some EPSG codes [1] transformation it would use by default the nadgrids [2] (for Portugal and Spain) that I have under the folder '/usr/share/proj/'. For that purpose in PostGIS I needed to add '+nadgrids=nadgrid_file_name.gsb' at the end of the line of the 'proj4text' field text in table 'spatial_ref_sys' for each EPSG code I wonted to use the nadgrid. So I suppose there must be a similar way of doing this with GDAL. How can I achieve this with GDAL? Thank's! [1] 27492,27493,20790,20791,23029,23030,23031,3763,4258,4326 [2] pt73_e89.gsb, ptLX_e89.gsb, ptLB_e89.gsb, ptED_e89.gsb, R2009V9.gsb, BALR2009.gsb Eloi Ribeiro GIS Analyst 39,45º -4,40º http://eloiribeiro.wordpress.com ___ 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
Re: [gdal-dev] Memory usage for GetProjectionRef
Livneh, I am assuming the 80KB refers to the memory change for getting the projection and not the whole dataset. Can you check if the 80KB memory is freed and not leaked if the dataset is closed? On Mon, Oct 4, 2010 at 10:41 PM, Livneh Yehiyam ye...@rafael.co.il wrote: Hi We are using Gdal 1.7.0b from FWTools 2.7.1. Our application is written in C#. In our application we need to open a large number of tiff files (more than 2000). We noticed that opening a dataset and then getting the projection string will increase the amount of memory (private bytes) by more that 80KB. This seems not a large amount, but multiplied by 2000 is more than 160MB. Is anyone aware of such a problem? 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:law...@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 -- 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
Re: [gdal-dev] Reading Geometry from text file
Moritz,
Did you compile GDAL/OGR with GEOS library support? IsValid() will fail
without this.
I can't tell why get_Area() crashes.
On Tue, Oct 5, 2010 at 3:03 PM, moritzzz s...@kolix.de wrote:
Hey guys,
I just started using gdal/ogr and am running into a lot of problems. The
main one right now comes up when I'm trying to create a geometry from a
string that I read from a file. The line I'm reading looks like this:
MULTIPOLYGON(((1 1,5 1,5 5,1 5,1 1),(2 2,2 3,3 3,3 2,2 2)),((6 3,9 2,9 4,6
3)))
Now I wrote some c++ code that's supposed to create a OGRMultipolygon in
which line is the mentioned line from the file:
double* kdTreeMgmtServer::process_polygon(string line, string path) {
char* lineArr = (char*) line.c_str();
OGRGeometry* new_geom;
OGRGeometryFactory::createFromWkt(lineArr, NULL, new_geom);
if (wkbFlatten(new_geom-getGeometryType()) != wkbMultiPolygon) {
log_error(not a multipolygon! geometrytype =
%d\n,new_geom-getGeometryType());
return NULL;
}
if (!new_geom-IsValid()) {
log_debug(line is invalid: '%s'\n, line.c_str());
}
OGRMultiPolygon* poly = (OGRMultiPolygon*) new_geom;
poly-get_Area();
}
The first part seems to work fine, as the geometry is recognized as a
multipolygon but the validation always fails and poly-get_Area(); causes a
crash of the code. What am I doing wrong?
Cheers
Moritz
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Reading-Geometry-from-text-file-tp5602472p5602472.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
--
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
Re: [gdal-dev] Re: Reading Geometry from text file
Moritz, Then we can probably rule out the geos library. Just make sure it was recognized by the configure script by looking at its output or in the config.log file. We need to have some info on the get_Area() error. Build gdal after configuring with the --enable-debug switch and run the application with the environment variable CPL_DEBUG set to 'ON'. For deeper analysis run it with ddd or some other debugger. On Tue, Oct 5, 2010 at 5:55 PM, moritzzz s...@kolix.de wrote: Hey, I checked gdal out from the svn repos and build it with: ./configure --libdir=/usr/lib --with-geos=yes make -j3 make install Installed geos stuff: dpkg -l | grep geos ii libgeos-3.2.0 3.2.0-1 Geometry engine for Geographic Information Systems - C++ Library ii libgeos-c1 3.2.0-1 Geometry engine for Geographic Information Systems - C Library ii libgeos-dev3.2.0-1 Geometry engine for GIS - Development files So from my pov it should be installed with geos support and IsValid() should not fail if the geometry is valid. For the crash of get_Area(), there is no error message or something like that. The program just shutsdown. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Reading-Geometry-from-text-file-tp5602472p5602924.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 -- 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
Re: [gdal-dev] ogr problems with MapInfo
Hi, I think the problem is with the call to stat() on the samba mounted files. tab2tab reported the same problem. On Thu, Sep 30, 2010 at 7:10 PM, Sebastian E. Ovide sebastian.ov...@gmail.com wrote: done... didn't work... Copied on the same SMB folder with undercase names... both ogrinfo and tab2tab failed. Copied the same files to a local folder and both ogrinfo and tab2tab succeeded... same errors On Thu, Sep 30, 2010 at 1:44 PM, Daniel Morissette dmorisse...@mapgears.com wrote: Sebastian E. Ovide wrote: can verbosity be increased further ? I don't think so... the only way to know more about what is happening would be to run this in gdb. and with TAB2TAB the only messages that I get are: g...@mapserver:/tmp$ /home/gis/src/mitab-1.7.0/mitab/tab2tab /home/gis/data/tmp/CA_AbandonedMine.TAB test.TAB ERROR 3: stat() failed for /home/gis/data/tmp/CA_AbandonedMine.id ERROR 3: Open() failed for /home/gis/data/tmp/CA_AbandonedMine.map ERROR 3: /home/gis/data/tmp/CA_AbandonedMine.TAB could not be opened as a MapInfo dataset. Failed to open /home/gis/data/tmp/CA_AbandonedMine.TAB This looks like an uppercase vs lowercase file extension problem. There is some logic in MITAB to try to guess and then adjust filename extensions (e.g. .MAP vs .map) on non-Windows systems that uses stat() and for some reason it seems to fail with the SMB share. Can you please try renaming all files for a given table to lowercase extensions (.tab, .map, .dat, .ind, .id) and then see if that changes anything with the tab2tab program on the SMB share? If that solves the issue then we'll need to reproduce this here and run this in gdb to figure the exact source of the problem and fix it. Daniel -- Daniel Morissette http://www.mapgears.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Sebastian E. Ovide ___ 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
Re: [gdal-dev] GDAL Error 4 - Again
Chris, Did yo remember to make a call to GDALAllRegister() ? Python automatically calls that when the GDAL module is imported. On Tue, Sep 28, 2010 at 3:31 PM, GOO Creations goocreati...@gmail.comwrote: Hi everyone I've looked through the mailing-list archive and I know this issue was addressed several 100 times, but I still can't find the problem: This is my code I use to open an image: const char* f = /home/goocreations/Documents/blue.pix; GDALDataset *d = (GDALDataset*) GDALOpen(f,GA_Update); I'm getting the following error: ERROR 4: `/home/goocreations/Documents/blue.pix' not recognised as a supported file format. The interesting part is that I have a python GUI (with SIP bindings) that calls exactly the same C++ code as above and passed a file path via the QFileDialog. This plugin can open the exact same image (/home/goocreations/Documents/blue.pix) correctly through GDAL, although some other images sometimes open and sometimes don't (this is weird). I've read through the archive, and yes the following applies: - The image actually exists. - I have full access/permission to the image - The image is 30mb - The image is not corrupt, since I can open it through the GUI and through QGis. I've really no idea what’s wrong, any idea?? Thanks Chris ___ 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
Re: [gdal-dev] Erdas 2010 and OpenEV different views
Ibrahim, Try the buttons in openev toolbar with the slant lines. They perform different kinds of rescaling. On Tue, Sep 28, 2010 at 5:10 PM, Ibrahim Saricicek ibrahimsarici...@gmail.com wrote: Hi List, By Erdas Imagine 2010 I've combined 3 bands (by Spectral/Layer Stack Menu). Saved as 32 bit. And by Rescale menu, rescaled to 8 bit. The image is shown the same on Mapserver, QGis, Ossim, OpenEv and different on Erdas Imagine 2010. You may see the differences on the images. And I attached the image on tif format. What is wrong with QGis, Ossim or OpenEv? Thanks in advance... http://osgeo-org.1803224.n2.nabble.com/file/n5579024/erdas.jpg http://osgeo-org.1803224.n2.nabble.com/file/n5579024/chip.tif chip.tif http://osgeo-org.1803224.n2.nabble.com/file/n5579024/gdal.jpg -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Erdas-2010-and-OpenEV-different-views-tp5579024p5579024.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 -- 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
Re: [gdal-dev] Erdas 2010 and OpenEV different views
Ibrahim, I don't think you can save the image that way in openev. You can use gdal_translate to perform linear scaling. Use the -scale option. If you think you can stand to lose some info in very dark or very bright areas, specify appropriate values for src_min and src_max. http://www.gdal.org/gdal_translate.html On Tue, Sep 28, 2010 at 6:26 PM, ibrahim saricicek ibrahimsarici...@gmail.com wrote: Hi List, Thanks Linear Stretch/ Enhancement works. And one more question how can i save the image with Linear Stretch/ Enhancement applied? Regards.. On Tue, Sep 28, 2010 at 2:59 PM, Chaitanya kumar CH chaitanya.ch@ gmail.com wrote: Ibrahim, Try the buttons in openev toolbar with the slant lines. They perform different kinds of rescaling. On Tue, Sep 28, 2010 at 5:10 PM, Ibrahim Saricicek ibrahimsarici...@gmail.com wrote: Hi List, By Erdas Imagine 2010 I've combined 3 bands (by Spectral/Layer Stack Menu). Saved as 32 bit. And by Rescale menu, rescaled to 8 bit. The image is shown the same on Mapserver, QGis, Ossim, OpenEv and different on Erdas Imagine 2010. You may see the differences on the images. And I attached the image on tif format. What is wrong with QGis, Ossim or OpenEv? Thanks in advance... http://osgeo-org.1803224.n2.nabble.com/file/n5579024/erdas.jpg http://osgeo-org.1803224.n2.nabble.com/file/n5579024/chip.tif chip.tif http://osgeo-org.1803224.n2.nabble.com/file/n5579024/gdal.jpg -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Erdas-2010-and-OpenEV-different-views-tp5579024p5579024.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 -- 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL easy_install problem
Greg, This issue is actively being pursued. There is a temporary fix for this. Refer to http://trac.osgeo.org/gdal/ticket/3468#comment:10 On Tue, Sep 28, 2010 at 8:30 AM, Greg Corradini gregcorrad...@gmail.comwrote: Hello, I'm trying to install GDAL using easy_install as detailed here ( http://trac.osgeo.org/gdal/wiki/GdalOgrInPython). I've never see this error before on my other GDAL Ubuntu 9.0 installs. Not sure what it means. I'm wondering if it might have to do with NumPy (I think I screwed that install up). Any ideas? # sudo easy_install GDAL Searching for GDAL Reading http://pypi.python.org/simple/GDAL/ Reading http://www.gdal.org Best match: GDAL 1.7.1 Downloading http://pypi.python.org/packages/source/G/GDAL/GDAL-1.7.1.tar.gz#md5=38b838d528b309a28a3aa24d4fcef3cd Processing GDAL-1.7.1.tar.gz Running GDAL-1.7.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-drTCwM/GDAL-1.7.1/egg-dist-tmp-nxP_u9 Could not run gdal-config cc1plus: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ extensions/gdal_wrap.cpp: In function ‘int PyProgressProxy(double, const char*, void*)’: extensions/gdal_wrap.cpp:2969: warning: the address of ‘_Py_NoneStruct’ will never be NULL extensions/gdal_wrap.cpp: In function ‘PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)’: extensions/gdal_wrap.cpp:5854: warning: deprecated conversion from string constant to ‘char*’ extensions/gdal_wrap.cpp: In function ‘PyObject* _wrap_PushErrorHandler(PyObject*, PyObject*)’: extensions/gdal_wrap.cpp:4888: warning: ‘argv[0]’ may be used uninitialized in this function cc1plus: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ extensions/osr_wrap.cpp:2906: warning: ‘char* GDALPythonObjectToCStr(PyObject*)’ defined but not used cc1plus: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ In file included from extensions/ogr_wrap.cpp:2808: /usr/local/include/ogr_p.h:94:17: error: swq.h: No such file or directory In file included from extensions/ogr_wrap.cpp:2808: /usr/local/include/ogr_p.h:105: error: ‘swq_field_type’ does not name a type error: Setup script exited with error: command 'gcc' failed with exit status 1 ___ 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
Re: [gdal-dev] gdal_fillnodata.py doesn't work
ahmet, This error is reported by the grass library. Is work1.tif in TIFF format? Can you post the output of gdalinfo on work1.tif for more info? On Wed, Sep 22, 2010 at 1:50 PM, ahmet temiz ahmettemi...@gmail.com wrote: hello can you tell me what this problem is ? or...@orkun-desktop:~/data/pro1001/yuk$ python gdal_fillnodata.py -md 100 work1.tif dem1.tif ERROR 1: libgrass: MAPSET is not set Aborted 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_fillnodata.py doesn't work
ahmet, I can't understand why the error occurs. Can you provide a sample data that gives this error? On Wed, Sep 22, 2010 at 4:53 PM, ahmet temiz ahmettemi...@gmail.com wrote: thank you for your interest here it is: or...@orkun-desktop:~/data/pro1001/yuk$ gdalinfo work1.tif Driver: GTiff/GeoTIFF Files: work1.tif Size is 4716, 5481 Coordinate System is `' Origin = (436921.7120955,4648461.9372529) Pixel Size = (20.000,-20.000) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 436921.710, 4648461.900) Lower Left ( 436921.710, 4538841.900) Upper Right ( 531241.710, 4648461.900) Lower Right ( 531241.710, 4538841.900) Center ( 484081.710, 4593651.900) Band 1 Block=4716x1 Type=Float64, ColorInterp=Gray NoData Value=0 regards 2010/9/22 Chaitanya kumar CH chaitanya...@gmail.com: ahmet, This error is reported by the grass library. Is work1.tif in TIFF format? Can you post the output of gdalinfo on work1.tif for more info? On Wed, Sep 22, 2010 at 1:50 PM, ahmet temiz ahmettemi...@gmail.com wrote: hello can you tell me what this problem is ? or...@orkun-desktop:~/data/pro1001/yuk$ python gdal_fillnodata.py -md 100 work1.tif dem1.tif ERROR 1: libgrass: MAPSET is not set Aborted 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 -- 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
Re: [gdal-dev] legend of the dem ?
ahmet, The gdaldem color-relief utility uses the color entries from a text file which is given as the argument color_text_file. If you did create a map using gdaldem color-relief, you should already have the file. Use the entries from it. On Wed, Sep 22, 2010 at 1:12 AM, ahmet temiz ahmettemi...@gmail.com wrote: So, what are they ? 2010/9/21 Chaitanya kumar CH chaitanya...@gmail.com: ahmet, You have to create a legend of the dem from the color configuration file using some other tool. On Wed, Sep 22, 2010 at 12:32 AM, ahmet temiz ahmettemi...@gmail.com wrote: I used gdaldem color-relief and created the map. Now, how can I generate the legend of the dem ? kind 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 -- 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
Re: [gdal-dev] Is the OGR SDE driver being maintained ?
Hi, I'm thinking about taking this up if and when I get a license for this. In any case, this will take some time. On Tue, Sep 21, 2010 at 6:21 PM, Howard Butler hobu@gmail.com wrote: On Sep 21, 2010, at 5:21 AM, Anders Moe wrote: Hello everyone I'm generally having some problems with the OGR SDE driver * lack of UTF support, for example; I reported this almost two years ago, had to fix this myself in ogrsdedriver * sql errors when writing to the database So I was just wondering if there is something going in the 1.8 branch for this driver, or if I should try a different solution/hacking something in place myself. I would say that the OGR SDE (and MapServer SDE too, for that matter) is looking for a maintainer. I no longer have the ability to maintain it as I do not have the pieces (SDE) to test with. Howard ___ 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
Re: [gdal-dev] Create a Google Earth overlay based on Geotiff
António, Refer to http://www.gdal.org/gdal2tiles.html and http://www.gdal.org/gdal_utilities.html 2010/9/6 António Rocha antonio.ro...@deimos.com.pt Greetings I have a goerreferenced Geotiff image, already in EPSG:4326, and I need to automatically create an KML with an overlay from this geotiff. Is it possible using GDAL? If so, how can I do that? Or can anyone indicate me an Wiki that explain this? I have found this link: http://code.google.com/apis/kml/articles/raster.html but it creates empty doc.kml Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5428 (20100906) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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
Re: [gdal-dev] MapInfo mixed geometry
Sebastian, You can write a python script to do that. Refer to ogr2ogr.py in http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples for a sample. Skip features according to their geometry's types using GetGeometryType(). On Wed, Sep 1, 2010 at 4:03 PM, Sebastian E. Ovide sebastian.ov...@gmail.com wrote: Hi All, I have MapInfo mixed geometry files. As MapServer doesn't support layers wityh mixed geometry, Is it possible to use gdal for extracting its points, its polygaons etc... and save them in different files ? thanks -- Sebastian E. Ovide ___ 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
Re: [gdal-dev] Extract elevation from (latitude, longitude)
Carmelo, In the code n30.dt0 is some raster image file. Replace it with your image path. The array named 'data' was renamed to pippo. Correct that. Refer to GDALDataset::GetGeoTransform() method at http://www.gdal.org/classGDALDataset.html Use GDALDataset::RasterIO() or GDALRasterIO while treating the pointer to a double variable as the buffer (pData in the function definition). On Tue, Aug 31, 2010 at 8:41 PM, Carmelo Terrasi terrasi.carm...@gmail.comwrote: Hello everybody, first of all my apologies cause I'm a newbie with this stuff... I'm trying to build a function able to extract altitude from latitude and longitude as parameters. Something like that: *double MyElevation(double lat, double lon)* * * I'm using Dted level 0 to get the elevation (I've already read this post: http://www.osgeo.org/pipermail/gdal-dev/2010-February/023457.html ) But I got lost... :( *GDALAllRegister(); * *pointerToDataSet=(GDALDataset*) GDALOpen(n30.dt0, GA_ReadOnly);* * * *double data[6];* *double longitude, latitude;* * * *pointerToDataSet-GetGeoTransform(data);* * * *longitude=???;* *latitude=???;* * * *double x = (longitude - pippo[0]) / pippo[1];* *double y = (latitude - pippo[3]) / pippo[5];* * * *GDALRasterBand* pointerToBand;* * * *pointerToBand=pointerToDataSet-GetRasterBand(1);* * * *float *elevation;* * * *pointerToDataSet-RasterIO(?,?, ... , ?);* *pointerToBand-RasterIO(?,?, ... , ?);* I supposed I had to store elevation data into the buffer I created, I mean the float pointer. I got confused among these: - the file *.dt0 - longitude and latitude - parameters for RasterIO() Every tips will be very appreciated, thanks a lot for your patience, Regards, Carmelo ___ 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
Re: [gdal-dev] how to clip the shape file
Vajram, Unless you want to do this with many files, you can just mention the raster's extents in the ogr2ogr utility with the options -spat and/or -clipsrs and convert the shapefile into a new shapefile that covers the raster. On Mon, Aug 23, 2010 at 2:56 PM, mail2vajram mail2vaj...@gmail.com wrote: I want to access shape files using GDAL, and i have a shape file and raster image. then how to clip the shape file which covers that rasterhow to do this. Thank you -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-clip-the-shape-file-tp5451928p5451928.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 -- 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
Re: [gdal-dev] Create copy without any bands
Tim, You can create it easily by modifying GDALDriver::DefaultCreateCopy() On Sat, Aug 21, 2010 at 9:51 PM, Tim Keitt tke...@gmail.com wrote: I am writing a utility that takes a raster as input and outputs a raster with all attributes the same, except that I only want one output band and I want to specify its type independent of the data type in the input file. Is there a function that creates a copy of a dataset (or creates a virtual dataset), but does not copy any raster bands? This would really simplify things as all I would have to do is add a band to the output dataset of the desired type. THK -- Timothy H. Keitt http://www.keittlab.org/ ___ 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
Re: [gdal-dev] Working with NED elevation data - part 2
0'0.34N) Lower Left (-171.000, -14.5000520) (171d 0'0.00W, 14d30'0.19S) Upper Right ( 163.4999735, 66.944) (163d29'59.90E, 66d 0'0.34N) Lower Right ( 163.4999735, -14.5000520) (163d29'59.90E, 14d30'0.19S) Center ( -3.7500132, 25.7500212) ( 3d45'0.05W, 25d45'0.08N) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray Minimum=-83.000, Maximum=4665.000, Mean=25.333, StdDev=189.129 Metadata: STATISTICS_MINIMUM=-83 STATISTICS_MAXIMUM=4665 STATISTICS_MEAN=25.332848474484 STATISTICS_STDDEV=189.12886049417 ___ 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
Re: [gdal-dev] .hgt
weixj2003ld, The SRTMHGT driver in GDAL should be able to open that file. http://www.gdal.org/frmt_various.html#SRTMHGT 2010/8/12 甘肃。思远 weixj200...@163.com I got a .hgt file,and do not know what is the format of it,and GDAL can read it? Thk u . -- 网易邮箱，没有垃圾邮件的邮箱。 http://mail.163.com/?from=fe1 ___ 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
Re: [gdal-dev] RE: [GDAL_TRANSLATE]Problem with colorimetry
Tacot, You could have used a small shell script like this for converting all the tif files. for f in *.tif; do echo $f - new_$f; gdal_translate -of GTiff -expand RGB -co compress=lzw $f new_$f; done The issue is reported as a warning in the trunk version of GDAL. It will appear in gdal-1.8.0 Your images had only one band of 8-bit pixels. The colors are interpreted using a color table. You can see it in the output of gdalinfo. By using the -expand RGB option in gdal_translate, you are creating a new tiff with three bands, one each for Red, Green and Blue colors. This way, all the image files will have the same values for any color. Note that your color table also had the alpha channel, but I ignored it since all of them were 255. Refer to http://www.gdal.org/gdal_utilities.html for documentation on various gdal utilities. On Wed, Aug 11, 2010 at 1:59 PM, Tacot cfa...@hotmail.fr wrote: Hi First of all, Thanks a lot: it works! I've run those commands line: /*For all pictures = it's a little bit repetitive: *gdal_translate -of GTiff -expand RGB -co compress=lzw SC25_TOPO_0850_6470_L93.tif 0850_6470.tif gdalbuildvrt truc.vrt *.tif gdal_translate -of GTiff truc.vrt truc.tif * But maybe you can explain somme things to me: - what version of gdal, reports the issue? - What does the option RGB do? - What is PCT2RGB? Best Regards Fab -- Date: Tue, 10 Aug 2010 09:01:36 -0700 From: [hidden email]http://user/SendEmail.jtp?type=nodenode=5411388i=0 To: [hidden email] http://user/SendEmail.jtp?type=nodenode=5411388i=1 Subject: Re: [GDAL_TRANSLATE]Problem with colorimetry Fab, I found the problem. There were some differences in color tables of your images. gdalbuildvrt application from the latest GDAL version reports the issue when you try to build the vrt file. You're advised to preprocess your rasters with other tools, such as pct2rgb.py or gdal_translate -expand RGB to operate gdalbuildvrt on RGB rasters instead. The reason the red areas were occuring in different areas is that gdalbuildvrt considers only the first file's color table. On Tue, Aug 3, 2010 at 8:36 PM, Tacot [hidden email] wrote: I think more about the value of data. http://osgeo-org.1803224.n2.nabble.com/file/n5368754/PixelRed.jpg But it's not always the picture on the right which pixels become red; it can be also the picture on the left. I have the felling it depends on the range of merging. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-TRANSLATE-Problem-with-colorimetry-tp5368059p5368754.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list [hidden email] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/gdal-dev -- View message @ http://osgeo-org.1803224.n2.nabble.com/GDAL-TRANSLATE-Problem-with-colorimetry-tp5368059p5393675.html To unsubscribe from Re: [GDAL_TRANSLATE]Problem with colorimetry, click here. -- View this message in context: RE: [GDAL_TRANSLATE]Problem with colorimetryhttp://osgeo-org.1803224.n2.nabble.com/GDAL-TRANSLATE-Problem-with-colorimetry-tp5368059p5411388.html Sent from the GDAL - Dev mailing list archivehttp://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.htmlat Nabble.com. ___ 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
Re: [gdal-dev] Retrieve number of layers with gdalpy
António, GDALDataset::GetRasterCount doesn't have the same interface in Python. You can get the value using the GDALDataset's member variable RasterCount in Python. Example: http://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/tiff_write.py?rev=19928#L764 2010/8/11 António Rocha antonio.ro...@deimos.com.pt Greetings I have a file Geotiff format (and other in GRIB) and I need to know how many layers of data I have in each one of them by using gdalPy. is it possible? (I don't want to use gdalinfo , I just want to get this value directly) Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5356 (20100810) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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
Re: [gdal-dev] Geotiff with bands of different type
Martin, Yes, it is possible. You can specify the data type in GDALDataset::AddBand() On Tue, Aug 10, 2010 at 12:44 PM, Martin Raspaud martin.rasp...@smhi.sewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm using gdal/python and I would like to create geotiffs using one band of bytes and one of float32s... Is this even possible ? Thanks, Martin ___ 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] Maintenance report for Jun 17, 2010 to Aug 07, 2010
Frank, Please find the attached maintenance report for the work done by me. Same can be found at http://trac.osgeo.org/gdal/wiki/MaintenanceReportsByChaitanya#Jun172010toAug072010 -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E GDAL Maintenance Reports by Chaitanya kumar CH. Duration: Jun 17, 2010 to Aug 07, 2010 #3630: Added some corrections, changes and a test for xlink support in GML driver. #2852: Added a test. #3364: Fixed a typo that was making the comparision of coordinate systems to fail sometimes. #2798: Prepared a test for index management in shapefile driver. #3045: Fixed a memory leak. #3694: Made the mif driver more lenient with the mif file formatting. -- Chaitanya kumar CH chaitany...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: How to retain double precision in GDAL?
Ole, This option is for the AAIGRID driver. So this option is valid any time the format is handled. In a python script you set the option you need to set this option during the call to gdal.Open() to set a specific datatype. Refer to http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/aaigrid.py#L245and http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/aaigrid.py#L247 . Remember to set it to 'None'. To set this option for gdal/ogr utilities use the option --config as described in http://www.gdal.org/gdal_utilities.html. Use the CPLSetConfigOption() function in C/C++ code. On Mon, Aug 9, 2010 at 8:10 AM, Ole Nielsen ole.niel...@aifdr.org wrote: Thanks for fixing the precision loss so quickly. you now can set the configuration option AAIGRID_DATATYPE to Float64 to force Float64 being used to avoid the loss of precision. I am not exactly sure whether this option relates to the gdal_translate command line utility or the Python binding (ReadAsArray) - or both. Could you perhaps post the updated script that produced the double precision values correctly? Thanks Ole Nielsen - Ole Nielsen Australia - Indonesia Facility for Disaster Reduction -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-How-to-retain-double-precision-in-GDAL-tp5379507p5387617.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 -- 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
Re: [gdal-dev] Help with python gdal.RasterizeLayer
GDALRasterBand::ComputeStatistics() recalculates them. On Sat, Aug 7, 2010 at 7:06 PM, Rudi von Staden rud...@gmail.com wrote: On 07/08/2010 13:29, Rudi von Staden wrote: Below I've included the output I'm getting (followed by my python script). The RasterizeLayer command should be burning the polygon onto the single band raster (initialized to have all cells = 255) using a value of 0. However, the stats show that nothing has happened, and if I check the resulting GTif, all cells are still 255. Apologies. It seems I was a little hasty in checking my own output, and I had some issues with the extents being different. It is working now, but the statistics are not reported correctly ([255.0, 255.0, 255.0, 0.0] before and after). Do I have to set them manually, or is there some way to recalculate them? Rudi ___ 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
Re: [gdal-dev] external overviews format
Duarte, The gdaladdo utility doc page at http://www.gdal.org/gdaladdo.html has the info on it. On Sat, Aug 7, 2010 at 10:55 PM, Duarte Carreira dcarre...@edia.pt wrote: What is the format of external overviews? Is the .ovr file in the same format as the original image? Or is it TIFF format, unless you choose Imagine format? I'm supposing that internal overviews are in the same format as the original image? Thanks, Duarte ___ 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
Re: [gdal-dev] ogr2ogr clipping shapefile
Giacomo, The ogr2ogr utility can do that. Use the clipping options. http://gdal.org/ogr2ogr.html On Fri, Aug 6, 2010 at 1:00 PM, Giacomo Piva p...@meeo.it wrote: Hi all, I need to cut a shapefile usins as bounding box another shapefile. Does someone can explain me how to do that with ogr2ogr? Thank you very much -- Giacomo ___ 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
Re: [gdal-dev] split netCDF
Martin, Use the gdal_translate utility (http://www.gdal.org/gdal_translate.html) with the -b option. You will have to run the command once for each band. A simple shell script should do it. On Fri, Aug 6, 2010 at 4:26 PM, Matin80 mar...@bier-mail.de wrote: Hi everyone, I have a netCDF-file containing over 300 bands. is it possible to split up the file and get the same number of GeoTiffs with GDAL in a single command line? All i found to this topic ended in merging the bands to a single output file... kind regards, Martin -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/split-netCDF-tp5380091p5380091.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 -- 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
Re: [gdal-dev] Merging shapefile
Giacomo, If you want to merge a small number of shapefiles into a single shapefile, look at the example near the bottom of the page http://www.gdal.org/ogr/drv_shapefile.html http://gdal.org/ogr2ogr.html On Fri, Aug 6, 2010 at 12:09 PM, Giacomo Piva p...@meeo.it wrote: Hi all, I need to merge two shapefile, is it possible with GDAL ? Thank you -- Giacomo ___ 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
Re: [gdal-dev] gdal warp of a shapefile
Giacomo, You can use ogr2ogr utility for that. (http://www.gdal.org/ogr2ogr.html) On Thu, Aug 5, 2010 at 7:48 PM, Giacomo Piva p...@meeo.it wrote: Hi all, I have a somple and fast question: is it possible to execute a gdalwarp command on a shapefile? how? Thank you -- Giacomo ___ 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
Re: [gdal-dev] gdaladdo and cubic resampling
Armin, GDAL's resampling algorithms for overviews are a bit restricted. Your best bet is to smoothen the image with an image processing software. On Thu, Aug 5, 2010 at 11:00 PM, Armin Burger armin.bur...@gmx.net wrote: Chaitanya I send the image just to you since it's not small any more. This is a mosaic of 3 versions of GDAL overviews: left: nearest middle: cubic right: gauss as you can see, nearest and cubic are looking very similar, quite grainy (which I would expect from nearest but not from cubic convolution). The gaussian on the other hand is very much smoothed, already a bit blurred. I was expecting that cubic would produce much less grainy results than nearest but less blurred effects than gaussian. Regards Armin On 05/08/2010 14:52, Chaitanya kumar CH wrote: Armin, Can you provide a sample image that shows this problem? On Thu, Aug 5, 2010 at 5:57 PM, Armin Burger armin.bur...@gmx.net mailto:armin.bur...@gmx.net wrote: Hi all I have a question regarding the resampling modes for the gdaladdo utility. Since the overviews are used by Mapserver afterwards, I ran some tests with a map file referencing the Tiff image and the shp2img tool to output the results. I found the gauss resampling smoothening the image a bit too much. Therefore I wanted to try the cubic resample method using the GDAL version included in FWTools 2.4.7 (1.7.0b2), but to me it looks like that this does not have any effect compared to nearest resampling. Does anybody have a clue why? Command used was gdaladdo -ro -r cubic image.tif 2 4 8 16 32 64 Thanks in advance for any help Armin -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://portal.gmx.net/de/go/dsl ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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
Re: [gdal-dev] Editing attributes with ogr causing corrupt shapefile
Tom,
Can you check the destination shapefile with 'ogrinfo' and see if it works?
If ogrinfo gives a valid output of the new file, check with 'ogrinfo -al'
and compare it with the old file's output.
( http://www.gdal.org/ogrinfo.html )
On Wed, Aug 4, 2010 at 6:57 PM, Tom Jeffery tjeff...@gmail.com wrote:
I'm working with GDAL's Java bindings, and trying to simply add an index
field to a shapefile. This is working, but the resulting shapefile gets
corrupted somehow, where viewing it in ArcMap causes the message Warning,
inconsistent extent. and viewing it in ArcCatalog shows all the points in
the shapefile in the very upper left corner of the preview. (Viewing the
metadata tab in ArcCatalog will crash the program.)
Below is the method where I'm adding the index field... is there anything
I'm missing / obviously wrong here? Any help would be greatly appreciated!
Thanks,
-Tom Jeffery
public static void addIndex(File input, String fieldName) throws
Exception
{
ogr.RegisterAll();
DataSource dataSource = ogr.Open(input.getAbsolutePath(),
true);
if (dataSource == null) {
throw new Exception(Error opening input file while
trying to add
index.);
}
// Shapefiles have a single layer
Layer layer = dataSource.GetLayer(0);
// Creating an OFTInteger alone didn't seem to do the trick,
but setting
the width to 9 created a Long Integer
// field (as viewed in ESRI)
FieldDefn newField = new FieldDefn(fieldName,
ogr.OFTInteger);
newField.SetWidth(9);
int result = layer.CreateField(newField);
if (result != ogr.OGRERR_NONE)
throw new Exception(Got OGR error code: + result
+ when trying to
add new field to shapefile.);
for (int i = 0; i layer.GetFeatureCount(); i++) {
org.gdal.ogr.Feature feature = layer.GetFeature(i);
feature.SetField(fieldName, i);
layer.SetFeature(feature);
feature.delete();
}
// you must call delete (or Destroy in c/c++) to properly
close / write
the datasource..
layer.delete();
dataSource.delete();
}
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Editing-attributes-with-ogr-causing-corrupt-shapefile-tp5372483p5372483.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
--
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
Re: [gdal-dev] Re: Editing attributes with ogr causing corrupt shapefile
Tom, GDAL/OGR updates the shapefile along with the dbf file when a feature is changed. That means updating the extents according to the geometries in the changed features. My guess is that there is a problem reading a feature's geometry extents. Call the OGRGeometry::getEnvelope method on each geometry and check if the OGREnvelope::MinX and OGREnvelope::MinY values are within the expected extents. You can isolate the problem this way. Otherwise, put together a sample dataset and create a new ticket at http://trac.osgeo.org/gdal/newticket On Wed, Aug 4, 2010 at 10:00 PM, Tom Jeffery tjeff...@gmail.com wrote: Chaitanya, The updated file is read properly with ogrinfo. The only difference between ogrinfo -al between the two, besides the new field that was created, is the extent, which looks like this: Original file: Extent: (1528126.013001, 45899.818172) - (1542444.478012, 61468.662925) Updated file: (-17976931348623157.00, -17976931348623157.00) - (1542444.478012, 61468.662925) That...is a really large negative number! Any idea why it might be getting blown up? -Tom Chaitanya kumar CH wrote: Tom, Can you check the destination shapefile with 'ogrinfo' and see if it works? If ogrinfo gives a valid output of the new file, check with 'ogrinfo -al' and compare it with the old file's output. ( http://www.gdal.org/ogrinfo.html ) -- 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 -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Editing-attributes-with-ogr-causing-corrupt-shapefile-tp5372483p5373236.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 -- 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
Re: [gdal-dev] new GDAL driver: how to proceed?
Constantin, In GDAL code, autoconf is used with configure.in to generate the configure script. In earlier versions of autoconf, configure.ac was named configure.in, which is still being used here. I believe it works almost the same. It is handwritten. Refer to http://trac.osgeo.org/gdal/wiki/rfc8_devguide for developer guidelines. A test script in python is created in the autotest suite for each driver (http://trac.osgeo.org/gdal/browser/trunk/autotest). You can look at the other raster driver test scripts at http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers for a general idea. Add any tests you think are specific to this format. Your code will go through a GDAL maintainer. So, don't worry too much about styling, etc. On Thu, Aug 5, 2010 at 1:48 AM, Constantin Jucovschi c.jucovs...@jacobs-university.de wrote: Hi Chaitanya, My question concerns the configure script. I cannot find a configure.ac file to specify the libraries which have to be searched for in order to be able to compile/use rasdaman driver for GDAL. Does that mean I should write code in the configure.in file, which does look like it's handwritten? Is there any requirements on code style/readability/testing I should know? Thanks in advance, Constantin -- 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
Re: [gdal-dev] [GDAL_TRANSLATE]Problem with colorimetry
Tacot, If the red pixels are shaped like a block, it could be a missing tif image. Otherwise, there may be a discrepancy in the nodata values. A screenshot of your data can help. On Tue, Aug 3, 2010 at 5:48 PM, Tacot cfa...@hotmail.fr wrote: Hi, I try to assemblez several TIF to make a unique picture. I use this command: C:\GDAL\SCAN25_SCOTgdalbuildvrt truc.vrt C:\GDAL\SCAN25_SCOT\*.tif -srcnodata 0 0 0 0...10...20...30...40...50...60...70...80...90...100 - done. C:\GDAL\SCAN25_SCOTgdal_translate -of GTiff C:\GDAL\SCAN25_SCOT\truc.vrt C:\GDAL\SCAN25_SCOT\truc.tif But a part of the picture gets a lots of red pixels. Does someone know why? Thanks Tacot -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-TRANSLATE-Problem-with-colorimetry-tp5368059p5368059.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 -- 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
Re: [gdal-dev] new GDAL driver: how to proceed?
Peter, Please create a new ticket at http://trac.osgeo.org/gdal/newticket and attach your code. If all goes smoothly, it will be added into the 1.8 branch of GDAL and released with GDAL-1.8.0 On Tue, Aug 3, 2010 at 12:20 AM, Peter Baumann p.baum...@jacobs-university.de wrote: Dear GDAL maintainers, we have written a GDAL driver to add the rasdaman database as another data format that GDAL can read, and we would like to contribute this to the GDAL project. Rasdaman is a raster database middleware offering an SQL-style query language on multi-dimensional arrays of unlimited size, stored in a relational database. See www.rasdaman.org for the open-source code, documentation, etc. Currently rasdaman is under consideration for OSGeo incubation. In our driver implementation, GDAL connects to rasdaman by defining a query template which is instantiated with the concrete subsetting box upon every access. This allows to deliver 2-D cutouts from n-D data sets (such as hyperspectral satellite time series, multi-variable climate simulation data, ocean model data, etc.). In particular, virtual imagery can be offered which is derived on demand from ground truth data. Some more technical details are given below [1]. The code compiles smoothly with the latest GDAL code and is undergoing final tests and documentation. For a clean integration with the GDAL code base we are asking for further advice. In particular, our Makefile structure needs some fine tuning, we need to know intended use of some parameters. We hope that this contribution is of value to the community, any comments are highly appreciated. Thanks in advance for your assistance, Peter Constantin [1] The connect string syntax follows the WKT Raster pattern and goes like this: rasdaman: query='select a[$x_lo:$x_hi,$y_lo:$y_hi] from MyImages as a' tileXSize=512 tileYSize=512 [host='localhost'] [port=7001] [database='RASBASE'] [user='rasguest'] [password='rasguest'] The rasdaman query language (rasql) string in this case only performs subsetting. Upon image access by GDAL, the $ parameters are substituted by the concrete bounding box computed from the input tile coordinates. However, the query provided can include any kind of processing, as long as it returns something 2-D. For example, this determines the average of red and near-infrared pixels from the oldest image time series: query='select ( a.red+a.nir ) /2 [$x_lo:$x_hi,$y_lo:$y_hi, 0 ] from SatStack as a' The further key-value pair parameters in brackets are optional, their defaults are listed. BTW, the default user has read-only access to the database as per rasdaman convention. As rasdaman supports concurrent access with parallel query evaluation, any number of such connections can be opened. -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 147737) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (mail disclaimer, AD 10xx) ___ 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
Re: [gdal-dev] GeoTiff null values
Filippo,
Please note that those values are called nodata values.
Nodata value is assigned a specific value during the creation of the raster
and all the pixels where data is unavailable are assigned that value.
Using the python interface, you can find the specified value with
GetNoDataValue(). You can compare it with None to check if a value is set.
if band.GetNoDataValue() != None:
print band.GetNoDataValue()
else:
print 'nodata not set'
You cannot reset all the nodata pixels of a raster band directly. You can
create a VRT file to do this. The VRT driver can translate the nodata value
from the underlying dataset to the value you specify with
NoDataValue99/NoDataValue. http://www.gdal.org/gdal_vrttut.html
On Fri, Jul 30, 2010 at 11:44 AM, Filippo Corò filippo.c...@alice.itwrote:
Hi List,
I'm running tests with GDAL 1.7 and python for achieving a function for
the sum of GeoTIFF file. I found some difficulty in handling null values.
I wanted to know if you can assign a specific value (like 99) to null when
I call the Open function.
The code is as follows:
# Open the image 1
primoDs=gdal.Open('eros.tif', GA_ReadOnly)
primoBand=primoDs.GetRasterBand(1)
If I use the following function:
noval=primoBand.GetNoDataValue()
print noval
I get:
0.0 with null value:
Is there any statement at this stage allow me to decide what value to
assign to null, when I call gdal.open?
Thanks in Advance
Filippo Corò
--
Creato con il rivoluzionario client e-mail di Opera:
http://www.opera.com/mail/
___
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
Re: [gdal-dev] Append a shapefile to a postgis table using the GDAL/OGR CSharp interface
Esben,
I am not sure why the value is not quoted in the error report. The
PostgreSQL driver quotes the string values.
When using CreateFeature() you need to make sure to set the feature's FID to
OGRNullFID using SetFID(OGRNullFID). In your error report it shows that
ogc_fid is set to 0. Perhaps there is already a feature with that value?
On Fri, Jul 23, 2010 at 7:05 PM, Esben Taudorf e...@le34.dk wrote:
Hi everybody
I just started using the GDAL/OGR CSharp interface in Visual Studio and it
works great.
I am trying to append a shapefile to a postgis table. This I can do with
the following lines in ogr2ogr:
Fist import the shapefile to postgis a table
ogr2ogr -f PostgreSQL PG:dbname='postgis' host='localhost' port='5432'
user='...' password='...' -lco PRECISION=NO -lco GEOMETRY_NAME=geom -a_srs
EPSG:25832 c:\temp\testfile.shp
Then append the same shapefile (this is a test) to the same postgis table
like this
ogr2ogr -append -update -f PostgreSQL PG:dbname='postgis'
host='localhost' port='5432' user='...' password='...'
c:\temp\testfile.shp
But how do I do this in the GDAL/OGR CSharp interface or which classes and
functions do I use?
So far what I have done is:
Open a layer from the shapefile:
string fileShp = @c:\temp\testfile.shp;
DataSource InputDataSource = Ogr.Open(fileShp, 0);
Layer inputLayer = InputDataSource.GetLayerByIndex(0);
FeatureDefn def = inputLayer.GetLayerDefn();
Open a datasource to postgis:
OutputDriver = Ogr.GetDriverByName(PostgreSQL);
DataSource OutputDataSource = OutputDriver.Open(PG:dbname='postgis'
host='localhost' port='5432' user='...' password='...', 1);
Copy the layer to the postgis table:
Layer outputLayer = OutputDataSource.CopyLayer(inputLayer, def.GetName(),
new string[] { GEOMETRY_NAME=geom, PRECISION=NO }); //How to add -a_srs
EPSG:25832?
This works to import the shapefile to a postgis table. But what should I do
when to append the same shapefile to the postgis a table. So far I have done
this:
Open a layer from the shapefile:
string fileShp = @c:\temp\testfile.shp;
DataSource InputDataSource = Ogr.Open(fileShp, 0);
Layer inputLayer = InputDataSource.GetLayerByIndex(0);
FeatureDefn def = inputLayer.GetLayerDefn();
Open a datasource to postgis:
OutputDriver = Ogr.GetDriverByName(PostgreSQL);
DataSource OutputDataSource = OutputDriver.Open(PG:dbname='postgis'
host='localhost' port='5432' user='...' password='...', 1);
Layer outputLayer = OutputDataSource.GetLayerByName(def.GetName());
Feature feat;
while ((feat = inputLayer.GetNextFeature()) != null)
{
outputLayer.CreateFeature(feat);
}
The CreateFeature functions fails with a syntax error in the INSERT
command. Below is a short version of the command with the syntax error:
Command: INSERT INTO testfile (geom , ogc_fid , name) VALUES
(GeomFromEWKT('SRID=-1;POINT (701678 6152444)'::TEXT) , 0 , Test)
The field name is a character varying in postgis a the command needs
single quotes around 'Test'.
How do I solve this syntax error?
I am also wondering how to assign an output SRS when creating the postgis
table like the ogr2ogr flag -a_srs EPSG:25832?
Any help or comment would be appreciated.
Regards Esben.
___
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
Re: [gdal-dev] Changing GDALDataset Pixel Line Resolution
Alex, The GDALWarpOperation class gives you extrapolation options. Make sure to set the variable GDALWarpOptions::eResampleAlg to GRA_CubicSpline. On Wed, Jul 21, 2010 at 2:09 PM, Alexander Plum alexander.p...@cae.dewrote: Hello there, I want to increase the size of a GDALDatasetH which has 1177 lines und 1177 pixels. It should have 7061 lines and also 7061 pixels but I do not know how to extrapolate the size of the GDALDataset. The cells of the GDALDatasetH contain elevation values. The cublicspline algorithm shall furthermore be employed for the extrapolation of the cells. I would be grateful for any help, Alex -- This email was Anti Virus checked by CAE ___ 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
Re: [gdal-dev] Optimizing access to shapefiles
Martin, These changes look quite promising. Please add two tickets at http://trac.osgeo.org/gdal/newticket , one for each topic, and attach the patch. On Mon, Jul 19, 2010 at 5:38 PM, Martin Dobias wonder...@gmail.com wrote: Hi, in order to speed up rendering in QGIS as a part of my GSoC project, I've took some time to profile reading of shapefiles in OGR. From the results I'd like to suggest some changes that significantly contribute to the speed of data retrieval. On a test shapefile of a road network (about 100 thousand polylines), I have seen 3-4 times faster retrieval when I've implemented the following changes: 1. allow users of OGR library set which fields they really need. Most of time is wasted by fetching all the attributes, but typically none or just one attribute is necessary when rendering. For that, I've added the following call: OGRLayer::SetDesiredFields(int numFields, int* fields); The user passes an array of ints, each item tells whether the field should be fetched (1) or not (0). The numFields tells the size of the array. If numFields 0 then the layer will return all fields (default behavior). The driver implementation then just before fetching a field checks whether to fetch the field or not. This optimization could be easily used in any driver, I've implemented it only for shapefiles. The speedup will vary depending on the size of the attribute table and number of desired fields. On my test shapefile containing 16 fields, the data has been fetched up to 3x faster when no fields were set as desired. 2. reuse allocated memory. When a new shape is going to be read within shapelib, new OGRShape object and its coordinate arrays are allocated. By reusing one such temporary OGRShape object within a layer together with the coordinate arrays (only allowing them to grow - to accommodate larger shapes), I have obtained further speedup of about 30%. I'm attaching patch for both cases. I'd like to hear from you if there is interest in making the OGR library faster using the suggested strategies. I don't expect the patch to be applied as-is since it is kind of a quick hack, though I hope it can serve well for a discussion. If there is interest, I think of some further optimizations by reusing OGRFeature instances and possibly also geometries - I expect further performance improvement of 10-20% in read access to features for all drivers. Regards Martin ___ 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
