Re: [gdal-dev] Re: How detect the BlockSize to make tiles of my dataset to open it?
On 11-04-20 02:43 PM, gistdt08 wrote: Many thanks Frank, Could be useful it for avoid OutMemoryException? Francisco, Reading the image one scanline at a time can be accomplished in a modest amount of memory. Attempting to read the whole image at once would take ... lots of memory. So, yes I imagine so. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_translate segfault with large netCDF
On 11-04-19 05:01 AM, josh.v...@csiro.au wrote: Hi, I’m new to GDAL so please forgive any glaring ignorance J Currently I have an 8GB ER Mapper (ERS) dataset that I want to convert to a NetCDF file with gdal_translate which always results in a segfault when using the following command. gdal_translate -of netCDF input.ers output.nc Whereas translating only a small 4B subset of the dataset works fine. Now I’ve been doing a bit of reading and I know that netcdf 3.6.2 and below doesn’t support variables greater than 4GB however I’ve been doing the translations with the Debian libnetcdf6 package (which I believe includes netCDF 4.1.1 and running ‘ncgen –version’ confirms this). I am operating under the impression that netCDF 4.1.1 should be able to handle netCDF files of this size without trouble. Now I’ve tested gdal_translate from a variety of builds and they all produce the same problem Josh, I don't see any immediately obvious problems in the way we call the netcdf API in netcdfdataset.cpp's CreateCopy method. I would suggest you file a ticket on the issue, and a developer can try to reproduce the problem. I would like to suggest that you do a gdal_translate from a subset of the ERS file at the bottom right corner of the source just to ensure that it isn't a problem with reading past the 4GB mark in the ERS file. I seem to have 3.6.3 of the netcdf library so I can't trivially check this on my system. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Shapefile (DBF) Code Page Handling
Folks, I have implemented some preliminary support for encoding/decoding of string attributes to/from DBF files in trunk. Changes are: http://trac.osgeo.org/gdal/changeset/22176 Some notes at: http://trac.osgeo.org/gdal/ticket/882#comment:11 Testing and example files are welcome, especially those with associated .cpg files. Best regards, ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr clipping issue
On 11-04-15 03:09 PM, edwarddes wrote:
I am trying to clip a dxf to a region, using the following command:
ogr2ogr -f DXF -clipdst $w $e $s $n ./tmp/${BASE}_avg_05_unbuffered.dxf
./tmp/${BASE}_avg_05.dxf
where w,e,s,n are defined as follows:
echo $w $e $s $n
225000 229000 902000 906000
The data is properly clipped on the north and west side, but on the south
and east side, no clipping takes place. The source file has extents that
are 100units larger in each direction
Edward,
From the usage message I see:
[-clipdst [xmin ymin xmax ymax]|WKT|datasource]
I think you need
-clipdst $w $s $e $n
That is, you have the arguments in the wrong order.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
On 11-04-14 04:15 AM, Hilmy Hashim wrote: I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04 box with GDAL 1.7.3, the gamma is not there. I've just updated QGis 1.7.0-114 and I don't get the gamma in the CRS listing. Hilmy, For reference, in my OSGeo4W install I see: C:\warmerdaepsg_tr -proj4 3168 # Kertau (RSO) / RSO Malaya (m) 3168 +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0257905 +k=0.99984 +x_0=8046 70.24 +y_0=0 +gamma=323.130102361 +a=6377295.664 +b=6356094.667915204 +units =m +no_defs C:\warmerdaepsg_tr --version GDAL 1.8.0, released 2011/01/12 Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Abstracts for FOSS4G 2011 are due tomorrow
Folks, FOSS4G 2011 presentation abstracts are due by tomorrow, April 15th. If you are thinking of attending FOSS4G 2011 in Denver and have something related to free geospatial software that you would like to present (30 minute slots including questions) then write up an abstract and submit it promptly. http://2011.foss4g.org/abstracts/ Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal datum shift
On 11-04-12 06:07 PM, Brian Wilson wrote: Trying to get a raster to go from NAD83 to NAD27 with gdalwarp. Can't see any way to tell how it is choosing to do it. Is this documented anywhere? Is there any way to make it verbose so I can tell if it's trying? I ran it through strace and watched it open a file called gdal_datum.csv but of course can't tell what it's trying to do. I found this post from Frank which implies it tries to be smart and figure out the transforms without my help: http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html But it's not working and since I don't know how to tell what it's doing I can't intelligently ask for help. :-) Thanks for your patience with a n00by Brian Command I am using: gdalwarp -of HFA -co COMPRESSED=YES -t_srs ESRI::NAD_1927_StatePlane_Oregon_North_FIPS_3601.prj 11s5w34f_color_ne.sid 11s5w34f_color_ne_nad27.img Output is in the right coordinate space (it's moved from meters to feet) but has that familiar 10 or so meter shift we get around like the NAD83-NAD27 transform failed. The input file SRS looks like this Coordinate System is: PROJCS[NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601, GEOGCS[GCS_North_American_1983_HARN, DATUM[NAD83_High_Accuracy_Regional_Network, SPHEROID[GRS_1980,6378137,298.257222101]], PRIMEM[Greenwich,0], UNIT[Degree,0.017453292519943295]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[False_Easting,250], PARAMETER[False_Northing,0], PARAMETER[Central_Meridian,-120.5], PARAMETER[Standard_Parallel_1,44.34], PARAMETER[Standard_Parallel_2,46], PARAMETER[Latitude_Of_Origin,43.66], UNIT[Meter,1], AUTHORITY[EPSG,102326]] Brian, I believe the problem is the source datum name NAD83_High_Accuracy_Regional_Network. I believe this is *not* recognised as essentially NAD83 and so the source datum is treated as unknown and no datum shifts are done. It can be helpful to run gdalwarp with the commandline option --debug on in which case the debug output should include the PROJ.4 rendering of the source and destination coordinate system. At a very low level you can also define the PROJ_DEBUG environment variable to the value ON and PROJ.4 will report some details on what datum files are opened. I think you are going to have to provide a source coordinate system with the -s_srs commandline switch to gdalwarp that defines a more conventional NAD83 based coordinate system. You might also want to file a ticket on this issue. Ideally we would be smarter about treating NAD83 HARN as equivelent to NAD83 for most purposes. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] About the legality of import - export
On 11-04-12 03:26 AM, Antonio P. wrote: What are your experience about this topic? For example, we have dwg, shp, pdf files : Can I distribute a program that import an export data in these formats ? And what about writing data into an existing files ? What legal implications we have to be in mind? Thanks Antionio, There are no legal issues with reading and writing shapefiles. The format is public and GDAL/OGR does not use any code with unusual licensing for this format. For PDF I am guessing you are using the Poppler based PDF driver in GDAL. If you build with Poppler you should review it's licensing information which is, I believe, GPL. So if you distribute a program using GDAL/OGR and Poppler there are legal ramifications for your program. Essentially you would need to provide source code for the program linked with GDAL. For DWG, I'm not sure what you are planning on. GDAL/OGR does not currently read DWG. There is some discussion of a DWG reader based on the Open Design Alliance libraries. If that comes to fruition there will be special legal issues due to their proprietary licensing. Note that the above addresses responsibility for software distribution. For any given file there may be other restrictions on it from the creator or distributor of the data. I can't address that here. But generally ensuring those requirements are followed will be the responsibility of whoever accepts the data - not the software distributor. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removing GCPs from tiff
On 11-04-12 03:17 AM, Goo Creations wrote: Hi all I've got a tiff file with a number of stored GCPs. How can I remove these GCPs from the file? I've tried: SetGCPs http://www.gdal.org/classGDALDataset.html#3c812b05467213f05055c1f18438d874(int nGCPCount, const GDAL_GCP http://www.gdal.org/structGDAL__GCP.html *pasGCPList, const char *pszGCPProjection) with the first parameter of 0, but without luck. Seems like SetGCPs only adds the GCPs, rather than re-assigns the entire stored set. Chris, Jukka's suggestion is good. I would also encourage you to file a ticket on this. Calling SetGCPs() with zero GCPs *ought* to clear them. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo doesn't show GEOS projection info
On 11-04-12 10:24 AM, kingkastle wrote: Greetings, I'm working with hdf5 file with the following attributes: (obtained with hdfview) http://osgeo-org.1803224.n2.nabble.com/file/n6265339/hdf5view.bmp However, when I gdalinfo the file, I get the following information: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4326]] Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 651.0) Upper Right ( 1701.0,0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) ... So, basically I can't see in the gdalinfo the following information: +) Proyection used +) Origin +) Pixel size In fact, when I do gdal-translate the file created is not georeferenced rightly. In my opinion, the problem is that the hdf5 attributes are imcomplete or not rightly defined, Please let me know your opinion Many thanks in advance and best regards, Rafa, One challenge with HDF5 (and HDF4) products is that coordinate system and other georeferencing metadata may be included in a wide variety of forms. This aspect is not well standardized - or at least the standards that exist are often not followed. So, in this case, GDAL is not able to deduce the coordinate system or geotransform. It seems like there *might* be enough metadata available to construct coordinate system information for this dataset but it would likely require a fair amount of fooling around to implement and verify. If the data is public you might want to file a GDAL ticket with a pointer to the dataset and the metadata report along with a request to support this georeferencing format. But I must confess I am unlikely to work on it unless I have client interest. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ArcSDE: connection times too long
On 11-04-12 10:33 AM, Duarte Carreira wrote: Hi listers. I’m seing a very long delay while connecting to ArcSDE. Even if I just do ogrinfo on a single layer I still have to wait a few minutes before I get anything back. Any parameter I can use? Duarte, The SDE driver docs at http://www.gdal.org/ogr/drv_sde.html says: If the layer parameter is specified then the SDE driver is able to skip reading the summary metadata for each layer; skipping this step can be a significant time savings. So try listing the layer of interest in the connection string. SDE:server,instance,database,username,password,layer Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ArcSDE: connection times too long
On 11-04-12 12:12 PM, Duarte Carreira wrote: Hi Frank. I do that already: ogrinfo -so -ro SDE:server,5151,,user,pdw user.featureclass Notice that I separate the layer name with a blank space. Using a comma does not work for me (wonder if the docs are right on that??). I still wait quite a bit. This is a mid-sized db, with some 1200 feature classes... Duarte, In your case you are passing user.featureclass as the layer name to ogrinfo telling it that you only want to report on that layer. But to avoid opening all layers, you should also include it in the connection string. eg. ogrinfo -so -ro SDE:server,5151,,user,pdw,user.featureclass user.featureclass Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Warping ECMWF's grib file
On 11-03-29 06:44 AM, António Rocha wrote: Driver: GRIB/GRIdded Binary (.grb) Files: c:\Test_areas\area8.grib Size is 15, 5 Coordinate System is: GEOGCS[Coordinate System imported from GRIB file, DATUM[unknown, SPHEROID[Sphere,6367470,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (169.500,6.000) Pixel Size = (1.500,-1.500) Corner Coordinates: Upper Left ( 169.500, 6.000) (169d30' 0.00E, 6d 0' 0.00N) Lower Left ( 169.500, -1.500) (169d30' 0.00E, 1d30' 0.00S) Upper Right ( 192.000, 6.000) (192d 0' 0.00E, 6d 0' 0.00N) Lower Right ( 192.000, -1.500) (192d 0' 0.00E, 1d30' 0.00S) Center ( 180.750, 2.250) (180d45' 0.00E, 2d15' 0.00N) So it seems some kind of a conflict with the coordinates. Right? Any tip on how to solve it? Thanks António Rocha wrote: Greetings I have a GRIB file with longitude between 170 and 190 (attached to this email) and, when I try to warp it to Geotiff the outcome cannot be displayed. Can anyone give me a tip on how to warp this file? (the problem is not the grib but the longitude coordinates) Antonio, The first email did not come through, likely due to a large attachment. Can you make the file you tried available by http, and post the exact command you used to transform it? There are various complexities with files crossing the dateline but I'd like to have the real file and command to test before trying to respond. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_translate gif-gtiff warning
On 11-03-29 12:22 PM, Dori wrote: Hi, I am trying to convert this GIF https://picasaweb.google.com/izzybitsie/GDALImage?feat=directlink http://aviationweather.gov/data/products/swl/ll_12_0_cl_new.gif to gtiff. I used this command after assuming projection was lcc: *gdal_translate -of GTiff -a_srs '+proj=lcc +lon_0=-95 +lat_0=25 lat_1=25' -a_ullr $ulx $uly $lrx $lry ../maps/my_image.gif ../maps/my_image.tif * If I try to view the image using ImageMagick I can see it but I get a warning about TiffReadDirectory field tag 42112 encountered. If I try to view the same image with a proprietary software then, I get the same warning but I am not able to see the image. ... Q1: is there any easy way to find out if this warning is caused because I am using the wrong projection? Dori, Tag 42112 is a custom GDAL tag for storing metadata and is unrelated to the projection. Q2: Does the command I am using look OK? The command looks plausible but from the output file it is clear you are assigning corner coordinates that are lat/long, not LCC projected meter coordinates. You will likely need to first reproject the lat/long corners into projected coordinates before you can assign them with -a_ullr. You could use the PROJ.4 cs2cs command or the gdaltransform command to accomplish the reprojection from lat/long to projected coordiantes. Q3: How do I get rid of the warning to try viewing the image with the proprietary software? You can avoid the warning by using the commandline option: -co PROFILE=GEOTIFF This instructs GDAL to avoid adding any tags not in the GeoTIFF standard. However, I suspect the warning isn't actually what is interfering with use of the image. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR S57 write support
On 11-03-29 03:38 PM, slava_l wrote: Good day everyone! I am a new OGR user, using S57 driver to write some data (like soundings and isobaths). Could somebody help me to find any docs or provide some example how to write isobath into the file? I can't find any docs neither over the Internet nor at the GDAL.org Actually, I made S57 file but it's definitely does not match S57 IHO standard. I don't understand how could I make correct Eage record and fill FOID and some other fields. Slava, Producing S-57 files is quite involved. The default support in ogr2ogr really depends on you having the data already in exactly the S-57 data model. This can work when transforming from S-57 to S-57 but otherwise is very very difficult. Are you hoping to write S-57 files with ogr2ogr? A script? A C++ program? I did once write a small c++ program to write files with just soundings but I can't seem to find the source code now. Normally a task like this would either require a serious S-57 expert or you would need to contract someone like me to assist and it would be somewhat expensive. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reproject Landsat USGS image
On 11-03-28 05:10 AM, Luisa Peña wrote: Hello I got a reply to my message stating that GDAL ignores a flag in the GEOTIF specification that says whether the coordinates are for the center or the lower-left of each pixel. Is this true? It's exacly what I am obtaining and what Markus Neteler explained me (about the useage of NN method) Can anyone confirm me? Luisa, Prior to GDAL 1.8 the PixelIsPoint information was not considered to affect the Geotransform. This was corrected in 1.8 and is described in this RFC: http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint Note that this does not have a different result depending on the warper resampling kernel used. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Getting unique values from a raster band
On 11-03-21 08:28 AM, Tom Jeffery wrote: What is the proper way to extract all the unique values contained in a raster Band object? I had initially assumed that if a RasterAttributeTable object existed, it would contain a Value column, but I have come across instances where the only column in the table is a Histogram field containing the counts of each pixel value, but not the value itself. Currently, I check for the existence of the table, check to see if it has a Value column, and if not, inspect each pixel value to get the unique set. The pixel scanning fallback method is quite slow, however, and when I view the same rasters in ArcCatalog and bring up the Table view, it is able to instantly display the typical Value / Count table. Is there some trick I'm missing here on how to get these values? Tom, I believe that ArcGIS is using the GetHistogram() method on the band which can also find the histogram stored in other ways than a RasterAttributeTable. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] download.osgeo.org down?
Hi, Still unavailable from my network, in Spain. Same problem with trac.osgeo.org since today. And http://www.downforeveryoneorjustme.com/trac.osgeo.org Says trac is down... Should we report this to http://lists.osgeo.org/mailman/listinfo/sac ? Jorge, The Trac/SVN VM was down for circa 30 minutes this morning, but should be working fine again now. This problem was unrelated to the download.osgeo.org issue. For GDAL or other OSGeo systems problems I would encourage the following sequence: 1) Mention it in the #osgeo channel on IRC if you notice a problem. 2) wait 10-15 minutes for a response or for a transient problem to go away. 3) Submit a trac ticket at http://trac.osgeo.org/osgeo (with component set to Systems Admin) and details on the issue. Email about the ticket will be sent to the sac mailing list. Obviously problems with trac can't be reported via trac in which case email to the s...@lists.osgeo.org mailing list would be good. Note that you need to be subscribed to the list to post to it. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] download.osgeo.org down?
On 11-03-18 07:50 AM, Niccolo Rigacci wrote: Can someone on the download.osgeo.org network check the reverse route? A ping should suffice, an example hosts to check against: 88.57.16.26 (my gateway on INTERB-MNT) Niccolo, I can confirm the above IP cannot be pinged from download.osgeo.org, but can be from Montreal. I will note there is a download mirror at http://download2.osgeo.org/ I would suggest we leave other dicussion of download.osgeo.org to the OSGEO System Administration Committee mailing list. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rotate unreferenced tiff file by -90 degrees
On 11-03-17 05:09 AM, Wesley Roberts wrote: Dear gdal'ers I am working with TRMM rainfall data from an HDF5 file (converted from hdf4 to hdf5). I am able to use gdal_translate to extract the gridded data from the HDF file using the following command. gdal_translate -of GTiff HDF5:3A25.071201.6A.h5://DATA_GRANULE/PlanetaryGrid2/e_surfRainMean2 test.tif Gdal_translate works a treat and writes out the test.tif file perfectly, however, the file is unreferenced and needs to be rotated by -90 degrees. Is it possible to do this using gdal_translate or do I need to make use of gdalwarp as well? My tiff world file needs to look something like this 0.50 0.000 0.000 -0.50 -179.75 36.75 Am I correct in assuming that a suitable proj4 statement might do the trick, wrt assigning projection info and defining rotation? If so can someone point me towards a document explaining the various proj4 declaration parameters, or give me some advice on how to go about getting the data properly referenced. Wesley, I think the easiest approach is to prepare a worldfile representing the current georeferencing in east-up or west-up orientation. Then use gdalwarp to transform it to north up. gdalwarp input.tif output.tif For east up I think the world file might look something like: 0.0 0.5 0.5 0.0 top-left-x top-left-y You might need to fiddle around with the orientation a bit to get it right. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rotate unreferenced tiff file by -90 degrees
On 11-03-17 10:49 AM, Zoltan Szecsei wrote: For east up I think the world file might look something like: 0.0 0.5 0.5 0.0 top-left-x top-left-y You might need to fiddle around with the orientation a bit to get it right. Best regards, But presumable the pixel sizes (1st 4th) would not be zero? Zoltan, For east-up or west-up I believe that the 1st and 4th elements in the world file *should* be zero and the 2nd and 3rd will be the pixel size though I may be mixed up about the signs. More detail on the meaning of the world file is available at: http://en.wikipedia.org/wiki/World_file Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need help generating output with alpha channels using Python API
On 11-03-14 12:50 PM, Michal Migurski wrote: Hello, I'm having some difficulties understanding how to get GDAL to generate images with usable alpha channels. I have 3-channel RGB input JPEG image, delivered to GDAL as a VRT with a projection and ground control points, which I'm warping to an output that's no longer rectangular, leaving background areas exposed. Here is an example output: http://things.teczno.com/gnomotile.png The black parts are intended to be transparent, but I haven't been able to understand how to make that work. Here's the relevant part of my Python code: http://dpaste.com/hold/500308/ I've tried to switch to a four channel output which gets me what I think are CMYK channels. I've tried to use SetNoDataValue on the destination bands to make the background purple so it can be easily knocked out. I've tried to create the GTiff output dataset using the ALPHA=YES creation option, but it seemingly doesn't make a difference. None of these ideas has worked - does anyone have any ideas on how the Python API can be used to create transparent output? Mike, I would have thought preinitializing the destination dataset to a marker value should have done the trick. I'm not sure what you mean by using SetNoDatavalue(). Are you aware that this just records metadata with the band indicating what the nodata value should be? Normally I would suggest adding an alpha band on the output and ensuring it is used. But I see GDALReprojectImage() does not make it easy to do this particularly the way it is bound in Python which does not allow one to pass in the warp options structure. So one approach is for you to precreate the output image, initializing with some particular nodata pixel value and then using that in post processing. Another approach might be for the me to modify GDALReprojectImage to utilize an alpha band properly if it exists on the destination image. I can do this in trunk if that would be helpful to you. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Chinese Filenames
On 11-03-10 10:42 AM, kui yang wrote: gdal 1.8.0 has problem. when the filename is in Chinese Kui Yang, That is not a very detailed bug report. GDAL 1.8 includes some changes in the underlying handling of filenames such that filenames passed in to GDALOpen() should be passed in UTF-8 rather than the local encoding. This was generally the situation already on Linux and I suppose most other unix type operating systems. But it was a change on windows. Are you working on windows? How are you encoding the filenames being passed to GDALOpen()? As a workaround, you can restore essentially the old filename handling behavior on windows by setting the GDAL_FILENAME_IS_UTF8 configuration variable to NO. Some info on setting config options is available at: http://trac.osgeo.org/gdal/wiki/ConfigOptions Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] crop a non-square subwindow?
On 11-03-10 05:07 PM, Wendell Turner wrote: Is there a way to force pixels outside of the cropping polygon to be 'not there', or transparent? Is there a burn value that indicates that? Wendell, The -dstnodata parameter can be used to set the output nodata value. I'm not sure if it will properly mark that value as no data or not and whether the end application honours nodata values in geotiff is ... variable. Another approach is to use -dstalpha to add an alpha channel to the output. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALWarpOperation.ChunkAndWarpImage slow on large tiffs
On 11-03-09 01:46 PM, Radim Blazek wrote: Hi, GDALWarpOperation.ChunkAndWarpImage was reported to be extremly slow on larger geotiff (over 1GB). Is it possible that it is much slower with respect to GDALRasterIO() even without reprojection? Should I return to 'manualy' reading data via GDALRasterIO() + fidling with data extents and cells alignement? I thought that GDAL ChunkAndWarpImage will do it even faster, possibly knowing better (?) various formats nature. Is there way to tune somehow performance? Currently no reprojection and GRA_NearestNeighbour. Radim, GDALWarpOperation is intended to be a high precision image resampler. Within the constraints of doing this correctly it attempts to be fast, but it will generally be quite a bit slower than direct RasterIO calls and in some situations dramatically slower. Particularly it is completely inappropriate to use for radical downsampling. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Polygon
On 11-03-04 05:02 AM, Alexandre Leclerc wrote: Anybody can help me please ? I feel that the SHPWriteObject() write a bad way in the file. Do you think it could come from compiler ? I use Borland C++ 6 When I edit the file in text editor it seems good, the length of the file is 1904 But when I read file with SHPOpen() the psSHP-nFileSize attribute is 100… oddly this corresponds to the size of the header (shx). So I wonder if It comes from compiler or not… What do you think ? Alexandre, It sounds like you neglected to close the file so the header remains as it was on creation. Shapelib related questions are better sent to the Shapelib mailing list. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How files are handled in OGR / GDAL
On 11-03-01 12:29 PM, Mikhail Tchernychev wrote: Hello List, I could probably figure it out from the source, but I would apprecaite if someone could point me in the right direction. The question is: does GDAL / OGR loads the file in the memory when it opens in or it just keeps reference to the actual file Say if I open it, process it etc hDS =OGROpen http://www.gdal.org/ogr/ogr__api_8h.html#123bb02ac8c5cfe143e132f627531125(point.shp, FALSE, NULL ); and then do (without closing) poLayer-ResetReading http://www.gdal.org/ogr/classOGRLayer.html#ad0f2cd7f0587584b8f382c6a913583c(); and process again would it actually trigger re-reading file from the disk or not? In other words does OGR creates complete memory image for the file or just reads actual file when it needs something? Mikhail, These is driver dependent. But we try to avoid holding too much of the underlying file in memory. In the case of the shapefile driver the .shx index contents are loaded into RAM and kept there but the .shp and .dbf records are read as-needed. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] What is status of RFC23?
On 11-02-24 09:05 AM, Mateusz Loskot wrote: Folks, I'm trying to find what's the actual status of the RFC 23 [1] The only reference I got so far is from its header: Status: Adopted (partially implemented) and 1.6.0 release notes [2]: RFC 23: Preliminary support for character set transcoding (in OGR for now). but what does it mean? What means preliminary and partially here? Are the functions like OGRFeature::SetField and GetFieldAsString() fully UTF-8 aware/enabled? [1] http://trac.osgeo.org/gdal/wiki/rfc23_ogr_unicode [2] http://trac.osgeo.org/gdal/wiki/Release/1.6.0-News Mateusz, The RFC is now mostly implemented. Only recently the iconv() implemented was integrated into CPLRecode(). Of course the RFC sets up the superstructure but does not guarantee that all drivers return UTF8. Skiming the code, it appears the dxf, GeoRSS, GML, GPX, NAS, Postgres, SOSI, VRT (depending on underlying layer) and WFS layers declare themselves with OLCStringsAsUTF8. Of course other drivers may also be UTF8 but not fully declared. What was listed in the RFC, but was not done, was UTF8 translation of wide string fields in the ODBC driver, and support for recoding from/to UTF8 in the Shapefile driver. So in that sense it is still incomplete. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bug in SetField
On 11-02-24 11:56 AM, Mohammed Rashad wrote: my code field - fieldname is of string type and 0th field poFeature-SetField(fieldname,value); poFeature-GetFieldAsString(0); returns v instead of value; I dont know is it bug or my problem but I opened the shapefile in OpenJUMP and QGIS both shows field names as only v instead of value I am working with shapefiles Mohammed, What does the ogrinfo report on the field definitions look? ie. ogrinfo -so -al abc.shp I suspect the field fieldname was defined with a width of one. SetField() will automatically truncate the value in such a case. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: What is status of RFC23?
On 11-02-24 12:10 PM, Mateusz Loskot wrote: Frank, It answers my question. Thanks. The RFC 30 states GDAL uses UTF-8 encoding internally when working with strings. Does it mean functions like GDALGetDataTypeName are considered to return UTF-8? I understand that in this particular case, there is no difference between ANSI and UTF8 regarding content of the string, but I'm trying to learn if and how far the uniform pattern applies. Mateusz, I don't think you should take that statement to mean very much. I think it was just intended to convey that the string and stringlist attributes of features would be treated as UTF-8 during internal processing. That statement might also have been left over from an earlier, broader version of the RFC. In practice the RFC should only be taken to address string and stringlist attributes of features. Certainly it is my *intent* that essentially all strings in GDAL/OGR should be handled as UTF-8. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Windows builds and wildcard usage for gdaltindex gdalbuildvrt
On 11-02-24 03:22 PM, Armin Burger wrote: Hi all I wanted to use a more recent Windows build than the latest FW Tools which are a bit old now. I used the binaries from http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1310-gdal-1-8-0-mapserver-5-6-6.zip All works fine, just the usage of wildcards in tools like gdaltindex or gdalbuildvrt does not work any more. If I run eg gdaltindex tileindex.shp *.tif I just get the error that the file *.tif could not be found. Same happens for gdalbuildvrt.exe. So the wildcard resolution seems not to work any more (it still did work in the last FWTools 2.4.7). For gdaltindex I can use a for loop command because it adds every tif to the same shape, but I don't think this workaround works for the gdalbuildvrt. On Linux builds the wildcards usage still works fine with GDAL 1.8. Any ideas if this will be fixed for Windows? Armin / Tamas, For this the SETARGV macro in nmake.opt needs to reference an appropriate setargv.obj object file from the visual studio tree. The default is commented out: #SETARGV = $(VCDIR)\lib\setargv.obj On Unix and unix like shells such as cygwin on windows the shell performs expansion of wildcards in filenames. On the Windows CMD.EXE command processor this is not the case, and the setargv.obj provides a default implementation of wildcard expansion. Perhaps Tamas could enable this for his builds. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] image header UL,LL,UR,LR
On 11-02-24 04:16 PM, Shawn Gong wrote: Hi list, I have a flat binary image HH.img and a HH.aux header The header file looks like: AuxiliaryTarget: HH.img RawDefinition: 1492 1680 1 ChanDefinition-1: 32R 0 4 5968 Unswapped ChanDesc-1: HH intensity SegDesc-1-0: Contents Not Specified MapUnits: LONG/LATD-04 UpLeftX: -5.601451 UpLeftY: 36.098471 UpRightX: -5.305277 UpRightY: 36.148817 LoLeftX: -5.522707 LoLeftY: 35.800948 LoRightX: -5.227759 LoRightY: 35.851245 ProjParms: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 gdalinfo does not give the right corner coordinates. what changes do I have to make for gdal to ingest? (I can use gdal_translate, but try to avoid that route) Shawn, The PCI .aux file is only intended to be used with north up images. I see your corner coordinates are not regular. For instance the longitude of the upper left and lower left corner are not the same. You could wrap the same dataset in a raw VRT and associate GCPs with it to identify the corner coordinates instead of trying to set a geotransform. Scan down to the raw file part of: http://www.gdal.org/gdal_vrttut.html Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] transform input image to UTM
On 11-02-23 11:27 AM, Jorge Martin wrote: Hello, I want to project an input Lat/Long image into UTM. I need to do this automatic, so I have to do it in C++. I have found a source code to implement this issue. I have paste below the source code that I have used. I When this code is running, appears some times the followin error messages: ERROR 1: no system list, errno: 42 and Jorge, This is normally an error message from PROJ.4. I see errno.h has error 42 as ENOMSG or No message of desired type which is unlikely. Error -42 (a PROJ.4 specific error) is |lat_1| == |lat_2|. I'd suggest careful examination of the input and output coordinate systems to see if there is anything odd about them. ERROR 6: SetColorTable() not supported for multi-sample TIFF files. What is it means? This is because you try to copy color tables from all three source bands to all three destination bands but it is highly unlikely there even is a color table on the source bands. The error message is reporting that TIFF has no way of storing color tables on multi-sample (ie. RGB) files. When I open the output image there are some strange black lines crossing the output image that not appear in the input image. Is there any reason for this behaviour? That is harder to analyse. You would pretty much need to provide a full bug report (ideally via Trac) in order to get a good answer. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to use GDAL C++ dynamically?
On 11-02-22 05:52 PM, Mikhail Tchernychev wrote: This is what I normally do, however it's not much less pain, even it's simple. I typically write a wrapper to execute all GetProcAdress() functions at once and store pointers in the class. Taking into number of GDAL functions, its' would be very challenging. Mikhail On 2/22/2011 2:43 PM, Even Rouault wrote: Le mardi 22 février 2011 23:14:50, Mikhail Tchernychev a écrit : Hello List, I wonder if someone could point me into the right direction. I would like to use GDAL as loaded DLL at run time, with LoadLibray() call under windows and corresponding calls under Linux. I see that most of the functions are virtual, so it seems it is made with this in mind. I am trying to compile simple program: I think you are going to inflict you a lot of pain with LoadLibrary() and C++ API at the same time ! If you really need to dynamicly load gdal, use the GDAL C API instead... Folks, I will note that at one time I maintained a bridge mechanism which basically did this. It dynamically loaded the C API at runtime. I stopped maintaining it several years ago but you can still find it in old code branches. ie. http://svn.osgeo.org/gdal/tags/gdal_1_2_0/bridge/ If someone felt it was really useful, that might be a good place to start. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL JP2KAK plugin for lossless 16 bit
On 11-02-22 11:31 AM, Frederic CLAUDEL wrote: Hi, I've been trying to create a lossless JPEG2000 image from a signed 16-bit DEM (stored in a TIFF file), but have had no success so far with JP2KAK. My DEM has large NoData regions (value is DTED NoData : -32767) I tried different GDAL versions (1.7 1.8), and different versions of KAKADU (6.3, 6.2) I'm using gdal_translate -of JP2KAK -co QUALITY=100 input.tif output.tif The image is created with no errors, but shows strong artefacts around Nodata parts, while the large NoData areas are transformed to random 16bit garbage. Frederic, I would encourage you to file a ticket and I'll investigate. I believe there is a bug in the JP2KAK driver. I started some related improvements a couple months ago but let them fall by the wayside since no one seemed to be running into the problems. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] 2011 FOSS4G Call for Papers
Folks, The call for presentations for FOSS4G 2011 in Denver is now open. The full announcement follows: Open Source Geospatial Conference Calls for Speakers Education for All Levels of Ability and Experience DENVER, Feb. 22, 2011 -- The Free and Open Source Software for Geospatial (FOSS4G) conference is reaching out to speakers interested in presenting at the 2011 conference that will be held Sept. 12 - 16 in Denver, CO, USA. FOSS4G is the premier international conference focused on open source geospatial software. The open source geospatial toolset is mature with enterprise-class deployments across the globe at all levels of enterprise for a wide variety of applications. Users and developers are encouraged to present their latest projects and software development work to demonstrate the power of open source geospatial solutions. The organizers are looking for a good mix of content for all levels of ability and experience with open source. In addition to high-caliber sessions for developers, there are plans for several workshops and sessions that will welcome non-technical decision makers to the power, capability and compelling business case for open source geospatial software. Presentation topics will include case studies of open source applications, benchmarks of performance between different components, visualization tips and tricks, and new tool developments, hacks and mashups. In addition to the core focus on free and open source software, this year’s conference will also feature a major focus on free and open data. Content may cover systems that are solely open source or a combination of open and closed source solutions. Sessions will run in seven concurrent tracks with space for around 135 presentations in both a regular program and an academic program. Presentations will either fill 30-minute slots with time for questions or 5-minute lightning talks. Proposals can be submitted online at http://2011.foss4g.org/program/. There is pent up demand in the North American market for this content given the growth in open source geospatial solutions and the fact that this is the first time this international event will return to a North American venue in four years. “With the current strong interest in open source geospatial solutions, we anticipate an attendance of around a thousand people” said Peter Batty, conference committee chair and vice president of geospatial technology at Ubisense, Inc. “We have a great venue and an experienced organizing team, and believe this will be one of the premier geospatial events of 2011.” This year’s FOSS4G event is also adjacent to State of the Map, the annual international conference focused on OpenStreetMap, the wiki-style creator and provider of free geographic data that has recently garnered corporate support from both MapQuest and Microsoft. The ability to attend both events with one trip to Denver in September makes for a great opportunity to learn about the latest developments in the geospatial industry. The event already has strong support, with major sponsors that include Esri, Google, OpenGeo, MapQuest, Newmont and Safe Software. Bronze sponsors include CamptoCamp, EOX, GeoCat, GeoIQ, GeoSolutions, Korem, MapGears, Metaspatial, Oracle Spatial, Spatial Networks and Terrestris. You can view an updated list of sponsors at http://2011.foss4g.org/sponsors. About FOSS4G FOSS4G is the global conference focused on Free and Open Source Software for Geospatial that is organized by the Open Source Geospatial Foundation (OSGeo) with support from an all-volunteer organizing committee and professional conference management from the Geospatial Information Technology Association (GITA). The 2011 FOSS4G event in Denver marks the first North American event in four years, with the prior three events taking place in Barcelona, Sydney and Cape Town. SOURCE FOSS4G Organizing Committee RELATED LINKS: http://2011.foss4g.org/ FOSS4G Denver 2011 http://www.osgeo.org/ Open Source Geospatial Foundation http://stateofthemap.org/ State of the Map Conference http://www.gita.org/ Geospatial Information Technology Association -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: GCP list projection
On 11-02-18 03:39 AM, Vadim Shlyakhov wrote: So, if you have GCP SRS, you don't need SRS set at the dataset level, do you? Vadim, Correct. BTW I've noticed if a dataset doesn't have a geotransform, then ds.GetGeoTransform() returns (0.0, 1.0, 0.0, 0.0, 0.0, 1.0). Is that a feature or a bug? As mentioned, this the fallback value when there isn't one. But the method should return CE_Failure on failure so you can distinguish whether the unity transform is real or just a filler value. So I consider it a feature. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal install error version 1.5.0
On 11-02-17 08:41 AM, Mohammed Rashad wrote: Install error; console log bin/sh /home/rashadkm/gdal-1.5.0/libtool ... -- Thanks Regards Rashad Rashad, GDAL 1.5.0 is quite old, and not even the newest of that stable branch. Try GDAL 1.8.0. If the problem persists I'm sure we would be glad to look into it. If you really need a GDAL 1.5.x version then at least use the newest 1.5.x release (1.5.4?). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal android
On 11-02-17 06:00 AM, Mohammed Rashad wrote: here is my new error log cpl_strtod.cpp: In function 'void CPLReplacePointByLocalePoint(char*, char)': cpl_strtod.cpp:200: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:201: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:204: error: 'struct lconv' has no member named 'decimal_point' make[1]: *** [cpl_strtod.lo] Error 1 make[1]: Leaving directory `/home/rashadkm/gdal-1.8.0/port' make: *** [port-target] Error 2 Which gdal version to use for Android Rashad, My copy of cpl_strtod.cpp (trunk) has an ifdef in that function for the __ANDROID__ case. Do you? If yes, I wonder why it isn't getting activated. Perhaps you should review the fairly new android notes at: http://trac.osgeo.org/gdal/wiki/BuildingForAndroid Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GCP list projection
On 11-02-17 10:08 AM, Vadim Shlyakhov wrote: Hello, I wonder if it makes any sense if GCP list at a dataset is different from the dataset's SRS. I've played a little with these in Python, but neither gdal.Transformer, nor warping via VRT doesn't produce the results expected. I mean, presumably if GCP's SRS is different from the dataset's SRS, then they are to be transformed internally into the dataset SRS, but this doesn't seem to happen Vadim, Normally I would expected a dataset with GCPs to have a GCP SRS, and no dataset level projection or geotransform. When given such a datsaet, gdalwarp will attempt to produce an output dataset in the *GCP SRS*. If the source dataset has both a GCP SRS and a dataset level SRS I am not absolutely positive what gdalwarp does, but I feel it *ought* to be producing an output file in the GCP SRS if it is using the GCPs. I am not sure why you expect the GCPs to be reprojected. Note, if the output file is in a different SRS than the GCPs, I think the GCPs would still be used to compute a polynomial in the SRS of the GCPs for getting from source file pixel/line to source georeferenced coordinates. Then reprojection would be applied as an extra step. In theory it could make sense to have a dataset with a dataset level SRS and geotransform, and also GCPs with a different SRS. In some cases the GCPs are in a particular SRS (say lat/long) just because it is a convenient coordinate system to collect the GCPs, not because it is representative of the geometry of the image. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Zero Pixel Values in the output! Solution Please
On 11-02-16 03:28 AM, user gdal wrote:
Dear all,
I am new to GDAL and I was at fault in being too hasty in asking for
an advanced topic in my previous post.
...
templateclass T void CIOImg_TemplT::Read(const unsigned int b,
GDALDataset* const *inds)
{
((*inds)-GetRasterBand(b+1))-RasterIO(GF_Read, 0, 0, Col, 1,
buf[b], Col, 1, datatype, 0, 0); // able to read the pixel values
correctly into buffer (buf)
}
Ramesh,
One thing I notice about your code is that you only appear to read
and write the first scanline of the image. Is this intentional?
For the purposes of asking a question of the list it would be helpful if
you could boil your program down to a minimum example including all the
essentials. It will require extra work on your part, but will make it
much easier for the many members of the list who might want to skim
through the code to see if they have suggestions.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] lat lon matrix tables to geotif
On 11-02-16 01:48 AM, Nikolaos Hatzopoulos wrote: So you are talking for something like this: Example VRT file for data (just to show the geolocation metadata reference): VRTDataset rasterXSize=2048 rasterYSize=964 Metadata domain=GEOLOCATION MDI key=X_DATASETdata.lon.vrt/MDI MDI key=X_BAND1/MDI MDI key=Y_DATASETdata.lat.vrt/MDI MDI key=Y_BAND1/MDI MDI key=PIXEL_OFFSET0/MDI MDI key=LINE_OFFSET0/MDI MDI key=PIXEL_STEP1/MDI MDI key=LINE_STEP1/MDI /Metadata SRS stuff goes here/SRS VRTRasterBand dataType=UInt16 band=1 subClass=VRTRawRasterBand ImageOffset1500/ImageOffset PixelOffset10/PixelOffset LineOffset22180/LineOffset ByteOrderLSB/ByteOrder /VRTRasterBand /VRTDataset Nikolaos, Yes, metdata formatted as above though the VRTRasterBand is incomplete. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo: Corner Coordinates
On 11-02-15 07:50 AM, Emilio de Torres Fernández wrote: If I use the equations of the azimuthal equidistant projection http:// to transform long=6d32'32.13W and lat=36d42'16.93N) I get x = -0.65688 and y = 0.78961, not (-4195457.112, 5006607.739). Why??? I guess I misunderstood some concept of the Corner Coordinates of gdalinfo. Emilio, Well, I don't know what equations you are using, but I can't imagine getting x and y values in meters that small unless you were *right at* the origin which is not the case. Perhaps you don't understand the units required by, and/or produced by the equations you are applying? When I use PROJ.4 to do the reprojection (as GDAL does underneath) I get: cs2cs -I +proj=aeqd +lat_0=-6.25005 +lon_0=36.51677 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +to +proj=latlong +datum=WGS84 6d32'32.13W 36d42'16.93N -4196092.49 5007369.96 0.00 Make sure you aren't mixing up longitude and latitude. GDAL and PROJ.4 default to long/lat order while the location seems coincidentally near the origin of the projection *if* you reversed the ordinates. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] lat lon matrix tables to geotif
On 11-02-15 01:20 PM, Nikolaos Hatzopoulos wrote: So we have three tables: one matrix for latitude values one matrix for longitude values one matrix for our data values all the matrix have the same dimensions how we can convert these three tables to geotif using gdal?? Mikos, This is a georeferencing method I refer to as geolocation grids. It is not a supported organization in GeoTIFF so there is no way to produce a GeoTIFF with the above data where the meaning of the latitude and longitude values will be well understood. If you want to use the resulting geotiffs in non-GDAL applications I think you are best just turning each matrix into a separate TIFF file with appropriate file names to suggest the meaning to and end user. Another option is to just rectify the image data into a normal north up rectified grid and write that to GeoTIFF. Such an output would be easily exploited in any GeoTIFF reading application. It also is possible to use metadata to associate the latitude and longitude as geolocation grids within a GeoTIFF file in a way that some GDAL applications (like gdalwarp) could take advtange of. This requires setting up very specific metadata items to relate the data. The metadata required (for geotiff or other formats) is listed in RFC 4: http://trac.osgeo.org/gdal/wiki/rfc4_geolocate Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] nmake.local on windows builds
On 11-02-14 08:54 AM, Jeff McKenna wrote: I personally have always just modified the nmake.opt. I am not sure what is recommended now. Can someone verify that the new recommended way is to create a 'nmake.local' file and then execute 'nmake /f makefile.vc' ? Jeff, Well, either way will work. But *my* recommendation is creating an nmake.local with GDAL trunk and beyond. This is better than editing nmake.opt directly particularly in the case where you later want to do svn update's and rebuilds. If you hand edit the nmake.opt there is a significant risk of needless merge conflicts. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MrSID mask band support
On 11-02-14 03:52 PM, Brian Claywell wrote: I'm attempting to use CreateMaskBand() on a MrSID dataset with GDAL 1.8.0 and receiving the error that CreateMaskBand() is not supported on this dataset. I presume this is because mask band support was implemented using the GDALDefaultOverviews manager, and since MrSID is a multi-resolution format, the overview manager is never initialized. Brian, This is a lucid deduction. I believe you are right. Is there a way to make mask bands work with MrSID datasets out of the box? Barring that, since the MrSID driver reimplements the overview-related virtual functions to bypass the default overview manager, would there be any harm in initializing the overview manager when a MrSIDDataset object is created? The one caveat I might offer is that it would be prudent to have MrSIDDataset override IBuildOverviews() or else people will find they can build external overviews for MrSID but they will never be used. The IBuildOverviews() override would presumably just report that overviews are built in for mrsid and building them is unnecessary. If you try this out, I'd be interested in a patch submitted via Trac. A similar approach would likely apply to formats like ECW and JPEG2000 with built in overviews, but where masks would still be useful. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MSVC warnings changes
Folks, I have spent several hours today cleaning up warnings when building with Microsoft Visual C++. The first step was to move warning suppression out of gdal/port/cpl_port.h and instead passing warning suppression via the compiler commandline line. This is accomplished by setting of the WARNFLAGS macro in nmake.opt with a warning level (/W4 now) and a set of specific warnings to be disabled (using /wd4127, etc). Moving the disabling out of cpl_port.h is important because it means GDAL policy of disabling some warnings will not impact applications including gdal.h. The warning I have disabled are things I feel are reasonable practice and not worth seeing as warnings. Mostly this is the same as the warnings disabled in cpl_port.h, but I have add a few including warnings related to signed/unsigned comparison mismatches. These drive me nuts and have not (for me) yet lead to identifying a real error. I have also introduced the SOFTWARNFLAGS macro. This disables a bunch more warnings, and is used in some of the submakefiles building code from external sources that we can't practically alter. This includes stuff like zlib, and libjpeg. I have made a variety substantial pass over the GDAL source tree building with MS Visual Studio 2008 Express Edition and trying to adjust the code to clean away warnings and in a few cases adding extra local warning disablers either in makefiles or using the pragma in the code. These changes can mostly be seen in these commits: http://trac.osgeo.org/gdal/changeset/21684 http://trac.osgeo.org/gdal/changeset/21680 The main warnings I'm still aware of are related to the MITAB and AVCE00 libraries. These changes need to be upstreamed and were sufficiently involved that I put them off. Beyond that I was able to get a pretty much warning free build on /W4. Going forward I am hoping we can balance appropriate choice of warnings to suppress globally and adjustments to the code to keep our windows build warning-clean. Hopefully this will help us be more vigilant in addressing new warnings that do pop up. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] nmake.local on windows builds
Folks, Some time ago Tamas added a mechanism to nmake.opt (the central include file for windows MSVC nmake based makefiles) so that you could provide an extra definition file on the commandline. eg. nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt While this is useful, expecially in cases where it is desirable to have several build configurations out of one tree, I never used it. I always just adding !INCLUDE nmake.osgeo4w or !INCLUDE nmake.frank at the beginning of nmake.opt and put my definitions in that new file. With Kirk's recent introduction of a complicated nmake.opt file for the MrSID driver, I've learned that you can check for the existance of a file in an nmake !IF EXISTS directive, and I have incorporated use of this in nmake.opt to pull in nmake.local if it exists. So going forward, I'm hoping the default way of tailoring windows builds will be to create an nmake.local file overriding definitions from nmake.opt. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] nmake.local on windows builds
On 11-02-11 06:56 PM, Tamas Szekeres wrote: Frank, While I'm not sure about what changes you intend to do here, I would emphatically disagree removing the current approach with the ability of setting the full path to the external configuration file from the nmake command line. My build system is higly depend on this setting and if we don't have any compelling reason I would like to avoid relocating this custom file (which is anyway generated dynamically) into the gdal source tree. Tamas, I did not remove the support for EXT_NMAKE_OPT - the first stuff in nmake.opt now looks like: ### # For convenience, user may put custom settings in a local settings file # named nmake.local, or a name defined by the EXT_NMAKE_OPT option. !IF EXIST($(GDAL_ROOT)\nmake.local) !INCLUDE $(GDAL_ROOT)\nmake.local !ENDIF # nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt !IFDEF EXT_NMAKE_OPT !INCLUDE $(EXT_NMAKE_OPT) !ENDIF I believe this will serve both needs smoothly, albeit with a little extra complication in the nmake.opt. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
On 11-02-10 01:43 PM, Hailey Eckstrand wrote: But the stays the same: ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds. Hailey, I tried with your file and with debugging on and saw the following message: WARP: Recompute out extent with CHECK_WITH_INVERT_PROJ=TRUE I read through the code in gdalwarp.cpp and it seems this is something added, perhaps by Even, to check that the output area selected is appropriate and can be effectively reprojected. I tested a few points between the somerc projection and WGS84 with the PROJ.4 cs2cs command and found there was often poor fidelity - likely indicating that points were being transformed that are far outside the well defined area for the projection. I did successfully run your gdalwarp command by adding: --config CHECK_WITH_INVERT_PROJ FALSE on the commandline, but I'm not convinced that the results are actually very accurate or meaningful. I'd suggest you reconsider whether you really want to try and warp nearly the whole world to a swiss oblique mercator projection. Possibly Even could consider improving the error reporting in this case if the issue is really that the transformation is not round tripping well. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libKML driver missing
On 11-02-09 10:27 AM, sebastien.fa...@infoterra.fr wrote: Hello, I have installed ms4w package which involves GDAL/OGR 1.8. Unfortunately, libKML announced as a new driver is missing. Do you have any explanation ? Thank you. Sébastien, There is information on how to build GDAL with libkml support at: http://trac.osgeo.org/gdal/wiki/LibKML Not surprisingly the libkml driver support requires special build time steps to utilize the library. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Help with import gdal import in python
On 11-02-09 11:23 AM, Giacomo Piva wrote: Hi all, I'm getting this error when calling gdal_merge.py command. Traceback (most recent call last): File /home/meeo/bin/gdal_merge.py, line 31, in ? import gdal File /usr/lib/python2.4/gdal.py, line 7, in ? import _gdal ImportError: No module named _gdal I don't know python 'cause I don't know how to solve this problem. Any suggestion? Giacomo, With all due respect you haven't given much context. Did you build and install GDAL and the python bindings yourself? I imagine the problem is related either to the _gdal.so file not being found, or it not loading because the underlying libgdal.so.* file not being found. Does _gdal.so exist in: /usr/lib/python2.4/osgeo Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Large ERDAS Imagine .img Files (HFA) Workaround
On 11-02-09 04:10 PM, Roland Duhaime wrote: I am using gdal2tiles under OSGEO4W. I use both gdal16 and gdal17. When I have a large HFA file I am not able to use gdal2tiles to process this file. These large .img (HFA) files have a spill file with a .ige extension. I receive an error similar to: 0ERROR 4: Unable to open external data file:z38null_rgb.ige (Note that this is not a name I specified) Roland, I imagine your .img and .ige file were renamed at some point and the .img file still has a reference to the original .ige file inside. One option might be to rename the .img to z38null_rgb.img and the .ige file to z38null_rgb.ige. Alternatively, you could use the default gdal package which is now GDAL 1.8 and has improved logic for handling referenced filename problems. It should fallback to assuming the same basename if the internal filename is wrong. My source .img file has a name simlar to: cape_impervious_mosaic_setnull_rgb.img As a workaround I rename just the Erdas Spill file to z38null_rgb.ige and the gdal2tiles command runs without error. Ah, I see you already have a work around. Excellent. Note that now that the default gdal package is 1.8, there should be few reasons to use the non-default version packages gdal16 and gdal17 in OSGeo4W. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Best practices for concurrent writes with GDAL (was RasterIO in paralel)
On 11-02-08 05:58 PM, Francis Markham wrote: Ouch, I guess I'll be slicing and mosaicing, sending all my data across the network, or looking for another IO library. Which approach would you recommend? Are you aware if any of the major non-GDAL libraries for popular formats (e.g. libgeotiff) support concurrent writes? -Francis Francis, Note that the core problem with writing relates to the shared block cache amoung datasets, and problems with ensuring that flushes occur in the appropriate thread. So, with some care you could in theory write from multiple threads, but you would need to ensure that you never fill the block cache triggering block writes due to cache fullness. Using Libtiff/libgeotiff directly will also avoid this problem. Best regards, On 9 February 2011 09:44, Even Rouault even.roua...@mines-paris.org mailto:even.roua...@mines-paris.org wrote: * you cannot write concurrently into the same file (and using several GDALDataset won't help) ___ 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, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Best practices for concurrent writes with GDAL (was RasterIO in paralel)
On 11-02-08 08:04 PM, Francis Markham wrote: Is there any way to disable the block cache altogether? Francis, No, there is no way to disable the block cache altogether. For specific drivers you could skip past the block cache by calling GDALRasterBand::WriteBlock() but this may not work well for all drivers. Does setting the cache size to zero work? In theory that might trigger an immediate flush as soon as the block is pushed into the cache, but I wouldn't trust it. And is there a way to do this from a python script? You can set the block cache max with gdal.SetCacheMax(). I think the argument is a size in bytes. GDALRasterBand::WriteBlock() is likely not accessable from Python. My suggestion is just to set the block cache very large, try to only keep a few datasets open at a time, and make sure they get closed before the block cache comes near to being full. But the real solution is to fix the issue in the core. Providing some logic to ensure that blocks are only flushed in the thread to which they belong or something like that. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDALDestroyDriverManager() - dataset cleanup
Folks, I have modified GDALDriverManager::~GDALDriverManager() so that when it is destroyed it will first close all still-open GDAL datasets. A debug message will be issued for each dataset force-closed. This is part of an effort to ensure a clean shutdown and to make it easier to detect memory leaks in some situations. This is not a completely safe operation. In particular, if there are VRT files referencing other GDALDataset's the referenced dataset may be cleaned up before the referencing dataset which would be bad. I need this primarily for cleanup in MapServer where GDAL datasets are now normally left open (CLOSE_CONNECTION=DEFER). If this automatic dataset description causes problems we can disable or remove it before the GDAL 1.9 release. But it seems relatively harmless to incorporate in trunk for the time being. http://trac.osgeo.org/gdal/changeset/21662 Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize 1.8.0 options
On 11-02-07 06:25 AM, Jan Hartmann wrote: Is there a place to put al the links on the stere-sterea subject together? In my experience, discussions about projection parameters tend to get fragmented, and even if a solution has been found, old errors tend to show up time and again. Sometimes, I can only find the solution in my private email archive. Jan, I had been hoping to convert the topics at: http://www.remotesensing.org/geotiff/proj_list/ into Trac wiki topics so that anyone could easily update them. Perhaps the MetaCRS wiki would be more appropriate than the GeoTIFF one. If anyone was interested in taking that on as a task, I'd be happy to update the links accordingly. We could start by moving over the oblique stereographic discussion and updating it with the missing information. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unable to compile OCI driver
On 11-02-07 04:08 AM, Alexandre Gacon wrote: Hi all, I am trying to build GDAL/OGR with the OCI driver with Visual Studio 2005 and with the OCI coming from the version 11g version of ORACLE. I am stuck with errors during linking : the linker cannot find the symbols defined in the OCI headers. I have put all the libraries I have in the lib path but it has no effect. Any idea ? Alexandre, My first idea is that it would be helpful if you could provide the exact link command that ends up being used, and capture the exact error messages from that link. Otherwise we are largely flying blind. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Read and Write ArcGIS Bynary GRID
On 11-02-07 09:51 AM, Jorge Martin wrote: Hello, Using GDAL library is posible to read and write ArcGIS binary GRID files? Jorge, The support for this format is briefly described at: http://www.gdal.org/frmt_various.html#AIG It is read-only. At one time there was a grid writer in GDAL but it depending on a fragile approach to using ArcView DLLs and it was removed due to a variety of problems. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] error adding ecw on Ubuntu 10.4 (lucid)
On 11-02-07 11:18 AM, Matt Wilkie wrote: Perhaps try setting the environment variable GDAL_DRIVER_PATH to /usr/lib/gdal17plugins Ok, that finally did the trick. Thanks for your help. $ export GDAL_DRIVER_PATH=/usr/lib/gdal17plugins Is this normally set as part of the install? (e.g. should I report a packaging bug?) Matt, No, this is not normally set for prepackaged GDAL's on linux. On linux GDAL defaults to looking in /usr/local/lib/gdalplugins. It is possible to set the GDAL_PREFIX to change the default from /usr/local to /usr for instance, but this is not apparently something the makefiles help with as far as I can see. Note that in 1.9 (aka trunk) GDAL now looks in /usr/local/lib/gdalplugins/1.9 before looking in /usr/local/lib/gdalplugins so embedding the version in the directory name is no longer needed. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Compiling only OGR
On 11-02-04 02:54 AM, Helm, P.W. (Pim) van den wrote: Hi all, I am using only vertex calculation (OGR part) of GDAL. Using the GDAL library does the work perfectly, but I think this 6mb+ dll is rather large for my usage only. Pim, If you really want to trim down GDAL/OGR you will likely have to do some fiddling. I'd start by going through gdal/frmts/makefile.vc and removing most formats from the EXTRAFLAGS list (each -DFRMT_xxx relates to one of the subdirectories). Because of relations to stuff on the OGR side you may find you need to keep the FRMT_pcidsk and FRMT_sdts items. You may also find that you need to keep FRMT_gtiff because the geotiff machinery is used to lookup EPSG coordinate systems, and FRMT_zlib (added below) for other things using compression. You might be able to skip building in all the stuff in gdal/alg by removing it from gdal/makefile.vc but you will also likely need to remove some entry points from BASE_INCLUDE in gdal/makefile.vc. Further more, do I really need the link to proj4 if I only refer to EPSG systems, since this also enlarges my project? PROJ.4 is usually loaded at runtime so if you don't need it just don't distribute PROJ.DLL. Note that if you use OGRCoordinateTransformation then you will need PROJ.4 even if you just use EPSG coordinate systems. It would be nice if your and others findings with doing slimmed down builds could find its way into the trac wiki - perhaps in the http://trac.osgeo.org/gdal/wiki/BuildingOnWindowsWithMinimizedDrivers page or elsewhere as appopriate off: http://trac.osgeo.org/gdal/wiki/BuildHints Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalbuildvrt
On 11-02-03 01:30 PM, Aníbal Pacheco wrote: Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can then used in Mapnik and its ogcserver(WMS), everything works except that the result image is black white and with a very poor resolution. The 2 source tif files used in this test were both colored with a good resolution. Any ideas? Aníbal, I would suggest examining the resulting vrt to see if there is anything odd about it. Start with gdalinfo to see if it's resolution seems reasonable and if in fact it is 3 bands. You might want to run gdalinfo -stats xx.vrt to get band statistics just to verify that the bands are radiometrically distinct. Also, check that the band pixel type is reasonable - the same as the source files. If that all looks ok, then perhaps visually examine the VRT with something like QGIS. After that it comes down to talking to Mapnik people about why there are problems. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_translate making NITF-JPEG2000 : memory exhausted?
On 11-02-03 03:19 PM, Jay Jennings wrote: In fact, we do have a Kakadu license here... but I see in NITFCreateCopy() that JP2ECW and JasPer are the only two JPEG-2000 options currently supported. Any idea how difficult it would be if I tried to implement JP2KAK as an additional option for NITF creation ? Jay, I recently did some work on this, likely only in trunk not GDAL 1.8, in this regard so I think you can use Kakadu now. What I haven't done is figure out what, if any, Kakadu creation options I should be using to make the result proper per the specification for NITF. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_translate making NITF-JPEG2000 : memory exhausted?
On 11-02-02 05:20 PM, Jennings Jay wrote: I have recently built GDAL including the optional JasPer library for JPEG-2000 support. Using gdal_translate, I am able to convert smaller GeoTIFFs into NITFs with JPEG-2000 this way. The first two attempts (both color uncompressed GeoTiff less than 200 MB) worked fine, with lossless compression and reduced in size by 67% and 59% respectively. The problem came when I tried the same command on a bigger (950 MB) GeoTIFF: gdal_translate apparently sucked up all available memory (as indicated by Physical Memory Free = 0 in Task Manager) then the app crashed. Are there any workarounds in such a case ? It looks like the “-multi” and “-wm” parameters aren’t available in gdal_translate. PS This is a Windows 7 64-bit machine with 8 GB RAM. Jay, This is a limitation of the JasPer based driver which is whole image in RAM at once oriented due to the way the JasPer library is structured. You could use the Kakadu or ECW based encoder though these have somewhat involved licensing issues. In theory we should be able to use the OpenJPEG jpeg2000 implementation for this but I'm not aware of it having been tested in the JPEG2000 in NITF case yet, and it may also not support setting the jpeg2000 creation options to be truely NITF compliant. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-02-01 11:04 AM, Ray Gardener wrote: Oh man. So over time, as more GPL'd drivers are written, the very purpose of GDAL gets watered down. It's not like people are going to develop MIT-licenced drivers if they see an existing GPL driver that does the job. At the very least, the motivation will be blunted. The whole reason I went with GDAL was that it was reasonable in regards to commercial devs. Now there's going to be a situation where they get increasingly treated as second-class citizens. It's unreasonable to disclose a large application just because drivers are GPL'd. It should be submission policy to GDAL that they're LGPL'd. Frank's gone to the trouble of creating an environment that is commercial agnostic, and now it's being undone. Folks, I would prefer that this RFC discussion not turn into a broad license argument. I accept the rights of software developers to offer their product under proprietary, recriprocal or non-reciprocal licenses and we as consumer need to take or leave the offered components on their own terms. GDAL is released under an MIT/X nonrecriprocal open source license because I and others believe this allows us to serve and involve the largest possible community. When we have an option between a proprietary driver or a nonreciprocal driver then we will choose the nonreciprocal driver. When we have a chose between a reciprocally licensed driver and a non-reciprocally licensed driver we will choose the nonreciprocally licensed driver. But I do not accept a that GDAL is made poorer by also having options for proprietary and reciprocal drivers for purposes that we could not otherwise serve. I don't see any evidence that GDAL is becoming more dependent on GPL or proprietary drivers as time goes on. Care has always been called for by distributors of software based on GDAL. Ray, Patrick and Howard have argued against taking on runtime responsibility for license checking in GDAL. I only very weakly grasp the argument so it might be worth expanding on it. But this RFC is not about whether there will be proprietary GDAL drivers, or reciprocally licensed drivers. There have been, are and will be. The question is in what ways does it make sense for the project to help support application developers and distributors in being license compliant. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interrupt long operation
On 11-01-31 04:26 AM, Stefano Moratto wrote: Hello, I need to interrupt a RasterIO and warp calls before they have been ended. The call is invoked in a background thread and It may happen that the user changes the requested area in the main thread (GUI) (eg. a pan/scroll operation). Stefano, Algorithms which take a GDALProgressFunc are likely to be interruptable. Each time the progress function is invoked it has the opportunity to return an indicate that the operation has been cancelled by the user. So the warper can be canceled if you provide a customized progress function. But RasterIO cannot since it has no progress function. If you want IO to be interruptible you would normally do it in modest sized chunks, though this can interfere with optimization of the IO in some cases. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-01-31 11:30 AM, Tamas Szekeres wrote: Frank, I've reviewed the document and it looks good to me, though it seems better to enforce these constraints rather at deployment time and not at run-time. However I would have some further questions: 1. With regards to GDAL_APPLICATION_LICENSE_POLICY=DEFAULT does this mean that GDAL will provide an error if a licensing violation is happening at run-time? For example when MapServer attempts to display an ECW and a MySQL layer at the same time? Tamas, Note that the intent of the RFC is that in a case of incompatible drivers and the default policy one or more drivers would be de-registered to bring things into compliance. So, for instance the MySQL driver might be de-registered and that means any effort to use MySQL would result in an error message about it being an unsupported format since no driver would recognise it. It would *not* be a license error. If this is not the case, I would prefer changing 'DEFAULT' to 'NONRECIPROCAL' and it would prevent from loading the GPL drivers during the default operation. Having GDAL_APPLICATION_LICENSE_POLICY=NONRECIPROCAL would provide better match with the licensing policy of GDAL itself which intends to be MIT/X. I can see that NONRECIPROCAL might be a better term than DEFAULT but I don't want to avoid loading reciprocal (ie. GPL) drivers in a default situation. 2. In my opinion the user shouldn't override any specific settings (like RECIPROCAL or PROPRIETARY) being enforced by the application. In this regard the user is allowed to violate the GPL like loading proprietary drivers in QGIS. I don't think if USE_ALL should be a valid environment setting either. This should only be allowed by a compilation flag which is not intended to be used for distribution purposes. I disagree strongly! The end user always has the legal and moral right to mix proprietary and free software. The purpose of the override operation is for them to knowingly make the decision that they want to do this. 3. I think the user should only be allowed to override GDAL_APPLICATION_LICENSE_POLICY=DEFAULT either by the environment settings or in the SWIG interface. 4. I don't really understand the rationale behind the PREFER_PROPRIETARY and PREFER_RECIPROCAL settings. Shouldn't we raise an error if a licence violation is detected? I think we might have to decide which kind of the licensing enforcement should be applied in GDAL, like: Version 1, The actual licensing mode is predefined within the scope of the execution (either by the applevel or environment setting) and GDAL should avoid to load any incompatible drivers. This was my intent, though because of the way we get metadata from drivers to examine their license constraints it is necessary for us to load them and then deregister them if they are in violation. Version 2, The actual licensing mode may be controlled by the drivers loaded and provide an error if an incompatible driver is about to be used. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-01-31 10:45 AM, Howard Butler wrote: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy I'm asymptotically approaching -1 on this RFC. My concern is that it misplaces the apparent responsibility for managing licensing constraints on *us*. It should always be the responsibility of users of the software to know, care, and mange the licensing of the software they're using. What happens if we mislabel a driver? Or not realize that a driver links to A, which links to B, which is GPL? It's still the user's responsibility, but we've just done them a disservice. Howard, I do not believe we are taking on any legal or moral responsibility if a driver is mislabelled. I think a best effort on our part is fine. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. Another reason I don't like this is that it puts us square in the middle of the GPL vs commercial software war which I don't think we have been so interested in fighting. I'll just note I do not see this as a war to fight. I am just trying to make it easier for software distributors to act responsibly with regard to licensing requirements of various components. IMO, we shouldn't try to protect users from having to care about this stuff, because they clearly need to understand the ground rules if they're going to choose to make a porridge of GPL and proprietary software. There's nothing preventing a user from manually registering only the drivers they need at runtime now. If they need to register only non-GPL drivers, or non-proprietary ones, they can do so. I completely agree this doesn't solve OSGeo4W's problem. You refer to user above, but I assume you are referring to application developers and software distributors. I agree that this RFC is not intended to absolve them of all awareness of the licensing of components they are distributing. I do not formally object to this RFC with a veto, and I expect that it will be implemented, but I wanted to voice my opinion that I think this is a slippery, slippery slope. You concerns have moderately sapped my interest in the RFC. As discussed in IRC it seems that the fact that the user must separately select packages like gdal-mrsid may be sufficient to protect OSGeo from license violation claims. I am going to try seeking input from the QGIS, and perhaps GRASS communities about their intent when applying the GPL license to their software. Beyond the strict legalities, I am interested in accounting for the intent of developers of GPL software. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-01-31 12:28 PM, Ray Gardener wrote: I think Mr. Butler makes a good point. Maybe just have folders in the source tree called frmts/reciprocal and frmts/proprietary and the same for any libs. That way it's in people's face all the time and impossible not to be conscious of what is licenced how. And easy to exclude such drivers, just skip building that folder's makefile. If I want total certainty, I can even delete those folders. And if someone makes a classification mistake, it'll be more obvious too (hey, driver XXX shouldn't be in that folder). Ray, That would be adequate for those who are building things from source and wanting to distribute the resulting binaries under a single consistent licensing policy. However it does not help me for the OSGeo4W need. OSGeo4W is a unified installer that can install a wide variety of OSGeo project binaries for windows into one unified tree. So, for instance if you install QGIS, MapServer and GRASS which all use GDAL they will end up using a common copy of GDAL. Users also often want proprietary format drivers for formats like MrSID and there is an optional package offered for this. In this situation MapServer and GDAL are under a non-reciprocal open source licenses and there is no problem using them with proprietary drivers. However, QGIS and GRASS are GPL and it is improper to distribute them with proprietary drivers. I am *hoping* to be able to deliver a solution that lets users have proprietary drivers easily with MapServer or GDAL commandline, while not letting them use these drivers with QGIS or GRASS unless they make a deliberate decision to do so even though it abridges the freedoms they would normally have with GPLed software. In the RFC I have also tried to offer a way for proprietary software to avoid loading GPLed drivers accidentally. But as you note most proprietary software distributors will just take care to avoid building in any GPLed dependencies at compile time. However, I do like to imagine a time in which even proprietary software distributors might be able to take advantage of common system level installations of GDAL in which case greater care about licenses might be appropriate. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-01-29 06:16 PM, Even Rouault wrote:
1) I had a strange feeling when I read that In the absence of a user or
application level policy, default to a policy of PREFER_PROPRIETARY. It
sounds a bit paradoxical for an open source library... I guess that on Linux,
it should be PREFER_RECIPROCAL and PREFER_PROPRIETARY on Windows. Just
kidding...
Even,
Indeed, I felt the same way. But I mostly think about formats like
ecw and mrsid being of high interest and I hadn't realized there were
as many reciprocally licensed drivers.
2) We don't control the licence of third party libraries and their licencing
terms can thus change over the time or have multiple licencing terms.
a) For example, currently the GDAL EPSILON driver relies on the epsilon
library which is currently GPL. But Alessandro Furieri (Spatialite/Rasterlite
author ) asked to the author of libepsilon if he would agree to relicence it
I believe we would just make a reasonable effort. In some cases
we might be able to detect from the version of the library what
policy applies.
b) For MySQL, it depends on whether you use the open source version (GPL) or
the commercial version.
Really? I had assumed that the client libraries would have been
under a non-reciprocal license even if the database server itself
was GPLed. I wonder if there is a way of determining the license
configuration at runtime or from the include files.
3) Licences of the drivers :
* In the list of reciprocal drivers, you can add PDF (because of poppler being
GPL)
* I'm not sure for the GPSBabel driver. The driver doesn't technically link to
GPSBabel (GPL) but communicate it with it through fork / exec / pipe. Does it
make the driver to be bound to the GPL ?
As long as the GPLed code is in a different process it seems clear
that the GPL license requirements do not apply. So this one should
be fine as nonreciprocal.
* As far as ODBC, PGEO, MSSQLSPATIAL (and GEOMEDIA in trunk), it depends on
the actual ODBC library... On unix, unixODBC is LGPL.
That could be hard to establish. I'm still unclear on what we will
do here.
* The OGR SOSI driver should probably be marked as proprietary currently as it
relies on linking with binary objects with unknown licencing terms, even if
apparently the ultimate goal seems to open source them.
Noted in the RFC.
* I'm not sure for the ArcSDE Raster. I imagine this should be commercial ?
agreed
* I'm a bit confused by http://gdal.org/frmt_msg.html. Seems that it relies on
third party stuff with both proprietary and GPL code.
I have listed this in the rfc.
4) A technical detail, but Python bindings automatically register the drivers
when importing gdal or ogr modules, so it would not be possible to do a
gdal.SetConfigOption('GDAL_LICENSE_POLICY', 'USE_ALL'), but
os.environ['GDAL_LICENSE_POLICY'] = 'USE_ALL' should work
Agreed, I have added a note about exposing AutoSkipDrivers() via SWIG
so an application that wants to apply a particular policy can update
the loaded drivers.
5) I was wondering if it wouldn't be nice to have a *build* option that could
be equivalent to setting GDAL_LICENSE_POLICY = USE_ALL. That would only be
usefull for power users that build their own GDAL for their own purposes and
don't intend distributing it. Obviously neither Linux distributions nor
OSGeo4W should use it, so that makes its use case scarce.
Yes, this seems like it could be useful. Presumably we would implement
this in a way that lets the software be built with any particular default
GDAL_LICENSE_POLICY if not provided by other means.I have incorporated
it in the RFC.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/OGR 1.8 Java Bindings for Windows Updated
Folks, I have updated the gdal-java package for OSGeo4W to be 1.8. I have also rewritten the building Java bindings on windows topic in the GDAL Trac to reflect how things work. I have only minimally tested the new package so feel free to let me know if there are problems. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 1.8 - Switch Thrown
On 11-01-29 09:52 AM, Ari Jolma wrote: Did anybody else try to use the now standard Visual Studio built GDAL DLL (which was much discussed some time ago here and is now available from Tamas' site) in a MinGW environment? I spent some time a week or two ago on the issue, but I had a hard time, which AFAIK is because the DLL mixes two function export methods and thus using the standard tools seems difficult if not impossible (I already downloaded the sources for latest GNU dlltool and considered hacking it...) The best page about the issue I found so far is this: http://wyw.dcweb.cn/stdcall.htm Anybody have any ideas? Is my observation about the two export methods correct and why is that? Ari, It is true that some GDAL/OGR entry points are using cdecl, and some are using stdcall. Some were converted to stdcall several years ago to facilitate calls into the DLL from VB6 and Delphi Pascal which apparently could not easily call cdecl functions. I believe these entry points can be used from gcc but you need to be sure the stdcall decorations are properly applied when the include files are processed. There is some stuff about this in cpl_port.h, and I think you can predefine CPL_STDCALL for alternate environments. I think I did note this as one item we would likely want to discard from the ABI in GDAL 2.0. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] reproject
On 11-01-29 04:55 AM, Mohammed Rashad wrote: is there any function in ogr to export the projection string to proj4. there is a function called importFromProj4 but nothing like export from proj4. i have the wkt of projection read from .prj file I need to convert it to proj4 string. Rashad, The method is OGRSpatialReference::exportToProj4(). There are corresponding C, C#, python, java, etc entry points. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Licensing Policy for drivers and applications
Folks, I have been thinking about how to adjust OSGeo4W in particular, and GDAL in general to make it easier to distribute software in a way that complies with the conflict between GPLed software and proprietary software. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. To that end, I have prepared an RFC which attempts to address this at the GDAL driver registration level. I'd appreciate feedback: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] strange output in reading points of linear ring
On 11-01-28 10:57 AM, Mohammed Rashad wrote:
OGRPolygon *polygon = (OGRPolygon *) poGeometry;
OGRLinearRing *extring = polygon-getExteriorRing();
for(int i=0;iextring-getNumPoints();i++)
{
cout extring-getX(i) :
extring-getY(i) endl;
}
...
-240802:2.80936e+06
.
..
-240802:2.80936e+06 how to get rid of e+06 and convert it to double
Rashad,
That is a c++ stream's formatting question, not a gdal-dev question. I
would suggest you review the formatting options for the stream class:
http://www.cplusplus.com/reference/iostream/ostream/
In particular pay attention to the field width and display precision
values. Also I see something about scientific vs. fixed format in the setf()
method:
http://www.cplusplus.com/reference/iostream/ios_base/setf/
Personally I hate the way formatting works with the C++ stream classes
but I'm very old fashioned.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ABI Version Specific Plugin Loading
Folks, In gdal trunk I have made changes to the way plugins are loaded for GDAL and OGR. Now each directory in the search path will first be checked for a subdirectory with the ABI version as the name (ie. /usr/local/lib/gdalplugins/1.8). If found that directory will be used instead of the original directory (ie. /usr/local/lib/gdalplugins). I see the MacOS X code already has a concept of different framework directories for different versions. I did not interfere with that though it kind of annoys me how different all this stuff works on MacOS X - even the name of the plugins directory is different - needlessly IMHO. For now I am leaving this only in trunk in subversion, though I will backport it to the OSGeo4W GDAL/OGR 1.8 package which is where I particularly want it. Let me know if there are any concerns or if it causes problems. http://trac.osgeo.org/gdal/changeset/21596 Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] to make black areas transparent
On 11-01-27 04:06 AM, ahmet temiz wrote: I want to make black areas transparent, and used: gdalwarp -overwrite -dstnodata 0 -dstalpha geobk_jeo.tif geobk_jeo2.png it didn't make them transparent. Ahmet, Try -srcnodata 0 instead of -dstnodata 0. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] projection in external file
On 11-01-26 08:33 AM, morabit wrote: Hi All, In our project we have to support the loading of tiff images that will be geo-referenced by means of external companion files containing the affine geo transformation and projection information (WKT). We have tested that GDAL supports external geo-transform using .tfw files, but we are not able to load WKT info included in companion .proj or .wkt files. Does GDAL support this kind of feature? Perhaps it supports this feature using some other format (aux.xml)? In case of positive answer, what is the right way to accomplish this? Bruno, Yes, it should be possible to embed a coordinate system in an .aux.xml file and have GDAL utilize it transparently for GeoTIFF files. I have attached an example .aux.xml file with a coordinate system and geotransform in it. Note that the coordinate system is in WKT, but with XML encoding of special characters like quotes. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent PAMDataset SRSPROJCS[quot;NAD27 / UTM zone 11Nquot;,GEOGCS[quot;NAD27quot;,DATUM[quot;North_American_Datum_1927quot;,SPHEROID[quot;Clarke 1866quot;,6378206.4,294.9786982139006,AUTHORITY[quot;EPSGquot;,quot;7008quot;]],AUTHORITY[quot;EPSGquot;,quot;6267quot;]],PRIMEM[quot;Greenwichquot;,0],UNIT[quot;degreequot;,0.0174532925199433],AUTHORITY[quot;EPSGquot;,quot;4267quot;]],PROJECTION[quot;Transverse_Mercatorquot;],PARAMETER[quot;latitude_of_originquot;,0],PARAMETER[quot;central_meridianquot;,-117],PARAMETER[quot;scale_factorquot;,0.9996],PARAMETER[quot;false_eastingquot;,50],PARAMETER[quot;false_northingquot;,0],UNIT[quot;metrequot;,1,AUTHORITY[quot;EPSGquot;,quot;9001quot;]],AUTHORITY[quot;EPSGquot;,quot;26711quot;]]/SRS GeoTransform 4.4072e+05, 6.e+01, 0.e+00, 3.75132000e+06, 0.e+00, -6.e+01/GeoTransform /PAMDataset ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with GEOTIFF
On 11-01-25 03:09 PM, Fernando Cacciola wrote: Hello, I have a geotiff image which, according to its accompaning htm, uses the WGS_1984 Datum. However, when I call GDALGetProjectionRef() it fails, returning GCS tag not found, plus ENR_L01.tif (from ENR_L01.zip) Failed to setup Geographic Coordinate System FAILED with error: 2 ... What can I do? Fernando, It might be helpful to see a listgeo report on the tiff file. Listgeo is a utility associated with libgeotiff and might already be available on your system or easily installed. I haven't been able to identify where the GCS tag not found error message is coming from. It does not seem to be part of the OGRSpatialReference, GeoTIFF driver, or libgeotiff code. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Problem with GEOTIFF
On 11-01-26 10:26 PM, Fernando Cacciola wrote: OK, I have it already so here is the information: Corner Coordinates: ... unable to transform points between pixel/line and PCS space Geotiff_Information: Version: 1 Key_Revision: 1.0 Tagged_Information: End_Of_Tags. Keyed_Information: End_Of_Keys. End_Of_Geotiff. Fernando, The above tells us there is no coordinate system in the .tif itself. I noticed that this dataset is made of 4 files: enr_p01.aux enr_p01.tfwx enr_p01.tif enr_p01.tif.aux.xml Oddly, the xml file contains this tag: WKTPROJCS[quot;Pac_chartquot;,GEOGCS[quot;GCS_WGS_1984quot;,DATUM[quot;D_WGS_1984quot;. so it seems like the data is there after all. Ah. I suspect this is a problem with having both an .aux and .aux.xml file. I suppose the .aux file is being used and the .aux.xml file is ignored. Try moving the .aux file somewhere out of the way and see if things behave more properly. If you can make the dataset available I might be able to improve the robustness of the logic for the case with a .aux and .aux.xml file. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/OGR 1.8.0 Released
On behalf of the GDAL/OGR development team and community, I am pleased to announce the release of GDAL/OGR 1.8.0. GDAL/OGR is a C++ geospatial data access library for raster and vector file formats, databases and web services. It includes bindings for several languages, and a variety of command line tools. http://www.gdal.org/ The 1.8.0 release is a major new feature release with the following highlights: * New GDAL drivers : GTX, HF2, JPEGLS, JP2OpenJPEG, JPIPKAK, KMLSUPEROVERLAY, LOS/LAS, MG4Lidar, NTv2, OZI, PDF, RASDAMAN, XYZ * New OGR drivers : AeronavFAA, ArcObjects, GPSBabel, HTF, LIBKML, MSSQLSpatial, NAS, OpenAir, PDS, PGDump, SOSI, SUA, WFS * Significantly improved OGR drivers : DXF, GML * New implemented RFCs: - RFC 7: Use VSILFILE for VSI*L Functions - RFC 24: Progressive data support in GDAL - RFC 28: OGR SQL Generalized Expressions - RFC 29: OGR Set Ignored Fields - RFC 30: Unicode Filenames - RFC 33: GTIFF - Corrected PixelIsPoint Interpretation * New utility : gdallocationinfo More complete information on the new features and fixes in the 1.8.0 release can be found at: http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Source code, documentation and the test suite can be downloaded from: http://download.osgeo.org/gdal/gdal180.zip - source as a zip http://download.osgeo.org/gdal/gdal-1.8.0.tar.gz - source as .tar.gz http://download.osgeo.org/gdal/gdalautotest-1.8.0.tar.gz - test suite http://download.osgeo.org/gdal/gdal180doc.zip - docs / web site Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] create attribute table
On 11-01-21 09:49 AM, Mohammed Rashad wrote: how to create attribute table for vector using ogr? Mohammed, New attribute fields are created on a vector layer in OGR using the CreateField() method on the layer. This is covered in the read/write tutorial (search for CreateField about 2/3 of the way down): http://www.gdal.org/ogr/ogr_apitut.html See also: http://www.gdal.org/ogr/classOGRLayer.html#00b1376a1eabb1298ef278f92f6d84be Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] segfault on importFromWkt
On 11-01-21 12:47 PM, Mohammed Rashad wrote: OGRGeometry *OLGeometry; char *geom = POINT(6 10); OLGeometry-importFromWkt(geom); } Rashad, The problem is that OLGeometry is an unitialized pointer as opposed to being a valid geometry object on which a method could be invoked. I would suggest changing this to: OGRGeometry *OLGeometry = NULL; char *geom = POINT(6 10); OGRGeometryFactory::createFromWkt( geom, NULL, OLGeometry ); Note that the documentation on OGRGeometry::importFromWkt() says: * The object must have already been instantiated as the correct derived * type of geometry object to match the text type. This method is used * by the OGRGeometryFactory class, but not normally called by application * code. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Create a shape file with polygons
On 11-01-18 11:28 AM, Jorge Martin wrote:
OGRPolygon myPoligon;
tmp = strtok (Line, :);
szName = string (tmp);
while (tmp != NULL)
{
OGRLinearRing MyRing;// = (OGRLinearRing*)
OGRGeometryFactory::createGeometry(wkbLinearRing);
tmp = strtok (NULL, ,);
if(tmp)
{
string Coords = string(tmp);
size_t pos = Coords.find( );
string CoordX = Coords.substr(0,pos);
string CoordY = Coords.substr(pos);
x = atof(CoordX.c_str());
y = atof(CoordY.c_str());
MyRing.addPoint(x,y);
}
myPoligon.addRing(MyRing);
}
Jorge,
The essence of your problem is that you are creating a new
ring for each point instead of creating one ring for the
polygon and adding all the points to that ring before adding
the ring to the polygon. A slightly altered form of the core
that works looks like:
OGRPolygon myPoligon;
OGRLinearRing MyRing;// = (OGRLinearRing*)
tmp = strtok (Line, :);
szName = string (tmp);
while (tmp != NULL)
{
OGRGeometryFactory::createGeometry(wkbLinearRing);
tmp = strtok (NULL, ,);
if(tmp)
{
string Coords = string(tmp);
size_t pos = Coords.find( );
string CoordX = Coords.substr(0,pos);
string CoordY = Coords.substr(pos);
x = atof(CoordX.c_str());
y = atof(CoordY.c_str());
MyRing.addPoint(x,y);
}
}
myPoligon.addRing(MyRing);
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp EPSG not being applied
On 11-01-18 01:45 PM, Gavin wrote: On Tue, 2011-01-18 at 10:06 -0700, Kyle Shannon wrote: .. System 2 (Fedora 10): Driver: GTiff/GeoTIFF Files: test3857.tif Size is 10749, 11713 Coordinate System is: PROJCS[unnamed, GEOGCS[, DATUM[unknown, SPHEROID[unretrievable - using WGS84,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,3857]] Origin = (367.042467534542084,-2998912.428198689594865) Gavin, This problem really does sound like some supporting data files not being found. For GeoTIFF it can also be important that the GeoTIFF csv files be findable. They are usually in /usr/local/share/epsg_csv and can be placed elsewhere as long as the GEOTIFF_CSV environment points to them. Also, in some cases GDAL will fallback to using the PROJ.4 init files for definitions, found via the PROJ_LIB environment variable if they are not in /usr/local/share/proj. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Importing and exporting shapefiles in mySQL with OGR
On 11-01-17 02:25 AM, Dr. Markus Müller wrote: Dear listers, I am trying to get shapefiles in and out of a mySQL database using OGR. I found some example commands for importing and succeeded in doing this. But getting the syntax together to get a spatial dataset out of mySQL db seems to be over my head. Can anybody supply an example command to convert from mySQL to shape? Or is it just not possible to export geodata from mySQL into shapefiles using OGR? Markus, It could be as simple as: ogr2ogr out_dir MYSQL:mydbname This would dump all spatial tables to shapefiles in a newly created directory out_dir from a MySQL database named mydbname. If you want to only extract particular tables, then just list them at the end. eg. ogr2ogr out_dir MYSQL:mydbname roads intersections For more options, such as custom queries, spatial restrictions and so forth see the ogr2ogr docs: http://www.gdal.org/ogr2ogr.html Or perhaps I'm missing the gist of your problem? Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaltransform and cs2cs don't agree ...
On 11-01-17 10:55 AM, Even Rouault wrote: I get the same results as in the cs2cs command line. I have no idea why we add +R_A when writting the PROJ.4 string of a Miller projection. SVN history points to a commit that dates back to 10 years ago : http://trac.osgeo.org/gdal/changeset/1862/trunk/ogr/ogr_srs_proj4.cpp Perhaps Frank will remember... ? In any case, you can open a Trac ticket to record the issue. Even, A bit of digging shows that +R_A tells PROJ.4 to use a spherical radius that gives a sphere with the same surface area as the original ellipsoid. I imagine I added this while trying to get the results to match PCI's GCTP based implementation though the history isn't clear on the details. Likely I should not be inserting that though I'm not clear what radius is chosen by default for spherical projections like this. Certainly there is no ambiguity if the coordinate system is actually using a sphere. I'm not going to take any action without a ticket and I'm not absolutely positive what I would do with one. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: Adopt GDAL/OGR RC2 as 1.8.0 Release
Motion: Adopt GDAL/OGR 1.8.0 RC2 as GDAL/OGR 1.8.0 Final Release Folks, There don't seem to be any serious issues with the RC2, so I'd like to adopt it as our 1.8.0 release. I'll start the voting with: +1 Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.8.0RC1 Release Candidate Prepared
On 11-01-12 11:18 PM, Greg Coats wrote: ls shows that every file and directory has the same (false) modification date and time. This makes it impossible to see when a particular source code file was actually last updated. Can the final GDAL source code be released with accurate modification dates and times? Greg Greg, We use svn checkout to get the source trip that will be packed up. It appears that svn checkout set the date on everything based on the checkout time. I have a vague recollection of trying to meet your need in the past in some fashion but that the result was fragile in some way - perhaps it depend on a particular version of svn or something. In any event, I do not consider accurate last update date dates as a valuable feature in a release source package and I am not inclined to try and produce it. I would strongly suggest you utilize svn (or svn via trac) to identify changes between different releases or recent changes. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/OGR 1.8.0RC2 Release Candidate Prepared
Folks, Some problems were discovered with the Python bindings in the RC being out of date, and the generated perl bindings being complete missing. I have prepared a new release candidate for GDAL/OGR 1.8.0. The source, testsuite and documentation can be found at: http://download.osgeo.org/gdal/gdal-1.8.0RC2.tar.gz http://download.osgeo.org/gdal/gdal180RC2.zip http://download.osgeo.org/gdal/gdal180doc.zip http://download.osgeo.org/gdal/gdalautotest-1.8.0.tar.gz I would appreciate broad testing of the release candidate and reporting problems via Trac tickets: http://trac.osgeo.org/gdal/ If things seem respectable I will introduce a motion to promote this release candidate as a final 1.8.0 release in the next day or two. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp with gauss resampling
On 11-01-12 08:53 AM, Jan Hartmann wrote: Is it possible to use gauss resampling with gdalwarp? The current resampling options (cubic, bilinear etc) work very well as long as the pixels in input and output rasters are about the same size, but not very well when downsampling to a much coarser scale. Gdaladdo has gauss resampling, but only for overviews of an existing file. I want to combine many mapsheets into one large map at a much lower resolution using gauss resampling. Would it make sense/be possible to add gauss resampling to gdalwarp itself/ Alternatively, is it possible to extract the overviews from a gdaladdo-ed file als regular rasters? Jan, No, gdalwarp does not support gaussian resampling. Yes, it might be desirable to add it though by it's nature gdalwarp isn't a great engine to severely downsample images as part of a warp. Yes, you can dump overviews to a standalone file using the dumpoverviews commandline application. I don't think it is built by default so you might need to go into gdal/apps and make it explicitly. You could also do a gdal_translate at the resolution of an overview and it should essentially just extract the overview though that might not be a completely sure thing. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Test and a question about gdal_warp and gdal_translate
On 11-01-12 04:30 PM, Antonio P wrote: Hello again : ( I dont know if my question was sent to the list ) Antonio, I believe it already went through and there were some responses. You can check the list archives after a bit to see if a message has gone through. I cannot use gdal_translate with % outsize parameters : gdal_translate -of JPEG -outsize 25% 25% DSC02699.jpg 02699.jpg does nothing (I view the use options of gdal_translate, it seems as I wrote a wrong parameter ) gdal_translate -of JPEG -outsize 25 25 DSC02699.jpg 02699.jpg works ok (I get a 25 x25 pixels image) I use gdal 7.7.0b2 provided by FWTools 2.4.7 You still haven't answered the easier question about what does nothing means in the regard. But I'm guessing you will have problems using percentage characters on the commandline on windows without some sort of escaping or quoting. % normally instructs Window's CMD.EXE to substitute in an environment variable. Any idea ? Also , I 'd like to use gdal_warp simply to rescale an image to 50% 50% ? Can anyone tell me the command line syntax ? I do not believe there is an equivelent to the percentage thing. But you can request a particular output size in pixels and lines using -ts. Just use gdalinfo to find the size of the input image in pixels and lines, and divide by two and use them with -ts. eg. gdalwarp -ts 1000 1000 in.tif out.tif (i'd like to use resampling options ...) And I miss more information, more examples or more tutorials on how to use the command line utilities. Any good link ? Thanks , Antonio There is some useful information at: http://trac.osgeo.org/gdal/wiki/UserDocs Good luck, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/OGR 1.8.0RC1 Release Candidate Prepared
Folks, I have prepared a release candidate for GDAL/OGR 1.8.0. The source, testsuite and documentation can be found at: http://download.osgeo.org/gdal/gdal-1.8.0RC1.tar.gz http://download.osgeo.org/gdal/gdal180RC1.zip http://download.osgeo.org/gdal/gdal180doc.zip http://download.osgeo.org/gdal/gdalautotest-1.8.0.tar.gz I would appreciate broad testing of the release candidate and reporting problems via Trac tickets: http://trac.osgeo.org/gdal/ If things seem respectible I will introduce a motion to promote this release candidate as a final 1.8.0 release in the next day or two. Note that as part of the 1.8.0 release candidate process I have established a GDAL/OGR 1.8 stable branch, and tagged the source used for the release candidate as 1.8.0: http://svn.osgeo.org/gdal/branches/1.8 http://svn.osgeo.org/gdal/tags/1.8.0 Any bug fixes intended for 1.8.x releases, including a possible 1.8.0RC2 need to be ported into the 1.8 stable branch starting now. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Hierarchical Data Format-EOS 2 conversion in Gdal
On 11-01-10 01:19 PM, Adam Bausch wrote: Hi All, I am attempting to process a large volume of MERIS mosaic data obtained from ENVISAT in HDF-EOS2 format, however, I continue to get a not a supported format error when I try to run it. I have installed the HDF-4 (libdf), HDF-5 (libhdf5) and NetCDF libraries and checked with our Linux/Unix administrator to try and identify the problem with no resolution. I was wondering if anyone else has had this problem or if there is a fix. Adam, Please ensure that GDAL has the hdf4 driver configured. You can do: gdalinfo --format hdf4 I was able to install the hdf4 development libraries and include files on my system, rebuild GDAL --with-hdf4 and then I could open the file and extract a data subproduct. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-07 10:07 AM, Jason Roberts wrote: put GDAL in Program Files\GDAL, and OSGeo4W in Program Files\OSGeo4W. Jason, I would note that OSGeo4W installs in C:\OSGeo4W by default, and there are no plans currently to change this. OSGeo4W will continue to use it's internal copy of GDAL. It could get messy if both installers have to be able to create the Program Files\OSGeo directory but not necessarily delete it when they are uninstalled, because there could be another OSGeo project in there. I would prefer to stick to C:\Program Files\GDAL. Along those lines, I would suggest that if GDAL plans to support side-by-side installations of GDAL itself, then we need to contemplate carefully whether to use Program Files\GDAL\GDAL-X.Y or Program Files\GDAL-X.Y. I think either one would be ok, so long as whoever writes the installer thinks out all the side-by-side installation/uninstallation scenarios. I prefer to just use the major.minor version as the subdirectory name. C:\Program Files\GDAL\1.7\ Another question, also already raised, is whether to have just two or all three version numbers in the installation directory. I think that question depends on whether you ever need to support bugfix releases installed side-by-side (e.g. 1.8.0 and 1.8.1), and also whether the bindings and other integrators will need to bind to specific bugfix releases or not. For example, if you guarantee that all 1.8.x releases will have compatible ABIs—that you will never introduce a change that will break the binary interface without increasing the minor build number—then it would be ok to just use X.Y in the directory name. But if that cannot be guaranteed, then you need to support X.Y.Z so that bindings and other integrators can locate the specific bugfix release that they are compatible with. It is an explicit guarantee that point releases do not change the C *or* C++ public ABI. It is an explicit intention that a point release can be installed over a previous release without impacting any applications using GDAL. This extends to the point that plugins should be compatible across point releases. Following up on that point: I think we’ve agreed that we do not want the user to have to set the PATH in order to have the GDAL bindings work. I do *not* agree that installing GDAL would necessarily insert it into the global PATH. It might, or might not, but I'm still very concerned about possible interference with other applications using GDAL. I'm not saying I will never agree to it, but I remain very cautious about interference in the global space. Particularly since we are likely to carry along lots of other DLLs (zlib, xerces, etc). If this installer is to be a product of the project, I would suggest you write up a proposal as an RFC and we work from that. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Improved support of OziExplorer datums
On 11-01-07 04:35 PM, Jean-Claude REPETTO wrote: Hello, Now that GDAL supports the OZF2 and OZFx3 formats, I think it is time to improve the processing of the .map files. The current implementation supports only 3 datums, while OziExplorer supports 123 datums. I have added the support for all OziExplorer datums, but before sending the patch, Even Rouault suggested me to post this message, so that anybody can send comments. I have created two files in the GDAL data directory : - gdal_ellips.csv contains the ellipsoid definitions - gdal_datum.csv contains the datum definitions Jean-Claude, I have two comments: 1) Please call the files ozi_ellips.csv and ozi_datum.csv 2) What is the origin of these files? What is their licensing? We can't just take files from other software packages and release them as part of GDAL unless they are under a compatible license, or the copyright holder gives us explicit permission to release them under the GDAL license. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem using gdalwarp to reproject Lambert Conformal Conic (LCC) to longlat
On 11-01-07 04:18 PM, James Hiebert wrote: All, Below is a question/probelm from one of my co-workers (who doesn't (yet) want to subscribe to the list). ~James Hiebert From: Hailey Eckstrandhail...@uvic.ca Date: Fri, 7 Jan 2011 13:05:10 -0800 Hello all, I am trying to reproject a geotif using gdalwarp: gdalwarp -t_srs +proj=longlat -s_srs +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637 -r bilinear -srcnodata 1e20 -dstnodata 1e20 -tr 0.5 0.5 -te -137.812943839532 33.8985446218588 -102.312943839532 63.3985446218588 mm5i-lcc.tif mm5i-latlong.tif ERROR 1: Translating source or target SRS failed: +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637 When I use the proj/invproj unix command, it works fine: invproj +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637 EOF James, I would suggest you collegue be more explicit about the earth models. PROJ.4 definitions passed to GDAL utility are parsed by GDAL, converted to WKT, and then later converted back to PROJ.4 format and so not all definitions supported by PROJ.4 are necessarily supported by GDAL. In this case I suspect GDAL is confused by the lack of a +b value for the lcc projection. It may also not handle a missing earth model on the geographic coordinate system well. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-06 04:42 PM, Christopher Barker wrote: On 1/6/11 12:31 PM, Jason Roberts wrote: Here are some comments on specific parts of your mail: Program Files\GDAL\1.6\gdal.dll and Program Files\GDAL\1.6\gdal.dll Those would be reasonable locations for GDAL to live if the GDAL team decided to distribute the GDAL binaries using an installer that adhered to the best practices on Windows. I *think* we're heading for a consensus to do that, but not many people have been on this thread. Jason / Christopher, I have no objection to using \Program Files\GDAL\major.minor\ as a standard location for GDAL stuff on windows. If this is done, the GDAL data search location should be compiled in for this location on windows, much as it defaults to /usr/share/gdal (or /usr/local/share/gdal) on linux. Note that this means point releases cannot coexist on a system. I think that is mostly a good thing, in that upgrading to a new point release should not change the ABI and should be a transparent change for any applications. That is also why we do not encode the point release values in the DLL name. That is the GDAL17.DLL from GDAL 1.7.3 should be a drop in replacement for the GDAL17.DLL from GDAL 1.7.2. If the DLL name was more specific then applications would be forced to relink to use the new version. On the other hand, we do want major relases (1.7.x vs. 1.8.x) to coexist and it is decision that applications need to make which they want to use. So the proposed structure handles that well. I'm going to stay out of the Python specific aspects. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-06 05:10 PM, Jason Roberts wrote: Frank, Thanks for sharing your opinion. I do have one question that I hope you will weigh in on. Which of the following two options seems better to you: 1. The GDAL libraries (possibly accompanied with executable programs) are installed as a separately from the GDAL Python bindings. The libraries are installed to \Program Files as you describe and the Python bindings are installed in the standard Python location. A Windows Python programmer wanting to use GDAL would perform two installs: one for the GDAL libraries, the other for the bindings. 2. The GDAL Python bindings include a private copy of the GDAL libraries (with no executable programs). These are installed to a private subdirectory with the bindings. A Windows Python programmer wanting to use GDAL only needs to perform one install: the bindings. #1 is essentially how things are done now, just not following Windows best practices (not using \Program files) and without any automation to ease the process (no regularly maintained installer for the Python bindings). I was proposing #2, basically under the argument that a Windows Python programmer who needs to use GDAL will rarely ever need to use GDAL for some other purpose, and therefore not want to install and think about a separate installation of the GDAL libraries themselves. But if you don't believe that, or think it is important that the libraries remain distinct from the bindings in this scenario for some other reason, then we would appreciate your opinion. Jason, I don't have a strong position on this, but I would note that beyond real Python programmers wanting to use the bindings, they are also needed just to run the python commandline utilities (such as rgb2pct.py). So there is definately a large body of folks who would benefit from having working python for the python utilities, and the regular commandline executables. Another benefit of even Python using GDAL from a standard location is things like format plugins could be easily handled in one place. Actually, the more I think about it, the more I prefer even the Python bindings to use the GDAL under \Program Files\GDAL. If the Pythonistas really want to have their own copy of GDAL then we really don't need to have this conversation. They can do their own thing, in their own place and there is no need for meaningful cooperation with the core project. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
On 11-01-06 06:43 PM, Jason Roberts wrote: Frank, Thanks for your thoughts. Based on them, I'd recommend the following two things be created. 1. GDAL windows installation program, or at minimum, a wiki page that says how to install the GDAL libraries and utilities (executables and Python scripts) to \Program Files\GDAL\... Perhaps a quick compromise would be for Tamas's build system to produce a .zip that would have everything in a suitable directory structure and for wiki page to instruct the user just unzip this to \Program Files\GDAL\ ... What do you think? Jason, I'm supportive, but not necessarily willing to take it as action item for myself. I would suggest building it as an installer .exe, perhaps using NSIS as I did for FWTools, or perhaps the method mentioned by Jurgen produces a nice installer. One question not discussed is whether GDAL should be minimalist or maximalist. That is, do we want to include as many formats as possible despite the fact that it drags in lots of supporting libraries? If we just use whatever decision OSGeo4W uses then we will have a fairly maximalist solution which is ok I suppose but might make integration of the resulting GDAL in other complex applications messy. I would like to suggest production of such an installer be done in such a way that the generating scripts live in SVN somewhere, and with instructions for the process in the wiki so it isn't all tied to one person (as FWTools was). Man, I'm really tempted to leap into this myself but I have so many other outstanding items right now. I am willing to assist in an effort by a small (2-3 people?) team. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
