Re: [gdal-dev] CADRG subdataset access help
Christiaan Janssen wrote: How exactly does one go about accessing the raster data in an format that contains subdatasets like CADRG? Any help would be greatly appreciated. Christiaan, Are you working programmatically or as a user with end-user tools like gdalinfo and gdal_translate? For an end user, one would normally run gdalinfo against the file/dataset and see the reported subdataset names. Then run gdalinfo or gdal_translate against the desired subdataset name. Scripts/applications operate similarly, fetching the subdataset names from metadata. You may find it helpful to read the section titled SUBDATASETS Domain in this doc: http://www.gdal.org/gdal_datamodel.html Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] CADRG subdataset access help
Christiaan Janssen wrote:
I'm working programmatically. I sort of understand the mechanism described in
the suggested document but would greatly appreciate a short snippet to show how
one goes about opening the subdataset. I'm guessing in the example described on
the web page that to open the first dataset I would call GDALOpen as follows:
GDALOpen(NITF_IM:0:multi_1b.ntf, GDALAccess::GA_ReadOnly);
Christiaan,
Yes, though you don't normally need to qualify GA_ReadOnly. The following
code chunk out of gdal_translate (used to recurse over subdatasets) might
also be helpful.
/* */
/* Handle subdatasets. */
/* */
if( CSLCount(GDALGetMetadata( hDataset, SUBDATASETS )) 0 )
{
if( !bCopySubDatasets )
{
fprintf( stderr,
Input file contains subdatasets. Please, select one of
them for reading.\n );
}
else
{
char **papszSubdatasets = GDALGetMetadata(hDataset,SUBDATASETS);
char *pszSubDest = (char *) CPLMalloc(strlen(pszDest)+32);
int i;
int bOldSubCall = bSubCall;
argv[iDstFileArg] = pszSubDest;
bSubCall = TRUE;
for( i = 0; papszSubdatasets[i] != NULL; i += 2 )
{
argv[iSrcFileArg] = strstr(papszSubdatasets[i],=)+1;
sprintf( pszSubDest, %s%d, pszDest, i/2 + 1 );
if( ProxyMain( argc, argv ) != 0 )
break;
}
bSubCall = bOldSubCall;
CPLFree( pszSubDest );
}
GDALClose( hDataset );
if( !bSubCall )
{
GDALDumpOpenDatasets( stderr );
GDALDestroyDriverManager();
}
return 1;
}
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| President OSGeo, http://osgeo.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Guidance sought on using gdal-translate
Christopher Hunt wrote: Hi Frank et. al, Sorry to be a pest. I've been trying tons of things, trawling tons of search results, and I'm really no better off than I was a few days ago. :-P In summary I have an aerial photo image of an airport with three well known points (expressed in lat/longs). I'm wanting the image to be projected using a equidistant cylindrical projection. On gdal_translate's gcps, I'm presuming that the origin of the image is assumed to be top-left for the gcp pixel and line values... and that the gcp easting and northing values are expressed in metres? Chris, Correct. How do I centre a projection? lat_0 and lon_0 values? Thanks again for your time - I appreciate that time is precious. I honestly believe that reprojection is the wrong tool to take a raw aerial photo and try to turn into an orthophoto. Normally this process is address by orthorectification software that takes into account the geometry of the camera lens, the orientation of the camera when the photo is taken, and the elevation model of the target region. If you are going to try and accomplish orthorectification by something as simple as reprojection then the fit is going to be relatively poor in all but the most ideal circumstances. So, sorry to say it, but I'm not going to wrack my brain to try and solve a problem that I think is likely insolvable. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| President OSGeo, http://osgeo.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Minimalist Windows binaries (OGR)
Philippe Kruschitz wrote: Thanks Frank and Matt, I'll have a look at it. Regarding the .prj-file generation, starting with what version does GDAL do it? The newer FWTools have it, but the 1.5.0 version (at least the one included in those minimalist binaries) doesn't. Philippe, I'm afraid I've lost a bit of our thread. The OGR Shapefile driver has supported .prj files since at least GDAL/OGR 1.4.0 if that is the question. I'm not sure what problem you are having with 1.5 binaries. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] could GDAL enforce towgs84=0, 0, 0 for ETRS89-based CRSs?
Maciej, Please file a ticket against the PROJ trac on this issue. I'm hoping to take advantage of datum and other definitions from CSMap at some point which may help. Otherwise, I'll try and include an override for ETRS89 which indicates that it can be treated as equivelent to WGS84 if that is in fact a reasonable approach. Best regards, FrankW On Wed, Jul 30, 2008 at 6:01 PM, Maciej Sieczka [EMAIL PROTECTED] wrote: Hi, Due to a change in PROJ 4.6.0, no datum shift is aplied when reprojecting between a CRS which has an implicit datum definition (e.g. Pulkovo 1942/58-based EPSG 4179, for which GDAL uses towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84) and an ETRS89-based CRS, e.g. EPSG 2180, that has no implicit towgs84 or datum. The above results in reprojection errors of about 150 m and makes using EPSG codes for ETRS89-based CRS impossible. Could PROJ.4 and GDAL enforce towgs84=0,0,0 for all ETRS89 CRSs that have no implicit datum definition otherwise? For instance, GRASS always forces towgs84=0,0,0 for EPSG 2180 and does the reprojection right. Maciek -- Maciej Sieczka www.sieczka.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Segmentation fault using gdal 1.4.4 and 1.5.2 on netcdf data
On Thu, Aug 14, 2008 at 12:42 PM, Vishal Mehta [EMAIL PROTECTED] wrote: 2. I compiled from source gdal1.5.2 from http://trac.osgeo.org/gdal/wiki/DownloadSource using the following configure ./configure --with-netcdf=/usr/lib --with-libtiff=yes --with-geotiff=yes --with-jpeg=/usr/lib --with-gif=/usr/lib --with-png=/ur/lib --with-pg=/usr/bin/pg_config --with-libgrass=yes make sudo make install and made sure the libgdal link was referring to the new one. I tried gdalinfo file.nc and again got 'segmentation fault' it works for other data types; only netcdf does not work (just like before with gdal1.4.4) Vishal, Have you tried with other netcdf files? How big is big? Perhaps you are encounter a 2GB file size limit? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deleting feature exceptions
Chen,
I'm surprised both approaches don't work smoothly. I'd suggest you boil
down a minimum example of the problem, and file a bug ticket on it
including the input data.
Best regards,
FrankW
2008/8/14 wow [EMAIL PROTECTED]:
Hi,
i try to delete features from a set of shape file, sometimes get error. I
use this version of ogrshapelayer.cpp :
http://trac.osgeo.org/gdal/changeset/10969 . Delete feature in two ways
would get different result:
(1) for(iFeat=0;iFeatnFeat;iFeat++)
{
int cplE = pLayer-DeleteFeature(0);
if(cplE==CE_None)
{
OGRShapeLayer* pShpLayer = (OGRShapeLayer*)pLayer;
cplE = pShpLayer-Repack();
if(cplE!=CE_None)
{
printf(delete feature failed ！\n);
return false;
}
}
}
int nFeatRest = pLayer-GetFeatureCount();
These codes could delete each feature with returned value CE_None, and
at the end nFeatRest=0. But when ran to pShpLayer-Repack() second, the
error occurs: Failure writing DBF record 0, it jumped untill all features
were deleted.
(2) for(iFeat=nFeat-1;iFeat=0;iFeat--)
{
int cplE = pLayer-DeleteFeature(iFeat);
if(cplE==CE_None)
{
OGRShapeLayer* pShpLayer = (OGRShapeLayer*)pLayer;
cplE = pShpLayer-Repack();
if(cplE!=CE_None)
{
printf(delete feature failed ！\n);
return false;
}
}
}
int nFeatRest = pLayer-GetFeatureCount();
These codes could delete each feature with returned value CE_None, but
at the end nFeatRest0 and nFeatRestnFeat, some features were NOT deleted
yet! Same as (1), when ran to pShpLayer-Repack() second, the error
occurs: Failure writing DBF record iFeat, it jumped untill all features
were deleted.
Trace the error Failure writing DBF record ... into Repack():
/*
*/
/* Build a list of records to be dropped.
*/
/*
*/
...
for( iShape = 0; iShape nTotalShapeCount; iShape++ )
{
if( DBFIsRecordDeleted( hDBF, iShape ) )//ERROR jumped
-
panRecordsToDelete[nDeleteCount++] = iShape;
}
Why did this phenomena occurs?
Thank you.
--
To the world you're little, but to a person you're the world.
Chen Xuexia
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Guidance sought on using gdal-translate
On Fri, Aug 15, 2008 at 8:41 AM, Christopher Hunt [EMAIL PROTECTED] wrote: Hi again Frank et. al, I've made some progress. The aerial image provider now tells me that it is projected as OSGB 1936 which I believe is EPSG:27700. Thus if I use a command like: gdal_translate -a_srs EPSG:27700 -a_ullr then I should be able to create my GeoTIFF. Unfortunately the image provider hasn't provided the top left/bottom right coords so I'm going to Google Earth to approximate them (yes, ugly I know). I'm hopeful that the actual top left/bottom right will ultimately be provided to me, but meanwhile I want to ensure that the a_ullr parameters I provide will be in metres i.e. eastings and northings from the OSGB 1936 origin. Is this correct? Chris, I believe EPSG:27700 is British National Grid which is a projected coordinate system based on the OSGB 1936 datum. So you should ensure the provider means the dataset is actually in BNG, in addition to being based on OSGB 1936. If you can get BNG coordinates then that is great. If you can only get WGS84 or OSGB1936 lat/long coordinates then you can convert these to BNG using a program like cs2cs though that is a bit tricky. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Disabiling Geos messages via OGR
On 8/15/08, Brent Fraser [EMAIL PROTECTED] wrote: I'm using OGR's Geos functions (e.g. OGRGeometry::IsValid) to process some polygons. Geos spits out messages to console (stderr?) like Warning 1: Self-intersection at or near point Is there a way to disable these messages via OGR? Brent, OGR reroutes GEOS errors and warnings via the CPL error reporting mechanism. So, if you are working programatically you could install a custom warning/error handler (see CPLPushErrorHandler() for instance). If you are just using the utilities there is no practical way to filter out the GEOS messages other than by redirecting stderr to /dev/null. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reprojection differs between FWtools versions
On 8/16/08, Koen Mannaerts [fietsnet.be] [EMAIL PROTECTED] wrote: Hi all, I noticed that ogr2ogr in FWtools 1.0.0.a7 returns a different result than ogr2ogr in FWtools 2.2.0, 2.2.1. Koen, The behavior of PROJ.4 changed between PROJ 4.5.x and PROJ 4.6.0. In particular, PROJ.4 will no longer attempt to apply a change of ellipsoid when going between different ellipsoids if no datum information is provided. No doubt it's due to what I pass as arguments. The idea is to convert Belgian Lambert, Belgian Datum shapefiles to Lat/Lon WGS84. With the following arguments 1.0.0.a7 does this correctly, 2.2.1 produces polylines ~110m off to the north west (Belgium). -f ESRI Shapefile -s_srs +proj=lcc +lat_2=49.839 +lat_1=51.17 +lat_0=90.000 +lon_0=4.3674867 +x_0=15.013 +y_0=5400088.438 +units=m +ellps=intl +towgs84=-99.059,53.322,-112.486,0.419,-0.830,1.885,-0.99 -t_srs +proj=latlong +ellps=WGS84 I would suggest using +datum=WGS84 in the second definition, instead of (or addition to) +ellps=WGS84. You will also need some datum shift info for the intl ellipsoid. If you want the old behavior, provide +towgs84=0,0,0. This means only a change of ellipsoid will be applied, but no other datum shifting will be done. Do I need to express the argument otherwise to make it work in newer versions? Please also keep in mind that if you play fast and loose with datum shifts, there is a substantial risk that the results are not accurate. At the best of times, a datum shift usually involves some error due to the approximate nature of datum shift formulas. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote: Mainly it is either end of response, image done, or window done to indicate that there is a buffer update and the display should be updated, anything else can pretty much be ignored. Ideally the callback should indicate the region that has changed, since the server is entitled to change the region it streams if the client has requested an invalid ROI. Norman, If we load this capability onto RasterIO() call I don't imagine we would want to allow the client to change the area being loaded. If an invalid ROI is requested the driver should either error out, or only update the valid part of the buffer. The callback isn't per scan line, but a whole window (at a particular resolution level). /ncb Ah, gotcha. I hadn't even considered this aspect! The simpliest case I can imagine would be passing (or installing) a callback that drivers *could* call periodically to indicate that some unspecified area of the RasterIO() buffer has been updated. ncb The callback would need to include the x,y offsets, width, height and resx, resy since otherwise there needs to be too much state synchronization between the format driver and the client. The simplest would be to specify x,y, width, height at the base resolution of the image and to use resx, resy to sample for the display implying the buffer size. The format driver would keep the cache. /ncb OK, now you have lost me. The RasterIO() call includes a buffer, and defines the size of that buffer (in x and y) and the size of file window to load into that buffer. I don't get what you mean about there being too much state synchronization between the driver and the client. Is the main objective to be able to update stuff on the screen while a buffer is being downloaded by JPIP or other slow access mechanisms? ncb Definitely, this is the main objective. A secondary objective is to use the mechanism to download complete sections of a streaming image (so to stream until a window done message) for use with gdal_translate for example. /ncb I don't follow the secondary objective. How does having the callback add value to just reading the data into the buffer in chunks and then writing it to the output file? Perhaps it would make sense to mock up a proposed RasterIO() variation with the callback in RFC form so we can more easily talk about the same thing? This can be done in the trac wiki. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] GTiff / gdal_translate / CMYK - problem
Maksim Sestic wrote: Hi all, I'm having troubles with gdal_translate while creating uncompressed 3-band GTiff with CMYK photometric representation. Well, at least CMYK representation recognized by Photoshop, which is PhotometricInterpretation=5. If I use recommended gdal_translate -co 'PHOTOMETRIC=CMYK' switch I keep getting grayscale (!) result, again, that's what Photoshop says (PhotometricInterpretation=1). What other -co parameters should I set to make it work? I'm using gdal_translate from FWTools 2.2.3 Here's the gdalinfo reports: 1) For RGB raster parsed with gdal_translate -co 'PHOTOMETRIC=CMYK' switch: Size is 945, 945 Coordinate System is `' Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=MyApp TIFFTAG_DATETIME=20.08.2008 02:51:37 TIFFTAG_XRESOLUTION=240 TIFFTAG_YRESOLUTION=240 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 945.0) Upper Right ( 945.0,0.0) Lower Right ( 945.0, 945.0) Center ( 472.5, 472.5) Band 1 Block=945x2 Type=Byte, ColorInterp=Gray Band 2 Block=945x2 Type=Byte, ColorInterp=Undefined Band 3 Block=945x2 Type=Byte, ColorInterp=Undefined Side note: I also tried using -co 'PHOTOMETRIC=YCBCR' and 'PHOTOMETRIC=CIELAB'switches but then gdal_translate crashes. Maksim, I would note that CMYK photometric interpretation requires 4 bands. Furthermore, GDAL does *not* manage the conversion to CMYK color space. You would need to do that ahead of time by some means. I've never tried to create CMYK files so I don't have any further advice. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] SoC Final Report: GDAL TMS driver
Folks, I received the following report from Václav on the GDAL TMS driver status: Since the final deadline has approached, I am sending you the result of my futile attempt to implement the TMS driver. The reading part sort of works. The driver always assumes Origin is in the bottom left corner of the map. There is no support for profiles and projections. It will read the raster data from disk. I could not get the writing right. During testing, gdal_translate regularily calls methods on dataset that has already been deleted, don't know why. The driver will write the xml resource file, create the directory structure and fill it with empty tiles. Writing after this point doesn't work, the cached tiles won't be written and for the life of me I don't know why. Also the IRasterIO implementation is probably bogus too, since gdal_translate calls IWriteBlock only on the TopRasterBand instead of on all overviews as it should. There are no output settings, tiles are hardcoded to PNG, 256x256 pixels. I have uploaded the source he supplied into /spike/tms in the GDAL subversion and added some notes on how to build and test it at: http://trac.osgeo.org/gdal/wiki/SoCTMSDriver The project period is over, and it isn't clear whether Václav will be doing any more work on the driver. I'm available to consult and help with anyone wanting to carry this effort forward. For the time being the project artifacts are captured in the wiki and subversion and should not be lost. Best regards, FrankW ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Support for reading GDAL datasets in compressed archives(.gz and .zip)
Baumann, Konstantin wrote: Hi Even! That sounds cool. Is there also a function for retrieving all available files inside of a ZIP archive? Kosta, Programatically this can presumably be accomplished with VSIReadDir() (aka CPLReadDir()). char CPL_DLL **VSIReadDir( const char * ); The VSI filesystem operations should generally work on virtual file systems, though in the case of the zip driver I presume all the update operations (like VSIRename() or VSIUnlink()) are unimplemented. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Injecting Projection information in CreateCopy
Christiaan Janssen wrote: VRTDatasets seem to be the best way to go in this case. Is there by chance a way to build a VRTDataset that is an exact copy of a GDALDataset or do I need to do it manually (not a big deal if I do). BTW, Thanks for all the help. Christiaan, I believe gdal_translate creates the VRTDataset bit by bit because it may need to alter some fundamental things (like number of bands, types and size). But if all you want to change is malliable stuff such as coordinate system or geotransform you can just use the VRT CreateCopy() and then modify the results. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RE: progressive rendering
Norman Barker wrote: Hi Adam, Tamas, Even, all I have updated the RFC http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support And completely changed the pattern used to reflect the general consensus to use an asynchronous queue for communication between threads. Can you comment on this, and let me know if it is acceptable? Can we iterate this is a few times, and then how is this RFC approved (or rejected!)? Norman, The RFC would be approved or rejected after you (or someone) calls for a vote by the PSC. The voting would normally occur over 2 business days and be done according to: http://trac.osgeo.org/gdal/wiki/rfc1_pmc With regard to the proposal, I'm afraid I'm still not clear on exactly what you are proposing. Is GDALAsyncDataset a new class? Are the methods like Open(), and ProgressiveRasterIO() methods on this new class. I don't understand how this new class relates to GDALDataset. How does one know if the dataset you get back from GDALOpen() supports the async interfaces or not? I presume I'm getting lost in stuff that is supposed to be obvious, but for my sake, I'd appreciate your nailing these aspects down fairly carefully. For instance, I'd like to see the actual C++ declarations for all new methods and classes, not an abstract approximation without argument types. I'd also essentially like to see the reference docs for the new methods. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] tiff support: internal or external?
Andreas Neumann wrote: Hi, I am wondering what are the pros and cons of using tiff support from internal or external (libtiff, libgeotiff). Are there any limitations with either approach? I am specifically wondering about the consequences with the bigtiff support. Do both approaches support bigtiff if I use the most recent versions? Thanks for any hints on what is the better option. Andreas, I think internal and external libtiff+libgeotiff should be equivelent as long as you are essentially using cvs head of libtiff and libgeotiff. So, the internal copies are generally there for convenient building, but if you are preparing complex binaries then using external copies of libtiff and libgeotiff may be more appropriate, such as I do with OSGeo4W and FWTools. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] module of a complex dataset
Antonio Valentino wrote:
Is it possible to extract the module (and possibly the phase) of a
complex dataset using GDAL utilities or playing with the virtual driver?
If I use
$ gdal_translate -ot Float64 src_dataset dst_dataset
on a complex src_dataset it seems to extract the real part.
Antonio,
I am not aware of any way to accomplish this with the virtual driver
or the commandline utilities. But I have added a small sample script doing
this with numpy and python if you would be interested in working from that.
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/magphase.py
import gdal
import gdalnumeric
try:
import numpy
except:
import Numeric as numpy
src_ds = gdal.Open('complex.tif')
xsize = src_ds.RasterXSize
ysize = src_ds.RasterYSize
src_image = src_ds.GetRasterBand(1).ReadAsArray()
mag_image = pow(numpy.real(src_image)*numpy.real(src_image) \
+ numpy.imag(src_image)*numpy.imag(src_image),0.5)
gdalnumeric.SaveArray( mag_image, 'magnitude.tif' )
phase_image = numpy.angle(src_image)
gdalnumeric.SaveArray( phase_image, 'phase.tif' )
I was also impressed to discover today that the numpy manual is now
finally free.
http://www.tramy.us/numpybook.pdf
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GetExtent method
Clay, Bruce wrote: When I used the debugger to step into the OGRLayer GetExtent method I noticed that it walks through all of the features in the dataset and tests the envelope of each feature in the set. Are there any driver specific optimizations (i.e. OCI) that could be called instead of this one since it does take a long time for a large dataset? I realize we can create our own but I would like to use a built in function if it is available. Frank: Since you are working in the OCI driver would this be a good time to add something like: select min(a1.SHAPE.SDO_POINT.X), max(a1.SHAPE.SDO_POINT.X), min(a1.SHAPE.SDO_POINT.Y), max(a1.SHAPE.SDO_POINT.Y) from DatasetName a1; Of course that falls back on the first question, is there already a built in method. Bruce, We already have a specialized implementation of OGROCITableLayer::GetExtent() at: http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/oci/ogrocitablelayer.cpp#L1072 I wonder if this optimized case is failing for some reason for you? Or perhaps you are working with an result from ExecuteSQL()? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal error 4
Christian Willmes wrote: Hello, I have a problem with the gdal Installation on our webserver. I'm new to gdal, to be specific I try to get some raster data into mapserver, but there occours the following error according gdal and I could not find anything what helped me out on google and other mailinglists. I get the following Error when I try to access data with gdal: [EMAIL PROTECTED] gdalinfo SRTM_Elevation.tif ERROR 4: `SRTM_Elevation.tif' not recognised as a supported file format. GDALOpen failed - 4 `SRTM_Elevation.tif' not recognised as a supported file format. - Christian, I would carefully review permissions to see if that might be the issue. I have stepped through the code and confirmed this is the sort of error you get if you don't have read permissions on a file. You might want to file a ticket on this, so we can improve the reporting of errors related to permissions. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] Attaching Text Files in NITF driver
Radeus wrote: Hello, I'm new to GDAL and have not been able to find any information on whether the NITF driver allows you to attach a text file (text segment) to the NITF file on Create or CreateCopy. I have tried with no luck to either attach or read back a NITF file with Text Segments. I have seen that the GDALPamDataset will create the aux.xml filler with the extra data when creating the NITF file, but the information is not actually writen to the NITF file itself. I am currently using build 1.5.2 compiled on VC++ 7.1 for Windows. Is this simply not supported in the NITF driver? If it is not supported, how hard would it be to add this in to the driver? Radeus, You are correct that the NITF driver does not currently support writing text segments. It would not be particularly hard to add. That means it might take me 2-3 hours. Someone unfamiliar with the driver might require a day to get to a stable and safe result. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] SWIG: GetHistogram(), etc
Folks, I have done a bunch of work on http://trac.osgeo.org/gdal/ticket/2477 to get GetHistogram() working in the python bindings. That should now be fixed. I also added the GetDefaultHistogram() and SetHistogram() methods. This email is mostly a notice to all the SWIG maintainers that some attention may be required for them on these new methods in Band.i. GetDefaultHistogram() now works in Python, but I suspect other bindings may need to do some stuff to get it working. The SetDefaultHistogram() method is pretty simple, but requires passing a variable sized array so some language bindings will likely need to work on this. Currently it is not implemented for Python - Howard - perhaps you could take a look or hold my hand through it? Note, all works is in trunk. I'm not inclined to backport this work. I have also added a python test script (autotest/gcore/histogram.py) where I'm accumulating testing of the histogram interface. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Polygonize
Ari Jolma wrote: Ari Jolma kirjoitti: In addition, I found also new Polygonize method! That's great since I'm going to need one soon. Hmm, seems to need much debugging still. Lots of warnings and lots of polygons with two points. Is the code in polygonize.cpp based on a published algorithm? Ari, It is not based on a published algorithm, and it does still need some work before it is ready for prime time (though it works well on my original contrived test image!) Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] Algorithm Development
Fodder wrote: Frank Warmerdam-2 wrote: - An algorithm for interpolation in regions of a raster. Hi Frank, Happy to hear about your research. I'm interested in the interpolation in regions of a raster algorithm. In particular: - What interpolation methods with be supported? Fodder, A simple four quadrant inverse distance interpolation is used. That is, I find the closest valid pixel for each of the four quadrants and then mix them based on inverse distance weighting. Then I apply some number of 3x3 average filtering in the interpolated areas to smooth out various artifacts somewhat. While this approach has a number of problems, I feel it is suitable for use in a variety of circumstances, including sparse data (such as might be the result of burning a bunch of known sample points into a raster), holes in data (such as SRTM or interferometry DEM holes), or to interpolate in data after burning contours into a raster. This is in contrast to approaches such as the spline interpolation in GRASS which produces (presumably) superior results when interpolating in modest sized holes in rasters but that does not scale well to sparse data or to large empty regions like with contours. - What vector sources will be supported (if any) (points only, or polyline polygon etc)? The fill algorithm does not directly use vector data. If you want to produce raster data by interpolating from vectors you would need to first use gdal_rasterize to turn the vectors into a raster, and then use the fill program/functions to interpolate in the holes. I believe someone (Andrey? Even?) has been improving gdal_rasterize to support additional data types. - Will it be incorporated in Gdal_Grid? No. I'm only moderately familiar with gdal_grid but my understanding is that it does not scale particularly well to handling huge numbers of points to interpolate from. But generally speaking gdal_grid will still be much superior for interpolating reasonable amounts of point data to build a raster. - When you say regions, do you mean vector polygons or raster zones? Raster zones. Note that this algorithm is already in trunk as the function GDALFillNodata(). However, I've had some problems with the post fill smoothing filtering and haven't really finished cleaning things up and documenting them. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Datum transformation method when projecting from a sphere to NAD83 shapefile
Limei Ran wrote: Hi: I am using ogr2ogr to project a shapefile defined in a sphere to NAD83. My command is like the following: ogr2ogr -t_srs +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs -s_srs +proj=lcc +a=637.0 +b=637.0 +lat_1=33 +lat_2=45 +lat_0=40 +lon_0=-97 wrf12km_nc_g152.shp wrf12km_nc.shp Limei, You have not provided a datum definition for the source coordinate system, only an ellipsoid definition. If you are using PROJ 4.6.0 or newer no datum transformation at all will be applied. The LCC coordinates will be reprojected to lat/long on the indicated ellipsoid, and then those lat/long values will projected into AEA on the NAD83 datum with no attempt to do any change of ellipsoid or datum shift between the LCC and AEA geographic coordinate system. If you are using anything older than PROJ 4.6.0, there will be a change of ellipsoid applied (which will be quite substantial since the LCC is on a sphere) implemented by converting from lat/long on the LCC sphere, to geocentric coordinates, and then from geocentric coordinates to lat/long on the AEA ellipsoid. This will result in large changes in latitude. So, basically, the approach used depends on the software version. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Datum transformation method when projecting from a sphere to NAD83 shapefile
Limei Ran wrote: Hi Frank: You mentioned that I have not provided a datum definition for the source coordinate system, only an ellipsoid definition. Could you tell me how I can provide the datum definition to get the same result from PROJ4.5? The command I used is: ogr2ogr -t_srs +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs -s_srs +proj=lcc +a=637.0 +b=637.0 +lat_1=33 +lat_2=45 +lat_0=40 +lon_0=-97 wrf12km_nc_g152.shp wrf12km_nc.shp Limei, I believe adding +towgs84=0,0,0 to the lcc definition would result in a sphere to ellipsoid conversion being applied. I will stress that this is generally *not* what you want to do, though it is possible it might make sense in your specific situation. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem in viewing NITF images created by GDAL_TRANSLATE
On Wed, Sep 17, 2008 at 2:26 PM, Mo Wang [EMAIL PROTECTED] wrote: Hi all, I used gdal_translate to make a complete copy of a nitf file and it ran to completion. But the output image file can only be viewed partially on a IMAGINE Viewer while the whole original image file can be viewed on the Viewer. I believe that the data is there just it can not be viewed. Mo, It looks like the NITF writer normally writes the entire NITF file as a single block image (regardless of the blocking of the input image). Possibly a single large block causes problems for imagine, though I'm not sure why that would be. You can force blocking using the BLOCKXSIZE and BLOCKYSIZE parameters. So,if you add -co BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 when running gdal_translate you should get 1024x1024 tiles. Check if that helps. Note that the GDAL NITF writer is not really very sophisticated, and will often be inadequate to reproduce an original NITF given as input. However, it is certainly my intent that it should produce a valid file. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] images with different resolution.
On 9/18/08, Michele Sanges [EMAIL PROTECTED] wrote: Hello all, what is the best way to represent two raster images with different resolution? In other words, how do I calculate the offset respect to the upper left corner of the region that includes both the images? Is there a code example? Michele, I'm not quite clear on what you are looking for. Two raster images with different resolutions would normally be represented as distinct GDAL datasets, each with their own geotransform indicating their original and pixel size. You might find it helpful to read over the section on the geotransform in the data model document: http://www.gdal.org/gdal_datamodel.html If you have the georeferenced origin of a region,and wish to determine the georeferenced distance from there to the origin of a particular image you would just subtract the origin of that images geotransform from the region's origin. Note that the geotransforms origin is the first and fourth element of the array for x and y respctively. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] projection locating image incorrectly.
On 9/18/08, Robert Beckwith [EMAIL PROTECTED] wrote: I downloaded idaho9798landsatencw.sid and its companion files from http://www.idwr.idaho.gov/ftp/gisdata/Spatial/Datareq/ When using gdal this image is re-projected in the wrong location (Africa) Robert, I review the .aux.xml file for this dataset and it looks like it has everything needed by GDAL to correctly place the file. You did have this, right? I can't download the big file (I'm stuck on dialup currently due to technical problems) so I can't easily check what is going on. I *suspect* that there is internal georeferencing in the .sid and GDAL it using it in preference to the info the .aux.xml or perhaps giving preference to the .sdw worldfile. What does a gdalinfo report on this dataset look like? Does it change if you delete the .sdw file? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fastest way to add the GeoTransform to a raster file with Python
On 9/18/08, Lucena, Ivan [EMAIL PROTECTED] wrote: Frank, ... Wouldn't be fair to say that some formats also requires a call to FlushCache() afterwards? Ivan, FlushCache may help push the updated geotransform out to the file immediately for some formats. But if you are just going to close the dataset then that should already do the equivelent of a FlushCache(). So, FlushCache() is only of use to try and push updates out to a file without closing the file. Whether it is implemented or not varies from driver to driver. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Add z values to polylines
On 9/18/08, Mullins, Steven [EMAIL PROTECTED] wrote: I have a large set of contoured data which has a z value in an attribute field. I would like to copy this value to the spatial z. I think this is going to require a bit of python. Any pointers? Steve, I would suggest you look at: http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/vec_tr.py It shows updating the geometries of a set of vectors as part of copying them. Then you just need to figure out how to get the attributes out of th features and passed into the processing functions. Good luck, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR dynamic query
Frédéric Therrien wrote: Hey guys, I'm using ogr to perform select statement in a database for a mapserver/gis. I would like to know something. Is it possible to build dynamic query ? Here is an example: Select * from Table where field1 X Where X can vary depending on the query. I would like to use this feature for time display (display information since a date and this date can be feed by the user in the user interface). Thx for you help. Frédéric, I don't know anything about your application, but of course it is generally possible to do dynamic queries. This would normally be accomplished by assembling the query string dynamically in your application before passing it to ExecuteSQL() or SetAttributeFilter(). Note that OGR SQL requires that the right side of any comparison be a constant, so you can't compare two fields in a non-database datasource (if that is what you were thinking). You can do anything supported by SQL in a real RDBMS. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MEM size limit
Ozy Sjahputera wrote: Hello everyone, According to the documentation in gdal.org, the in-memory file format (MEM) has a 2GB size limit. I recently used MEM to process an image whose size is larger than 2GB without encountering any error message. The output seems to be fine as well. Has the MEM driver been upgraded to handle image 2 GB. I am using GDAL v1.5.2. Ozy, Yes, it appears that as part of treating bug #1503 this limitation was removed on 64bit platforms. I have removed the 2GB limit mention in the formats_list.html file. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Status of RFC 4: Geolocation Arrays especially Envisat wrt GCPs
Brent Fraser wrote: Frank, The short story: I've got some Single Look Complex EnviSat data I need to process. Will gdalwarp do a piecewise (triangulated) warp using GCPs or only(!) use them to calculate an image-wide polynomial? Brent, There are two choices from GCPs. Either polynomial (1st to 3rd order) or thin plate splines. Thin Plate Splines are nice in that the transformation is exact at all GCPs, and it will give similar, but more continuous results to piecewise triangulated warps which I don't support. But TPS is likely to be slow on a large dataset with a lot of GCPs. The longer story: ESA's Best (http://earth.esa.int/services/best/) does an OK job extracting the amplitude from the data, but because it uses tiff files for intermediate storage, and their implementation is limited to 2gb tiffs, it's necessary to tile an input image. Best assigns a different affine transformation to each output GeoTiff tile, which causes a mis-alignment of the tiles when re-assembling them (using gdalwarp etc). Best does output an extensive metadata text file with each tile including a geolocation array of latitude and longitude. Unfortunately the array is not regular (eg, my test tile has values for lines 1, 811, 812, 1622, 1623, 2240; every 165 pixels except the last interval which is 195 pixels). If gdalwarp would use this semi-regular array to triangulate the pixel locations, that would be great, otherwise I'll have to use something else... There is no mechanism to use geolocation arrays that are irregular in this way, and even for regular geolocation arrays the existing code is a bit questionable. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] pct2rgb.py: files 4GB
Sven Geggus wrote: Hello, I've got some trouble using pct2rgb.py: pct2rgb.py in.tif out.tif ERROR 6: A 81408 pixels x 58368 lines x 3 bands Byte image would be larger than 4GB but this is the largest size a TIFF can be. Creation failed. Unfortunately the -of switch does not change this: pct2rgb.py -of hfa in.tif out.img ERROR 6: A 81408 pixels x 58368 lines x 3 bands Byte image would be larger than 4GB but this is the largest size a TIFF can be. Creation failed. Any hint on how to convert the file to rgb in another way? Sven, You might want to edit pct2rgb.py and change this line: if format == 'GTiff': to: if format == 'GTiff' or format == 'HFA': and see if that works. Alternatively, get a GDAL build with BigTIFF support. It would appear you have either an old GDAL or a new GDAL with an old (pre libtiff4) version of libtiff that does not support bigtiff. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 8-bit GeoTIFF and transparency over multiple bands
D wrote: I would need to know, if a three band (RGB) 8-bit GeoTIFF can have transparency enabled? I know that it is possible to enable transparency on a singleband TIFF. Can someone confirm this? Dejan, Multi-band TIFF files represent transparency using an alpha band. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading/Interpreting multi band Tiffs
Tom Kazimiers wrote: Hi there, up to now I only faced Tiff images with palette information. It was relatively easy to read and display everything - I use RasterIO for the one available band and the color table. Now I want to load and display multi band Tiff images - namely the bands red, green and blue. For what I have understood a pixels RGB value is then the value from the red band at the pixels position as red value, the green value from the green band and so on. So do I understand it right that I have to make three RasterIO calls to get the color of one pixel - one call for each band? Exists there maybe a more convenient way like making one call and getting back the color? Tom, There is also a RasterIO() method on the Dataset which allows fetching all the bands in one request. In C++ this is: http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a05743 In C: http://www.gdal.org/gdal_8h.html#764cb93a266ada902b13c2bdad3f7037 In Python you would use: def ReadRaster(*args, **kwargs): ReadRaster(self, int xoff, int yoff, int xsize, int ysize, int buf_len, int buf_xsize=0, int buf_ysize=0, GDALDataType buf_type=0, int band_list=0) - CPLErr return _gdal.Dataset_ReadRaster(*args, **kwargs) eg. rgb_buffer = dataset.ReadRaster(0,0,100,100,gdal.GDT_Byte,[1,2,3]) to read a 3 band buffer for the region 1,2,3 in Byte format. Note that the C/C++ APIs read in band interleave format by default. So the buffer would be filled with all the red, followed by tall the green followed by all the blue. If you want pixel interleaving you will need to carefully select appropriate nPixelSpace, nLineSpace and nBandSpace parameters. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading/Interpreting multi band Tiffs
Tom Kazimiers wrote:
There is also a RasterIO() method on the Dataset which allows
fetching all the bands in one request. In C++ this is:
http://www.gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a05743
thank you very much - this was what I was looking for. Unfortunately I
need to write Data in the form Band3, Band2, Band1, Band3, Band2, Band1,
... (BGR)
Like you have said, the reading is sequential and it was not very hard
to get it working with a result of the form Band1, Band2, Ban3, Band1,
Band2, Band3, ... (RGB)
Is there a way to change the order of the bands so that I can use this
function (alternatively I could write a fast switch function, sure - but
it would be nicer to have it all in one function)? With three seperate
calls to the per-raster-band-RasterIO I can controle everything pretty
good, but it seems that the per-dataset-RasterIO is faster (maybe
illusion :P).
Tom,
To read or write from a BGR buffer you can either passing the band
list reversed (ie. panBandMap is {3,2,1}) or fudze with the
pixelspace, linespace and bandspace values to simulate the reverse.
Sometimes dataset level io will be faster but often it is internally
implemented by calling band level io.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem with 5D variables in NetCDF
Michael Sumner wrote: Hello, The 5D dataset in this NetCDF file causes an error on Windows but not on Linux. http://staff.acecrc.org.au/~mdsumner/gdal/foo.nc The Windows FWTools is recent, and the Linux version is old: Linux: GDAL 1.5dev, FWTools 1.3.2, released 2007/06/01 Windows: GDAL 1.6.0dev, FWTools 2.2.6, released 2008/08/22 Is this a known problem? Variables of 2D, 3D and 4D all seem fine on Windows even when in a file containing a 5D variable. I've put details below for (1) the file, (2) the SDS on Linux, (3) the SDS on Windows. Mike, I have confirmed this problem and discovered that gdalinfo on the same thing reports problems on linux if run under valgrind (but happened not to crash). So the bug is not actually new. I have filed: http://trac.osgeo.org/gdal/ticket/2582 on the issue, and am committing a fix in subversion now. Thanks for the bug report. Do you have any objection to foo.nc being incorporated into the GDAL test suite as public domain data? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] mask bands howto
Vincent Schut wrote: Hi, is there any up-to-date documentation/tutorial available on the recently added mask bands feature? I found http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask, but I was hoping more on something like an api tutorial. The doxygen generated stuff all is empty for mask related functions... Vincent, Indeed, the RFC is the majority of the documentation. If you can file a ticket on specific methods lacking documentation, I'll try and add it. Specifically, I'd like to know if it is possible to (using swig python) create a DS (gtiff), and then write boolean data into ds.GetRasterBand(1).GetMaskBand()? Or should I call CreateMaskBand first? This is not entirely clear to me... Generally you will need to call CreateMaskBand(). The mask you get back by default will likely be read-only (derived from nodata values, or the special all valid mask). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal error 4
sigmazero13 wrote: I've had the same problem with another .tif file on my machine, too. I checked the permissions, and it's readable by owner, group, and world, so I'm not sure what else to try. When I do a gdalinfo --formats, though, there is a GTiff format, but nothing for just TIF. I'm not sure what might be wrong here :( Scott, My next guess would be that it is larger than 2GB and that somehow your GDAL did not get built properly with big file support, or that big file handling is somehow being botched by the operating system. Do modest sized tiff files work fine? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Edit Metadata on MrSID image
On Fri, Sep 26, 2008 at 2:50 PM, Mullins, Steven [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to replace the projection WKT in a group of MrSID files. I do not need to modify the compressed image itself, only the metadata. Can I do this in GDAL? Steve, No, I do not believe you can. I'm not sure if it can even be done by the underlying mrsid libraries. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to add a OGRSpatialReference to an OGRLayer?
On Tue, Sep 30, 2008 at 10:55 PM, Tom Kazimiers [EMAIL PROTECTED] wrote: Hi, unfortunately I have no experience with OGR and want to display a SHP-File (on WinCE, but I don't think that matters). The rendering works well, but is slow - so I will add some caching. One thing of faster rendering is to use SetSpatialFilterRect() I guess. This works, as written in the docs, with comparing the coorinates (they must be in the same coorinate systeme). Sadly, my shp files do not have any SpatialReference (I get NULL returned from OGRLayer::GetSpatialRef() ). If I use SetSpatialFilterRect() with this shp file datasource I will get back absolutely no features. I thought the reason for this could be the missing spatial referenc. So I wonder how to add/change a spatial reference (e. g. a coorinate interpretation, right?) to a layer? Tom, In fact there is no GDAL way to do this. You can however manually put a .prj file with an ArcGIS PE string along side the shapefiles. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PAM nodata values
Matt, I have had no problem reproducing your bug. Could you file a ticket on th issue. The following change fixes the bug, but I need a ticket to push the fix back into the source tree. Thanks! Best regards, [EMAIL PROTECTED] svn diff Index: nitfdataset.cpp === --- nitfdataset.cpp (revision 15371) +++ nitfdataset.cpp (working copy) @@ -458,7 +458,7 @@ if( psImage-bNoDataSet ) return psImage-nNoDataValue; else -return -1e10; +return GDALPamRasterBand::GetNoDataValue( pbSuccess ); } // On Tue, Sep 30, 2008 at 8:27 PM, Matt Klaric [EMAIL PROTECTED] wrote: I'm attempting to set the nodata value on an NITF image and then subsequently read this nodata value back out of the image. However this read fails to find the newly set nodata value. See the attached source code and an example image. You can see that the nodata value is being set for (the first band of) the image in the PAM XML file. Any ideas? FYII'm using version 1.5.2. Thanks, Matt Klaric ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to add a OGRSpatialReference to an OGRLayer?
On Tue, Sep 30, 2008 at 11:11 PM, Tom Kazimiers [EMAIL PROTECTED] wrote: Tom, In fact there is no GDAL way to do this. You can however manually put a .prj file with an ArcGIS PE string along side the shapefiles. Best regards, Frank, thanks for the answer. So does this actually mean I have to look if there is a .prj file - if not create one by myself (maybe ask the user for the parameters) and then load the file with OGR? And if a spatial reference of a layer is NULL I have to create also a (new) .prj file (in case of the one provided is damaged). Tom, The OGR shapefile driver will read .prj files and return the coordinate system properly OGR-ified from the layer. It will also properly write .prj files, but only if you pass the spatial reference into the CreateLayer() call. There is no facility for updating the coordinate system of an existing layer via OGR. Best regards, thanks, regards, Tom -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff image writing problem
On Fri, Oct 3, 2008 at 6:52 AM, Silvia Marchesi [EMAIL PROTECTED] wrote: Hi, I'm using gdal for reading and writing geotiff images; I nedd to write a c++ code able to read a geotiff image (I have already done it!), process it and then give as output an image qith the same size of the input one (exception for the number of bands) and with the same geographic data; the only difference consists in the DN values (the type is the same) and as I said in the number of bands (form multiband image to 1 band). Can anybody help me? Silvia, I would encourage you to review the existing API Tutorial if you have not already done so: http://www.gdal.org/gdal_tutorial.html You might also find it instructive to review the gdalenhance.cpp application which takes and image and produces a modified image. http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalenhance.cpp Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [SOLVED] Re: Trouble connecting to PostGIS db
On Mon, Oct 6, 2008 at 7:44 AM, Jose Gómez-Dans [EMAIL PROTECTED] wrote: Hi, On Friday 03 October 2008 20:58:27 you wrote: Nope, that doesn't change a thing. I am realising that my geometry_columns table is empty, maybe this is where the problem lies? May be. However, quotes seem to make difference on both my Windows XP and Windows Vista: Single quotes are yielding the same message that you got, while double quotes are working. Yes, I added an entry in the geometry_columns table, and I can access my data in PostGIS. I imported my data with shp2pgsql, and I assumed entries to the geometry table were done automatically, which doesn't seem to be the case. If having an entry in geometry_columns is a requirement, maybe it should be visible in OGR's PostGIS page? Or maybe it's there and I haven't seen it! Jose, You are correct. There is a rather questionable decision to assume the open fails if no layers are found in read-only mode for this, and a few other drivers. I've often found this to be a problem and would consider changing it. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Ingres driver for gdal
On Mon, Oct 6, 2008 at 11:11 AM, Denise MacLeod [EMAIL PROTECTED] wrote: ogr2ogr -overwrite -append -skipfailures -f ingres INGRES:mydbname road.shp Now however, the syntax is (as documented on the GDAL website): ogr2ogr -overwrite -append -skipfailues -f Ingres @driver=ingres,dbname=mydbname,user=mydbuser,password=mypwd road.shp I was wondering if there's a reason to have the syntax so different from some of the other formats, such as Postgres? (with the @ sign at the beginning). Denise, The ingres driver is my first attempt at a new unified syntax for complex OGR driver datasource names. This unified syntax for passing many arguments was my intended response to: http://trac.osgeo.org/gdal/wiki/rfc10_ogropen without having to change the normal API. Sorry for breaking the old name style, but I assumed the driver was new enough that I could take the chance to change things without it having much impact. Normally I'm quite conservative about such things. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] interpretation of nodata in OGR libraries
Dylan Beaudette wrote: Hi, I am not sure if this is a DBF issue, or something deeper in OGR, but there does not appear to be a mechanism for preserving 'nodata' or NULL values when exporting from GRASS to vector formats through v.out.ogr. ... It seems that on export via OGR there is some kind of mangline of nodata. This issue is a serious problem anytime you need to move vector data between applications, through the use of an intermediate file (usually a shapefile). Any ideas on what could be causing this problem? Fixing it would solve several important issues. If need be I will file a new ticket on the topic. Relevent tickets? http://trac.osgeo.org/gdal/ticket/809 http://trac.osgeo.org/gdal/ticket/528 Dylan, Generally speaking OGR understands about null attribute values, though there may be no way to represent them in some formats. They should work fine in shapefile format though. Reviewing the mk_att() function in v.out.ogr's main.c I don't see any effort to distinguish between null and non-null attributes so I think the problem is just a limitation of v.out.ogr. If possible, I'd suggest fixing it there. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL Releases
Folks, I would like to prepare a 1.5.3 release candidate tomorrow since it has been quite a while since the last stable release. Are there any objections or bug fixes seen as worth holding this up for? Also, I'd like to start progress toward a 1.6.0 release. I had hoped to address additional UTF-8 handling issues before 1.6 but this seems somewhat unlikely at this point. Are there any new features or major changes folks forsee wanting in before a 1.6 release? Depending on feedback, I'd like to schedule a 1.6 release IRC meeting in the next week or so to plan the release. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] lost gdal_polygonize
Gennady Khokhorin wrote: Can not find gdal_polygonize utility: http://www.gdal.org/gdal_polygonize.html Want to extract polygons based on color range Any help, please. GDAL 1.5.1 Gennady, gdal_polygonize is only available in trunk, not the 1.5.x series. It is a new capability. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL Releases
Dale Harris wrote: I would like to see ticket 2585 be resolved. This has been available in MITAB since February and Mapinfo has support date fields for a few years now. Dale, I get the impression this fix will not make it into the 1.5.x stable releases, but that it should make it into 1.6.0 (with luck the first beta). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] Trouble reading Geotiff projection
CELLIER François wrote: Hi everybody, I need to read geotiff with the gdal library. This geotif had no projection so I opened it through Global Mapper and Export it in order to have a projection within it. When I do a gdalinfo on the file I have : Driver: GTiff/GeoTIFF Files: testAvecProj.tif Size is 4000, 4000 Coordinate System is: PROJCS[NTF (Paris) / France II, ... GDALAllRegister(); this-_pGDALDataSet = (GDALDataset *) GDALOpen( _NomFichierImport.c_str(), GA_ReadOnly ); In debug mode, the pszProjection field of _pGDALDataSet is : PROJCS[“unamed”,GEOGCS[“unamed”,DATUM[“unknown”,SPHEROID[“unretrievable’ etc… Can someone tell me what I did wrong ? François, To get names like NTF (Paris) / France II for the coordinate system strings from a GeoTIFF GDAL needs to lookup the geotiff codes in the support files pcs.csv and gcs.csv normally living in gdal/data, and installed in locations like /usr/local/share/gdal. If they are not found you will get things like unnamed. You may find you need to set the GDAL_DATA environment variable to point to the directory where these data files are found. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr option-spat
Guillaume Sueur wrote: Weird to say why it doesn't work when you don't know yourself what it should really do... This option (and not function) is designed to extract a specific extent of your input data when using ogr2ogr. Actually it SHOULD work as I use it really often. Check your data/values/result, and provide more precise test case if it doesn't. Folks, The only thing I might add is that -spat does not actually clip the returned geometries. It returns all features whose geometries touch the selection region but it returns the geometries intact, not clipped. Lionel, I think you will need to supply a specific example that is not working for us to followup. I will say that the spatial filtering is done by the individual driver and there is always the chance that some drivers do not do it properly. Best regards, GOUBET LIONEL a écrit : Hi, How use the options –spat XMIN YMIN XMAX YMAX ? I try but it doesn’t work … All data layer is returned (same if I add in a table these columns). What’s the problem ? What’s the utility of this focntion ? Thanks you ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: EASE-grid projection
Bruce Raup wrote: All, We at NSIDC had the EASE-Grid projections added to the EPSG code list last year or so, and I recently noticed that in the share/proj/epsg file in FWTools, for the entry for 3410, it says: # NSIDC EASE-Grid Global # Unable to translate coordinate system EPSG:3410 into PROJ.4 format. I don't understand why it says this, especially since the Proj.4 parameters are defined at Bruce, It says this because EPSG projection method 9834 (Lambert Cylindrical Equal Area) has no translation support in gdal/ogr/ogr_fromepsg.cpp. If you file a ticket on this issue I can add it. http://nsidc.org/data/atlas/epsg_3410.html as pointed out by Jose. Can anyone say why the epsg file says that? Proj.4 doesn't deal with datums, so it can handle EASE-Grid just fine, but it should be noted that EASE-Grid maps lon/lat, usually defined on the WGS-84 datum, to a projection that uses a non-standard spheroid. In other words, the datum ellipsoid and the projection ellipsoid are not the same. This is common for satellite-era data. Unfortunately, lots of software and data formats do not properly make this distinction, or allow for this distinction, and so one can run into problems. For example, display software can display the wrong lon/lat under the cursor by erroneously doing a datum shift after unprojection. This is most annoying since there seems to be no standard way of representing such a coordinate system in WKT (for instance). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_polygonize losing the projection info?
Tyler Erickson wrote: I have been trying to use gdal_polygonize to convert a TIF to an ESRI Shapefile, but it seems to be losing the projection information (i.e. no *.prj file is created). The following output illustrates the loss of projection information. I'm currently using gdal trunk revision 15512. Any suggestions on how to keep the projection info? Tyler, This was a problem with the gdal_polygonize.py script. I have modified it to preserve the coordinate system when creating an output file in subversion. http://svn.osgeo.org/gdal/trunk/gdal/swig/python/scripts/gdal_polygonize.py Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Build gdal 1.5.2 on FreeBSD
Ben Madin wrote: G'day Markus, I didn't realise I needed to do both - so that got me over that hump, but now it is hung up on jpeg 2000 (which I don't seem to be able to turn off using --with-jasper=NO) Ben, Try instead --with-jasper=no or --without-jasper. The configure logic is case sensitive and does not treat NO the same as no. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal and python problems
Andreas Neumann wrote: Thank you very much - problem solved. There was an indeed an old version of libgdal around (gdal1.5.2 - also self-compiled under /usr/local/lib) The strange thing is that the svn trunk version reports as older (libgdal.so.1.12.0) even if it is newer than gdal1.5.2, which reports as libgdal.so.1.12.2 Andreas, This is because the svn versioning information for shared libraries is not normally set until release time (ie. 1.6.0) so it is basically just a clone of what it was for 1.5.0 release time. I could bump the version now in svn but I will almost certainly forget I did so at 1.6.0 release and bump it again. I suppose version inflation isn't really a terrible thing. I'll go ahead and do that. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] OGR: DXF driver
Andreas Neumann wrote: Frank, can you do a very rough estimate how much it would cost to implement the read/write dxf driver based on your proposal? Andreas, I think the proposal already covered the pricing for a read/write dxf driver. It was 2200 euros which is a fixed quote - not an estimate. Would you deal with dwgs also, or just dxf - how similar/different are dxf and dwg? Absolutely not DWGs. They are a completely different file format, though one can imagine that the data models are closely related. Implementing DWG read support without using the open design alliance libraries would run at least two orders of magnitude more money and I just wouldn't have the time to do it anyways. We could help financing it, but not the whole thing. If a couple of interested parties would collaborate for the financing it could work. I'm not especially interested in collecting multiple contributors for this task. I have done this in the past and serving multiple masters on one (tiny) contract does not make my end of things any easier. If a couple organizations wanted to get together to fund it, I would still want to serve one technical point of contact for the purposes of reviewing and accepting deliverables. dxf would definitely be interesting to have in ogr. I know that there can be a wide variety of dxf files from the different products that generate dxf. Right - it is important to realize that what I propose is a fairly simplistic DXF driver - not an attempt to do an all-singing, all-dancing job. I would note that the activity is not terribly complicated, and I would welcome others taking a crack at it. I am not particularly trying to drum up business for myself here. I should also note that there is a contributed write only dxf driver sitting in Trac currently waiting for integration. It is using dxflib (which I'm not so keen on), and doesn't do the read side that is of greatest interest. But it might be a base on which someone could build the read side of things. http://trac.osgeo.org/gdal/ticket/2555 Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] OGR: DXF driver
Andreas Neumann wrote: In your proposal you mention that arcs and other curves could be supported if the client has interest in it. In Switzerland, Arcs are widely used in survey data. Support for arcs would be important. Do you plan to convert those arcs to vertices, similar to the Interlis driver? For the long-term - are there plans for upcoming ogr versions to support the transformation of arcs and curves? More and more formats support them and it would be great if an upcoming ogr version could handle arcs. Andreas, If curves are supported they would be approximated using line strings as is done in several other drivers. There is a new (a couple years old now) simple features geometry model from OGC that includes some kinds of curves. I would like to upgrade OGR to support this new geometry model at some point but this is a substantial effort and demand for this upgrade has been weak so far. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Supporting ECW as GDAL plugin.
Daniele Romagnoli wrote: Hi list, I would like to get some information about how to support ECW as a GDAL's plugin. Andrea Aime, back from the FOSS4G, have proposed to improve the support to ECW format offered by our ImageIO-Ext project, by leveraging on GDAL plugin mechanism. Which steps are involved to support ECW Driver as a plugin? (on both Windows/Linux). Should I also tweak the java bindings generation step to handle this? Any information/suggestion/link would be greatly appreciated. (I have already taken a look at ticket 2385) Daniele, In addition to the notes already provided by someone else, you might also want to review (and possibly improve) the wiki topic: http://trac.osgeo.org/gdal/wiki/ECW I would note that no change is required for the java binding generation when adding new formats or plugins. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Adopt GDAL 1.5.3RC1 as official 1.5.3 Release
Frank Warmerdam wrote: Motion: Adopt GDAL 1.5.3RC1 as official 1.5.3 Release This vote should be open till late on Tuesday. Please vote or comment after you have had a chance to try the release candidate. Folks, I'm +1 on this motion as well. I declare the motion passed with support from Tamas, Even and myself and no PSC opposition from the PSC. There were a few items mentioned as desirable but missing from this release but I think it is more appropriate to hold a 1.5.4 release within a month or so that captures those if we can get them incorporated. Without a paid maintainer some bug patches are delayed getting incorporated. I'll take care of updating the web site, etc with the 1.5.3 release, and announcing it on gdal-announce. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with image overview creation in GTiff files
Ozy Sjahputera wrote:
I am trying to create image overviews for a GTiff file using
GDALDataset::BuildOverviews. I keep getting various errors such as:
ERROR 1: TIFFSetField:VISUAL.tif: Cannot modify tag Compression while
writing
...
writing
ERROR 1: TIFFSetField:VISUAL.tif: Cannot modify tag TileLength while
writing
ERROR 1: TIFFBuildOverviews:Can not write tiles to a stripped image
Here is my code:
int OverviewList[5] = { 2, 4, 8, 16, 32 };
CPLErr overview_err = outDS-BuildOverviews( AVERAGE_MAGPHASE, 5,
OverviewList, 0, NULL, NULL, NULL );
I have used BuildOverviews before on HFA images and they are fine. Any
idea?
Ozy,
I'm surprised. I wonder if you might have opened your file in read-only
mode? Can you reproduce the problem with the gdaladdo commandline program?
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] he5 is not a supported format?
Becker, Thomas wrote: Hi listers, I have a problem reading he5 files with gdal. After installing FWTools 2.0.6 on a Suse 9 machine (compiled the sources) it seems like I do not have support of HDF5 files. The files I have are from the OMI tropospheric NO2 data archive (http://www.temis.nl/airpollution/no2col/omi_data_col3.php?) and when I try to read them with gdalinfo I am getting the following failure: ERROR 4: `gdalinfo failed - unable to open 'OMI-Aura_L2-OMDOMINO_2008m1007t2337-o22510_v883-2008m1008t031738.he5 not recognised as a supported file format. gdalinfo failed - unable to open 'OMI-Aura_L2-OMDOMINO_2008m1007t2337-o22510_v883-2008m1008t031738.he5'. I am using gdalinfo version GDAL 1.6.0dev, FWTools 2.0.6, released 2008/02/03. Thomas, I can confirm that FWTools for windows 2.2.6 (the current release) includes HDF5 support. You might want to confirm whether your FWTools release includes HDF5 by issuing the command: gdalinfo --format hdf5 If you get something like: Format Details: Short Name: HDF5 Long Name: Hierarchical Data Format Release 5 Extension: hdf5 Help Topic: frmt_hdf5.html then you have the driver. The file(s) you reference seem pretty big so I have avoided downloading and testing myself. But if you have the HDF5 driver and cannot open your files it is likely they are an HDF5 variation not supported by the driver. Filing a ticket in the GDAL trac would be helpful in this situation, but please at least test with the latest FWTools first. Best regards,-- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] he5 is not a supported format?
Becker, Thomas wrote: Frank, I followed your advice to check if the driver is in place and you are right. The FWTools I am running do not include HDF5. However, I do not run the FWTools on a Windows machine but on Linux Suse 9. So I was wondering why the Linux version 2.0.6 of the FWTools (according to http://fwtools.maptools.org/ the current release) does not support HDF5? Thomas, It is just a omission. HDF5 can work fine on linux. Unfortunately, I'm not in a position to produce new Linux FWTools releases at this time so I can't easily correct this. When i was installing the FWTools there is only the install.sh which I used and the README.1ST. In the README.1ST HDF support is mentioned, but something went wrong. The linux version does support HDF4. Frank, maybe you can help me out once again! I am also willing to run the FWTools on a Windows machine, but do I have the HDF driver at Windows or do I have to compile the driver on Windows with the VisualStudio archives from the HDF Group? The FWTools for windows (recent release) already includes HDF5 so you shouldn't need to compile anything if you just wanted to use gdal_translate or other existing tools. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] to write earth coordinates into NITF image subheader
Mo Wang wrote: Hi all, There is a function called NITFReadBLOCKA_GCPs in nitfimage.c that can read earth coordinates for image corner locations in the NITF image subheader to provide higher precision. Is there a function that can write higher precision earth coordinates into the NITF image subheader? Is there an option in gdal_translate so that the earth coordinates can be written into the NITF image subheader? Thanks in advance. Mo, Currently GDAL does not support creating a BLOCKA segment automatically from GCPs. If you know exactly what you are doing, you can create BLOCKA segment but you need to pass the appropriate creation options when creating the NITF file. There is some documentation of this in: http://www.gdal.org/frmt_nitf.html Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/OGR 1.6.0 Planning Meeting
Folks, I'd like to hold a meeting for planning the GDAL/OGR 1.6 release this Friday at 10:00am EST (1400 GMT). http://trac.osgeo.org/gdal/wiki/ThirdMeeting All members of the development community with an interest in the release are invited to attend. We should be planning our release timetable, and establishing if there are new features to get in before the release efforts start. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Heap Corruption
Joel Odom wrote: Anybody knows why these two lines of code cause corruption on the heap? Thanks. OGRPoint* ogr_point = new OGRPoint(5.0, 5.0); delete ogr_point; Joel, My guess is that you are doing this cross heap. Are you running on windows? Do you build your application calling OGR with /MD? If not your application code may have a distinct heap from the GDAL DLL and this makes it very hard to safely create and destroy c++ objects using new and delete. Assuming you don't want to harmonize the heap, the normal solution is to ensure creation and destruction are done within the DLL. So change to something like: OGRPoint *ogr_point = (OGRPoint *) OGRGeometryFactory::createGeometry( wkbPoint ); ogr_point-setX( 5.0 ); ogr_point-setY( 5.0 ); ... OGRGeometryFactory::destroyGeometry( ogr_point ); Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Using ogr / gdal libraries in java programs
Rushforth, Peter wrote: Hi, I'm interested in using ogr and gdal libraries in java applications. Would you please point me to relevant wiki / documentation / external web sites which might help in figuring out how to do that? Is there javadoc on the library? How does that work, anyway? Or, if anyone has a code example of this, that would be probably even better, as I could code by modification. Peter, The primary information on using GDAL from Java is accessable from: http://trac.osgeo.org/gdal/wiki/GdalOgrInJava Note that this is a wiki and you are encouraged to extend it. There are no javadoc docs for the GDAL Java bindings. You are generally expected to work out the java details by examination of the .java files and relate them back to the C++ docs as reference. Building the Java bindings has proven a bit challenging (for me at least) in the past, but it is doable. I would note that the Java bindings are currently without an active primary maintainer so they don't get as much love as they ought to. OSGeo4W includes a gdal-java package if you are working on windows. On Linux or MacOS X I think you will need to build them yourself from source. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Odd things after using ogr2ogr
Kai Behncke wrote: then the weird thing start. I Load selektion_roads_4326 in Quantum GIS (under the 4326-projection) and after that selektion_roads_31467 (here I use on the fly the 4326-projection) but the layer don`t lay over each other, there is a mismatch of about 50 meter. See her: http://www.selbstverwaltung-bundesweit.de/test/mystery.PNG How can this be? Might this be a bug in reprojection? Kai, I imagine there is an issue with how the datum shifting is being done. It looks to me that by default EPSG:31467 does not have datum shift parameters supplied with it (as expected by GDAL/OGR). Is it possible that your qgis uses PROJ.4.4.9 and your ogr2ogr uses 4.5.0? (or the other way around)? If so, the default rules for shifting between ellipsoids without stated datum parameters will be different. Even if they are the same version, I would suspect that one way there are proper datum shift parameters being used, and the other way there are not. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Build OGR with ESRI SDE
Mullins, Steven wrote: I am interested in using OGR to read data from an ArcSDE (9.2-9.3) database. The manual page at http://www.gdal.org/ogr/drv_sde.html indicates that GDAL must be compiled with the ESRI provided ArcSDE client libraries. Before I sink a lot a time into this, can anyone share their experience compiling OGR with ESRI libraries for SDE? What specific steps need to be taken to accomplish this? Steve, On linux this boils down to setting one or both of: --with-sde=DIRInclude ESRI SDE support (DIR is SDE's install dir). --with-sde-version=VERSION NUMBER Set ESRI SDE version number (Default is 80) when configuring. On Windows setting of: #SDE_ENABLED = YES #SDE_VERSION=91 #SDE_PLUGIN = NO #SDE_SDK = C:\arcgis\arcsde #SDE_INC = $(SDE_SDK)\include #SDE_LIB = $(SDE_SDK)\lib\pe$(SDE_VERSION).lib \ # $(SDE_SDK)\lib\sde$(SDE_VERSION).lib $(SDE_SDK)\lib\sg$(SDE_VERSION).lib in gdal/nmake.opt I'd appreciate someone setting up a topic on SDE under: http://trac.osgeo.org/gdal/wiki/BuildHints if interesting information is collected. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Odd things after using ogr2ogr
Kai Behncke wrote: Dear Frank, thank you for that hint. I imagine there is an issue with how the datum shifting is being done. It looks to me that by default EPSG:31467 does not have datum shift parameters supplied with it (as expected by GDAL/OGR). Is there a possibility to put this datum shift parameters manually? Kai, Yes, it should be possible though perhaps tricky. With ogr2ogr you can replace EPSG:31467 with a PROJ.4 style definition instead which would look like this: +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=350 +y_0=0 +datum=potsdam without any datum shift parameters. Doh! I see that in fact this does have datum shift parameters since +datum=potsdam expands internally within PROJ.4 to: +towgs84=606.0,23.0,413.0 +ellps=bessel OK - so EPSG:31467 is likely fine. I imagine the problem then is that QGIS is not associating appropriate datum shift parameters when back-shifting. I tried assigning EPSG:31467 to a shapefile here, and then examining what OGR uses as the PROJ.4 translation and got: +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=350 +y_0=0 +ellps=bessel So the problem appears to be that once the coordinate system is converted to ESRI WKT format (in the .prj file associated with the shapefile) the relationship of the coordinate system to the potsdam DHDN 1950 datum is lost - at least as far as OGR can work out. So presumably the datum shift is properly applied by ogr2ogr, but thereafter OGR (and consequently QGIS) does not recognise the datum properly. This is a common sort of problem. Even when we know the properly EPSG datum shift info it is often lost when the coordinate system is converted to less expressive file formats. One work around would be to add some specific translation rules for datums named D_Deutsches_Hauptdreiecksnetz in the OGR morphFromESRI() code but this would need to be done on a case by case basis for all datums of interest and to be honest I'm not even sure OGR is converting this to the expected ESRI datum name. Grr. I'm so sick of coordinate system related issues! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Desktop App Map Server?
Brian Hone wrote: Hi Folks, Sorry if this is a newbie question, but I've looked all over and can't find any good information. I have a desktop app (wxGTK / C++ / OpenGL) on which I want to display all manner of geo-images, in all manner of projections, etc. I have coded the ability to display simple NITF, etc. using GDAL, but I am constantly finding image formats or projection systems which I haven't supported. I really want to have a data store with an API which looks something like: getMapLayers( area, layers, resolution ) o It looks like OGDI is built to solve this problem, but I can't find a 'howto'. o PostGIS + GDAL? o MapServer et al.? - look good, but are more web focused. Can anyone give me a good starting point? Brian, I am not clear on what you are looking for that GDAL doesn't already do. In your getMapLayers() function above, are you suggesting that it is returning the area, layers and resolution? Are you wanting it to work for feature datasources as well as raster data sources? If you support NITF via GDAL - is there some reason you don't automatically support the rest of the GDAL raster formats? What are you using for projections? Normally GDAL+PROJ.4 allows you to support a wide set of coordinate systems without having to do anything special for particular projections. I guess I'm not getting the dilemma. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Going between gdal nodata and GMT NaN
Roger André wrote: Hmm, let me ask this a different way. Does the GMT driver implemented in gmtdataset.cpp support the creation of Nan values when writing to an output dataset? Roger, I see no support for handling NaN on read or write in gmtdataset.cpp. So, no. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_merge.py outputs bad geotiff?
Andrew Brooks wrote: On Fri, 24 Oct 2008 19:21:22 +0100, Even Rouault [EMAIL PROTECTED] wrote: my guess is that your merged1.tif TIFF has areas which are not initialized (black/transparent areas). gdal_merge.py probably doesn't write any data in them, thus leading to missing blocks in the file. Thanks for the reply, that certainly seems to be the explanation. It does raise further questions though. 1. Should the gdal utilities' output be consistent with each other? Andrew, I don't see this as an inconsistency. 2. Should the default output format be the most compatible? Yes, within reason it likely ought to be. 3. Should there be an option to turn on/off the writing of sparse files? Yes, likely. In fact it wouldn't so much be an option to turn sparse writing on/off as it would be an option to push out zeroed blocks for all missing blocks when a file is closed. Feel free to file a ticket on this, and I'll try to fix it fairly soon. The default should presumably be to produce maximally compatible files even though I wish the rest of the world would support sparse files in a sensible way. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JPEG2000 question/issue
Christiaan Janssen wrote: I'm wondering if someone can help me with this. I'm trying to build GDAL with both support for MrSID and ECW while using the former for JPEG2000 support. It appears that as soon as libecw is linked in, it is being used as the JPEG2000 reader (even when I have MRSID_FLAGS = -DMRSID_J2K uncommented in the make options). I'm assuming this probably has something to do with the order that the drivers are tried at runtime. Is there a correct way to force the support to default to the MrSID library? Thanks for the help. Christiaan, Disabling the -DMRSID_J2K should disable the JP2MRSID driver though you may need to do a clean build for the change in the nmake.opt to take effect. Alternatively you can force a particular driver to be ignored at runtime using the GDAL_SKIP configuration variable. Set it to the driver name you want to ignore ... such as JP2MRSID. It can be set in the environment, before running GDAL commands. set GDAL_SKIP=JP2MRSID Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Release Meeting Minutes
Folks, I have written up the minutes from Friday's release meeting. http://trac.osgeo.org/gdal/wiki/ThirdMeeting Key items: * Frank Warmerdam named release manager. * Last friday declared RFC freeze day ... that is, it is too late for new RFCs to go into the 1.6.0 release. Release Schedule: * October 29th: Beta 1 (this Wednesday!) * November 12th: Beta 2 * November 26th: RC 1 * Additional RCs as needed (hopefully only a few days apart) till final release approved Please try to get new development items completed by Wednesday and into trunk for inclusion in beta1. There will be two weeks for agreessive bug fixing during the beta1 period. The beta2 period should hopefully be for more conservative bug fixing (avoiding riskier fixes for marginal problems). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Saving data to the TEXT domain NITF
Kurt Landrus wrote: Hello; I working with GDAL to support NITF imagery, I'm having a problem with trying to save text data to the I can read data from the Text segment just fine. However when I try to save data back to the nitf in the TEXT segment using the call below, I receive no err, but the data doesn't get saved. // save text segment to dataset. err = GDALSetMetadataItem(dataset, DATA_0, tmp3, TEXT); When I try to verify the text in the TEXT segment using gdalinfo, there is no TEXT segment data contained in the NITF file. Is there other calls required to set up this, what I am doing wrong. Thanks; Kurt, I believe that at this time the GDAL NITF driver does not support writing out text segments. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: No support for widestrings in ArcSDE driver for OGR ?
Ragi Y. Burhum wrote: On Mon, Oct 27, 2008 at 8:33 AM, [EMAIL PROTECTED] Hi all Throughout GDAL 1.5 and 1.6+ I havent been able to reading most strings from ArcSDE using OGR, which is probably caused by the ArcSDE drivers lack of widestring support (?). Is this correct, or am I doing something wrong ? I'm pretty desperate for this to work now. Seems as if a lot of ArcSDE data is stored as widestrings, which seriously limits the applicability of my connection. Could anyone give me an update on this ? I've tried looking at the tickets but failed to find an entry that adressed this issue. Thanks, Anders. Starting from 9.3 (or was it 9.2?) the strings created by ArcCatalog are widestring by default. I took a quick look at ogrsdelayer.cpp and ogrsdedatasource.cpp and that code is only consuming the non-Unicode API. Frank: I did see that OGRSDELayer::Initialize(..) maps an OGR OFTWideString (a type that the documentation says it is deprecated) to an SDE widestring (i.e. SE_NSTRING_TYPE) if #SE_NSTRING_TYPE is defined, however OGRSDELayer::TranslateSDERecord() does not have a case statement for SE_NSTRING_TYPE (and therefore has no call to SE_stream_get_nstring http://edndoc.esri.com/arcsde/9.3/api/capi/schemaobjects/streams/strmgetnstring.htm). A quick fix to at least be able to consume the sde unicode strings would be to add that case for that switch statement and take the result and encode the UTF16 string to UTF8. I would fix it myself and submit a patch, but ironically enough, I don't have a way to test it or compile it since I don't have ArcSDE nor ArcGIS anywhere... should I submit a ticket? Ragi, I'm in the same position - no SDE instance to test against. A patch might be good if either Howard or Anders are willing to commit to testing it out. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_priv.h not found on ubuntu
Matt Wilkie wrote: Hello Folks, I could use some hand-holding please... :) I'm trying to compile Matt Perry's hillshade [http://www.perrygeo.net/wordpress/?p=7] utility on Ubuntu 8.10 (amd64 if that makes a difference). I'm told hillshade.cpp:24:23: error: gdal_priv.h: No such file or directory. I have installed libgdal1-dev and verified gdal_priv.h does exist in /usr/include/gdal. What am I missing? Matt, Try: g++ -I/usr/include/gdal hillshade.cpp -lgdal -o hillshade PS. I'm interested in adopting Matt Perry's utillities into GDAL proper at some point to streamline their use and maintenance. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MSYS buildslave
Ari Jolma wrote: All, I've set up a buildslave, which builds GDAL from a fresh checkout of the trunk in Windows using the MSYS environment. Currently the build is quite lean and only Perl bindings are built in addition to the core dll and apps. Only Perl tests are run. Ari, Excellent! The one addition I'd be particularly keen to see would be building the python bindings and running the python test suite since it is our comprehensive standard test suite. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] SQLite problem
iomeneandrei wrote: Hi all, I have created a sqlite spatial db with ogr2ogr, starting from a simple shapefile. I'm able to read the proper info of this sqlite db with ogrinfo. If I add a column to this sqlite db inside the table where I have the WKT_GEOMETRY, ogrinfo is no more able to read properly this db. Is it possible to add a column to a sqlite spatial db without destroy the spatial component? I'm using SQLite Manager 0.3.15 for firefox to edit the db. I'm attaching the original sqlite file: http://www.nabble.com/file/p20233548/output1.sqlite output1.sqlite Andrea, The file you referenced seems to work fine with my (trunk) ogrinfo. Can you provide an example that ogrinfo can't read? Generally, adding new columns to a spatial table should not cause problems for OGR. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] SetEquarectangular() changes
Didier, I've backed out r15642 (in r15643) for the time being because I suspect it included some unrelated changes that were inadvertant. http://trac.osgeo.org/gdal/changeset/15642 For instance some of the changes to geo_normalize.c and geo_ctrans.inc which really need to start out upstream in libgeotiff. Also, the UOMLengthInMeters changes in gt_wkt_srs.cpp seem unrelated to the stated reason for the commit. Likewise many changes in nitfdataset.cpp. There also seems to be substantial alterations to ogr_srs_api.h that I don't really understand. The core reason for the change seemed to be to replace use of SetEquirectangular() with calls to SetEquirectangular2() with the first argument being zero. I'm not sure this is a great idea. Can we not leave SetEquirectangular and just have it call SetEquirectangular2() with the first argument as 0.0? This would minimize changes, and leave the API so that private plugins won't be broken. Generally speaking, I'm not keen on changing existing parts of the C++ API when easily avoidable as it seems to be in this case. I'd appreciate it if you could review the changes you want to make and apply them more narrowly. I find commits from root can be pretty dangerous! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.6.0 Beta 1 Available
William Kyngesburye wrote: Is there an overview of changes? The NEWS file hasn't been updated since 1.5.0 prerelease. William, There isn't yet a NEWS file update available. It is produced rather manually and I didn't have the time/energy to do it today. It will be in place for the first RC, hopefully for beta2. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.6.0 Beta 1 Available
Frank Warmerdam wrote: Folks, I have prepared the GDAL/OGR 1.6.0 Beta1 release. This is the first of two planned betas, the second is planned for November 12th. The source is available at: http://download.osgeo.org/gdal/gdal-1.6.0beta1.tar.gz http://download.osgeo.org/gdal/gdal160beta1.zip I have also snapped the Python autotest suite. It can be downloaded from: http://download.osgeo.org/gdal/gdalautotest-1.6.0-beta1.tar.gz http://download.osgeo.org/gdal/gdalautotest-1.6.0-beta1.zip Folks, I neglected to mention that the 1.6.0 beta1 source has been used in the latest FWTools for windows (2.2.8): http://home.gdal.org/fwtools/FWTools228.exe Also, the gdal-dev package in OSGeo4W has been updated with the beta source. http://osgeo4w.osgeo.org/ The gdal-dev package needs to be installed via the advanced install sequence. Once installed you need to run the gdaldev bat file in the OSGeo4W command shell to use the gdal-dev package instead of the 1.5.3 version for the gdal utilities and python scripts. Note that there is currently no way in OSGeo4W to use gdal-dev with other GDAL using packages like MapServer, or OpenEV which always use the standard GDAL package (1.5.3). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Can't build without INCLUDE_OGR_FRMTS = YES (RE: [gdal-dev] GDAL/OGR 1.6.0 Beta 1 Available)
Peng Gao wrote: Frank, I am getting unresolved symbols without INCLUDE_OGR_FRMTS = YES. I am building GDAL 1.6.0 Beta 1 using VS2008 on Windows XP. Is there a way to keep building GDAL 1.6.0 without OGR? The release dll size difference is 3.6M (gdal15.dll without OGR) vs. 4.8M (gdal16dev.dll with OGR). ... link /nologo /dll /INCLUDE:_OGRFeatureStylePuller /INCLUDE:_OSRValidate /INCLUDE:_OPTGetProjectionMethods /INCLUDE:_OGR_G_GetPointCount /INCLUDE:_GDA [EMAIL PROTECTED] /INCLUDE:[EMAIL PROTECTED] /INCLUDE:_GDALComputeMedia [EMAIL PROTECTED] /INCLUDE:[EMAIL PROTECTED] /INCLUDE:_OCTNewCoordinateTransforma [EMAIL PROTECTED] port\*.obj gcore\*.obj alg\*.obj frmts\o\*.obj ogr\ogr.lib C:\A Gao, The makefiles and software is slightly broken in this regard. If you file a ticket on this I'll try to have it resolved before beta2. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JPEG2000 issues
Stephen Woodbridge wrote: Stephen Woodbridge wrote: Hi Frank, et al, I'm working with GDAL 1.5.3, released 2008/09/09 built with libjasper so I can process some DOQQ composites and chop them into smaller tiles. Below is a typical image but I get a bunch of errors in gdalinfo. The system has like 6 GB of memory and only about 1.5GB of swap. The compressed image is huge at 538MB. I tried 3-4 images in the directory and got the same report on all of them. Any thoughts on this? Is this a real problem, ie. I will not be able to access these images. Other options solutions? Steve, I'm not familiar with the cannot get box error you are seeing, but generally speaking the JasPer based JPEG2000 driver is not suitable for use on large images due to it's decode-the-whole-image-in-memory model of imagery access. Best regards, Band 1 Block=256x256 Type=Byte, ColorInterp=Undefined error: expecting signature box Metadata: LAYER_TYPE=athematic error: cannot get box GDALRasterAttributeTable/ error: cannot get box I must be a Zen thing that I always find answers after a give up looking and post to the list. So, to reply to myself, I was about to use the JP2MrSID driver like the following and without any error. So, I'll try to move forward using this more of access. I'm still interested in any other thoughts you have on the above issues. -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is GDAL reentrant
Clay, Bruce wrote: I have a Microsoft application with multiple tabs / property pages. Each tab is controlled by a separate class. I have a separate instance of GDAL in each class. I also had an instance in a popup that I used to connect to the database. After the user logins and the popup window goes away it seems that I have to reregister the OGR drivers in the tabs as if the OGRCleanupAll in the destructor of the popup was being applied to the instances in the tabs as well. Is GDAL / OGR reentrant? Can we have multiple instances that act independently? Bruce, GDAL/OGR is endeavors to achieve some forms of re-entrancy. In particular it should be possible to have distinct threads accessing distinct GDALDataset objects in read-only mode for well behaved drivers. This is also generally true of OGRDataSource objects. However, a call to OGRCleanupAll() or other similar funcitions that tear down the environment should only generally be done on application exit, not cleanup of a single thread. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR DeleteFeature throws memory exception
Brad Grinstead wrote: I am wondering if someone has experienced a memory access violation when attempting to delete OGRFeatures. I am running the latest build off the trunk and have been able to find no information regarding this error. Brad, Can you confirm that you are operating using the C# bindings for OGR? Your code looks ok to me, but I'm not completely clear on the built-in disposal logic for features in C#. Also, you don't seem to have mentioned the GDAL/OGR version which could be important to diagnosing the problem. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] converting KML to CSV
Markus Neteler wrote: On Tue, May 20, 2008 at 3:25 PM, Frank Warmerdam [EMAIL PROTECTED] wrote: Tim Michelsen wrote: Hello, I'd like to convert KML back to CSV. When I issue ogr2ogr -f CSV out.csv in.kml there are no coordinates written to the CSV file. Only the placemark names are written. How can I get ogr2ogr to create a file like Latitude,Longitude,Name 48.1,0.25,First point 49.2,1.1,Second point 47.5,0.75,Third point Tim, The CSV driver does not support writing geometries, though I can see some support for this might be desirable. Frank, I would need the same... is there any work-around (or would it be a pain to add that)? Markus, As a workaround you could write a script that would essentially .csv with a WKT column. It would not be hard to add directly in the .csv driver but I'm not all that keen on doing it myself. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_rasterize usage problems
Andrew Brooks wrote: On Mon, 10 Nov 2008 21:43:02 -, Roger André [EMAIL PROTECTED] wrote: I believe your syntax is incorrect. The manual implies that the -b and -burn options are optional but they appear to be mandatory. Andrew, One of -3d, -burn or -a are required. I have not found anything in the manual that seems to imply they are optional. Giving just a source and destination results in the usage message. The only option noted as mandatory is -l but if only -l is used then the misspelled and confusing message is To many of -3d, -burn and -a specified. I have corrected the message to indicate that one of these is required. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: GDAL encounters problem with very small files
Matthieu Rigal wrote: Hi all, hi Frank, I am encountering problem with gdal_translate and gdalinfo with very little images. I have for example a 9*16 pixels image, georeferenced, 16bits and 8bits, that I have tested in 2 formats : .pix PCIDSK and .tif GTiff. And both times, I get errors : gdal_translate: symbol lookup error: gdal_translate: undefined symbol: GDALValidateCreationOptions gdalinfo: symbol lookup error: gdalinfo: undefined symbol: GDALGetFileList I have attached both tif files in 8bits and 16 bits, with the hope it will help. Notice that these images can be open by software like QGis or PCI Geomatica... If you have any ideas or if it is a known bug... let me know ! Matthieu, I tried gdalinfo on the files and it worked fine. Your Python looked fine. The error messages seem to indicate an inappropriate mixture of versions. Presumably recent Python bindings that are trying to pick up an older version of GDAL lacking some modern entry points. Does the same configuration work fine with larger TIFF files? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR WFS driver
Johan Nouvel wrote: Hello all, I know GDAL has a WMS and WCS driver, but no WFS driver. After looking into the mailing list archives I have found no references to a WFS driver. For my job, we have developped such a driver (in readonly mode, but write mode is planned) , based on OGR and its GML driver. Is it interesting for GDAL/OGR users to have a WFS driver ? If yes, I could spend time to put our code into gdal source (actually it is separate from gdal source because of a specific compiling process) and then send it in order to be integrated in the svn trunk. Johan, We are indeed interested in having a WFS driver for OGR - whether read-only or read-write. There has been discussion of doing this in the past but there was never sufficient resources to pursue it. I'd suggest preparing the driver code and submitting it as a ticket. But, assuming you are willing, I'd like to propose you as a commiter to take care of final integration and ongoing support. An existing commiter will presumably also be involved to do some review and support. I would like to see such a WFS driver use the existing libcurl interface (as defined in cpl_http.h) if it doesn't already. I'm also curious what you do for parsing the GML. Do you process it through the existing OGR GML driver? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] raw x-y-z height map.
Eran Burstain wrote: Hi. I want to convert a height map (DTED or other format) to simple ASCII file with X,Y,Z coordinates, supplemental data (datums) should be in separate file (.vrt), Is there support in such a format ? Eran, No, there is currently no direct support for such a format in GDAL. The gdal/swig/python/scripts/gdal2xyz.py script will produce such a file but it is not then readable with GDAL, nor can it be referenced from a .vrt file. I do frequently use the AAIGRID driver to produce easy to read ascii files, but it does not produce x/y values for each pixel. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] nitf xbands supported?
Sarah Mulholland wrote: In looking at the NITF 2.1 spec, I notice that the number of bands (NBANDS) in an image is by default represented by an ascii charactacter ‘0’ to ‘9’. There’s an XBANDS field that you can use for images with more bands when there are multispectral bands in excess of 9. I notice that when I call “driver.Create” with more than 9 bands, python seg faults when I call GetRasterBand for the first band. Would I be correct in assuming that gdal doesn’t support the XBANDS feature in the NITF? Sarah, That would appear to be the case. I encourage you to file a ticket on the issue. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Gdal Bug? was: Re: [gdal-dev] JP2MRSID Issues
Stephen Woodbridge wrote: Frank, If someone can generate a patch the prints this stuff out, I'll have our guys build a version with the patch and I'll run it against one of the cases that fails. There wouldn't happen to be a hidden debug option that might already print this out? Thank you Michael for any assistance from your end also. Steve, Skimming through mrsiddataset.cpp, it appears there are already quite extensive debug statements. Try enabling debug output when running the failed operation. For GDAL commandline apps adding --debug on to the commandline (without the quotes) should do the trick. The debug output all goes to stderr. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_rasterize usage problems
Andrew Brooks wrote: Thanks for the help everyone, I'll summarise when I get it all working ;-) Jamie Adams [EMAIL PROTECTED] wrote: 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. To what extent do they need to be in the same projection? Isn't a change of datum sufficient? Firstly, is gdal_rasterize not capable of performing the change of SRS internally itself? That would save having to use ogr2ogr to write a new vector file for every image. Andrew, While it could be made to do so, gdal_rasterize does not currently reproject the vectors on the fly. Secondly, how closely do the vector and raster SRS need to match? Surely as long as both are WGS84 (for example) that should suffice? But when I try to rasterise a WGS84 vector onto a WGS84 Mercator raster it complains and doesn't work. Thirdly, when I reproject the vector to Mercator first and then rasterize it does work, to an extent, but it smears random extra vectors across the raster :-( It does this for both gshhs_land and v0_landmass so I don't think the vector itself is the problem. I'd guess this represents a world wrapping problem but if you can demonstrate the issue it might be appropriate to file a ticket. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] access of 16-bit GeoTiff image using GDAL
zither wrote: Hi all, I'm using GDAL to read some Geotiff files. But how I can get the information about little endian or big endian? Any method can support to get this ? Zither, GDAL does not provide information on the endian-ness of the file, but it shouldn't matter as data read through GDAL is always returned to the application in local machine order. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal 1.5.3 make error - HDF 4 conflicting types for`UNKNOWN'
Gong, Shawn (Contractor) wrote: Thank you Frank and Andrew Brooks. Following your leads, I went to check the ticket #2609 and the nightly snapshot of the 1.5 branch. I have two questions: 1) Is http://download.osgeo.org/gdal/daily/ always the latest update on the last public release (currently 1.5.3)? Shawn, The trunk and stable branches are captured each night and placed in this location. So you can always grab essentially the latest code from there. 2) I'd like to use latest Rsat2 and TerraSAR-X drivers. Can I overwrite the 1.5.3 with the drivers from 1.6 beta (by copying the entire sub-directory)? This will almost certainly work fine. But you might also consider just using the trunk version from svn or the nightly snapshot. Certainly we would appreciate your trying it out before the final 1.6 release. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] CreateCopy() Not writing ColorInterp Data
Tom V. wrote: Hey, I'm using GDAL to read in a NITF image and write it out as either a NITF or a GeoTiff file, and I'm basically doing it the same way as gdal_translate but with a few changes. The reason I'm writing is because when the GeoTIFF gets written out using CreateCopy(), the ColorInterp data is gray for the first band and Undefined for the other three bands. We're using a stripped down version of GDAL so I can't use the SetAccess() method to write out to the file after it's already written. I tried reading it back in with the access set as GA_Update. Has anyone seen anything like this before, or know what the problem could be? I'd be happy to answer any questions or go into more detail. Tom, What does the gdalinfo report on the input dataset to the CreateCopy() look like? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
