Re: [gdal-dev] create classified PNG from ASCIIGrid
Stephen, You can script the import, classification, and display with python in GRASS in a couple of ways. I generally just run python from the GRASS command window to echo the GRASS commands and variables I need, but there are other ways of doing it. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Stephen Crawford Sent by: gdal-dev-boun...@lists.osgeo.org 07/26/2011 08:50 PM To gdal-dev@lists.osgeo.org cc Subject [gdal-dev] create classified PNG from ASCIIGrid Hi All, I have 60 or so asciiGrids of climate data that I would like to tun into PNGs, with the climate values classified by color. I would like to script this process using Python. Is there a way to do this with GDAL? Or if not, is there any other open source way to do this? Thanks, Steve ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] libjpeg-turbo for gdal?
Hi Folks, I had seen libjpeg-turbo , http://www.libjpeg-turbo.org/Main/HomePage, in the announcement for Fedora 14 bu had forgotten about it until Franks' FOSS4G talk last week. Has anyone tried using it in GDAL? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libjpeg-turbo for gdal?
Thanks! Sorry for the noise. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -gdal-dev-boun...@lists.osgeo.org wrote: - To: doug_newc...@fws.gov From: Mateusz Loskot Sent by: gdal-dev-boun...@lists.osgeo.org Date: 09/21/2011 06:08PM cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] libjpeg-turbo for gdal? On 21/09/11 21:46, doug_newc...@fws.gov wrote: >I had seen libjpeg-turbo , > Has anyone tried using it in GDAL? http://www.gdal.org/frmt_jpeg.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] re-gridding to a coarser grid
For what it's worth, What do you consider large and what kind of method for downscaling you wish to use? I do this in GRASS using the r.neighbors command, http://grass.fbk.eu/grass64/manuals/html64_user/r.neighbors.html. I've done an averaging method to convert a 20 ft elevation grid ( statewide coverage) of approximately 7 billion cells to an averaged 60 ft grid ( 777 million cells) by performing a 3x3 neighbor hood analysis on the 20 ft grid, setting the GRASS workspace resolution to 60 ft and multiplying the 20ft grid created by the 3x3 neighborhood analysis by 1 to create a new grid ( http://grass.fbk.eu/grass64/manuals/html64_user/r.mapcalculator.html) . GRASS will take the value of the center averaged 20 ft cell in the 60ft block as the value of the cell in the new 60 ft raster. options for r.neigbors calculations are : average,median,mode,minimum,maximum,range,stddev,sum,variance,diversity,interspersion Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Tim Keitt Sent by: gdal-dev-boun...@lists.osgeo.org 12/15/2011 01:17 PM To "Andreas H." cc gdal-dev@lists.osgeo.org Subject Re: [gdal-dev] re-gridding to a coarser grid If you need complete control, and your data are not too massive in number, I have had good results pushing pixel coordinates as points into postgis and then using spatial queries to aggregate in various ways (eg averages a hexagonal grid). It seems round-about, but it works. I've actually done it on some pretty massive grids. THK On Wed, Dec 14, 2011 at 7:26 AM, Andreas H. wrote: > Travis, > > thanks for your answer! > > Regarding the resampling methods: Do they all just interpolate the data? I > mean, when downsampling, usually I would use mean() or something similar > to fill the new (coarser) grid cells. Doas gdalwarp actually do this and > I'm not able to understand the documentation, or is it different? > > Thanks again! > Andreas. > > >> Andreas, >> >> gdalwarp can be used to resample images using the -tr flag or -ts flag. >> >> For example resample 1m image to 10m using cubic resampling and >> "target resolution' >> >> gdalwarp -r cubic -tr 10 10 input_1m.tif output_10m.tif >> >> You may have an issue determining the output resolution as I believe >> the resolution will be in decimal degrees rather than arc-seconds. >> >> Regards >> >> On 13 December 2011 14:52, Andreas H. wrote: >>> Hi, >>> >>> let's say I have a GeoTIFF file with a global grid in a 30 arc-second >>> resolution. Which would be the appropriate GDAL command to spatially >>> down-sample this file to say 0.125°? >>> >>> Thanks for your insight, >>> Andreas. >>> ___ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Timothy H. Keitt http://www.keittlab.org/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PDF selective layer sample wanted
>Hi, >I did mean that with "contains vector graphics" and "zoom in and enjoy". >-Jukka- Does that also mean extract vector layers from a geopdf and save out as shapefile ? For those of us trying to translate government-distributed data into something useable Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: PDF selective layer sample wanted
Looks good! Thanks for the link! Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Jukka Rahkonen Sent by: gdal-dev-boun...@lists.osgeo.org 03/05/2012 04:45 PM To gdal-dev@lists.osgeo.org cc Subject [gdal-dev] Re: PDF selective layer sample wanted Even Rouault mines-paris.org> writes: > > There's no support for generating PDF layers in the GDAL or MapServer drivers. > Could be perhaps be done in GDAL, but it is not obvious which GDAL concept > would map to a PDF layer. As far as MapServer Cairo/PDF driver is concerned, > this is not technically feasable (without rewriting a new MapServer backend) : > the PDF code is generated by Cairo and, AFAIK, Cairo PDF backend doesn't > support layers. I know only one open source GIS software which creates PDF files with layers. It is SkyJUMP by Larry Becker and I have added a sample to Geoserver feature suggestion some time ago http://jira.codehaus.org/browse/GEOS-3640 The jira issue has has a sample image as an attachment http://jira.codehaus.org/secure/attachment/45741/SkyJUMP.pdf and a comment that layers are selectable with Acrobat Reader but not with all readers. I know that SkyJUMP is makind PDF with iText and layers are raster layers. The image is fine and worth having a look. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] shifting (or snapping) one raster to another
Derek, You can do this in GRASS ( using gdal in the background) by doing the following: 1) create a workspace in the same projection as your existing raster ( when you first start GRASS it will ask you to set up a workspace with projection information) 2) import the existing raster layer into GRASS, ( r.in.gdal,http://grass.fbk.eu/grass64/manuals/html64_user/r.in.gdal.html) 3)set the region to match the imported raster layer in extent and resolution (g.region, http://grass.fbk.eu/grass64/manuals/html64_user/g.region.html) 4) import the county vector layer (v.in.ogr, http://grass.fbk.eu/grass64/manuals/html64_user/v.in.ogr.html ) 5) convert the vector layer to a raster layer(v.to.rast, http://grass.fbk.eu/grass64/manuals/html64_user/v.to.rast.html) When you create the new raster it will use the existing alignment and resolution of the region ( based off of the existing raster) in the placement of the cells. Even though I reference the tabular commands in the above process, it can be easily done through both GRASS gui's Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Derek Morgan Sent by: gdal-dev-boun...@lists.osgeo.org 03/22/2012 10:12 PM To gdal-dev@lists.osgeo.org cc Subject [gdal-dev] shifting (or snapping) one raster to another Hello, I am in a jam with ArcGIS, and am hoping there is a easier way to do this with GDAL. Here is the situation: I am converting a vector dataset of county polygons to raster at a pixel resolution of 231 m. However, I want this to line up with a different raster dataset I have at a much larger extent, but also the same resolution 231 m. As you probably guessed the two datasets are slightly askew as they have different extents. I would like to align the newly created county raster with the larger raster data set by shifting (or snapping) it to the closest pixels. Hopefully, this makes enough sense for someone to let me know if this can be done in GDAL. Thanks ahead of time, Derek ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] problem with CloseRings
Oliver, Would it just be a matter of counting the vertices of each polygon, selecting the polygons with 3 vertices, and comparing the value of the first and last vertex as you are building wkt value string below? Doug >The problem with your rings isn't that they are not closed, it is that >they are degenerate. >For instance: >(559560.19 142169.94,559550.64 142173.43,559560.19 142169.94) >This goes from PointA to PointB back to PointA. It is closed, it just >is degenerate. It has no area. I'm not aware of a super easy way of >cleaning out such junk rings - you might need to explicitly test them >and remove them if they are degenerate. >Best regards, Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Frank Warmerdam Sent by: gdal-dev-boun...@lists.osgeo.org 08/22/2012 12:49 PM To Oliver Christen cc gdal-dev@lists.osgeo.org Subject Re: [gdal-dev] problem with CloseRings Oliver, The problem with your rings isn't that they are not closed, it is that they are degenerate. For instance: (559560.19 142169.94,559550.64 142173.43,559560.19 142169.94) This goes from PointA to PointB back to PointA. It is closed, it just is degenerate. It has no area. I'm not aware of a super easy way of cleaning out such junk rings - you might need to explicitly test them and remove them if they are degenerate. Best regards, On Wed, Aug 22, 2012 at 9:13 AM, Oliver Christen wrote: > dear community > > first of all please accept my apologies if this is not the correct > place to ask about such question. > > I am trying to manipulate some geometric data using the gdal/ogr > python lib and Im facing a problem when trying to transform invalid > ring into valid ring. > > I have polygons with unclosed holes and I expected the CloseRings > function to solve this for me, but unfortunately, that functions > doesnt seem to do anything (in my case). > > see below for a simply python testcase, > > if you could tell me if I am possibly not using that function > correctly or if there is a more correct way to do that, you would be > very welcome > > using python version 2.6.6 > osgeo ogr lib version 1.3.40 > > thank you very much for your attention > best regards > Oliver > > from osgeo import ogr > > wkt = "POLYGON ((559577.81 142165.04,559577.67 142161.79,559577.66 > 142161.16,559577.18 142139.0,559564.07 142140.84,559562.99 > 142132.4,559556.42 142134.85,559556.47 142134.96,559541.39 > 142140.58,559549.54 142162.4,559547.0200406529475 > 142163.310114102292573,559550.57042342808 > 142173.455536680703517,559577.81 142165.04),(559559.95600777247455 > 142169.280249390256358,559550.996165407239459 > 142172.552877245907439,559550.996165407355875 > 142172.552877245907439,559547.909677243907936 > 142163.733065433305455,559550.443360350676812 > 142162.817994827404618,559542.290859716595151 > 142140.991299878398422,559557.417905980604701 > 142135.353766721702414,559557.367843619547784 > 142135.243629527511075,559562.407678314950317 > 142133.364239115995588,559563.465598454349674 > 142141.631689094298054,559576.497222575126216 > 142139.80268921770039,559576.960120304953307 > 142161.173134415294044,559576.970239149406552 > 142161.810621617711149,559577.084823867655359 > 142164.470624003995908,559577.084823867655359 > 142164.470624004025012,559570.876975534367375 > 142165.896950183814624,559564.754505693446845 > 142167.653979024267755,559564.75450569356326 > 142167.653979024296859,559559.956007772590965 > 142169.280249390256358,559559.95600777247455 > 142169.280249390256358),(559560.19 142169.94,559550.64 > 142173.43,559560.19 142169.94),(559564.97 142168.32,559560.19 > 142169.94,559564.97 142168.32),(559577.81000172295 > 142165.04,559571.34395208011847 142166.499739240010967,559564.97 > 142168.32,559577.81000172295 142165.04))" > > poly = ogr.CreateGeometryFromWkt(wkt) > > poly.IsValid() > ERROR 1: IllegalArgumentException: Invalid number of points in > LinearRing found 3 - must be 0 or >= 4 > False > > poly.CloseRings() > > poly.IsValid() > ERROR 1: IllegalArgumentException: Invalid number of points in > LinearRing found 3 - must be 0 or >= 4 > False > ___ > 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 Software Developer ___ gdal-dev mailing list gd
[gdal-dev] Shapefile reprojection - copy and update metadata file
Hi Folks, Before I try to clumsily reinvent the wheel, I'd like to know if someone has a method to : 1) use ogr2ogr to reproject a shape file ( easy enough ). 2) after the above projection copy the .xml file (if it exists) from the old shapefile to the new shapefile (easy as well). 3) Update the copied .xml file to reflect the new projection information, and possibly the action of projecting (the fun part :-)) . Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 [EMAIL PROTECTED] - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr in fwtools 2.3 on windows gml to shp issue
There seems to be an issue with the python scripts in fwtools 2.3.0 and 2.3.1 Example: C:\Program Files\FWTools2.3.1>gdal_polygonize Traceback (most recent call last): File "C:\PROGRA~1\FWTOOL~1.1\bin\gdal_polygonize.py", line 34, in import gdal, ogr, osr File "C:\PROGRA~1\FWTOOL~1.1\pymod\gdal.py", line 191, in import _gdal ImportError: No module named _gdal C:\Program Files\FWTools2.3.1> Not complaining, just grateful the toolset is there for Windows. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Even Rouault To Sent by: "Rushforth, Peter" gdal-dev-bounces@ lists.osgeo.orgcc gdal-dev@lists.osgeo.org Subject 04/29/2009 01:48 Re: [gdal-dev] ogr2ogr in fwtools PM2.3 on windows gml to shp issue Hi, As far as the message "ERROR 1: Too much data inside one element. File probably corrupted" is concerned, I think that FWTools-2.3.0 showed a temporary regression where the maximum size for a geometry was limited to 100,000 bytes to avoid reading corrupted/hostile files. This limit was proved to be too low and raised to 10,000,000 bytes a bit later (see http://trac.osgeo.org/gdal/ticket/2818) and I believe that this fix went into FWTools-2.3.1. Unfortunately the FWTools home page isn't well updated and it only shows 2.3.0 as the latest version. But you can find here FWTools 2.3.1 : http://home.gdal.org/fwtools/FWTools231.exe I was able to rename an attribute in a generated .gfs file and ogrinfo successfully returned the modified attribute name. So you'll have to provide more details, ideally a small GML file and the modified .gfs demonstrating a problem. Best regards, Even Le Wednesday 29 April 2009 17:16:11, vous avez écrit : > Hi, > > Using fwtools 2.3 on windows, I run the ogr2ogr command on a gml file to > create a shp file. > > I get the following error message: > > C:\Program Files\FWTools2.3.0\>ogr2ogr -f "ESRI Shapefile" peter.shp > test.gml ERROR 1: Too much data inside one element. File probably corrupted > > When I cut down the number of coordinates in the gml:Polygon (to an extreme > minimum), the shp file is created. But I can't do that in real life. > > Also, I want to supply a gfs file to control attribute name mapping. But > it seems to be ignored. > > Thanks > > Peter Rushforth > Technology Advisor / Conseiller technique > GeoConnections / GéoConnexions > 650-615 Booth St. / rue Booth > Ottawa ON K1A 0E9 > E-mail / Courriel: peter.rushfo...@nrcan-rncan.gc.ca > Phone / Télephone: (613) 943-0784 > Fax / telecopier: (613) 947-2410 > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Make install problem on Centos 5.3 64-bit with gdal1.6.1
Hi, I'm trying to compile gdal 1.6.1 on a Centos 5.3 x86_64 computer. The make portion works fine, but the make install bombs with : /usr/bin/ld: skipping incompatible /usr/lib/libcom_err.so when searching for -lcom_err /usr/bin/ld: skipping incompatible /usr/lib/libcom_err.a when searching for -lcom_err /usr/bin/ld: skipping incompatible /usr/lib/libcom_err.so when searching for -lcom_err /usr/bin/ld: skipping incompatible /usr/lib/libcom_err.a when searching for -lcom_err /usr/bin/ld: cannot find -lcom_err collect2: ld returned 1 exit status I have compat-libcom_err.x86_64 installed, but I don't see a libcom_err-devel rpm available. Options? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Make install problem on Centos 5.3 64-bit with gdal1.6.1
Even, Thanks! That did the trick! Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Even Rouault To gdal-dev@lists.osgeo.org 06/30/2009 04:00 cc PMdoug_newc...@fws.gov Subject Re: [gdal-dev] Make install problem on Centos 5.3 64-bit with gdal1.6.1 A quick Google search gives http://www.saiweb.co.uk/tag/libcom_err that seems to be exactly your issue Le Tuesday 30 June 2009 20:41:25 doug_newc...@fws.gov, vous avez écrit : > libcom_err <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shortening execution time of Python script
David, zip format files for 32bit WindowsXP maxes out at 4GB. You can create larger zip files on Vista. I'm wildly guessing that you are running into the 4GB limit as well on reading your zip files with . 7zip, http://www.7-zip.org/, might be able to handle zip format files larger than 4GB. If that doesn't work, see if you can switch to gzip format. Gzip works just fine with files larger than 4 GB on 32 bit Windows systems. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Roger André To Sent by: David Shi gdal-dev-bounces@ cc lists.osgeo.org gdal-dev@lists.osgeo.org Subject Re: [gdal-dev] Shortening execution 09/19/2009 01:16 time of Python script AM So the problem is that ArcGIS Server is expecting the data to be ready (unzipped), but due to the large size of the data set, the unzip has not finished? Roger -- On Wed, Sep 9, 2009 at 3:54 AM, David Shi wrote: I have a Python script that automatically downloads zip files containing large datasets from another server and then unzips the files to further process the data. It has been used as a geoprocessor of ArcGIS Server. The script works fine when two datasets each has several kilobytes size, but the script stops half way when datasets were about 11,000KBytes. I think that the execution time is too long and ArcGIS Server just simply killed the process. What actions can I try to reduce the execution time? ArcGIS Server only works on the basis of 32 bits and I was told that the maximum memory it can utilise is 4 MBytes. I should be grateful if someone can make suggestions/recommendations. Sincerely, David ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev<><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fastest vector format for combining shapefiles
I'm confused, I thought spatialite support was being added to ogr in 1.7 . http://www.gdal.org/ogr/drv_sqlite.html As to ESRI, I asked at the last DOI meeting prior to the ESRI conference this year about spatialite support and they said they had no plans to support it. Of course, they used to say the same thing about postgresql/postgis and if spatialite is implimented in ogr it will probably be included down the road. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Chris Barker To Sent by: "gdal-dev@lists.osgeo.org" gdal-dev-bounces@ lists.osgeo.orgcc Subject 10/18/2009 11:42 Re: [gdal-dev] Fastest vector PMformat for combining shapefiles Simon Greener wrote: > What else is there to do for its adoption as the new shapefile for the > open source community? I heard someone say once that a specification isn't a standard unless there is more than one implementation (preferably more). Is there any other way to read or write a spatialite file than sqlite itself? It's also not a standard without a specification -- is there one (other than the source code, which, of course is the only truly accurate specification). Also -- do ESRI tools read or write it? Like it or not, they are the elephant in the room. My ESRI-using colleagues want to distribute data in the ESRI geodatabase format -- I don't like that, as I don't use ESRI tools, but I can't suggest an alternative that won't work for them. Sigh. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] tab delimited to shapefile
Bruce, If you're on a linux system with perl: perl -pi -e 's/\t/,/g' filename is a perl one-liner that should replace all of the tabs with commas in the file, working on the file in place. I've used similar commands on text files up to 379 GB in size, although it does take a while for files that size. It does alter the file in place, which can be dangerous. It's best to test on a sample of the file : head filename> testfile ( take the first 10 lines of the file and write it to a separate file) perl -pi -e 's/\t/,/' testfile If the testfile works fine, use it on the main file. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. "Clay, Bruce" Sent by: To gdal-dev-bounces@ lists.osgeo.orgcc Subject 11/18/2009 11:09 [gdal-dev] tab delimited to AMshapefile Is there any way to use ogr2ogr to convert tab-delimited data such as the geoname dot org files into shapefiles short of converting all tabs to commas? I created a VRT file that works with CSV files but I can not find any way to convert tab-delimited data. Bruce This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: CUDA PyCUDA and GDAL
>> Shaun Kolomeitz wrote: >> > could push beyond 1GB/s. Currently to process (mosaic) an 80GB image it >> > takes several days to complete. This is also on 32bit hardware, and I >> >> Shaun, > >> I suspect that there is a gross issue with how the warping is being done, >> and that it could be sped up substantially. On my two year old consumer >> grade desktop I'm able to warp/reproject around 30GB/hour with gdalwarp. >My numbers for warping single images or small mosaics with cubic spline option >show about 12 GB/hour. However, I have tried sometimes to warp tens of gigabytes >of imagery through .vrt file to a BigTIFF and that process progressed very very >slow. I need to admit that I used ER Mapper and ERDAS Imagine and never bothered >to investigate further what was going wrong when building mosaic with gdal. I >have lot of imagery easily available and I volunteer for testing is somebody has >suggestions for better gdalwarp parameters or has new program versions to try. >-Jukka Rahkonen- Hi Folks, Here's the gdal command (gdal 1.6.2) I used to merge ~3500 1 meter NAIP quarter quads (uncompressed geotiff TIFF) in 3 UTM projections into one Bigtiff Image in the USGS Albers projection. It took about 15 hours ( on a 3 year old Intel Core2 Duo 64 bit Centos 5.3 Linux box with 6GB RAM) and created an uncompressed, tiled, bigtiff file of 485 GB. About 32 GB/hr. gdalwarp -t_srs "+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23.0 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m no_defs <>" -wo "SKIP_NOSOURCE" --config "GDAL_CACHEMAX=500" -wm=5000 -co "TILED=YES" */*.tif /biggis/albers/nc_naip2008.tif In the above command, -t_srs "+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23.0 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m no_defs <>" indicates the target projection, -wo "SKIP_NOSOURCE" don't write in areas for which there is no data for the current file, --config "GDAL_CACHEMAX=500" set the cache memory at 500MB ( set this close to the maximum input file size), -wm=5000 set the warp memory to 5000MB , -co "TILED=YES" create a tiled tiff as output, */*.tif, use all of the tiffs in all of the subdirectories as input files ( in this case there was one directory for each of the 3 utm zones) , /biggis/albers/nc_naip2008.tif, the output file name and location. Hmm, I may have to do this again, I didn't include the -rcs option. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Jukka Rahkonen To Sent by: gdal-dev@lists.osgeo.org gdal-dev-bounces@ cc lists.osgeo.org Subject [gdal-dev] Re: CUDA PyCUDA and GDAL 11/19/2009 03:08 AM Frank Warmerdam pobox.com> writes: ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: CUDA PyCUDA and GDAL
>Hi Doug, >I finally tried your parameters and they did work fine for me also. I >had something like hundred geotiffs, 400 MB each, and I was pushing >them to bigtiff mosaic. I tried first with your *.tif selection and then >again by using a virtual raster file as source, created from Mapserver >tileindex shapefile with gdalbuildvrt. My Windows computer was handling >about 20 GB/hour with cubic resampling (-rc) this time. Parameters ?-wo "SKIP_NOSOURCE" --config "GDAL_CACHEMAX=500" -wm=5000 >seem to have a big influence on efficiency. I wonder if there are some >rules of thumb for selecting values of GDAL_CACHEMAX and -wm. You said >cachemax is good to be close to the maximum input file size, how about >-wm? >-Jukka Rahkonen- Jukka, I remember seeing someone mention on the mailing list ( Can't recall who at the moment) that setting GDAL_CACHEMAX close to the maximum size of the input files gave the best performance. I did try bumping GDAL_CACHEMAX up to 2000 to see what would happen ( while dropping -wm down to 3000, only 6GB of RAM on that computer) , but none of the input files I was processing were larger than 500MB and I saw no increase in performance. For the -wm parameter, I just gave it the rest of the RAM available on the computer, and I did not benchmark while varying that number. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. "Rahkonen Jukka" To , 12/07/2009 05:06 AM cc Subject Re: CUDA PyCUDA and GDAL > fws.gov> writes: > > Hi Folks,Here's the gdal command (gdal 1.6.2) I used to merge ~3500 1 meter NAIP > quarter quads (uncompressed geotiff TIFF) in 3 UTM projections into one Bigtiff Image > in the USGS Albers projection. It took about 15 hours ( on a 3 year old Intel Core2 > Duo 64 bit Centos 5.3 Linux box with 6GB RAM) and created an uncompressed, tiled, > bigtiff file of 485 GB. About 32 GB/hr. > gdalwarp -t_srs "+proj=aea +lat_1=29.5+lat_2=45.5 +lat_0=23.0 +lon_0=-96 > +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m no_defs <>" > -wo "SKIP_NOSOURCE" --config "GDAL_CACHEMAX=500" -wm=5000 > -co "TILED=YES" */*.tif /biggis/albers/nc_naip2008.tif > > In the above command, -t_srs "+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23.0 > +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m no_defs <>" > indicates the target projection, -wo "SKIP_NOSOURCE" don't write > in areas for which there is no data for the current file, > --config "GDAL_CACHEMAX=500" set the cache memory at 500MB ( set this close > to the maximum input file size), -wm=5000 set the warp memory to 5000MB , > -co "TILED=YES" create a tiled tiff as output, */*.tif, use all of the tiffs > in all of the subdirectories as input files ( in this case there was one > directory for each of the 3 utm zones) , /biggis/albers/nc_naip2008.tif, > the output file name and location. > Hi Doug, I finally tried your parameters and they did work fine for me also. I had something like hundred geotiffs, 400 MB each, and I was pushing them to bigtiff mosaic. I tried first with your *.tif selection and then again by using a virtual raster file as source, created from Mapserver tileindex shapefile with gdalbuildvrt. My Windows computer was handling about 20 GB/hour with cubic resampling (-rc) this time. Parameters -wo "SKIP_NOSOURCE" --config "GDAL_CACHEMAX=500" -wm=5000 seem to have a big influence on efficiency. I wonder if there are some rules of thumb for selecting values of GDAL_CACHEMAX and -wm. You said cachemax is good to be close to the maximum input file size, how about -wm? -Jukka Rahkonen- <><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/l
Re: [gdal-dev] Re: CUDA PyCUDA and GDAL
>Folks, >I would note that large -wm values can be very counter productive when >used in combination with SKIP_NOSOURCE. The problem is that the larger >the chunk size, you run into the chance that a large window will intersect >a small amount of data and the whole window ends up being processed - most >of it without any real work to do. >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 Frank, As always, thanks for the insight. Doug __ Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp use of Michigan Oblique Mercator
Carolyn, I may be running into something similar. Try setting the origin projection of the source tiff using the -s_srs parameter and see what result you get. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Carolyn Gacke Sent by: To gdal-dev-bounces@ gdal-dev@lists.osgeo.org lists.osgeo.orgcc Subject 01/04/2010 09:24 [gdal-dev] gdalwarp use of Michigan AMOblique Mercator Hello- Is anyone aware of the use of gdalwarp on GeoTIFF files; projecting from Michigan Oblique Mercator (epsg 3078) to WGS84 (epsg 4326)? ls EXAMPLE: gdalwarp -t_srs EPSG:4326 085_r3c25.tif 085_r3c25warp.tif We end up NE of Alaska, where as the original tifs overlay just fine in Michigan when using ArcMap 9.3.1 These are tifs of high resolution orhto flown in 2006 over Lake County MI; the MI projection info appears correct in the tags. We have quite a bit of high res ortho datasets; at times we have to modify tfws/tags, however this one has us stumped(!) Here is the gdalinfo of the original GTIFF; it also interprets the xys to lat/longs in Alaska: TIF: gdalinfo 085_r3c25.tif Driver: GTiff/GeoTIFF Size is 1619, 1708 Coordinate System is: PROJCS[" Projection Name = Oblique Mercator (Hotine) Units = meters GeoTIFF Units = meters", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010042, AUTHORITY["EPSG","7019"]], AUTHORITY["EPSG","6269"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4269"]], PROJECTION["Hotine_Oblique_Mercator"], PARAMETER["latitude_of_center",45.3091667], PARAMETER["longitude_of_center",-86], PARAMETER["azimuth",337.25556], PARAMETER["rectified_grid_angle",90], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",2546731.496], PARAMETER["false_northing",-4354009.816], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (519086.028692,400863.870183) Pixel Size = (0.6096,-0.6096) Metadata: AREA_OR_POINT=Area Corner Coordinates: Upper Left ( 519086.029, 400863.870) (173d36'53.89"W, 73d28'19.77"N) Lower Left ( 519086.029, 399822.673) (173d34'57.28"W, 73d28'14.49"N) Upper Right ( 520072.971, 400863.870) (173d36'36.33"W, 73d28'51.24"N) Lower Right ( 520072.971, 399822.673) (173d34'39.66"W, 73d28'45.96"N) Center ( 519579.500, 400343.272) (173d35'46.79"W, 73d28'32.87"N) Band 1 Block=1619x5 Type=Byte, ColorInterp=Gray TFW: cga...@edclxs84> more 085_r3c25.tfw 0.609630 0.0 0.0 -0.609630 519086.33349170600 400863.56538265612 Any advice or suggestions would be greatly appreciated! Carolyn Gacke SGT Inc. Contractor to the USGS EROS Sioux Falls SD Email: cga...@usgs.gov___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev<><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Open source vector geoprocessing libraries?
Jason, If you're working with vector data, why not throw the data into Postgresql/Postgis, http://postgis.refractions.net, and use the spatial operators there to select/buffer/intersect the vector geometries as you describe. http://postgis.refractions.net/documentation/manual-1.4 /ch07.html for geoprocessing operations. Your application can pass SQL commands to the database. You can use ogr to load data /export your finished product to/from postgresql/postgis . You might be able to similar things in spatialite, http://www.gaia-gis.it/spatialite/spatialite-tutorial-2.3.1.html#t4. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. "Jason Roberts" To Sent by: "'gdal-dev'" gdal-dev-bounces@ lists.osgeo.orgcc Subject 01/11/2010 05:32 [gdal-dev] Open source vector PMgeoprocessing libraries? Dear geospatial software experts, By integrating with GEOS, OGR can perform various spatial operations on individual geometries, such as buffer, intersection, union, and so on. Is there a library that efficiently performs these kinds of operations on entire OGRLayers? For example, this library would have functions that would buffer all of the features in a layer, or intersect all of the features in one layer with all of those in another. Basically, I am looking for an open source technology that replicates the "geoprocessing tools" found in ArcGIS and other GIS packages. These tools traditionally operate on one or more layers as input and produce one or more layers as output. If such a library does not exist, does the OGR team envision that they might add such capabilities to OGR in the future? From software design and performance points of view, would it be appropriate to extend OGR to include functions for spatial operations on entire layers, or is this best left to other libraries? I can see rudimentary ways to implement such tools (e.g. for intersecting layers: loop over all features in both layers, calling OGRGeometry::Touches on all combinations, or something similar). But I am not a geometry expert and do not know if OGRLayer's cursor-based design is compatible with such capabilities; I do not know about spatial indexing, for example. I develop open source geoprocessing tools that help with spatial ecology problems. At the moment, my tools depend on heavily on ArcGIS for these operations with vector layers. I would like to remove this dependency, and, if possible, develop a toolbox that exposes the same ecology tools to several GIS packages. Many GIS packages, such as ArcGIS, QGIS, MapWindow, and OpenJump, support plugin extensions. I am wondering whether how difficult it would be to develop a package of tools that does not depend on a specific GIS package but exposes them to several packages via the package-specific plugin mechanisms. For this to work, I'd have to find a library that can do the kind of geoprocessing with layers that ArcGIS can do, or write my own. Writing it myself sounds daunting and am hoping that there are existing projects to draw from. Thank you very much for any comments you can provide. Jason ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev<><><>___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Integer error in creating bigtiff image
Hi folks, I'm working with someone trying to merge and reproject 1108 4 band tiff images into 1 BIGTIFF image. The command line options are as follows: gdalwarp -s_srs EPSG:26918 -t_srs EPSG:32119 -wo 'SOURCE_EXTRA=3' -wo 'SKIP_NOSOURCE=YES' -wm 4000 --config 'GDAL_CACHEMAX=2000' -tps -rcs -srcnodata '0' -of GTIFF -co 'BIGTIFF=YES' -co 'TFW=YES' -tr 1 1 /work/lisa/utm18/*.tif /work/lisa/reprojected_and_merged/naip_utm18_32119.tif The process stops with the following error: ERROR 1: Integer overflow : nDstXSize=29400, nDstYSize=19377 The command worked fine with 33 tiff images. The individual is using gdal 1.7.2 on 64 bit linux. Googling a bit and grepping the source code makes me think the problem is in reading the a tiff file, perhaps a badly formatted input tiff image? I suggested that the user try smaller chunks based on latitude rather than the whole utem zone for the state. Thoughts? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 2.0 Notes
>As we are running out of 1.x numbers (1.8.0 hopfully coming out soon), I'm >thinking about a 2.0 release for something like the fall of 2012 - just in >time for the world to end. That should simplify keeping track of the EPSG codes... Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize -tr and -te
I probably do it the hard way. The USDA flies summer color imagery in North Carolina every couple of years for crop verification. They will put draft versions of the imagery up in single image per county mosaics in MrSid format for download about 6-8 months before they make the final quarter quadragle geotiffs available. The single county mosaics are in UTM projection. In NC, we like utm zones so much, we have three of them. Since I prefer to work with a seamless image layer in the same projection (North Carolina State Plane) and quarter quad format, I: 1) Use nearblack on the county MrSid images and output to Imagine format. 2) Reproject the county Imagine images to NC State Plane projection 3) use gdaltindex to create a shapefile index (1) from an older statewide image layer with image overlap in North Carolina State Plane projection. 4) use gdaltindex to make a shapefile index (2) of the reprojected county Imagine format image files. 4) Run a python script which grabs the corner coordinates of each polygon from shapefile index 1 and use that to create a list of Imagine images that overlap with the polygon by comparing it to index 2. This script then recursively "cookie cuts" the section of each Imagine image that falls within the polygon and creates a tiff file , using gdaltranslate. After all of the "cookie cutting" has been done, the script merges all of the tiff files into one tiff file using gdalwarp. For most of this, I cheat by using python to pass os.system commands to use the utility binaries. I made up a powerpoint presentation on this a couple of years ago at an internal national meeting, is there a suitable wiki to upload it to ( after getting release permission and conversion to Openoffice impress format)? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Hermann Peifer Sent by: gdal-dev-boun...@lists.osgeo.org 10/01/2010 09:21 AM To Jukka Rahkonen cc gdal-dev@lists.osgeo.org Subject [gdal-dev] Re: gdal_rasterize -tr and -te On 01/10/2010 07:03, Jukka Rahkonen wrote: > Hermann Peifer gmx.eu> writes: > > >> At work, we are taking this "standard grid" issue pretty serious, but >> indeed, we might be the only ones worldwide with such a business rule. > > You are not alone, we are reprojecting our rasters to standard grid because it > helps in making seamless mosaics from the reprojected images. We are widening > the target extents a little bit to all directions with a python script to suit > the grid. > So we are already 2 ;-) Actually, I tentatively thought there would be more. This was why I wrote to the mailing list in the first place. I am aware that this (non-)issue can be solved in a shell one-liner or perhaps X lines of some other script code. I just thought that if there is a general interest, it could perhaps be built into the library. Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Read and Write ArcGIS Bynary GRID
Jorge, > Hello, > > Using GDAL library is posible to read and write ArcGIS binary GRID files? I generally work with GRID files in GRASS. As mentioned before, gdal ( r.in.gdal in this case) imports the GRID layers fine. To export back to ArcGIS, I use the r.out.arc command, http://grass.fbk.eu/grass65/manuals/html65_user/r.out.arc.html , in GRASS to create an ESRI ASCII GRID file. You can then import that back into ArcGIS. Bear in mind that if you are a 32-bit windowsXP platform you will not be able to import a text file larger than 43? GB ( Frank?) in size due to the limitations of the WindowsXP 32 bit filesystem. I have successfully imported data ESRI ASCII GRID files to ArcGIS up to 60GB in size on a computer running WindowsXP 64 bit with ArcGIS 9.3.1. Email me directly if you need further info. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
