[gdal-dev] [Q] gdal2tiles.py hack for 16-bit data

Hi All, As far as I can tell, there is a discussion about extending gdal2tiles to accommodate more data types. Is this correct? In the near-term, is there a hack or a beta version that will allow me to output tiles besides 8-bit PNGs? Thanks in Advance. /trk

Re: [gdal-dev] gdal_translate drops overviews

Le vendredi 14 janvier 2011 08:41:42, Jean-Claude Repetto a écrit : > On 01/14/11 00:02, Even Rouault wrote: > > Le jeudi 13 janvier 2011 22:33:41, Jean-Claude REPETTO a écrit : > >> Thanks for your answer. Unfortunately, I get an error message : > >> > >> $ gdal_translate -co COPY_SRC_OVERVIEWS=Y

Re: [gdal-dev] [ogr] Unexplained third dimension in linear ring

Thanks for your clear explanation and easy workaround. I filed the ticket: http://trac.osgeo.org/gdal/ticket/3907 On 14/01/2011 16:07, Chaitanya kumar CH wrote: 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

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 wrote: > > The problem seems to be tha

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 a

Re: [gdal-dev] [ogr] Unexplained third dimension in linear ring

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, doub

[gdal-dev] [ogr] Unexplained third dimension in linear ring

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 #include int

Re: [gdal-dev] Problem with gdalwarp and resampling_method

Hi Jan, There is a simple TYPO in your commands: -s_src EPSG:25832 -t_src EPSG:31468 you should use: -s_srs EPSG:25832 -t_srs EPSG:31468 Note the last char for the referencing options, is an "s" instead of a "c". Then -s_srs instead of -s_src and -t_srs instead of -t_src :) Hope this helps :) D

[gdal-dev] Problem with gdalwarp and resampling_method

HI ! i will translate a tif-image between two systems and use following command gdalwarp -s_src EPSG:25832 -t_src EPSG:31468 D:\\Orthophotos\2616_5806_RGB.tif D:\\Orthophotos\2616_5806_RGB_GK.tif then i get following message... Usage: gdalwarp [--help-general] [--formats] [-s

[gdal-dev] GDAL WriteArray Memory Error (Python)

Hi, When doing the following in Windows XP, I get an error: dst_ds.GetRasterBand(band_num).WriteArray ( rasterarray ) Traceback (most recent call last) ... File "C:\Python26\lib\site-packages\osgeo\gdal_array.py", line 160, in BandWriteArray array = array.astype( numpy.float64 ) MemoryErro