Re: [gdal-dev] Countour polygons instead of lines

>From a user perspective, this can be done pretty easily using gdal_calc.py & gdal_polygonize.py. I've used this technique in the past several times. This doesn't help with gdal_contour of course, but is a viable way of doing the same thing. Maybe worth considering as a new python tool. Using a ra

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

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

Re: [gdal-dev] Conversion from ASCII to GeoTIFF with gdalwarp: incorrect output

I would use the CENTER_LONG config argument. That will extend the raster past the -180/180 boundary depending on which side you want to extend. --config CENTER_LONG 180 Upper Left ( 176.0010322, -16.1523859) (176d 0' 3.72"E, 16d 9' 8.59"S) Lower Left ( 176.0010322, -18.2685614) (176d 0' 3.72"E,

Re: [gdal-dev] Re: Mask and GEOTiff

You could run gdal_polygonize on the mask geotiff and then use the output vector with gdal_rasterize. That's the only way I can think of without writing a python script to do the pixel comparisons. Jamie On Thu, Apr 28, 2011 at 2:30 AM, canduc17 wrote: > I think gdal merge is the easier way. >

[gdal-dev] gdal_translate format listing is too long

Hello all, Question - is there some reason why gdal_translate needs to show a format listing when invoked on the command line with no arguments? On my system this outputs 61 lines which is nearly a maximized shell on my 24" monitor. Wouldn't requiring the --formats flag be more consistent with o

Re: [gdal-dev] kmlsuperoverlay nodata support

> > > > *Gdal_translate.exe –of KMLSUPEROVERLAY c:\my.tif c:\myResult.kmz –co > FORMAT=PNG* > > > > *Regards,* > *Harsh Govind* > > *From:* gdal-dev-boun...@lists.osgeo.org [mailto: > gdal-dev-boun...@lists.osgeo.org] *On Behalf Of *Jamie Adams > *Sent:* Monday, October

[gdal-dev] kmlsuperoverlay nodata support

I'm evaluating the new kmlsuperoverlay driver in trunk and have been unable to get nodata values to show up as transparent in the output. Are there format specific creation options I should be using? - Jamie ___ gdal-dev mailing list gdal-dev@lists.osge

Re: [gdal-dev] OT: Need help with proj definition

I quickly ran this in a python shell: >>> from osgeo import osr >>> wkt = 'GEOGCS["GCS_ITRF_2000",DATUM["D_ITRF_2000",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]' >>> srs = osr.SpatialReference() >>> srs.ImportFromWkt(wkt) >>> srs.Ex

Re: [gdal-dev] flipping raster in python

_count > count: > print new_count > count = new_count > > inline = inband.ReadAsArray(0, i, inband.XSize, 1) >flipline = numpy.fliplr(inline) >outband.WriteArray(flipline, 0, i) > >inline = None > > inband = None > outband = None >

[gdal-dev] flipping raster in python

I've written some simple Python code to flip a raster in relation to the y-axis. The raster is 2x19459 and has 4 bands of type Byte, and is written east to west (I have no idea why). The script proceeds normally for the first 2 bands, but slows way down after starting band 3. I let it run ov

Re: [gdal-dev] No PROJ.4 translation for source SRS

There is no UTM zone specified in the input proj string. Is that the issue? On Tue, Jan 19, 2010 at 5:36 AM, Smart, Gary wrote: > I still can’t get to the bottom of this message – can anyone explain it… > > > > *ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation > initial

Re: [gdal-dev] Proper input for TransformPoint

I have it working for KML output like this: *projection = dataset.GetProjection()* *in_projection = osr.SpatialReference() in_projection.ImportFromWkt(projection)* * out_projection = osr.SpatialReference() out_projection.ImportFromEPSG(4326) coortran = osr.CoordinateTransformation(in_projection,

Re: [gdal-dev] open source tool

You probably want these, specifically las2tin.exe : http://www.cs.unc.edu/~isenburg/lastools/ - Jamie 2009/8/27 Riki Tiki > hi, > > do you know any tools available for the conversion of LAS (LIDAR data) into > Voronoi diagrams or TIN (triangular irregular networks)? thanks a lot! > > or anyone

[gdal-dev] gdal2tiles altitude mode clampToSeaFloor ?

Hello all, Is there a way to get the 1.6 version of gdal2tiles to clamp tiles to the seafloor? I've tried modifying the script with & , but the tiles remain clamped to z=0. What's the correct approach? - Jamie ___ gdal-dev mailing list gdal-dev@lists

Re: [gdal-dev] gdal and gras from svn, export problem GTIFF - UINT32

I had a similar issue with gdal gtiff output awhile back and solved it by using the internal gdal libtiff. Try using "--with-libtiff=internal" when compiling gdal. -Jamie On Mon, Apr 27, 2009 at 3:57 AM, massimo di stefano wrote: > Hi All, i'm having problems using gdal (svn version) from gras

Re: [gdal-dev] need suggestion on Linux OS

+1 for Ubuntu I too have been using Ubuntu 8.04 (Hardy) to compile and run GIS apps & libs (grass, gdal, qgis, geos, proj, etc) and have had no problems at all. On Wed, Apr 22, 2009 at 9:55 AM, Roger André wrote: > I have been running a fairly complete open source GIS stack on a couple of > Ubu

Re: [Gdal-dev] gdaltransform v.1.6.0 - result differs from documentation

Looks like they may have added a towgs84 parameter to the proj definition for 31370: http://postgis.refractions.net/pipermail/postgis-commits/2008-May/000283.html That would likely explain the shift - the documentation probably hasn't been updated. On Sat, Apr 18, 2009 at 1:53 PM, geep999 wrote

Re: [gdal-dev] gdal contour, output polygon

You could also try using gdal_polygonize, but you'd need to find a way to reclass your source raster to discrete groups (i.e, elevation ranges). This could be done pretty easily using python, maybe something like val_repl.py

Re: [gdal-dev] Help with Maine state plane US feet

Hey Michael, Have you tried EPSG 102684? There's a esri_extra file in the FWTools/share dir that has additional definitions, including Maine Stateplane West Nad83 Feet. Cheers, Jamie Adams On Mon, Jan 26, 2009 at 6:01 AM, Smith, Michael wrote: > I am trying to work with severa

Re: [gdal-dev] gdal_rasterize usage problems

;Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]] As far as the reprojection goes, are you getting errors in the output

