Re: [gdal-dev] Creating mosaic larger than 4GB using gdal_merge.py
On Fri, May 13, 2011 at 11:03 AM, Vytas wrote: > Hi, > gdal_merge.py -o tot.tif Port*.tif Try "gdal_merge.py -co BIGTIFF=IF_NEEDED -o tot.tif Port*.tif" ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Fwd: [gdal-dev] merging shapefiles larger than 4GB
I am afraid you are out of luck, the shapefile format restricts its size to 32 bit. See bytes 24-27 http://en.wikipedia.org/wiki/Shapefile Even if the SHP part was not so restricted, I bet the DBF part is. Cheers Brian On Mon, May 2, 2011 at 3:28 PM, Harsha Ch wrote: > Hi all, > I am using ogr2ogr merge all my shapefiles into one large file. Its > failing with following error > ERROR 1: Failed to write shape object. File size cannot reach 4294967280 + > 28. > ERROR 1: Terminating translation prematurely after failed > > I looked at shapefil.h its using unsigned int for filesize which would > restrict the filesize to 4GB. > Is there any easy way to increase the filesize it can address, compiling in > 64bit doesn't help either. > I'll appreciate if you can give me any pointers on this issue . > > Thanks, > Harsha > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: cropping a tif with lat/lon
I keep a lot of my memory on a wiki because I am so forgetful. This page might help you. http://wildsong.biz/index.php?title=Mapping_Vietnam A couple months ago I was working with decollaring GeoPDF files from scanned maps of Vietnam. They are set up the same way as you describe, with one set of corner points indicates the edge of the paper map with collar attached and a second set is a polygon around the actual map area. I think the write up is good enough not to copy it here. Please look at it and let me know. Brian ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: cropping a tif with lat/lon
I am a newby too so I will share what I have learned lately. You can convert
from one srs to the other using the cs2cs tool from proj.4 which is probably
already installed if you have gdal.
To test it I typed this lengthy command all
cs2cs +proj=lcc +lat_1=44.34 +lat_2=46 +lat_0=43.66
\
+lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80 +units=m +to +proj=latlong \
+datum=WGS84
The program starts listening on stdin and I can feed it coordinate pairs in
meters for my neighborhood by typing this on a line and hitting "Enter".
2280696 101184
It responds on stdout with the pair converted to latlong as I have
requested..
123d15'36.84"W 44d32'36.644"N 0.000
Next I use control-D to exit. Then I can go the other direction by adding
the -'I' option to the cs2cs command and I feed it the latlong pair. ('-I'
just saves me some typing.) It responded with
2280696.01 101184.01 0.00
This is reasonably close to what I started with. (What's 1 cm among
friends?)
To make it work, you would have to know the projection that your FAA chart
is in (UTM zone something right?), convert it into the funny format that
proj.4 understands, and build a command line. Then you could put your
latlong corners into a file, feed them into cs2cs, get the corners back in
the FAA space and feed them to the gdal command. Taking a stab at it, for
zone 10N where I live I would try this
+proj=utm +zone=10 +north +ellps=GRS80 +units=m
I looked up the projection stuff with grep because I happen to know the EPSG
code for it is 102326. Then I cut and pasted. The latlong part came from
google and the cs2cs manpage.
grep 102326 /usr/local/share/proj/esri
<102326> +proj=lcc +lat_1=44.34 +lat_2=46
+lat_0=43.66 +lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80
+units=m no_defs <>
Anyway - if I needed to do this TODAY that's what I would do because it's
now in my meager skill set. Someone inspired by my clumsiness might be
inspired now to chime in with a more elegant way to do this.
Hope this helps
Brian
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal datum shift
Thanks Frank I had guessed that I might have to use -s_srs but doing I saw no tangible results hence my request for more verbose output. "--debug on" was very useful as was PROJ_DEBUG. As you surmised, the datum "NAD83_High_Accuracy_Regional_Network" is not recognized as +datum=NAD83 Then I found that I had missed the step in building Proj.4 of downloading separately the datum shift zip file. Upon fixing that I am now able to reproject correctly! HURRAH! Brian 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
[gdal-dev] gdal datum shift
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"]] ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Fwd: [gdal-dev] kml superoverlay help request
Darn -- meant this to go to the list not just to Harsh -- Forwarded message -- From: Brian Wilson Date: Mon, Apr 4, 2011 at 11:10 AM Subject: Re: [gdal-dev] kml superoverlay help request To: Harsh Govind Okay, so I cannot read KMZ w/gdal. I am using version 1.8 running on Ubuntu. Mostly I wanted to confirm that. I hate duplicating other people's work just because I am too dense to understand docs. :-) I never looked at a KMLSUPEROVERLAY before yesterday so I don't know how much variation there is in one. (Though there is XML involved so there could be LOTS of variation... :-) I started to describe the files in this message and decided a URL is easier. http://hupi.org/map/vietnam/50k/ For example, nc4806-50/ <http://hupi.org/map/vietnam/50k/nc4806-50/> is the unzipped version of nc4806-50.zip<http://hupi.org/map/vietnam/50k/nc4806-50.zip> (FYI this project is for the Vietnam Helicopter Pilot Association vhpa.organd the rasters are scans of Vietnam war era paper maps.) Brian Wilson Corvallis OR ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] kml superoverlay help request
I received a batch of files that are in a kml format that looks like the "KML SUPEROVERLAY" that gdal supports. There is a kmz flle which when unzipped contains a batch of JPEGs and a file called doc.kml that describes them. My "gdalinfo --formats" command says "KMLSUPEROVERLAY (rwv): Kml Super Overlay" but I don't know how to feed it the files. I tried the KMZ, the unpacked directory, and the doc file ERROR 4: `nc4806-50.kmz' not recognised as a supported file format. ERROR 4: `nc4806-50' not recognised as a supported file format. ERROR 4: `nc4806-50/doc.kml' not recognised as a supported file format. Or maybe I am wrong about what a kml super overlay is? My google searches only turned up help with writing the kml files, but I am assuming the formats "rwv" means it can read, write, and also do something else starting with the letter 'v' -- always wondered about those codes like rw+ maybe the + means update or append?? (And "rov" means remotely operated vehicle? oops context shift sorry) Thanks in advance Brian Wilson Corvallis OR ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] openjpeg build configuration
I am trying to build 1.8.0 on Linux with openjpeg support. I can easily build and install openjpeg from source (oropenjpeg_v1_4_sources_r697) into /usr/local ./configure --with-openjpeg ./configure --with-openjpeg=/usr/local both result in OpenJPEG support: no I wiped my gdal-1.8.0 directory and unpacked a fresh copy to make sure nothing was cached. I can see this test in configure output checking for opj_decode_tile_data in -lopenjpeg... no which does not look promising. Is there a version compat problem? Brian ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Building GDAL 1.7.3 Python bindings
Greetings, I am looking for some suggestions on how to build the python bindings for the latest gdal sources (1.7.3) for Windows. Environment: Windows 7, Visual Studio 2010, Python 2.5 Success: building gdal itself Failure: python module + bindings I keep hitting dead ends getting Python set up. I am trying to include details here because I searched and saw many "which version are you using" messages... sorry for the verbosity. I am not encountering ERROR messages, just trying to complete the build process and get up to date python bindings. I set up nmake.opt including PYDIR and PY_INST_DIR. I can't see anywhere those are USED but I followed docs and set them appropriately. (C:\Python25) And indeed, nothing pythonic appears to get built or installed. In desperation I tried just copying the python stuff into site-packages but of course that does not work, since there is no _gdal.dll built and thus Python cannot find it. I searched for hints on how to get there from here, but I only found a few other people with similar problems. I was able to build gdal with Visual Studio's "Build" command. I see references to building from the command line, but I don't have a clue how to do that in Windows. Something called nmake is referenced. I have not marched down that road yet. I got source code from http://trac.osgeo.org/gdal/wiki/DownloadSource I looked at I looked at http://pypi.python.org/pypi/GDAL/ which has lovely and usable Linux instructions but I am currently trapped in a Windows world at my otherwise wonderful day job. The text is duplicated in the source code under swig/python/Readme.txt The link on that page suggesting that I download binaries jumps to the old 1.5 version, but I can find this folder http://download.osgeo.org/gdal/win32/1.7 which seems to have only a couple plugins. As a Linux person it seems very odd to drill down 3 levels into source code only to find something like "Windows: go get the binaries somewhere else". Where do Windows binaries come from if they don't get built ever?? So mysterious. I suspect I need to do something with swig, which I downloaded and installed, but the "Windows" notes basically say "you should never have to do this". I don't know what I should never have to do, so that is as far as I have gotten. I can't use FWTools as they are built against an old version of Python (2.3) and I am trying to work in an ESRI world which means I am using 2.5 and 2.6 and further I really would like to be able to build support for file geodatabases to make this gdal python thing really usable in my work. I am sorry this email is long, but I have had plenty of time to work on building GDAL today while waiting for fragile and slow ESRI tools to run, really motivating me to try to use GDAL + Python. (Did the geoprocess crash or is it just sloo... one never knows with ESRI Model Builder. OH! The process just FINISHED. Unreal. I had time to download and build gdal itself a couple times while waiting. Now I can go back to real work.) Cheers -- Brian Wilson Corvallis Oregon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