Re: [gdal-dev] gdal_rasterize usage problems

Hey Andrew, Are your files in the same projection? I know gshhs is projected in wgs84 by default, and I see your raster is in British National Grid. AFAIK, gdal_rasterize assumes the vector & raster data sets are in the same projection. -Jamie On Mon, Nov 10, 2008 at 11:11 AM, Andrew Brooks <[

Re: [gdal-dev] error using gdaltindex on grass rasters

I'm using GDAL 1.5.2 built on Ubuntu 8.04. On Wed, Oct 15, 2008 at 1:45 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 7:29 PM, Jamie Adams <[EMAIL PROTECTED]> wrote: > > Hello all, > > > > I needed to create a shapefile index of

[gdal-dev] error using gdaltindex on grass rasters

Hello all, I needed to create a shapefile index of all the rasters in a grass mapset so I ran: ls /grass/location/mapset/cellhd/* | xargs gdaltindex all.shp and got this error: Warning 1: GRASS warning: Unable to open datum table file /usr/local/share/gdal/grass//etc/ellipse.table: No such fil

Re: [gdal-dev] gdal2tiles.py - can additional Zoom levels be forced?

Hey Roger, You can always make create an up-sampled VRT of the source image with "gdalwarp -of VRT -tr x y". Yes, it does involve an additional step, but the VRT takes almost no time to create and doesn't waste disk space. You can then use that as the input to gdal2tiles. From the limited tests

Re: [gdal-dev] Re: The world is flipped redux

It looks like Matt's script doesn't modify the geotransform, just reverses the rows in the image. You probably need to calculate a new ulx and make sure the pixel dimensions are expressed correctly (+/-). >From the sound of it, your original image would actually be right if the viewer software re