From neteler at osgeo.org Sun Mar 1 06:22:54 2009 From: neteler at osgeo.org (Markus Neteler) Date: Sun Mar 1 06:22:56 2009 Subject: [gdal-dev] different results for vector and raster data reprojections In-Reply-To: <39624f50902271142j2d6b8bcbsa9d724adb0d2f090@mail.gmail.com> References: <39624f50902271142j2d6b8bcbsa9d724adb0d2f090@mail.gmail.com> Message-ID: <86782b610903010322m5869ec06vf01977b3972cf59f@mail.gmail.com> Nimalika, On Fri, Feb 27, 2009 at 8:42 PM, nimalika fernando wrote: > Hi, > > I have used ogr2ogr to assign projection information(SL99) to some vector > data which does not contain any projection information. How did you do that? Please post the details. > I used the same projection information to reproject a raster in UTM 44N to > SL99.Both data sets contain data of same location. > > When I try to overlay the projected data ?( using QGIS where the SL99 is > defined using the same projection information) there is a small shift in two > layers. This may be an indicator for the datum not being recognized properly. > When check the projection information using ogrinfo/gdalinfo I found that > even though the same parameters are used for projection of vector and raster > data , some parts of the WKT is different. I am not sure whether this is the > reason for the problem in overlapping. It might be - the "morphing" of similar names might fail. > The resulting WKT are as follows > > Raster > > PROJCS["Transverse_Mercator", > ??? GEOGCS["Everest 1830", > ??????? DATUM["unknown", > ??????????? SPHEROID["unnamed",6377276.345,300.8017000000115]], > ??????? PRIMEM["Greenwich",0], > ??????? UNIT["degree",0.0174532925199433]], > ??? PROJECTION["Transverse_Mercator"], > ??? PARAMETER["latitude_of_origin",7.00047], > ??? PARAMETER["central_meridian",80.77171], > ??? PARAMETER["scale_factor",1], > ??? PARAMETER["false_easting",200000], > ??? PARAMETER["false_northing",200000], > ??? UNIT["metre",1, > ??????? AUTHORITY["EPSG","9001"]]] > > Vector > > PROJCS["Transverse_Mercator", > ??? GEOGCS["Everest 1830", > ??????? DATUM["unknown", > ??????????? SPHEROID["evrst30",6377276.345,300.8017]], > ??????? PRIMEM["Greenwich",0], > ??????? UNIT["Degree",0.017453292519943295]], > ??? PROJECTION["Transverse_Mercator"], > ??? PARAMETER["latitude_of_origin",7.00047], > ??? PARAMETER["central_meridian",80.77171], > ??? PARAMETER["scale_factor",1], > ??? PARAMETER["false_easting",200000], > ??? PARAMETER["false_northing",200000], > ??? UNIT["Meter",1]] > > Can anybody help me to identify what went wrong? ? please post more details (see above). Markus From nimalikaf at gmail.com Sun Mar 1 07:25:57 2009 From: nimalikaf at gmail.com (nimalika fernando) Date: Sun Mar 1 07:25:59 2009 Subject: [gdal-dev] different results for vector and raster datareprojections Message-ID: <39624f50903010425g599c1b1dif86fc13edf4de686@mail.gmail.com> Hi, Thank you for the support I couldn?t solve the issue yet Please note that I have redone the work with updated SL99 information. Still I have the same issue. Earlier I have used projection parameters in the ogr2ogr command and this time the WKT based on a projection file which I am using regularly is used. Detailed information is as follows The content of the file : SL99 WKT PROJCS["SL_grid_99", GEOGCS["GCS_Kandawala", DATUM["D_Kandawala", SPHEROID["Everest_1830",6377276.345,300.8017]], PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",200000.000], PARAMETER["False_Northing",200000.00], PARAMETER["Central_Meridian",80.77171], PARAMETER["Scale_Factor",0.9999238418], PARAMETER["Latitude_Of_Origin",7.00048], UNIT["Meter",1]] Following command is used to project the vector data ogr2ogr -a_srs slgrid99.wkt F:\UDAdata\test\cmc_b_sl99.shp F:\UDAdata\test\cmc_bound.shp Raster data?s original projection information is as follows ( from gdalinfo) PROJCS["UTM Zone 44, Northern Hemisphere", GEOGCS["WGS_1984", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235630016], TOWGS84[0,0,0,0,0,0,0]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",81], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["Meter",1], AUTHORITY["EPSG","32644"]] Then I have used the following command to re-project raster data. gdalwarp -t_srs slgrid99.wkt -s_srs "+proj=utm +zone=44 +ellps=WGS84 +datum=WGS84 +units=m" F:\UDAdata\po_310491_rgb_0000000_Clip.img F:\ UDAdata\test\raster_sl99.tiff Then , when over layering I use the following custom projection in QGIS. It worked fine with different vector data in the local context. This is the first time I?m using raster data in my work. +proj=tmerc +lat_0=7.00047 +lon_0=80.77171 +x_0=200000 +y_0=200000 +ellps=evrst30 +to_meter=0.999924 +units=m The shift is around 200m. WKT of the re projected files are as below Vector PROJCS["SL_grid_99", GEOGCS["GCS_Kandawala", DATUM["Kandawala", SPHEROID["Everest_1830",6377276.345,300.8017]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",200000.000], PARAMETER["False_Northing",200000.00], PARAMETER["Central_Meridian",80.77171], PARAMETER["Scale_Factor",0.9999238418], PARAMETER["Latitude_Of_Origin",7.00048], UNIT["Meter",1]] Raster PROJCS["SL_grid_99", GEOGCS["GCS_Kandawala", DATUM["unknown", SPHEROID["unnamed",6377276.345,300.8017000000115]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",7.00048], PARAMETER["central_meridian",80.77171], PARAMETER["scale_factor",0.9999238418], PARAMETER["false_easting",200000], PARAMETER["false_northing",200000], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Any clarification would be much appreciated. Thanking you nimalika -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090301/e58eac62/attachment.html From szekerest at gmail.com Sun Mar 1 10:24:02 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Sun Mar 1 10:24:05 2009 Subject: [gdal-dev] GDAL autotest failures on Windows Message-ID: Hi Folks, I've managed to include the GDAL auto-tests with my regular builds on Windows. The stable branch has no failures. The SVN trunk produces 17-18 failures for each compilers/architectures: ------------ Failures ------------ Script: ogr/ogr_gml_read.py TEST: ogr_gml_4 ... fail Wrong featureCode field value Script: gcore/hfa_write.py TEST: SetProjection: byte.tif ... fail Did not get expected projection reference. TEST: SetProjection: int16.tif ... fail Did not get expected projection reference. TEST: SetProjection: uint16.tif ... fail Did not get expected projection reference. TEST: SetProjection: int32.tif ... fail Did not get expected projection reference. TEST: SetProjection: uint32.tif ... fail Did not get expected projection reference. TEST: SetProjection: float32.tif ... fail Did not get expected projection reference. TEST: SetProjection: float64.tif ... fail Did not get expected projection reference. TEST: SetProjection: cfloat32.tif ... fail Did not get expected projection reference. TEST: SetProjection: cfloat64.tif ... fail Did not get expected projection reference. TEST: SetProjection: utmsmall.tif ... fail Did not get expected projection reference. Script: gcore/misc.py TEST: misc_5 ... fail (blowup) TEST: misc_6 ... fail (blowup) Script: gdrivers/aigrid.py TEST: aigrid_online_1 ... fail No RAT found Script: gdrivers/bsb.py TEST: bsb_online_1 ... fail Checksum for band 1 in "tmp/cache/14850_1.KAP" is 63005, but expected 54674. Script: gdrivers/hfa.py TEST: hfa_delete_colortable ... fail (blowup) Script: osr/osr_esri.py TEST: osr_esri_15 ... fail Did not get rectified_grid_angle as expected. TEST: osr_esri_16 ... fail Did not get expected equidistant cylindrical. ---------------------------------- Test Script: utilities/test_ogrtindex.py Succeeded: 1287 Failed: 18 (3 blew exceptions) Skipped: 238 Expected fail:0 For more details about the issues you can inspect the build logs here: http://vbkto.dyndns.org:1280/sdk/index.html Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090301/858fb183/attachment.html From even.rouault at mines-paris.org Sun Mar 1 12:11:16 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 1 12:11:27 2009 Subject: [gdal-dev] GDAL autotest failures on Windows In-Reply-To: References: Message-ID: <200903011811.17295.even.rouault@mines-paris.org> Tamas, I've just fixed the failures for bsb_online_1 (the online dataset had apparently changed since I downloaded it) and hfa_delete_colortable (a file copy was made in text mode instead of binary mode). I've added a missing file close in the PCRaster driver in an error path that might account for the failures on misc_5 and misc_6. And I've also added more info in case of failure so that we can identify more easily the driver that causes the error. The failures in hfa_write.py and osr_esri.py also occur on Linux and are known and reported in http://trac.osgeo.org/gdal/ticket/2755 The failure on aigrid_online_1 seems to reveal a bug in the AIGRID driver on Windows. VSIStatL seems to fail on a directory whose name is like 'foo/../info/' (in AIGDataset::ReadRAT()) My feeling on the failure on ogr_gml_4 is that it might be related to a recent change in the GML driver (http://trac.osgeo.org/gdal/ticket/1017) on how we fetch the FID of features. On Linux, an ogrinfo on autotest/ogr/data/bom.gml now show the 3 features with an identical fid = 2147483647. On Windows, ogrinfo.exe loops endlessly and returns always the content of the first feature with a fid = -416888225. Le Sunday 01 March 2009 16:24:02 Tamas Szekeres, vous avez ?crit?: > Hi Folks, > > I've managed to include the GDAL auto-tests with my regular builds on > Windows. The stable branch has no failures. > > The SVN trunk produces 17-18 failures for each compilers/architectures: > > ------------ Failures ------------ > Script: ogr/ogr_gml_read.py > TEST: ogr_gml_4 ... fail > Wrong featureCode field value > Script: gcore/hfa_write.py > TEST: SetProjection: byte.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: int16.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: uint16.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: int32.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: uint32.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: float32.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: float64.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: cfloat32.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: cfloat64.tif ... fail > Did not get expected projection reference. > TEST: SetProjection: utmsmall.tif ... fail > Did not get expected projection reference. > Script: gcore/misc.py > TEST: misc_5 ... fail (blowup) > TEST: misc_6 ... fail (blowup) > Script: gdrivers/aigrid.py > TEST: aigrid_online_1 ... fail > No RAT found > Script: gdrivers/bsb.py > TEST: bsb_online_1 ... fail > Checksum for band 1 in "tmp/cache/14850_1.KAP" is 63005, but expected > 54674. Script: gdrivers/hfa.py > TEST: hfa_delete_colortable ... fail (blowup) > Script: osr/osr_esri.py > TEST: osr_esri_15 ... fail > Did not get rectified_grid_angle as expected. > TEST: osr_esri_16 ... fail > Did not get expected equidistant cylindrical. > ---------------------------------- > > Test Script: utilities/test_ogrtindex.py > Succeeded: 1287 > Failed: 18 (3 blew exceptions) > Skipped: 238 > Expected fail:0 > > > For more details about the issues you can inspect the build logs here: > > http://vbkto.dyndns.org:1280/sdk/index.html > > Best regards, > > Tamas From yann.chemin at gmail.com Sun Mar 1 21:48:09 2009 From: yann.chemin at gmail.com (Yann Chemin) Date: Sun Mar 1 21:48:13 2009 Subject: [gdal-dev] problem accessing rows of an image in parallel Message-ID: <4f37eb890903011848p69ecb776s375958193fea1a8c@mail.gmail.com> Hello list, I am working on an OpenMP implementation of an image processing algorithm and was wondering if there is a known problem in accessing different rows at the same time on the same band handle. sometimes I get this (or similar): ERROR 1: TIFFFillStrip:b4.tif: Seek error at scanline 186, strip 345 ERROR 1: TIFFReadEncodedStrip() failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 345 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 345 ERROR 1: TIFFFillStrip:b4.tif: Seek error at scanline 1269, strip 157 ERROR 1: TIFFReadEncodedStrip() failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 157 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 157 On the original standard serial code, all is fine. Thanks for any suggestions, Yann -- Yann Chemin Perso: http://www.freewebs.com/ychemin YiKingDo: http://yikingdo.unblog.fr/ From warmerdam at pobox.com Sun Mar 1 22:02:51 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Sun Mar 1 22:03:05 2009 Subject: [gdal-dev] problem accessing rows of an image in parallel In-Reply-To: <4f37eb890903011848p69ecb776s375958193fea1a8c@mail.gmail.com> References: <4f37eb890903011848p69ecb776s375958193fea1a8c@mail.gmail.com> Message-ID: <49AB4C5B.3000100@pobox.com> Yann Chemin wrote: > Hello list, > > I am working on an OpenMP implementation of an image processing > algorithm and was wondering if there is a known problem in accessing > different rows at the same time on the same band handle. > > sometimes I get this (or similar): > ERROR 1: TIFFFillStrip:b4.tif: Seek error at scanline 186, strip 345 > ERROR 1: TIFFReadEncodedStrip() failed. > > ERROR 1: IReadBlock failed at X offset 0, Y offset 345 > ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 345 > ERROR 1: TIFFFillStrip:b4.tif: Seek error at scanline 1269, strip 157 > ERROR 1: TIFFReadEncodedStrip() failed. > > ERROR 1: IReadBlock failed at X offset 0, Y offset 157 > ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 157 Yann, I would not particularly expect the above error, but it is not legal to use one GDALDataset object in more than one thread at the same time. Basically there is only one FILE* per dataset and if one thread does a seek while another thinks the file offset is at a known point for a subsequent read havoc will ensue. I am guessing you are running into some manifestation of this. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From mapbutcher at mapbutcher.com Mon Mar 2 05:10:57 2009 From: mapbutcher at mapbutcher.com (mapbutcher) Date: Mon Mar 2 05:11:02 2009 Subject: [gdal-dev] FOSS4G 2009 One week extension to Workshops and Tutorial abstract submissions Message-ID: <486f11580903020210i8ace876qf9c262bbad122eb9@mail.gmail.com> FOSS4G 2009 One week extension to Workshops and Tutorial abstract submissions Sydney, Australia. 2 March 2009. In response to requests from presenters, the deadline for the FOSS4G 2009 workshop and tutorial abstract submissions has been extended by one week, to Monday 9 March 2009. If you are considering submitting a workshop, please notify your intent by emailing the Workshop/Tutorial coordinator, Mark Leslie, at m a r k . l e s l i e AT l i s a s o f t . c o m. About FOSS4G FOSS4G, held 20-23 October 2009 in Sydney, Australia, is the international "gathering of tribes" for open source geospatial communities. The theme for the FOSS4G 2009 conference will be "User Driven". Users and developers are encouraged present their latest projects and software to demonstrate the power of Open Source for system integration through a series of workshop sessions and tutorial presentations. Session participants should expect to see presentations on both geospatial open source and propriety software integration along with pure open source solutions. Workshops Workshops are expected to be a hands-on experience with participants following along with the instructor, working directly with the application under discussion. All workshop rooms will be equipped with computers (two students sharing one system) to support this vision. Workshop computers will pre-installed with a basic image containing standard packages running in a Windows XP environment. A projector will be provided for each computer room for use within a workshop. Instructors will need to discuss pre-installation requirements with the Conference Organising Committee if required. Workshops are expected to require considerable effort to create, with past experience showing that three days of preparation per hour of presentation are required to produce a high quality workshop. Additionally you will be expected to develop material for attendees to take home with them, such as handouts, workbook, CD-ROMs etc. Due to the effort involved in producing and presenting a workshop, instructors will receive a single complementary registration to the conference for delivering a workshop. All workshop submissions will be considered, but particular interest will be shown in the following topics: Practical Introduction to ____ Integrating Open Source Spatial Data Privacy and Security Tutorials Tutorial rooms will not be equipped with computers, however presenters may optionally make use of delegate laptops and the FOSS4G LiveDVD. At least 80% of delegates are expected to be carrying a laptop and FOSS4G LiveDVDs will be given to all delegates. Preference will be given to hands-on tutorials. Any hands-on aspects to a tutorial will be the responsibility of the presenter and needs to be described in the tutorial description. Presenters making use of the Live DVD or Climate Challenge Integration Plugfest (CCIP) will be expected to contribute to testing pre-releases to ensure material and software is properly installed. To discuss your requirements for LiveDVD, please contact the organising committee: http://2009.foss4g.org/contacts/. All tutorial submissions will be considered, but particular interest will be shown in the following topics: Practical introductions Interoperability Spatial data accuracy Spatial data privacy Spatial data security System implementation Data migration Submission instructions and templates are available at http://2009.foss4g.org/workshops/ and http://2009.foss4g.org/tutorials/. The deadline for workshop / tutorial submissions is March 9, 2009. FOSS4G 2009 Highlights The Climate Challenge Integration Plugfest (CCIP): FOSS4G will launch the OGC's Climate Challenge Integration Plugfest (CCIP), which demonstrates standards based interoperability between Open Source and Proprietary geospatial applications. It consists of a server with multiple virtual machines, each installed with geospatial applications offering standards based web services. All web services will demonstrate a common dataset, and will be accessed by a range of geospatial client applications installed on client computers. http://external.opengis.org/twiki_public/bin/view/ClimateChallenge2009/WebHome Presenters are encouraged (but not mandated) to make use of scenarios and on-site data from the Climate Challenge Integration Plugfest (CCIP). This is especially important as demand for access to data over the internet is expected to be high, and Australia has notoriously slow connections to the outside world. FOSS4G Live DVD: LiveDVDs, based on the Xubuntu operating system and including Geospatial Open Source Software, will be given to all delegates. Users can boot a Live DVD on their computer and trial the software without installing or effecting the existing system. http://wiki.osgeo.org/wiki/Live_GIS_Disc Installfest: The Installfest will give delegates the opportunity to meet in a common area and install a wide variety of FOSS software on their laptops, EEPC or any other system they care to bring in. Community members will be around to assist with any troubles and provide help and insight into the software. The install fest will take place after workshops on the first day. Workshops and Tutorials: Workshops and Tutorials allow presenters to lead attendees through applications, integration solutions, or other topics in an interactive environment. Half-day workshops (3 hours) will be held in computer rooms on the first day. Tutorials (90 minutes) will be held in standard presentation rooms, run concurrently with presentations during the third and fourth days. Presentations: The meat of the conference are it's presentations. Drawing on a huge community of local, regional and international experts we will discuss some of the most current and poignant topics in the industry today. Birds of a Feather: Rooms have been set aside for semi-organised meetings between like minded groups. Some prominant community initiatives started in prior FOSS4G Birds of a Feather sessions. Code Sprint: The weekend after FOSS4G is reserved for the Hackers' Code Sprint. Hackers will be locked in a basement with lots of bandwidth, pizzas and coke. (Well, maybe something better than that, but we don't want to spoil the mystical hacker image by describing it any differently.) Upcoming milestones 2 Feb 2009, Call for Workshops/Tutorials opens 9 Mar 2009, Call for Workshops/Tutorials closes 9 Mar 2009, Call for Abstracts opens 30 Mar 2009, Notification of acceptance for workshops/tutorials 13 Apr 2009, Registration for conference and tutorials opens 1 Jun 2009, Abstract submission deadline 13 Jul 2009, Presenters notified of acceptance for talks 31 Jul 2009, Author/Early registration deadline 14 Sep 2009, Completed program available on the wiki 20 Oct 2009, FOSS4G Workshop 21-23 Oct 2009, FOSS4G Presentations and Tutorials 24-25 Oct 2009, FOSS4G Code Sprint For information about this announcement, contact: FOSS4G Organising Committee: http://wiki.osgeo.org/wiki/FOSS4G_2009#Contact_Us or, Cameron Shorter, Chair of the FOSS4G Organising Committee and Geospatial Systems Architect at LISAsoft tel +61-8570-5050 c a m e r o n . s h o r t e r @ l i s a s o f t . c o m -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090302/f4b7dcef/attachment-0001.html From s.normann at gmx.com Mon Mar 2 08:28:28 2009 From: s.normann at gmx.com (Simmer) Date: Mon Mar 2 08:28:32 2009 Subject: [Gdal-dev] How to read GeoTIFF dimensions? Message-ID: <1236000508901-2409146.post@n2.nabble.com> Hi! I want to cut several hundred GeoTIFFs of 1GB each into 4 pieces each. I'm using the following commands for each image: gdal_translate.exe -srcwin 0 0 10460 11931 source.tif output_01.tif gdal_translate.exe -srcwin 10460 0 10460 11931 source.tif output_02.tif gdal_translate.exe -srcwin 0 11931 10460 11931 source.tif output_03.tif gdal_translate.exe -srcwin 10460 11931 10460 11931 source.tif output_04.tif Problem is: This is just an example. Each GeoTiff has different dimensions. Is there a possibility to either: - Let GDAL automatically cut each image into 4 parts without giving XY coordinates? or: - To read the GeoTIFF coordinates into a list or something without having to open each single file. I know that gdal_translate.exe -srcwin can read the dimensions but I need them all to be listed somewhere to insert them to the commands. Windows Explorer should be able to show the dimensions in a list, but crashes at GeoTiffs of that size... Bests, Simmer -- View this message in context: http://n2.nabble.com/How-to-read-GeoTIFF-dimensions--tp2409146p2409146.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From jonahd at gmail.com Mon Mar 2 09:34:55 2009 From: jonahd at gmail.com (Jonah Duckles) Date: Mon Mar 2 09:34:57 2009 Subject: [Gdal-dev] How to read GeoTIFF dimensions? In-Reply-To: <1236000508901-2409146.post@n2.nabble.com> References: <1236000508901-2409146.post@n2.nabble.com> Message-ID: > > - Let GDAL automatically cut each image into 4 parts without giving XY > coordinates? > Your question really has nothing to do with GDAL and is more about shell programming and shell usage. GDAL gives you all the information, what you do with it is up to you. The DOS/Windows shell is not optimized for this kind of scripting. Running the gdal tools under cygwin might work best for you as many examples exist of this type of thing in bash. Looks like you're on windows, but if you have sed and grep installed in your path you could run: gdalinfo image.tif |grep ^Size | sed 's/Size is//g;s/ //g'. - To read the GeoTIFF coordinates into a list or something without having to > open each single file. > I know that gdal_translate.exe -srcwin can read the dimensions but I need > them all to be listed somewhere to insert them to the commands. Windows > Explorer should be able to show the dimensions in a list, but crashes at > GeoTiffs of that size... > In bash (under cygwin on windows perhaps) you could set this to a shell variable: XY=$(gdalinfo image.tif |grep "^Size" | sed 's/Size is//g;s/ //g') # Then parse out the X and Y extents individually. x=$(echo $XY | cut -d"," -f1) y=$(echo $XY | cut =d"," -f2) gdalinfo can give you a bunch of other info too, try just: gdalinfo image.tif to see all of gdalinfo's output. Jonah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090302/d73fc669/attachment.html From frdcn at hotmail.com Mon Mar 2 10:31:35 2009 From: frdcn at hotmail.com (godofredo contreras) Date: Mon Mar 2 10:31:38 2009 Subject: [gdal-dev] OGR Grass driver error In-Reply-To: <86782b610902280927w2dc037c2s923b1f031626b636@mail.gmail.com> References: <86782b610902280927w2dc037c2s923b1f031626b636@mail.gmail.com> Message-ID: > On Sat, Feb 28, 2009 at 4:43 AM, godofredo contreras wrote: > > Hi: > > > > I tried to use ogrinfo with the grass driver, this was the command I used: > > > > C:\dev\cpp\qgisrelease>ogrinfo > > C:/spearfish60/PERMANENT/vector/landcover/head > > > > and I got the following warnings: > > > > Warning 1: GRASS warning: Unable to open datum table file > > > ENT/vector/landcover/head/etc/datum.table> > > Warning 1: GRASS warning: Unable to open ellipsoid table file > > > RMANENT/vector/landcover/head/etc/ellipse.table> > > > > and didn't show any layers. > > > > Is the grass driver updated to work with grass 6.0 data?, I'm using the > > ogrinfo from > > osgeo4w and I set GISBASE to an installation of grass-6.4.0RC3 inside > > osgeo4w > > directory. > > The problem is that the software wasn't compiled with the (AFAIK) > --with-proj-share=... > flag to indicate the correct path of these files. > > On my Linux box they stay in: > /usr/share/gdal/grass/etc/ > > Best reported to > http://trac.osgeo.org/osgeo4w/ > as bug. > > Markus Thank you Markus for the answer, it was an error mine. I took out ogrinfo from osgeo4w directory and I forgot to set GDAL_DATA environment variable. After setting GDAL_DATA the error have gone. Regards Godofredo Contreras _________________________________________________________________ Windows Live? Contacts: Organize your contact list. http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090302/9a59779e/attachment.html From rush at winkey.org Mon Mar 2 11:14:50 2009 From: rush at winkey.org (brian) Date: Mon Mar 2 11:21:00 2009 Subject: [gdal-dev] OGR Feature Style Message-ID: <1236010490.24730.4.camel@winkey.org> When a style at the feature level is a @name, how do you know if that name refers to a style at the layer or dataset level? Brian From warmerdam at pobox.com Mon Mar 2 12:07:49 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 2 12:08:11 2009 Subject: [gdal-dev] OGR Feature Style In-Reply-To: <1236010490.24730.4.camel@winkey.org> References: <1236010490.24730.4.camel@winkey.org> Message-ID: <49AC1265.3080503@pobox.com> brian wrote: > When a style at the feature level is a @name, how do you know if that > name refers to a style at the layer or dataset level? Brian, I hadn't even realized that the API and OGR Feature Style specification addressed datasource level style tables. The spec does not seem very specific on this point so I would assume a feature would first search for a named style on the layer, and if not found would then search on the datasource. In case it isn't obvious, style tables are not a significantly used technology currently. :-) Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From legeochen at gmail.com Mon Mar 2 20:53:56 2009 From: legeochen at gmail.com (legeochen) Date: Mon Mar 2 20:53:58 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: References: Message-ID: Wow: Tanks for your suggestion! Yeaph! That maybe where the rub is. I will try it out soon. cheers! 2009/3/3 wow <27949218@qq.com> > Hi, > Your code looks like that you didn't create any field for the feature. At > least create one field would ensure success. > Like this: > OGRFieldDefn oField( "Name", OFTString ); > oField.SetWidth(32); > if( pLayer->CreateField( &oField ) != OGRERR_NONE ) > { > printf( "Creating Name field failed.\n" ); > exit( 1 ); > } > > Xuexia Chen > ------------------ > To the world you're little, but to a person, maybe you're the world. > > > > > ------------------ Original ------------------ > *From: * "legeochen"; > *Date: * Fri, Feb 27, 2009 09:47 PM > *To: * "Gdal-Dev"; > *Subject: * [gdal-dev] create 25D MultiPolygon how to > > Hi All > I try to create some multipolygons?with OGR.?After creating them, but when > I want view them in arcscene, it just make arcscene crash! Then I tried > osgviewer with ESRI Shapefile, I was warned: > ESRIShape loader: .dbf file containe different record number that .shp > file. > ???????????????????????????? .dbf record skipped. > Actually, only one feature in the dataset had been readed out. > Then, I tried osgviewer with ogr, got warnings like this: > Warning something wrong with a polygon in a multi polygon. > And, the result is not quite as expected! > Here is?my code: > ?const char* pszDriverName = "ESRI Shapefile"; > ?OGRSFDriver *poDriver; > ?OGRRegisterAll(); > ??? poDriver = OGRSFDriverRegistrar::GetRegistrar()->GetDriverByName( > ??????????????? pszDriverName ); > ??? if( poDriver == NULL ) > ??? { > ??????? printf( "%s driver not available.\n", pszDriverName ); > ??????? return false; > ??? } > ?OGRDataSource *poDS; > ?poDS = poDriver->Open(shpfile,TRUE); > ?if(poDS == NULL) > ??poDS = poDriver->CreateDataSource(shpfile,NULL); > ?if(poDS == NULL) > ?{ > ??printf("Creation of output file failed.\n"); > ??return false; > ?} > ?OGRLayer* poLayer = poDS->GetLayerByName (layername); > ?if(poLayer == NULL) > ?{ > ??if( !poDS->TestCapability( ODsCCreateLayer ) ) > ??????? { > ??????????? fprintf( stderr, > ????????????? "Layer Roadway not found, and CreateLayer not supported by > driver." ); > ??????????? return FALSE; > ??????? } > ??CPLErrorReset(); > ??poLayer = poDS->CreateLayer(layername,NULL,wkbMultiPolygon25D,NULL); > ??if(poLayer == NULL) > ??{ > ???printf( "Layer creation failed.\n" ); > ???return false; > ??} > ?} > > ?for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != > _roadwayArr.end();itrw++) > ?{ > ??OGRFeature *poFeature; > ?? > ??OGRMultiPolygon multiPoly; > ??poFeature = OGRFeature::CreateFeature(poLayer->GetLayerDefn()); > ??Roadway::Triangle_list tris = (*itrw)->getTrianglelist(); > ??for(Triangle_list::const_iterator ittri = tris.begin();ittri != > tris.end();ittri++) > ??{ > ???OGRPolygon polygon; > ???OGRLinearRing poRing; > ???poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); > ???poRing.addPoint((*ittri).b().x(),(*ittri).b().y(),(*ittri).b().z()); > ???poRing.addPoint((*ittri).c().x(),(*ittri).c().y(),(*ittri).c().z()); > ???poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); > ??? > ???polygon.addRing(&poRing); > ???multiPoly.addGeometry(&polygon); > ??? > ??} > ??poFeature->SetGeometry(&multiPoly); > ??if( poLayer->CreateFeature( poFeature ) != OGRERR_NONE ) > ??{ > ???printf( "Failed to create feature in shapefile.\n" );?????? > ???return false; > ??} > ??OGRFeature::DestroyFeature( poFeature ); > ?} > ?OGRDataSource::DestroyDataSource( poDS ); > Any help is appreciated!!? > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090303/863f5563/attachment.html From didier.richard at ign.fr Tue Mar 3 09:14:03 2009 From: didier.richard at ign.fr (Richard didier) Date: Tue Mar 3 09:09:17 2009 Subject: [gdal-dev] [1.6.0][GDALWARP] World file name is empty In-Reply-To: <49A43A05.50507@pobox.com> References: <32928.87.231.96.39.1235476511.squirrel@webmail.ign.fr> <49A43A05.50507@pobox.com> Message-ID: <200903031514.03133.didier.richard@ign.fr> Le Mardi 24 F?vrier 2009 19:18, Frank Warmerdam a ?crit : > RICHARD Didier wrote: > > Hi all, > > > > I am having the following behavior with gdalwarp (freshly compiled from > > 1.6.0) when I am requiring to get a tfw file (former releases didn't have > > this behavior) : > > > > $ gdalwarp ... -co "TFW=YES" in.tif out.tif > > > > "out.tif" and ".tfw" files are generated (before 1.6.0, I got "out.tif" > > and "out.tfw") > > > > If I remove the -co "TFW=YES", only the "out.tif" is produced. Then, > > > > $ gdal_translate -co "TFW=YES" out.tif out2.tif > > > > "out2.tif" and "out2.tfw" are generated as expected. > > > > I noticed that osFilename is empty in WriteGeoTIFFInfo() function. > > A workaround solution (for me only) was to add : > > > > poDS->osFilename = pszFilename; > > > > at line 5420 of GTiffDataset::Create() function in geotiff.cpp. > > > > > > Did anyone else face this behavior ? > > > > Should I put a ticket (I didn't find such a report in the trac) ? > > Didier, > > I was unable to reproduce this problem and it appears that > GTiffDataset::Create() does assign osFilename with pszFilename fairly > prominately in trunk and 1.6 branch. I suspect this is a problem someone > already noticed and fixed. I'd appreciate it if you could confirm the > behavior no longer occurs for you with trunk (or 1.6 branch if that is > convenient for you to build from). If the problem persists, then filing > a ticket would be appropriate. > I can now confirm : branches 1.6 (today) : no problem trunk (today) : no problem too ! All the best, didier > Best regards, -- Didier RICHARD, chef du p?le technique G?oportail pour l'IGN Institut Geographique National tel: +33/0 1.43.98.83.23 2/4 Avenue Pasteur fax: +33/0 1.43.98.80.88 F-94165 St-Mande Cedex e-mail: Didier.Richard@ign.fr From nahumoz at gmail.com Tue Mar 3 11:12:29 2009 From: nahumoz at gmail.com (Oz Nahum) Date: Tue Mar 3 11:12:31 2009 Subject: [gdal-dev] ASCII Rasters and 'null' values in python-gdal In-Reply-To: <49A81784.9040501@pobox.com> References: <6ec71d090902261304u398d4468we3ca3558ca918956@mail.gmail.com> <6ec71d090902270009v2e4ec57at35efbf2d4485cbf@mail.gmail.com> <49A81784.9040501@pobox.com> Message-ID: <6ec71d090903030812y7b07e7e1v8509d8ecc5ef0d3e@mail.gmail.com> Hi, Thank you all for your answers. This was probably a bug in debian lenny: python-gdal in lenny is 1.5.2-3 python-gdal in squeeze is 1.5.4-2 This behavior does not occur in debian squeeze, so I will look up if a bug report on this exists in debian-lenny and report this internaly to the debian guys. Oz. On Fri, Feb 27, 2009 at 5:40 PM, Frank Warmerdam wrote: > Oz Nahum wrote: > >> Hi, Thanks for the answer. >> Ok, I admit the way I presented my first email is a bit confusing. >> But the problem is not with the 'null' values. Rather the problem is with >> the raster containing the no data values as -9999. This is a no data >> representation like you said. My problem is that GDAL is converting the last >> -9999 value to this value 31081. >> raster2.asc and looks like this: >> >> in text editor: >> |ncols 6 >> nrows 4 >> xllcorner 3366820.0000019 >> yllcorner 5814589.0300007 >> cellsize 10 >> NODATA_value -9999 >> 1 1 1 1 1 1 >> 1 1 1 1 1 1 >> 1 1 1 1 1 1 >> 1 1 1 1 -9999 -9999| >> >> |in python: >>> dataset = gdal.Open('raster1.asc', GA_ReadOnly) >> >>> a = gdal_array.DatasetReadAsArray(dataset) >> >>> a >> array([[ 1, 1, 1, 1, 1, 1], >> [ 1, 1, 1, 1, 1, 1], >> [ 1, 1, 1, 1, 1, 1], >> [ 1, 1, 1, 1, -9999, 31081]], dtype=int16) >> > > Oz, > > I'm not seeing this behavior on my system: > > >>> a = gdalnumeric.DatasetReadAsArray(ds) > >>> print a > [[ 1 1 1 1 1 1] > [ 1 1 1 1 1 1] > [ 1 1 1 1 1 1] > [ 1 1 1 1 -9999 -9999]] > > I'd suggest filing a ticket on the issue and being very specific > about the operating system platform, and GDAL version you are using. > Also, make sure you zip and attach the grid file in case there is some > issue with missing final newline or something that is having an influence. > > Best regards, > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent > > -- when one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion." Robert Pirsig, Zen and the Art of Motorcycle Maintenance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090303/59c270fe/attachment.html From jorge.arevalo at gmail.com Tue Mar 3 12:03:02 2009 From: jorge.arevalo at gmail.com (Jorge) Date: Tue Mar 3 12:03:25 2009 Subject: [gdal-dev] Problem with gdal2tiles and IE7 Message-ID: <49AD62C6.1070602@gmail.com> Hello everybody I have problems with some tiles generated with gdal2tiles. Basically: - I create 4-bands blank GTiff files (based on the extent of MIF files) using this code. shp = str(shapeFile) tiff = str(tiffFile) px = pxResolution # Import vector shapefile vector = ogr.GetDriverByName('Mapinfo File') src_ds = vector.Open(shp) src_lyr = src_ds.GetLayer( 0 ) src_extent = src_lyr.GetExtent() # Xmin Xmax Ymin Ymax (meters) # Define raster properties tiff_width = int((src_extent[1] - src_extent[0]) / px) tiff_height = int((src_extent[3] - src_extent[2]) / px) # Create new raster layer with 4 bands raster = gdal.GetDriverByName('GTiff') dst_ds = raster.Create( tiff, tiff_width, tiff_height, 4,gdal.GDT_Byte) # Create raster GeoTransform based on upper left corner andpixel resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3],0.0, -px] dst_ds.SetGeoTransform( raster_transform ) # Get projection of shapefile and assigned to raster srs = osr.SpatialReference() srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__()) dst_ds.SetProjection( srs.ExportToWkt() ) # Create blank raster with fully opaque alpha band zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) dst_ds.GetRasterBand(1).WriteArray( zeros ) dst_ds.GetRasterBand(2).WriteArray( zeros ) dst_ds.GetRasterBand(3).WriteArray( zeros ) opaque = numpy.zeros((tiff_height,tiff_width), numpy.uint8 )*255 dst_ds.GetRasterBand(4).WriteArray( opaque ) - Then, I rasterize the polygons of the MIF file to the GTiff file created using gdal_rasterize, based on my own colours and my own logic to apply them. I use the fourth band of each GTiff file as alpha channel, with the value 127 (50% transparency): gdal_rasterize -b 1 -b 2 -b 3 -b 4 -burn -burn -burn -burn 127 -where -l gdal_rasterize -b 1 -b 2 -b 3 -b 4 -burn -burn -burn -burn 127 -where -l gdal_rasterize -b 1 -b 2 -b 3 -b 4 -burn -burn -burn -burn 127 -where -l I need 3 calls because I use 3 colours for my tiles. The "-where" option select different mif polygons in every call. - After this, I create a VRT file using gdal_vrtmerge (I have a lot of GTiff files to be tiled): gdal_vrtmerge -o tiles.vrt - Finally, I apply gdal2tiles in that way: gdal2tiles -r near -s -z - -v -w google tiles.vrt . The generated tiles are properly shown on IE6 and Firefox, But IE7 shows an UGLY dark background and the borders of the thiles. I provide screenshots of the map shown with ie6 (ok), firefox (ok) and ie7 (error). http://www.nebulared.com/tmp_geo/ie6.png http://www.nebulared.com/tmp_geo/ie7.png http://www.nebulared.com/tmp_geo/firefox.png Does anyone know what could be happening? Thanks in advance Regards Jorge From robert.coup at onetrackmind.co.nz Wed Mar 4 05:16:46 2009 From: robert.coup at onetrackmind.co.nz (Robert Coup) Date: Wed Mar 4 05:16:48 2009 Subject: [gdal-dev] Building under gcc-4.3/libtool-2.2.4 (ubuntu intrepid) Message-ID: Hey folks, I'm struggling to build either the 1.5 branch or trunk on Ubuntu Intrepid with gcc 4.3.2 and libtool 2.2.4. The symptoms are the same as described in http://trac.osgeo.org/gdal/ticket/2138 , except updating ltmain.sh doesn't seem to help. And i get the same building the Debian v1.5.4 source package under intrepid as well (how i got started down this track). I've run libtoolize/aclocal/autoconf/autogen/etc to redo the setup stuff, but i still get the same error. I'm not an autotools expert though, so advice would be appreciated. Building with gcc/g++ 4.1 errors out in the same way. Thanks! Rob :) libtool: link: g++ -I/usr/include -Wl,-Bsymbolic-functions -g -O2 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -rdynamic gdal_wrap.o -o .libs/gdal.so -L/usr/lib -L/usr/lib/mysql -L/home/rcoup/packages/gdal/orig/gdal-svn-1.5 /home/rcoup/packages/gdal/orig/gdal-svn-1.5/.libs/libgdal.so /usr/lib/libgeos_c.so /usr/lib/libgeos.so /usr/lib/libsqlite3.so /usr/lib/libodbc.so /usr/lib/libodbcinst.so /usr/lib/libltdl.so /usr/lib/libexpat.so -lxerces-c /usr/lib/libjasper.so /usr/lib/libhdf5.so -lmfhdf -ldf /usr/lib/libgif.so /usr/lib/libtiff.so -lc /usr/lib/libjpeg.so -lpng -lnetcdf -lpq -ldl /usr/lib/libcurl-gnutls.so /usr/lib/libidn.so -lldap -lrt -lkrb5 -lk5crypto -lcom_err -lgssapi_krb5 /usr/lib/libgnutls.so /usr/lib/libtasn1.so /lib/libgcrypt.so /usr/lib/libmysqlclient.so -lm -lpthread -lcrypt -lnsl -lz -lruby1.8 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090304/574afb58/attachment.html From ali.guidara at stage.cnes.fr Wed Mar 4 05:19:11 2009 From: ali.guidara at stage.cnes.fr (Guidara Ali) Date: Wed Mar 4 05:26:47 2009 Subject: [gdal-dev] Problem in configuration of gdal Message-ID: Hi, I'm installing OTB on Windows host with cygwin, i have just installed cmake but when i was configuring gdal (version 1.5.2) by the command (./configure --prefix=INSTALL_DIR), an error apprears (cannot create temp file for here document :permission denied). I tried to use the option --without-python but i can't solve the problem, the error presented is (invalid package name: python). Can you help me? Thanks. From wroberts at csir.co.za Wed Mar 4 06:56:45 2009 From: wroberts at csir.co.za (Wesley Roberts) Date: Wed Mar 4 06:57:55 2009 Subject: [gdal-dev] Problem in configuration of gdal Message-ID: <49AE889E020000730001937C@pta-emo.csir.co.za> Dear Ali, I have not used cygwin in ages so cant help with regards to the actual workings around cygwin. One question could help with your problem, do you have write permissions in the folder you are trying to install gdal? I have recently installed OTB on a Linux machine running Ubuntu Hardy Heron and if I want to install in /usr/local/ for example, I need to use the 'sudo' command to get it done. Do you know if their is an equivalent command in cygwin? I dont think your error has anything to do with python, have a good look at your write permissions. HTH Wesley >>> "Guidara Ali" 03/04/09 12:27 PM >>> Hi, I'm installing OTB on Windows host with cygwin, i have just installed cmake but when i was configuring gdal (version 1.5.2) by the command (./configure --prefix=INSTALL_DIR), an error apprears (cannot create temp file for here document :permission denied). I tried to use the option --without-python but i can't solve the problem, the error presented is (invalid package name: python). Can you help me? Thanks. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From gregor.fikoczek at wheregroup.com Wed Mar 4 08:45:20 2009 From: gregor.fikoczek at wheregroup.com (Gregor Fikoczek) Date: Wed Mar 4 08:45:25 2009 Subject: [gdal-dev] SRS-Transformation(DHDN/GK=>ETRS89/UTM) with towgs84 - Accuracy Message-ID: <200903041445.20892.gregor.fikoczek@wheregroup.com> Hi list, i am trying to transform some point (in a gml-file) from DHDN/GK3 - srs to ETRS89/UTM - srs in some diferent ways: some points(gml-File) in start-srs ----------------------------------------------------------------------------------------------------------- Pointnr. | X[m] | Y[m] ----------------------------------------------------------------------------------------------------------- 5216100002 | 2552401,862 | 5616707,524 5414100047 | 2554778,697 | 5614549,001 5508100055 | 2555906,314 | 5608696,986 some points(gml-File) in target-srs ----------------------------------------------------------------------------------------------------------- Punktnr. | East[m] | North[m] ----------------------------------------------------------------------------------------------------------- 5216100002 32340408,033 5617072,487 5414100047 32342695,230 5614819,749 5508100055 32343584,901 5608927,638 1.) using the srs defined in the proj-epsg-File: ogr2ogr -s_srs EPSG:31466 -t_srs EPSG:25832 -f GML points_etrs_gdal.gml points.gml ----------------------------------------------------------------------------------------------------------- Results | difference East[m] | North[m] | E | N | distance ----------------------------------------------------------------------------------------------------------- 340411,269 | 5617068,431 | -3,236 | 4,056 | 5,188 342698,445 | 5614815,708 | -3,215 | 4,041 | 5,164 343588,142 | 5608923,646 | -3,241 | 3,992 | 5,142 2.) using a nadgrid (BETA 2007) ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +k=1.000000 +x_0=2500000 +y_0=0 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext" -t_srs "+proj=utm +ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_BETA2007_gdal.gml points.gml ----------------------------------------------------------------------------------------------------------- Results | difference East[m] | North[m] | E | N | distance ----------------------------------------------------------------------------------------------------------- 340408,064 | 5617072,481 | -0,031 | 0,006 | 0,031 342695,246 | 5614819,723 | -0,016 | 0,026 | 0,031 343584,918 | 5608927,610 | -0,017 | 0,028 | 0,033 3.) using towgs-option (Transform-Parameter) ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 +ellps=bessel +units=m +towgs84=590.1181,99.6226,340.1890,1.185095,-1.334952,-2.904521,1.00001651559" -t_srs "+proj=utm +ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_7P_gdal.gml points.gml ----------------------------------------------------------------------------------------------------------- Results | difference East[m] | North[m] | E | N | distance ----------------------------------------------------------------------------------------------------------- 340408,056 | 5617072,821 | -0,023 | -0,334 | 0,334 342695,237 | 5614820,058 | -0,007 | -0,309 | 0,309 343584,897 | 5608927,933 | 0,004 | -0,295 | 0,295 Parameter: dX +590.1181m dY +99.6226 m dZ +340.1890 m rX +1.185095" rY -1.334952" rZ -2.904521" dm = 1.00001651559 ========= Accuracy: ========= 1.) ~ 5m 2.) ~ 0.033 m 3.) ~ 0.3 m <=== Why so bad ??? The accurancy by using the towgs-option is worse then expected, i was expecting ~ 0.02 m. Aspacielly the difference in North (-0,334, -0,309, -0,295) is remarkable. So maybe an algebraic sign is incorrect or what ever, anybody a suggestion? Best regards, Greg --------------------------------------- WhereGroup GmbH & Co. KG Siemensstra?e 8 53121 Bonn Germany Gregor Fikoczek Email: gregor.fikoczek@wheregroup.com Fon: +49 (0)228 / 90 90 38 - 25 Fax: +49 (0)228 / 90 90 38 - 11 info@wheregroup.com www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplement?rin: WhereGroup Verwaltungs GmbH vertreten durch: Olaf Knopp, Peter Stamm --------------------------------------- From gregor.fikoczek at wheregroup.com Wed Mar 4 09:53:29 2009 From: gregor.fikoczek at wheregroup.com (Gregor Fikoczek) Date: Wed Mar 4 09:53:38 2009 Subject: [gdal-dev] SRS-Transformation(DHDN/GK=>ETRS89/UTM) with towgs84 - Accuracy Message-ID: <200903041553.29995.gregor.fikoczek@wheregroup.com> Hi list, i figured out why the accuracy was so bad using the towgs84-Option: the scaling was not in parts per million indicated wrong scaling-specification: --------------------------------------------- => 1.00001651559 ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 +ellps=bessel +units=m +towgs84=590.1181,99.6226,340.1890,1.185095,-1.334952,-2.904521,1.00001651559" -t_srs "+proj=utm +ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_7P_gdal.gml points.gml right scaling-specification: --------------------------------------------- => 16.51559 (ppm) ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 +ellps=bessel +units=m +towgs84=590.1181,99.6226,340.1890,1.185095,-1.334952,-2.904521,16.51559" -t_srs "+proj=utm +ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_7P_gdal.gml points.gml ----------------------------------------------------------------------------------------------------------- Results | difference East[m] | North[m] | E | N | distance ----------------------------------------------------------------------------------------------------------- 340408,046 5617072,499 -0,013 -0,012 0,018 342695,227 5614819,736 0,003 0,013 0,013 343584,887 5608927,612 0,014 0,026 0,030 ========= Accuracy: ========= ~ 0.3 m Best Regards, Greg >---------- Weitergeleitete Nachricht ---------- > >Betreff: SRS-Transformation(DHDN/GK=>ETRS89/UTM) with towgs84 - Accuracy >Datum: Mittwoch 04 M?rz 2009 >Von: Gregor Fikoczek >An: gdal-dev@lists.osgeo.org > > >Hi list, > >i am trying to transform some point (in a gml-file) from DHDN/GK3 - srs to >ETRS89/UTM - srs in some diferent ways: > > >some points(gml-File) in start-srs >----------------------------------------------------------------------------------------------------------- >Pointnr. | X[m] | Y[m] >----------------------------------------------------------------------------------------------------------- >5216100002 | 2552401,862 | 5616707,524 >5414100047 | 2554778,697 | 5614549,001 >5508100055 | 2555906,314 | 5608696,986 > >some points(gml-File) in target-srs >----------------------------------------------------------------------------------------------------------- >Punktnr. | East[m] | North[m] >----------------------------------------------------------------------------------------------------------- >5216100002 32340408,033 5617072,487 >5414100047 32342695,230 5614819,749 >5508100055 32343584,901 5608927,638 > > >1.) using the srs defined in the proj-epsg-File: > >ogr2ogr -s_srs EPSG:31466 -t_srs EPSG:25832 -f GML points_etrs_gdal.gml >points.gml > >----------------------------------------------------------------------------------------------------------- >Results | difference >East[m] | North[m] | E | N | distance >----------------------------------------------------------------------------------------------------------- >340411,269 | 5617068,431 | -3,236 | 4,056 | 5,188 >342698,445 | 5614815,708 | -3,215 | 4,041 | 5,164 >343588,142 | 5608923,646 | -3,241 | 3,992 | 5,142 > > >2.) using a nadgrid (BETA 2007) > >ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +k=1.000000 +x_0=2500000 +y_0=0 >+ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext" -t_srs "+proj=utm >+ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_BETA2007_gdal.gml >points.gml > >----------------------------------------------------------------------------------------------------------- >Results | difference >East[m] | North[m] | E | N | distance >----------------------------------------------------------------------------------------------------------- >340408,064 | 5617072,481 | -0,031 | 0,006 | 0,031 >342695,246 | 5614819,723 | -0,016 | 0,026 | 0,031 >343584,918 | 5608927,610 | -0,017 | 0,028 | 0,033 > >3.) using towgs-option (Transform-Parameter) > >ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 >+ellps=bessel +units=m >+towgs84=590.1181,99.6226,340.1890,1.185095,-1.334952,-2.904521,1.00001651559" -t_srs "+proj=utm >+ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_7P_gdal.gml points.gml > >----------------------------------------------------------------------------------------------------------- >Results | difference >East[m] | North[m] | E | N | distance >----------------------------------------------------------------------------------------------------------- >340408,056 | 5617072,821 | -0,023 | -0,334 | 0,334 >342695,237 | 5614820,058 | -0,007 | -0,309 | 0,309 >343584,897 | 5608927,933 | 0,004 | -0,295 | 0,295 > > >Parameter: >dX +590.1181m >dY +99.6226 m >dZ +340.1890 m >rX +1.185095" >rY -1.334952" >rZ -2.904521" >dm = 1.00001651559 > > >========= >Accuracy: >========= >1.) ~ 5m >2.) ~ 0.033 m >3.) ~ 0.3 m <=== Why so bad ??? > >The accurancy by using the towgs-option is worse then expected, i was >expecting ~ 0.02 m. Aspacielly the difference in North >(-0,334, -0,309, -0,295) is remarkable. > >So maybe an algebraic sign is incorrect or what ever, anybody a suggestion? > >Best regards, >Greg > --------------------------------------- WhereGroup GmbH & Co. KG Siemensstra?e 8 53121 Bonn Germany Gregor Fikoczek Email: gregor.fikoczek@wheregroup.com Fon: +49 (0)228 / 90 90 38 - 25 Fax: +49 (0)228 / 90 90 38 - 11 info@wheregroup.com www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplement?rin: WhereGroup Verwaltungs GmbH vertreten durch: Olaf Knopp, Peter Stamm --------------------------------------- ------------------------------------------------------- -- Mit freundlichen Gr??en / Kind regards Gregor Fikoczek --------------------------------------- WhereGroup GmbH & Co. KG Siemensstra?e 8 53121 Bonn Germany Gregor Fikoczek Email: gregor.fikoczek@wheregroup.com Fon: +49 (0)228 / 90 90 38 - 25 Fax: +49 (0)228 / 90 90 38 - 11 info@wheregroup.com www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplement?rin: WhereGroup Verwaltungs GmbH vertreten durch: Olaf Knopp, Peter Stamm --------------------------------------- From jrepetto at free.fr Wed Mar 4 09:58:16 2009 From: jrepetto at free.fr (Jean-Claude Repetto) Date: Wed Mar 4 10:25:14 2009 Subject: [gdal-dev] SRS-Transformation(DHDN/GK=>ETRS89/UTM) with towgs84 - Accuracy In-Reply-To: <200903041445.20892.gregor.fikoczek@wheregroup.com> References: <200903041445.20892.gregor.fikoczek@wheregroup.com> Message-ID: <49AE9708.9010606@free.fr> Gregor Fikoczek wrote : > 3.) using towgs-option (Transform-Parameter) > > ogr2ogr -s_srs "+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 > +ellps=bessel +units=m > +towgs84=590.1181,99.6226,340.1890,1.185095,-1.334952,-2.904521,1.00001651559" -t_srs "+proj=utm > +ellps=GRS80 +datum=WGS84 +zone=32" -f GML points_7P_gdal.gml points.gml > > ----------------------------------------------------------------------------------------------------------- > Results | difference > East[m] | North[m] | E | N | distance > ----------------------------------------------------------------------------------------------------------- > 340408,056 | 5617072,821 | -0,023 | -0,334 | 0,334 > 342695,237 | 5614820,058 | -0,007 | -0,309 | 0,309 > 343584,897 | 5608927,933 | 0,004 | -0,295 | 0,295 > > > Parameter: > dX +590.1181m > dY +99.6226 m > dZ +340.1890 m > rX +1.185095" > rY -1.334952" > rZ -2.904521" > dm = 1.00001651559 > > Hello, Where did you find these parameters ? The EPSG database gives these ones : dX 598.1 dY 73.7 dZ 418.2 rX 0.202 rY 0.045 rZ -2.455 dm 6.7 Regards, Jean-Claude From bryan at ideotrope.org Wed Mar 4 10:27:22 2009 From: bryan at ideotrope.org (Bryan Keith) Date: Wed Mar 4 10:27:25 2009 Subject: [gdal-dev] how to find gdal_fillnodata In-Reply-To: <2627.64.78.232.178.1234907025.squirrel@ideotrope.org> References: <1983.64.78.232.178.1233159071.squirrel@ideotrope.org> <49809298.8030007@pobox.com> <2627.64.78.232.178.1234907025.squirrel@ideotrope.org> Message-ID: <2192.64.78.232.178.1236180442.squirrel@ideotrope.org> Hello, See below. I'm sending this again since I still don't have the issue resolved. Bryan >> Bryan Keith wrote: >>> Hello, >>> >>> I combined two DEM datasets with gdal_merge, and there's a broken strip >>> of >>> nodata between the two. What gdal utility can I use to fix this? I >>> found >>> references to gdal_fillnodata on the web, but I don't have it. I >>> installed FWTools 2.2.8 on windows, but that doesn't seem to include >>> gdal_fillnodata either. On Linux I have GDAL 1.4.4.0, released >>> 2007/11/23. I looked at the source code (from the daily svn snapshot), >>> and it looks I need gdal.FillNoData but that's not part of the bindings >>> that I have on either Windows or Linux. How can I get this utility or >>> is >>> there another utility that I can use? >> >> Bryan, >> >> This utility only exists in the most recent builds from trunk. I see it >> was not in FWTools 2.3.0, but it is in the gdal-dev package of OSGeo4W. >> On linux you could build from svn with python support and you should >> have >> it. >> > > Frank, > > I installed OSGeo4W this afternoon. I had to do a little futzing to get > python to work with gdal-dev (change the windows %path% variable and > change the Python sys.path list). However, when I run gdal_fillnodata, I > end up with a tif that has all 0s. What am I doing wrong? Commands are > pasted below. > > Bryan > > C:\Projects>gdalinfo dem.tif -stats > Driver: GTiff/GeoTIFF > Files: dem.tif > Size is 2200, 1411 > Coordinate System is: > Origin = (1749100.677571530000000,304762.295903306220000) > Pixel Size = (32.820441700754138,-32.820441700754138) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( 1749100.678, 304762.296) (122d52'36.09"W, 38d30'0.63"N) > Lower Left ( 1749100.678, 258452.653) (122d52'30.48"W, 38d22'22.86"N) > Upper Right ( 1821305.649, 304762.296) (122d37'27.85"W, 38d30'6.53"N) > Lower Right ( 1821305.649, 258452.653) (122d37'23.86"W, 38d22'28.75"N) > Center ( 1785203.163, 281607.474) (122d44'59.57"W, 38d26'14.94"N) > Band 1 Block=2200x1 Type=Float32, ColorInterp=Gray > Minimum=10.000, Maximum=563.300, Mean=78.248, StdDev=78.791 > NoData Value=-32766 > Metadata: > STATISTICS_MINIMUM=10 > STATISTICS_MAXIMUM=563.29998779297 > STATISTICS_MEAN=78.248205065279 > STATISTICS_STDDEV=78.791386753552 > > C:\Projects>\OSGeo4W\apps\gdal-dev\bin\gdal_fillnodata.bat dem.tif > dem_nnd.tif > 0...10...20...30...40...50...60...70...80...90...100 - done. > > C:\Projects>gdalinfo dem_nnd.tif -stats > Driver: GTiff/GeoTIFF > Files: dem_nnd.tif > Size is 2200, 1411 > Coordinate System is: > Origin = (1749100.677571530000000,304762.295903306220000) > Pixel Size = (32.820441700754138,-32.820441700754138) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( 1749100.678, 304762.296) (122d52'36.09"W, 38d30'0.63"N) > Lower Left ( 1749100.678, 258452.653) (122d52'30.48"W, 38d22'22.86"N) > Upper Right ( 1821305.649, 304762.296) (122d37'27.85"W, 38d30'6.53"N) > Lower Right ( 1821305.649, 258452.653) (122d37'23.86"W, 38d22'28.75"N) > Center ( 1785203.163, 281607.474) (122d44'59.57"W, 38d26'14.94"N) > Band 1 Block=2200x1 Type=Float32, ColorInterp=Gray > Minimum=0.000, Maximum=0.000, Mean=0.000, StdDev=0.000 > Metadata: > STATISTICS_MINIMUM=0 > STATISTICS_MAXIMUM=0 > STATISTICS_MEAN=0 > STATISTICS_STDDEV=0 > > C:\Projects> > From jasonbeverage at gmail.com Wed Mar 4 11:05:32 2009 From: jasonbeverage at gmail.com (Jason Beverage) Date: Wed Mar 4 11:05:35 2009 Subject: [gdal-dev] Transparency using gdalbuildvrt Message-ID: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> Hi all, I've been playing around with gdalbuildvrt lately and it has proven to be a very useful tool:) What I'm attempting to do is take multiple RGB images and treat them as a single image using the VRT. This works great, but since the images are RGB, areas where there is no data are coming back as black. Is there a way that I can modify the VRT or the code to treat the VRT as an RGBA dataset and somehow say "If there is no data in any bands, the alpha is 0"? Thanks! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090304/34027017/attachment.html From warmerdam at pobox.com Wed Mar 4 11:11:07 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 4 11:11:35 2009 Subject: [gdal-dev] Transparency using gdalbuildvrt In-Reply-To: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> References: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> Message-ID: <49AEA81B.8060808@pobox.com> Jason Beverage wrote: > Hi all, > > I've been playing around with gdalbuildvrt lately and it has proven to > be a very useful tool:) > > What I'm attempting to do is take multiple RGB images and treat them as > a single image using the VRT. This works great, but since the images > are RGB, areas where there is no data are coming back as black. Is > there a way that I can modify the VRT or the code to treat the VRT as an > RGBA dataset and somehow say "If there is no data in any bands, the > alpha is 0"? Jason, It looks like if there is a nodata value set on the bands in the VRT, this value will be used in nodata areas. So it should be possible to set the otherwise unset areas to be white for instance. However, I am not aware of any way to have an alpha band that would be opaque in areas of data and transparent in areas of nodata if the source images are RGB (not RGBA). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From Shawn.Gong at drdc-rddc.gc.ca Wed Mar 4 12:01:23 2009 From: Shawn.Gong at drdc-rddc.gc.ca (Gong, Shawn (Contractor)) Date: Wed Mar 4 12:03:00 2009 Subject: [gdal-dev] TIFFReadEncodedTile() failed error Message-ID: hi list, I am using gdal 1.6.0 on windows that I built a few months ago. When I opened RSAT2 image with OpenEV I got: ERROR 1: IReadBlock failed at X offset 3, Y offset 6 ERROR 1: GetBlockRef failed at X block offset 3, Y block offset 6 ERROR 1: TIFFFillTile:Read error at row 256, col 1536; got 0 bytes, expected 655 36 ERROR 1: TIFFReadEncodedTile() failed. ERROR 1: IReadBlock failed at X offset 3, Y offset 6 ... ... ... ... More than 1000 errors or warnings have been reported. No more will be reported f rom now. Was that bug fixed in 1.4.4? thanks, Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090304/951fd314/attachment.html From warmerdam at pobox.com Wed Mar 4 12:23:51 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 4 12:24:13 2009 Subject: [gdal-dev] TIFFReadEncodedTile() failed error In-Reply-To: References: Message-ID: <49AEB927.5030204@pobox.com> Gong, Shawn (Contractor) wrote: > hi list, > > I am using gdal 1.6.0 on windows that I built a few months ago. > > When I opened RSAT2 image with OpenEV I got: ... > ERROR 1: TIFFFillTile:Read error at row 256, col 1536; got 0 > bytes, expected 655 ... > Was that bug fixed in 1.4.4? Shawn, Unfortunately, this could be quite a number of different issues, such as a truncated file. It is hard to given meaningful feedback without the file to examine more closely or perhaps a tiffinfo & tiffdump report on it. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ASP at blominfo.dk Wed Mar 4 12:47:05 2009 From: ASP at blominfo.dk (Asger Sigurd Skovbo Petersen) Date: Wed Mar 4 12:47:08 2009 Subject: [gdal-dev] Blocks of data missing when using gdalwarp Message-ID: <25BE68A4D83DD4438F701DF0311F3F4A98538A@posthus.blominfo.dk> Hi list, I have a setup for transforming a large quantity of raster tiles from utm into spherical mercator. The setup is like: ------------------- // This first step has some rather unimportant explanations foreach SourceFile.tif { ?gdal_translate -of vrt SourceFile.tif SourceFile.vrt } gdalbuildvrt SourceMosiac.vrt SourceFile*.vrt foreach outputtile { ?gdalwarp -te tilebounds -of gtiff -co tiled=yes -co interleave=band -t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs" -r cubic -wm 100 SourceMosaic.vrt outputtile.tif } ----------------------- This _almost_ works as a dream. The only problem is that the warped tif tiles have some very systematic blocks of black pixels which suspiciously look like warp errors. They are definitely not in the input data. The blocks are strictly rectangular and they are found in patterns that are very much alike from outputtile to outputtile. Please see attached jpg file for an example. Has anyone seen this before and are there any ways to work around this weird effect? Best regards Asger -------------- next part -------------- A non-text attachment was scrubbed... Name: 1013000_7369000_1016500_7372500.jpg Type: image/jpeg Size: 16099 bytes Desc: 1013000_7369000_1016500_7372500.jpg Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090304/5a274ba4/1013000_7369000_1016500_7372500-0001.jpg From chaitanya.ch at gmail.com Wed Mar 4 12:59:06 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Wed Mar 4 12:59:11 2009 Subject: [gdal-dev] Blocks of data missing when using gdalwarp In-Reply-To: <25BE68A4D83DD4438F701DF0311F3F4A98538A@posthus.blominfo.dk> References: <25BE68A4D83DD4438F701DF0311F3F4A98538A@posthus.blominfo.dk> Message-ID: Asger, Can you provide the source tif files to reproduce the problem? Regards, -- Chaitanya kumar CH. On Wed, Mar 4, 2009 at 11:17 PM, Asger Sigurd Skovbo Petersen wrote: > Hi list, > > I have a setup for transforming a large quantity of raster tiles from utm into spherical mercator. The setup is like: > > ------------------- > > // This first step has some rather unimportant explanations foreach SourceFile.tif { > ?gdal_translate -of vrt SourceFile.tif SourceFile.vrt } > > gdalbuildvrt SourceMosiac.vrt SourceFile*.vrt > > foreach outputtile > { > ?gdalwarp -te tilebounds -of gtiff -co tiled=yes -co interleave=band > ? ? ? ?-t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 > ? ? ? ?+x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs" -r cubic -wm > ? ? ? ?100 SourceMosaic.vrt outputtile.tif > } > > ----------------------- > > This _almost_ works as a dream. The only problem is that the warped tif tiles have some very systematic blocks of black pixels which suspiciously look like warp errors. They are definitely not in the input data. The blocks are strictly rectangular and they are found in patterns that are very much alike from outputtile to outputtile. > Please see attached jpg file for an example. > > Has anyone seen this before and are there any ways to work around this weird effect? > > Best regards > Asger > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From ASP at blominfo.dk Wed Mar 4 13:28:40 2009 From: ASP at blominfo.dk (Asger Sigurd Skovbo Petersen) Date: Wed Mar 4 13:28:38 2009 Subject: [gdal-dev] Blocks of data missing when using gdalwarp Message-ID: <003e01c99cf7$0835fe82$0b0111ac@Blominfo.local> Hi Chaitanya, I'll compile a subset first thing Thursday morning european time. Regards Asger -----Original Message----- From: "Chaitanya kumar CH" To: "Asger Sigurd Skovbo Petersen" Cc: "gdal-dev@lists.osgeo.org" Sent: 04-03-2009 18:59 Subject: Re: [gdal-dev] Blocks of data missing when using gdalwarp Asger, Can you provide the source tif files to reproduce the problem? Regards, -- Chaitanya kumar CH. On Wed, Mar 4, 2009 at 11:17 PM, Asger Sigurd Skovbo Petersen wrote: > Hi list, > > I have a setup for transforming a large quantity of raster tiles from utm into spherical mercator. The setup is like: > > ------------------- > > // This first step has some rather unimportant explanations foreach SourceFile.tif { > gdal_translate -of vrt SourceFile.tif SourceFile.vrt } > > gdalbuildvrt SourceMosiac.vrt SourceFile*.vrt > > foreach outputtile > { > gdalwarp -te tilebounds -of gtiff -co tiled=yes -co interleave=band > -t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 > +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs" -r cubic -wm > 100 SourceMosaic.vrt outputtile.tif > } > > ----------------------- > > This _almost_ works as a dream. The only problem is that the warped tif tiles have some very systematic blocks of black pixels which suspiciously look like warp errors. They are definitely not in the input data. The blocks are strictly rectangular and they are found in patterns that are very much alike from outputtile to outputtile. > Please see attached jpg file for an example. > > Has anyone seen this before and are there any ways to work around this weird effect? > > Best regards > Asger > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From mateusz at loskot.net Wed Mar 4 18:48:27 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed Mar 4 18:48:32 2009 Subject: [gdal-dev] [Fwd: [postgis-devel] WKT Raster: GDAL or World file upper left coordinates] Message-ID: <49AF134B.6030509@loskot.net> Hi, I'm forwarding Pierre's post sent to PostGIS list about handling georeferencing in WKT Raster. This is also related to GDAL, as Pierre asks about GDAL. Perhaps someone could help to explain it. -------- Original Message -------- Subject: [postgis-devel] WKT Raster: GDAL or World file upper left coordinates Date: Wed, 4 Mar 2009 18:10:12 -0500 From: Pierre Racine Reply-To: PostGIS Development Discussion To: PostGIS Development Discussion gdal2wktraster.py stores the GDAL version of the upper left corner coordinate. This seems to be the real (or external) upper left corner. World files (and WKT Raster) stores the "center" of the upper left pixel which is not the same thing. rt_raster_envelope(raster) was implemented this way. It add half of a pixelsize to get the BBOX of the raster. So now it returns an envelop a bit too big. We'll have to decide if we stick to GDAL specs or to World file specs. Why does GDAL does not stick to the Word File specs? What are the pros and cons of one way over the other? Pierre _______________________________________________ postgis-devel mailing list postgis-devel@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-devel -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From randre at gmail.com Thu Mar 5 01:40:18 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Thu Mar 5 01:40:21 2009 Subject: [gdal-dev] NetCDF data upside down when read by gdal In-Reply-To: References: <9c2015090902181245s7868f9f1s632748e9730eaaf3@mail.gmail.com> Message-ID: <9c2015090903042240i27b0b52t994b2cb41985429c@mail.gmail.com> Hi Shawn, Just wanted to follow up and let you know that the patch you sent me seems to work very well. gdal-based conversions of CF convention netCDF files are now properly oriented on the Y axis. Thanks again for sending me the files, Roger -- Thanks again for sending it to me. Roger -- On Fri, Feb 20, 2009 at 8:32 AM, Gong, Shawn (Contractor) wrote: > hi Roger, > > > > Here are cpp and h files that I modified to flip netCDF images. > > They are in ..\gdal-1.6.0\frmts\netcdf\ > > > > hope that they help, > Shawn > > > > ________________________________ > > From: gdal-dev-bounces@lists.osgeo.org > [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Roger Andr? > Sent: Wednesday, February 18, 2009 3:45 PM > To: gdal-dev > Subject: [gdal-dev] NetCDF data upside down when read by gdal > > > > Hi All, > > - I am attempting to use a NetCDF file as a data source for a raster layer > in Mapserver.? According to a very useful email sent in November 2005 from > Norman Barker, > http://lists.osgeo.org/pipermail/mapserver-users/2005-November/012153.html, > and from Mapserver documentation at > http://www.mapserver.org/ogc/wcs_format.html#netcdf, it seems like this > should be possible using Mapserver's gdal driver to read the file.? However, > I am running into some problems when trying to implement these examples > using GDAL 1.5.2, released 2008/05/29. > > - The NetCDF file which I am using to test with is a "CF Convention" sample > file which I downloaded from > http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc. > This file contains information about sea-surface temperatures, and when > viewed by gdalinfo has the following characteristics: > > $ gdalinfo tos_O1_2001-2002.nc > Driver: netCDF/Network Common Data Format > Files: tos_O1_2001-2002.nc > Size is 512, 512 > Coordinate System is `' > Metadata: > ? NC_GLOBAL#title=IPSL? model output prepared for IPCC Fourth Assessment > SRES A2 experiment > ? NC_GLOBAL#institution=IPSL (Institut Pierre Simon Laplace, Paris, France) > ? NC_GLOBAL#source=IPSL-CM4_v1 (2003) : atmosphere : LMDZ (IPSL-CM4_IPCC, > 96x71x19) ; ocean ORCA2 (ipsl_cm4_v1_8, 2x2L31); sea ice LIM (ipsl_cm4_v > ? NC_GLOBAL#contact=Sebastien Denvil, sebastien.denvil@ipsl.jussieu.fr > ? NC_GLOBAL#project_id=IPCC Fourth Assessment > ? NC_GLOBAL#table_id=Table O1 (13 November 2004) > ? NC_GLOBAL#experiment_id=SRES A2 experiment > ? NC_GLOBAL#realization=1 > ? NC_GLOBAL#cmor_version=9.600000e-01 > ? NC_GLOBAL#Conventions=CF-1.0 > ? NC_GLOBAL#history=YYYY/MM/JJ: data generated; YYYY/MM/JJ+1 data > transformed? At 16:37:23 on 01/11/2005, CMOR rewrote data to comply with CF > standards and IPCC Fourth Assessment requirements > ? NC_GLOBAL#references=Dufresne et al, Journal of Climate, 2015, vol XX, p > 136 > ? NC_GLOBAL#comment=Test drive > Subdatasets: > ? SUBDATASET_1_NAME=NETCDF:"tos_O1_2001-2002.nc":lon_bnds > ? SUBDATASET_1_DESC=[180x2] lon_bnds (64-bit floating-point) > ? SUBDATASET_2_NAME=NETCDF:"tos_O1_2001-2002.nc":lat_bnds > ? SUBDATASET_2_DESC=[170x2] lat_bnds (64-bit floating-point) > ? SUBDATASET_3_NAME=NETCDF:"tos_O1_2001-2002.nc":time_bnds > ? SUBDATASET_3_DESC=[24x2] time_bnds (64-bit floating-point) > ? SUBDATASET_4_NAME=NETCDF:"tos_O1_2001-2002.nc":tos > ? SUBDATASET_4_DESC=[24x170x180] sea_surface_temperature (32-bit > floating-point) > Corner Coordinates: > Upper Left? (??? 0.0,??? 0.0) > Lower Left? (??? 0.0,? 512.0) > Upper Right (? 512.0,??? 0.0) > Lower Right (? 512.0,? 512.0) > Center????? (? 256.0,? 256.0) > > - The SUBDATASET of interest is the "tos" one, and when queried by gdalinfo > it shows that it contains 24 bands, each of which varies by > NETCDF_DIMENSION_time that increments by 15.? When specifically queried by > gdalinfo, this SUBDATASET looks like this: > > $ gdalinfo NETCDF:"tos_O1_2001-2002.nc":tos > Driver: netCDF/Network Common Data Format > Files: none associated > Size is 180, 170 > Coordinate System is `' > Origin = (0.000000000000000,90.000000000000000) > Pixel Size = (2.000000000000000,-1.000000000000000) > Metadata: > ? NC_GLOBAL#title=IPSL? model output prepared for IPCC Fourth Assessment > SRES A2 experiment > ? NC_GLOBAL#institution=IPSL (Institut Pierre Simon Laplace, Paris, France) > ? NC_GLOBAL#source=IPSL-CM4_v1 (2003) : atmosphere : LMDZ (IPSL-CM4_IPCC, > 96x71x19) ; ocean ORCA2 (ipsl_cm4_v1_8, 2x2L31); sea ice LIM (ipsl_cm4_v > ? NC_GLOBAL#contact=Sebastien Denvil, sebastien.denvil@ipsl.jussieu.fr > ? NC_GLOBAL#project_id=IPCC Fourth Assessment > ? NC_GLOBAL#table_id=Table O1 (13 November 2004) > ? NC_GLOBAL#experiment_id=SRES A2 experiment > ? NC_GLOBAL#realization=1 > ? NC_GLOBAL#cmor_version=9.600000e-01 > ? NC_GLOBAL#Conventions=CF-1.0 > ? NC_GLOBAL#history=YYYY/MM/JJ: data generated; YYYY/MM/JJ+1 data > transformed? At 16:37:23 on 01/11/2005, CMOR rewrote data to comply with CF > standards and IPCC Fourth Assessment requirements > ? NC_GLOBAL#references=Dufresne et al, Journal of Climate, 2015, vol XX, p > 136 > ? NC_GLOBAL#comment=Test drive > ? tos#standard_name=sea_surface_temperature > ? tos#long_name=Sea Surface Temperature > ? tos#units=K > ? tos#cell_methods=time: mean (interval: 30 minutes) > ? tos#_FillValue=1.000000e+20 > ? tos#missing_value=1.000000e+20 > ? tos#original_name=sosstsst > ? tos#original_units=degC > ? tos#history= At?? 16:37:23 on 01/11/2005: CMOR altered the data in the > following ways: added 2.73150E+02 to yield output units;? Cyclical dimension > was output starting at a different lon; > ? lon#standard_name=longitude > ? lon#long_name=longitude > ? lon#units=degrees_east > ? lon#axis=X > ? lon#bounds=lon_bnds > ? lon#original_units=degrees_east > ? lat#standard_name=latitude > ? lat#long_name=latitude > ? lat#units=degrees_north > ? lat#axis=Y > ? lat#bounds=lat_bnds > ? lat#original_units=degrees_north > ? time#standard_name=time > ? time#long_name=time > ? time#units=days since 2001-1-1 > ? time#axis=T > ? time#calendar=360_day > ? time#bounds=time_bnds > ? time#original_units=seconds since 2001-1-1 > Corner Coordinates: > Upper Left? (?? 0.0000000,? 90.0000000) > Lower Left? (?? 0.0000000, -80.0000000) > Upper Right (???? 360.000,????? 90.000) > Lower Right (???? 360.000,???? -80.000) > Center????? ( 180.0000000,?? 5.0000000) > Band 1 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=15 > ??? NETCDF_time_units=days since 2001-1-1 > Band 2 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=45 > ??? NETCDF_time_units=days since 2001-1-1 > Band 3 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=75 > ??? NETCDF_time_units=days since 2001-1-1 > Band 4 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=105 > ??? NETCDF_time_units=days since 2001-1-1 > Band 5 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=135 > ??? NETCDF_time_units=days since 2001-1-1 > Band 6 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=165 > ??? NETCDF_time_units=days since 2001-1-1 > Band 7 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=195 > ??? NETCDF_time_units=days since 2001-1-1 > Band 8 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=225 > ??? NETCDF_time_units=days since 2001-1-1 > Band 9 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=255 > ??? NETCDF_time_units=days since 2001-1-1 > Band 10 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=285 > ??? NETCDF_time_units=days since 2001-1-1 > Band 11 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=315 > ??? NETCDF_time_units=days since 2001-1-1 > Band 12 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=345 > ??? NETCDF_time_units=days since 2001-1-1 > Band 13 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=375 > ??? NETCDF_time_units=days since 2001-1-1 > Band 14 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=405 > ??? NETCDF_time_units=days since 2001-1-1 > Band 15 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=435 > ??? NETCDF_time_units=days since 2001-1-1 > Band 16 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=465 > ??? NETCDF_time_units=days since 2001-1-1 > Band 17 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=495 > ??? NETCDF_time_units=days since 2001-1-1 > Band 18 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=525 > ??? NETCDF_time_units=days since 2001-1-1 > Band 19 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=555 > ??? NETCDF_time_units=days since 2001-1-1 > Band 20 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=585 > ??? NETCDF_time_units=days since 2001-1-1 > Band 21 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=615 > ??? NETCDF_time_units=days since 2001-1-1 > Band 22 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=645 > ??? NETCDF_time_units=days since 2001-1-1 > Band 23 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=675 > ??? NETCDF_time_units=days since 2001-1-1 > Band 24 Block=180x1 Type=Float32, ColorInterp=Undefined > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=705 > ??? NETCDF_time_units=days since 2001-1-1 > > - I am able to test that I can extract one of these bands with GDAL, and > convert it to GeoTIFF with the following command: > gdal_translate -b 1 NETCDF:"tos_O1_2001-2002.nc":tos sea_temp_band_1.tif. > Here however is where the first problem appears.? As you can see from the > screenshot of the sea_temp_band_1.tif that I've posted at > http://2.bp.blogspot.com/_-yICqdt0mtY/SZxtI4yUHdI/AAAAAAAAA-I/z7W_O6qBXho/s1600-h/upside_down_netcdf.jpg, > the data in the file appears to be represented upside down.? Since this file > is a sample from the Unidata web site, I'm reasonably confident that the > file follows the CF convention.? Every NetCDF file I have tried to read with > GDAL has had this problem, including ones that I have created with > gdal_translate.? As you can see from the gdalinfo output above, the > georeferencing and pixel dimensions seem to be reasonable.? In the past I > have used flip_raster.py to "fix" this, and created an intermediary > GeoTIFF.? Now that I would like to use the NetCDF itself as the data source > to feed a WCS service, this is no longer an acceptable solution.? Of > interest though, is that the georeferencing info between the flipped and > unflipped files are exactly the same.? See below: > > - Flipped file: > --------------- > $ gdalinfo flipped_sea_temp_band_1.tif > Driver: GTiff/GeoTIFF > Files: flipped_sea_temp_band_1.tif > Size is 180, 170 > Coordinate System is `' > Origin = (0.000000000000000,90.000000000000000) > Pixel Size = (2.000000000000000,-1.000000000000000) > Image Structure Metadata: > ? INTERLEAVE=BAND > Corner Coordinates: > Upper Left? (?? 0.0000000,? 90.0000000) > Lower Left? (?? 0.0000000, -80.0000000) > Upper Right (???? 360.000,????? 90.000) > Lower Right (???? 360.000,???? -80.000) > Center????? ( 180.0000000,?? 5.0000000) > Band 1 Block=180x11 Type=Float32, ColorInterp=Gray > > - Unflipped file: > ----------------- > $ gdalinfo sea_temp_band_1.tif > Driver: GTiff/GeoTIFF > Files: sea_temp_band_1.tif > Size is 180, 170 > Coordinate System is `' > Origin = (0.000000000000000,90.000000000000000) > Pixel Size = (2.000000000000000,-1.000000000000000) > (Metadata removed for clarity) > Image Structure Metadata: > ? INTERLEAVE=BAND > Corner Coordinates: > Upper Left? (?? 0.0000000,? 90.0000000) > Lower Left? (?? 0.0000000, -80.0000000) > Upper Right (???? 360.000,????? 90.000) > Lower Right (???? 360.000,???? -80.000) > Center????? ( 180.0000000,?? 5.0000000) > Band 1 Block=180x11 Type=Float32, ColorInterp=Gray > ? NoData Value=1.00000002004087734e+20 > ? Metadata: > ??? NETCDF_VARNAME=tos > ??? NETCDF_DIMENSION_time=15 > ??? NETCDF_time_units=days since 2001-1-1 > > - I'm unsure if this is a bug in GDAL, or an incorrectly formatted NetCDF > file.? So, would it be possible for someone who has a NetCDF file that is > read? "right-side-up" to post it as a sample for me to test with? > > Thanks in advance, > > Roger From antonio.valentino at tiscali.it Thu Mar 5 08:53:25 2009 From: antonio.valentino at tiscali.it (Antonio Valentino) Date: Thu Mar 5 08:54:39 2009 Subject: [gdal-dev] Creating derived raster bands using python Message-ID: <20090305145325.18b43c8c@valentinows> Hi list, I'm trying to create a *Derived* raster band in a virtual dataset. All my attempts seems to fail: >>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) raises an exception while >>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') >>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) give a wrong result: $ cat test.vrt Where is the mistake? Thanks -- Antonio Valentino From warmerdam at pobox.com Thu Mar 5 09:26:51 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 5 09:27:15 2009 Subject: [gdal-dev] Creating derived raster bands using python In-Reply-To: <20090305145325.18b43c8c@valentinows> References: <20090305145325.18b43c8c@valentinows> Message-ID: <49AFE12B.2090601@pobox.com> Antonio Valentino wrote: > Hi list, > I'm trying to create a *Derived* raster band in a virtual dataset. > > All my attempts seems to fail: > >>>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) > > raises an exception while > >>>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') >>>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) Antonio, I believe the correct syntax is: ds.AddBand(options=['subClass=VRTDerivedRasterBand']) The options should be a list of name=value pairs. Your extra double quotes within the string will make the class name comparison fail since you are effectively passing "\"VRTDerivedRasterBand\"" in C terms. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ivan.lucena at pmldnet.com Thu Mar 5 10:12:26 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Thu Mar 5 10:12:27 2009 Subject: [gdal-dev] Bigtiff question Message-ID: <20090305151226.3019.qmail@s466.sureserver.com> Hi there, I am running a Python script that goes through a relatively large number of single band raster files (320) and aggregates it in a big-geotiff (around 7Gb) and I am facing three basic problems *poor performance*, *wrong results*" and *lost of metadata*. I need that geotiff to be interleaved by pixel since the goal is to query for historical values in a given location and return then in the best response time possible. So I am using this create options: -- driver_tif = gdal.GetDriverByName("GTIFF") output_dst = driver_tif.Create( output_tif, x_size, y_size, serie_count, data_type, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) -- I also need to add custom metadata entries to the dataset and to the individuals bands so that we know their data stamps. That is how I loop to all the files and copy then to the output big-geotiff file: -- gdal.SetCacheMax(500) count = 1 for i in list_tsf: input_dst = gdal.Open( f ) input_band = input_dst.GetRasterBand( 1 ) output_band = output_dst.GetRasterBand( count ) output_band.WriteRaster( 0, 0, x_size, y_size, input_band.ReadRaster( 0, 0, x_size, y_size ) ) output_band.FlushCache() count = count + 1 -- *Performance*: The process takes more than 6 hours. (Wrong Results*: All the pixels are zero (0) If I just change the script on 'INTERLEAVE=PIXEL' to 'INTERLEAVE=BAND' the whole process takes around 30 minutes. I can then use gdal_translate to convert from GTIFF to GTIFF with -co 'INTERLEAVE=PIXEL'. That takes another 30 minutes. *Lost Metadata*: That looks like a solution except that I will then loose all my custom metadata entries. Does anybody have any idea to improve that process. Thanks is advance, Ivan From warmerdam at pobox.com Thu Mar 5 10:37:58 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 5 10:38:23 2009 Subject: [gdal-dev] Bigtiff question In-Reply-To: <20090305151226.3019.qmail@s466.sureserver.com> References: <20090305151226.3019.qmail@s466.sureserver.com> Message-ID: <49AFF1D6.1040106@pobox.com> Lucena, Ivan wrote: > Hi there, > > I am running a Python script that goes through a relatively large number of > single band raster files (320) and aggregates it in a big-geotiff (around > 7Gb) and I am facing three basic problems *poor performance*, *wrong > results*" and *lost of metadata*. > > I need that geotiff to be interleaved by pixel since the goal is to query > for historical values in a given location and return then in the best > response time possible. > > So I am using this create options: ... > I also need to add custom metadata entries to the dataset and to the > individuals bands so that we know their data stamps. > > That is how I loop to all the files and copy then to the output big-geotiff > file: > > -- > gdal.SetCacheMax(500) > count = 1 > for i in list_tsf: > input_dst = gdal.Open( f ) > input_band = input_dst.GetRasterBand( 1 ) > output_band = output_dst.GetRasterBand( count ) > output_band.WriteRaster( 0, 0, x_size, y_size, input_band.ReadRaster( 0, 0, x_size, y_size ) ) > output_band.FlushCache() > count = count + 1 > -- > > *Performance*: The process takes more than 6 hours. Ivan, I'm not surprised that the performance sucks. Doing random reads and writes to a pixel interleaved file is triggering a great deal of extra data movement. > (Wrong Results*: All the pixels are zero (0) > > If I just change the script on 'INTERLEAVE=PIXEL' to 'INTERLEAVE=BAND' the > whole process takes around 30 minutes. OK, it sounds like the pixels all being zero is a bug, and it would be good to file a ticket demonstrating this problem. Hopefully a somewhat minimalist example of the problem. > I can then use gdal_translate to convert from GTIFF to GTIFF with -co > 'INTERLEAVE=PIXEL'. That takes another 30 minutes. > > *Lost Metadata*: That looks like a solution except that I will then loose > all my custom metadata entries. Are your custom metadata values in a non-default domain? If so they will not be copied by default, and you would need to add something in the script to copy them after gdal_translate (or driver.CreateCopy()). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ivan.lucena at pmldnet.com Thu Mar 5 11:43:41 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Thu Mar 5 11:43:43 2009 Subject: =?utf-8?B?UmU6IFtnZGFsLWRldl0gQmlndGlmZiBxdWVzdGlvbg==?= Message-ID: <20090305164341.8814.qmail@s466.sureserver.com> Frank, > > I am running a Python script that goes through a relatively large number of > > single band raster files (320) and aggregates it in a big-geotiff (around > > 7Gb) and I am facing three basic problems *poor performance*, *wrong > > results*" and *lost of metadata*. > > > Ivan, > > I'm not surprised that the performance sucks.??Doing > random reads and writes to a pixel interleaved file is > triggering a great deal of extra data movement. > Yes, that runs a lot of seek's to writes just few bytes here and there. I am wondering what the geotiff driver could do to improve that; keeping tiles in memory until they are filled up for writing at once for example (?) BTW, would make any difference if tile the geotiff? In that case what would be the blockxsize, blockysize recommended for 320 bands interleaved by PIXEL? > OK, it sounds like the pixels all being zero is a bug, and > it would be good to file a ticket demonstrating this problem. > Hopefully a somewhat minimalist example of the problem. I think it would be very hard so send data samples so I would suggest running a script that creates fake raster bands with all pixels as 1 on band 1, 2 on band 2, etc. Something like that perhaps: -- driver_tif = gdal.GetDriverByName("GTIFF") output_dst = driver_tif.Create( output_tif, x_size, y_size, serie_count, data_type, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) for i in range(320): output_band = output_dst.GetRasterBand( 1 + 1 ) output_band.Fill(i + 1) output_band.FlushCache() -- > > *Lost Metadata*: That looks like a solution except that I will then loose > > all my custom metadata entries. > > Are your custom metadata values in a non-default > domain???If so they will not be copied by default, > and you would need to add something in the script > to copy them after gdal_translate (or driver.CreateCopy()). That makes sense too. Thanks. Best regards, Ivan From warmerdam at pobox.com Thu Mar 5 12:07:43 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 5 12:08:06 2009 Subject: [gdal-dev] Bigtiff question In-Reply-To: <20090305164341.8814.qmail@s466.sureserver.com> References: <20090305164341.8814.qmail@s466.sureserver.com> Message-ID: <49B006DF.1010706@pobox.com> Lucena, Ivan wrote: > Yes, that runs a lot of seek's to writes just few bytes here and there. Ivan, I would note that for pixel interleaved data, access is still a whole strip/tile at a time which in your case likely means a whole scanline. In no case does GDAL's GTiff driver seek along to update individual bytes in a pixel interleaved scanline or tile. > I am wondering what the geotiff driver could do to improve that; keeping tiles in memory until they are filled up for > writing at once for example (?) GDAL will cache the blocks on a band-by-band basis (at a level where it doesn't realize the underlying datastore is pixel interleaved). The actual block flushing code in the GTIFF driver does ensure that all the cache data for all bands is assembled and written at once if available. So if you had a big enough block cache - or if you wrote all bands for a given scanline at approximately the same time - then only one write to disk would take place for each block. But because you write "all of the first band", then all of the second band and so on, you are basically triggering cache writes often and preventing GDAL from doing things intelligently. > BTW, would make any difference if tile the geotiff? In that case what would be the blockxsize, blockysize recommended for 320 bands interleaved by PIXEL? I do not anticipate this would make much difference. As noted, the key factors affecting performance are block cache size, and the order you write data. >> OK, it sounds like the pixels all being zero is a bug, and >> it would be good to file a ticket demonstrating this problem. >> Hopefully a somewhat minimalist example of the problem. > > I think it would be very hard so send data samples so I would suggest running a script that creates fake raster bands > with all pixels as 1 on band 1, 2 on band 2, etc. Something like that perhaps: > > -- > driver_tif = gdal.GetDriverByName("GTIFF") > output_dst = driver_tif.Create( output_tif, x_size, y_size, serie_count, data_type, > [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > for i in range(320): > output_band = output_dst.GetRasterBand( 1 + 1 ) > output_band.Fill(i + 1) > output_band.FlushCache() > -- Well, please develop such a script, confirm it reproduces the bug (ideally with a well known binary version of GDAL like the OSGeo4W package) and then file the bug accordingly. You might want to check if it really needs a lot of bands to trigger the issue. The position I *hate* to be in is doing a lot of guessing trying to reproduce a bug. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From even.rouault at mines-paris.org Thu Mar 5 13:45:59 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 5 13:46:13 2009 Subject: [gdal-dev] Bigtiff question In-Reply-To: <49B006DF.1010706@pobox.com> References: <20090305164341.8814.qmail@s466.sureserver.com> <49B006DF.1010706@pobox.com> Message-ID: <200903051946.01242.even.rouault@mines-paris.org> Ivan, for the very poor performance when dealing with pixel interleaved GTiffs with a large number of bands, I think you've hit ticket #2838 that has been fixed 3 weeks ago in trunk and branches/1.6 (*). The performance issue was about *reading* in such files, but sometimes when you write and the block cache size is not big enough, you also end up reading back partially written scanlines. Hopefully this would correct the problem you observe. But as Frank suggested, I would not recommand using pixel interleaved GTiffs with a large number of bands anyway. This is fine for RGB or RGBA datasets, but for more bands, it could cause cache trashing problems as we prefill the blocks for all bands in pixel-interleaved mode (#2838 was about the fact this technic wasn't correctly implemented) However I'm not sure why you would get black files. I've tested the following with trunk and it produces the expected result. #!/usr/bin/python import gdal driver_tif = gdal.GetDriverByName("GTIFF") output_dst = driver_tif.Create( 'test.tif', 20, 20, 320, gdal.GDT_Byte, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) for i in range(320): output_band = output_dst.GetRasterBand( i + 1 ) output_band.Fill(i + 1) output_band.FlushCache() output_dst = None Even (*) : Currently there's an outstanding issue in 1.6 branch related to the GTiff driver (#2820) and color table handling, so I wouldn't recommand you to grab it. Or maybe just the patch of r16298 in 1.6.0 release. Le Thursday 05 March 2009 18:07:43 Frank Warmerdam, vous avez ?crit?: > Lucena, Ivan wrote: > > Yes, that runs a lot of seek's to writes just few bytes here and there. > > Ivan, > > I would note that for pixel interleaved data, access is still a whole > strip/tile at a time which in your case likely means a whole scanline. > In no case does GDAL's GTiff driver seek along to update individual > bytes in a pixel interleaved scanline or tile. > > > I am wondering what the geotiff driver could do to improve that; keeping > > tiles in memory until they are filled up for writing at once for example > > (?) > > GDAL will cache the blocks on a band-by-band basis (at a level > where it doesn't realize the underlying datastore is pixel > interleaved). The actual block flushing code in the GTIFF driver > does ensure that all the cache data for all bands is assembled > and written at once if available. So if you had a big enough > block cache - or if you wrote all bands for a given scanline at > approximately the same time - then only one write to disk would > take place for each block. > > But because you write "all of the first band", then all of the second > band and so on, you are basically triggering cache writes often and > preventing GDAL from doing things intelligently. > > > BTW, would make any difference if tile the geotiff? In that case what > > would be the blockxsize, blockysize recommended for 320 bands interleaved > > by PIXEL? > > I do not anticipate this would make much difference. As noted, > the key factors affecting performance are block cache size, and > the order you write data. > > >> OK, it sounds like the pixels all being zero is a bug, and > >> it would be good to file a ticket demonstrating this problem. > >> Hopefully a somewhat minimalist example of the problem. > > > > I think it would be very hard so send data samples so I would suggest > > running a script that creates fake raster bands with all pixels as 1 on > > band 1, 2 on band 2, etc. Something like that perhaps: > > > > -- > > driver_tif = gdal.GetDriverByName("GTIFF") > > output_dst = driver_tif.Create( output_tif, x_size, y_size, > > serie_count, data_type, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > > for i in range(320): > > output_band = output_dst.GetRasterBand( 1 + 1 ) > > output_band.Fill(i + 1) > > output_band.FlushCache() > > -- > > Well, please develop such a script, confirm it reproduces the > bug (ideally with a well known binary version of GDAL like the > OSGeo4W package) and then file the bug accordingly. You might want > to check if it really needs a lot of bands to trigger the issue. > > The position I *hate* to be in is doing a lot of guessing trying > to reproduce a bug. > > Best regards, From even.rouault at mines-paris.org Thu Mar 5 13:54:14 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 5 13:54:31 2009 Subject: [gdal-dev] Transparency using gdalbuildvrt In-Reply-To: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> References: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> Message-ID: <200903051954.15066.even.rouault@mines-paris.org> Hi, no, I don't think you can do it right now. But this would be doable by adding a new source to the VRT driver, something like VRTMaskSource, that would use the mask band of the underlying dataset for an alpha channel in the VRT. In areas without rasters, you'll get 0 (transparent), and in areas with rasters, you'll get 255 (opaque) or something more complex if the dataset has nodata values, or an alpha channel. This could be implemented as a new option of the existing VRTComplexSource too. And an extra option of the gdalbuildvrt utility would ask the creation of this extra band. You could file a track ticket with this enhancement proposal. Even Le Wednesday 04 March 2009 17:05:32 Jason Beverage, vous avez ?crit?: > Hi all, > > I've been playing around with gdalbuildvrt lately and it has proven to be a > very useful tool:) > > What I'm attempting to do is take multiple RGB images and treat them as a > single image using the VRT. This works great, but since the images are > RGB, areas where there is no data are coming back as black. Is there a way > that I can modify the VRT or the code to treat the VRT as an RGBA dataset > and somehow say "If there is no data in any bands, the alpha is 0"? > > Thanks! > > Jason From oz.nahum at student.uni-tuebingen.de Thu Mar 5 14:34:02 2009 From: oz.nahum at student.uni-tuebingen.de (Oz Nahum) Date: Thu Mar 5 14:34:04 2009 Subject: [gdal-dev] saving numpy array as ascii raster Message-ID: <6ec71d090903051134h585906abmb4002a99e7fe63b4@mail.gmail.com> Hello Again, I have been googling around and reading how to save my numpy arrays to rasters. So far I have not found a satisfying answer. The closest thing to what I'd would like to do is found here: * http://n2.nabble.com/basic-raster-math-td2033308.html#a2033316* When I try do to the following: from osgeo import gdal from osgeo.gdalconst import * dataset = gdal.Open('raster1.asc', GA_ReadOnly) dataset1 = gdal.Open('raster2.asc', GA_ReadOnly) print dataset, dataset1 from osgeo import gdal_array from osgeo import osr a = gdal_array.DatasetReadAsArray(dataset) b = gdal_array.DatasetReadAsArray(dataset1) print a print b def WriteRaster (dst_filename, raster): format = "GTiff" driver = gdal.GetDriverByName( format ) dst_ds = driver.Create( dst_filename, 71, 73,\ 1,gdal.GDT_Float32,options=["COMPRESS=PACKBITS","TFW=YES"] ) dst_ds.SetGeoTransform( [-19.5, 1.0, 0.0, 37.5, 0.0, -1.0] ) srs = osr.SpatialReference() srs.ImportFromEPSG(4326) #WGS84 lat long. dst_ds.SetProjection( srs.ExportToWkt() ) dst_ds.GetRasterBand(1).WriteArray( raster ) dst_ds = None c= a+b print c WriteRaster ('raster3.gtiff', c) A file with following content is created: 1.0000000000 0.0000000000 0.0000000000 -1.0000000000 -19.0000000000 37.0000000000 The rasters originally used are ascii type, and this are their contents: raster1.asc: raster2.asc: ncols 6 nrows 4 xllcorner 3366820.0000019 yllcorner 5814589.0300007 cellsize 10 NODATA_value -9999 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 -9999 -9999 So I would expect a file containing just: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 -19998 -19998 I would appreciate it if some one can supply a code snippet how to successfuly save numpy arrays into ascii raster. Thanks again, Oz Nahum Eberhard Karls Universit?t T?bingen Grad-student Applied Environmental Geosciences Institut f?r Geowissenschaften -- --- when one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion." Robert Pirsig, Zen and the Art of Motorcycle Maintenance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090305/4aaaf45e/attachment.html From ivan.lucena at pmldnet.com Thu Mar 5 14:45:49 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Thu Mar 5 14:45:51 2009 Subject: =?utf-8?B?UmU6IFtnZGFsLWRldl0gQmlndGlmZiBxdWVzdGlvbg==?= Message-ID: <20090305194549.13598.qmail@s466.sureserver.com> Even, > for the very poor performance when dealing with pixel interleaved GTiffs with > a large number of bands, I think you've hit ticket #2838 that has been fixed > 3 weeks ago in trunk and branches/1.6 (*). The performance issue was about > *reading* in such files, but sometimes when you write and the block cache > size is not big enough, you also end up reading back partially written > scanlines. Hopefully this would correct the problem you observe. Ah! > But as Frank suggested, I would not recommand using pixel interleaved GTiffs > with a large number of bands anyway. This is fine for RGB or RGBA datasets, > but for more bands, it could cause cache trashing problems as we prefill the > blocks for all bands in pixel-interleaved mode (#2838 was about the fact this > technic wasn't correctly implemented) What raster format would you suggest then? I mean, based on those requirements: - Multiband; - Large files; - Good performance *reading* the data in pixel space. Not the "band as usual" ;) > #!/usr/bin/python > import gdal > > driver_tif = gdal.GetDriverByName("GTIFF") > output_dst = driver_tif.Create( 'test.tif', 20, 20, 320, gdal.GDT_Byte, > [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > for i in range(320): > ????output_band = output_dst.GetRasterBand( i + 1 ) > ????output_band.Fill(i + 1) > ????output_band.FlushCache() > output_dst = None My real data is 5000x2500x312 Int16, can you try with: -- output_dst = driver_tif.Create( 'test.tif', 5000, 2500, 312, gdal.GDT_Int16, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) -- My best regards, Ivan From even.rouault at mines-paris.org Thu Mar 5 15:09:54 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 5 15:10:07 2009 Subject: [gdal-dev] Bigtiff question In-Reply-To: <20090305194549.13598.qmail@s466.sureserver.com> References: <20090305194549.13598.qmail@s466.sureserver.com> Message-ID: <200903052109.55950.even.rouault@mines-paris.org> Le Thursday 05 March 2009 20:45:49 Lucena, Ivan, vous avez ?crit?: > Even, > > > for the very poor performance when dealing with pixel interleaved GTiffs > > with a large number of bands, I think you've hit ticket #2838 that has > > been fixed 3 weeks ago in trunk and branches/1.6 (*). The performance > > issue was about *reading* in such files, but sometimes when you write and > > the block cache size is not big enough, you also end up reading back > > partially written scanlines. Hopefully this would correct the problem you > > observe. > > Ah! > > > But as Frank suggested, I would not recommand using pixel interleaved > > GTiffs with a large number of bands anyway. This is fine for RGB or RGBA > > datasets, but for more bands, it could cause cache trashing problems as > > we prefill the blocks for all bands in pixel-interleaved mode (#2838 was > > about the fact this technic wasn't correctly implemented) > > What raster format would you suggest then? > > I mean, based on those requirements: > > - Multiband; > - Large files; > - Good performance *reading* the data in pixel space. Not the "band as > usual" ;) Have you tried a tiled (128x128) band-interleaved GeoTIFF instead ? And read block per block. In any event, you should be careful than the block cache size is at least blockXSize * blockYSize * sizeof(datatype) * nbands. > > > #!/usr/bin/python > > import gdal > > > > driver_tif = gdal.GetDriverByName("GTIFF") > > output_dst = driver_tif.Create( 'test.tif', 20, 20, 320, gdal.GDT_Byte, > > [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > > for i in range(320): > > ????output_band = output_dst.GetRasterBand( i + 1 ) > > ????output_band.Fill(i + 1) > > ????output_band.FlushCache() > > output_dst = None > > My real data is 5000x2500x312 Int16, can you try with: > > -- > output_dst = driver_tif.Create( 'test.tif', 5000, 2500, 312, > gdal.GDT_Int16, [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > -- This is too large for my modest PC. I've tried up to 10 bands 5000x2500 and it worked fine. > > My best regards, > > Ivan From bryan at ideotrope.org Thu Mar 5 15:28:09 2009 From: bryan at ideotrope.org (Bryan Keith) Date: Thu Mar 5 15:28:11 2009 Subject: [gdal-dev] saving numpy array as ascii raster In-Reply-To: <6ec71d090903051134h585906abmb4002a99e7fe63b4@mail.gmail.com> References: <6ec71d090903051134h585906abmb4002a99e7fe63b4@mail.gmail.com> Message-ID: <4643.64.78.232.178.1236284889.squirrel@ideotrope.org> > Hello Again, > def WriteRaster (dst_filename, raster): > > format = "GTiff" Oz, You're creating a geotiff. Try: format = "AAIGrid" > driver = gdal.GetDriverByName( format ) > dst_ds = driver.Create( dst_filename, 71, 73,\ > 1,gdal.GDT_Float32,options=["COMPRESS=PACKBITS","TFW=YES"] > ) These options won't be available for "AAIGrid". > dst_ds.SetGeoTransform( [-19.5, 1.0, 0.0, 37.5, 0.0, -1.0] ) > srs = osr.SpatialReference() > srs.ImportFromEPSG(4326) #WGS84 lat long. > dst_ds.SetProjection( srs.ExportToWkt() ) > dst_ds.GetRasterBand(1).WriteArray( raster ) > dst_ds = None > > > c= a+b > print c > WriteRaster ('raster3.gtiff', c) > > A file with following content is created: > > 1.0000000000 > 0.0000000000 > 0.0000000000 > -1.0000000000 > -19.0000000000 > 37.0000000000 This file must be the .tfw, right? I expect you created a geotiff file as well which is where your data is. Bryan From oz.nahum at student.uni-tuebingen.de Thu Mar 5 15:45:24 2009 From: oz.nahum at student.uni-tuebingen.de (Oz Nahum) Date: Thu Mar 5 15:45:27 2009 Subject: [gdal-dev] saving numpy array as ascii raster In-Reply-To: <4643.64.78.232.178.1236284889.squirrel@ideotrope.org> References: <6ec71d090903051134h585906abmb4002a99e7fe63b4@mail.gmail.com> <4643.64.78.232.178.1236284889.squirrel@ideotrope.org> Message-ID: <6ec71d090903051245x6151c784gb6b952a9428d685@mail.gmail.com> Hi, Thanks for your quick reply. When I edit my code function to be: def WriteRaster (dst_filename, raster): format = "AAIGrid" driver = gdal.GetDriverByName( format ) dst_ds = driver.Create( dst_filename, 71, 73,\ 1,gdal.GDT_Float32,options=["COMPRESS=PACKBITS","TFW=YES"] ) Python complains: ERROR 6: GDALDriver::Create() ... no create method implemented for this format. alsp >This file must be the .tfw, right? I expect you created a geotiff file as >well which is where your data is. True, a file with the suffix I choose. This file is binary and I can't see it. So I would rather use the code supplied to save as text. This however is still not successful, Thanks, Oz. On Thu, Mar 5, 2009 at 9:28 PM, Bryan Keith wrote: > > Hello Again, > > def WriteRaster (dst_filename, raster): > > > > format = "GTiff" > > Oz, > > You're creating a geotiff. Try: > > format = "AAIGrid" > > > driver = gdal.GetDriverByName( format ) > > dst_ds = driver.Create( dst_filename, 71, 73,\ > > 1,gdal.GDT_Float32,options=["COMPRESS=PACKBITS","TFW=YES"] > > ) > > These options won't be available for "AAIGrid". > > > dst_ds.SetGeoTransform( [-19.5, 1.0, 0.0, 37.5, 0.0, -1.0] ) > > srs = osr.SpatialReference() > > srs.ImportFromEPSG(4326) #WGS84 lat long. > > dst_ds.SetProjection( srs.ExportToWkt() ) > > dst_ds.GetRasterBand(1).WriteArray( raster ) > > dst_ds = None > > > > > > c= a+b > > print c > > WriteRaster ('raster3.gtiff', c) > > > > A file with following content is created: > > > > 1.0000000000 > > 0.0000000000 > > 0.0000000000 > > -1.0000000000 > > -19.0000000000 > > 37.0000000000 > > This file must be the .tfw, right? I expect you created a geotiff file as > well which is where your data is. > > Bryan > > > -- ---- Imagine there's no countries It isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace ---- You all must read 'The God Delusion' http://en.wikipedia.org/wiki/The_God_Delusion --- when one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion." Robert Pirsig, Zen and the Art of Motorcycle Maintenance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090305/a7656fb2/attachment.html From bryan at ideotrope.org Thu Mar 5 16:26:43 2009 From: bryan at ideotrope.org (Bryan Keith) Date: Thu Mar 5 16:26:46 2009 Subject: [gdal-dev] saving numpy array as ascii raster In-Reply-To: <6ec71d090903051245x6151c784gb6b952a9428d685@mail.gmail.com> References: <6ec71d090903051134h585906abmb4002a99e7fe63b4@mail.gmail.com> <4643.64.78.232.178.1236284889.squirrel@ideotrope.org> <6ec71d090903051245x6151c784gb6b952a9428d685@mail.gmail.com> Message-ID: <4765.64.78.232.178.1236288403.squirrel@ideotrope.org> > Hi, > Thanks for your quick reply. > When I edit my code function to be: > def WriteRaster (dst_filename, raster): > > format = "AAIGrid" > driver = gdal.GetDriverByName( format ) > dst_ds = driver.Create( dst_filename, 71, 73,\ > 1,gdal.GDT_Float32,options=["COMPRESS=PACKBITS","TFW=YES"] ) > > Python complains: > > ERROR 6: GDALDriver::Create() ... no create method implemented for this > format. > Oz, AAIGrid cannot use Create, only CreateCopy. That's the difference between the + in the gdalinfo --formats list. I tried this code, and I think it does what you're looking for: #! /usr/bin/python from osgeo import gdal from osgeo.gdalconst import * dataset = gdal.Open('raster1.asc', GA_ReadOnly) dataset1 = gdal.Open('raster2.asc', GA_ReadOnly) print dataset, dataset1 from osgeo import gdal_array from osgeo import osr a = gdal_array.DatasetReadAsArray(dataset) b = gdal_array.DatasetReadAsArray(dataset1) print a print b def WriteRaster (dst_filename, raster): format = "MEM" driver = gdal.GetDriverByName( format ) dst_ds = driver.Create( dst_filename, len(raster[0]), len(raster),\ 1,gdal.GDT_Float32) dst_ds.SetGeoTransform( [-19.5, 1.0, 0.0, 37.5, 0.0, -1.0] ) srs = osr.SpatialReference() srs.ImportFromEPSG(4326) #WGS84 lat long. dst_ds.SetProjection( srs.ExportToWkt() ) dst_ds.GetRasterBand(1).WriteArray( raster ) format = 'AAIGrid' driver = gdal.GetDriverByName(format) dst_ds_new = driver.CreateCopy(dst_filename, dst_ds) dst_ds = None c= a+b print c WriteRaster ('raster3.asc', c) Bryan From nowak at xpam.de Thu Mar 5 15:46:48 2009 From: nowak at xpam.de (Adam Nowacki) Date: Thu Mar 5 17:08:35 2009 Subject: [gdal-dev] Bigtiff question In-Reply-To: <200903052109.55950.even.rouault@mines-paris.org> References: <20090305194549.13598.qmail@s466.sureserver.com> <200903052109.55950.even.rouault@mines-paris.org> Message-ID: <49B03A38.1050204@xpam.de> Even Rouault wrote: >> What raster format would you suggest then? >> >> I mean, based on those requirements: >> >> - Multiband; >> - Large files; >> - Good performance *reading* the data in pixel space. Not the "band as >> usual" ;) How about rotating the axis so: stored x axis = data time axis, stored y axis = data x axis, stored z (band) axis = data y axis. For your 5000x2500 with 312 bands example this would result in 312x5000 and 2500 bands tiff file. Reading all 312 values for some point would mean reading a single row (scanline) from a single band, a very fast operation. From ivan.lucena at pmldnet.com Fri Mar 6 08:38:40 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Fri Mar 6 08:38:49 2009 Subject: =?utf-8?B?UmU6IFtnZGFsLWRldl0gQmlndGlmZiBxdWVzdGlvbg==?= Message-ID: <20090306133846.24819.qmail@s466.sureserver.com> Frank, I understand that the geotiff driver is not going to do 'seek & write' for every single pixel but since I am not giving it a change to manage the blocks intelligently (as you said) it is probably doing ever worse than that. Like Even said, it is probably getting to a point that it needs to not only write but also read from the geotiff file in order to update the tiles/strips. My solution to the problem would be to change the way I loop through the single-banded input files and update the geotiff nicely. I don't think we need to pursue on that potential bug but Even got my Python script anyway. Thanks a lot. My best regards, Ivan > -------Original Message------- > From: Frank Warmerdam > Subject: Re: [gdal-dev] Bigtiff question > Sent: Mar 05 '09 17:07 > > Lucena, Ivan wrote: > > Yes, that runs a lot of seek's to writes just few bytes here and there. > > Ivan, > > I would note that for pixel interleaved data, access is still a whole > strip/tile at a time which in your case likely means a whole scanline. > In no case does GDAL's GTiff driver seek along to update individual > bytes in a pixel interleaved scanline or tile. > > > I am wondering what the geotiff driver could do to improve that; keeping tiles in memory until they are filled up for > > writing at once for example (?) > > GDAL will cache the blocks on a band-by-band basis (at a level > where it doesn't realize the underlying datastore is pixel > interleaved).??The actual block flushing code in the GTIFF driver > does ensure that all the cache data for all bands is assembled > and written at once if available.??So if you had a big enough > block cache - or if you wrote all bands for a given scanline at > approximately the same time - then only one write to disk would > take place for each block. > > But because you write "all of the first band", then all of the second > band and so on, you are basically triggering cache writes often and > preventing GDAL from doing things intelligently. > > > BTW, would make any difference if tile the geotiff? In that case what would be the blockxsize, blockysize recommended for 320 bands interleaved by PIXEL? > > I do not anticipate this would make much difference.??As noted, > the key factors affecting performance are block cache size, and > the order you write data. > > >>??OK, it sounds like the pixels all being zero is a bug, and > >>??it would be good to file a ticket demonstrating this problem. > >>??Hopefully a somewhat minimalist example of the problem. > > > > I think it would be very hard so send data samples so I would suggest running a script that creates fake raster bands > > with all pixels as 1 on band 1, 2 on band 2, etc. Something like that perhaps: > > > > -- > >???? driver_tif = gdal.GetDriverByName("GTIFF") > >???? output_dst = driver_tif.Create( output_tif, x_size, y_size, serie_count, data_type, > >???????? [ 'TILED=NO', 'INTERLEAVE=PIXEL' ]) > >???? for i in range(320): > >???????? output_band = output_dst.GetRasterBand( 1 + 1 ) > >???????? output_band.Fill(i + 1) > >???????? output_band.FlushCache() > > -- > > Well, please develop such a script, confirm it reproduces the > bug (ideally with a well known binary version of GDAL like the > OSGeo4W package) and then file the bug accordingly.??You might want > to check if it really needs a lot of bands to trigger the issue. > > The position I *hate* to be in is doing a lot of guessing trying > to reproduce a bug. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up?? | Frank Warmerdam, warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush????| Geospatial Programmer for Rent > > From jmckenna at gatewaygeomatics.com Fri Mar 6 09:45:32 2009 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Fri Mar 6 09:52:15 2009 Subject: [gdal-dev] setargv with windows 64-bit Message-ID: <49B1370C.30506@gatewaygeomatics.com> I am building a 64-bit GDAL on a 32-bit windows machine, and enabling setargv throws this GDAL error when compiling: ********* cd apps nmake /nologo /f makefile.vc cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_N O_DEPRECATE /DNDEBUG -I..\port -I..\ogr -I..\gcore -I..\alg -I..\ogr\ogrsf_frmt s -I..\frmts -I..\alg -I..\ogr -I..\ogr\ogrsf_frmts gdal_translate.cpp "D:\So ftware\MICROS~1.0\VC\lib\setargv.obj" ..\gdal_i.lib /link gdal_translate.cpp D:\Software\MICROS~1.0\VC\lib\setargv.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio 9.0\VC\BIN\x86_ amd64\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio 9.0\VC\BIN\nmak e.EXE"' : return code '0x2' Stop. ********** If I don't enable setargv GDAL 64-bit compiles fine (using today's GDAL trunk). (I have set GDAL's "WIN64" flag) Any ideas why this error is happening? -jeff -- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ From szekerest at gmail.com Fri Mar 6 10:28:42 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 6 10:28:45 2009 Subject: [gdal-dev] setargv with windows 64-bit In-Reply-To: <49B1370C.30506@gatewaygeomatics.com> References: <49B1370C.30506@gatewaygeomatics.com> Message-ID: Jeff, I'm guessing you're linking against an incorrect version of setargv.obj. I see the Win64 version can be found in: C:\Program Files (x86)\Microsoft Visual Studio 8\VC\lib\amd64 if you use VC2008 for example. Best regards, Tamas 2009/3/6 Jeff McKenna > I am building a 64-bit GDAL on a 32-bit windows machine, and enabling > setargv throws this GDAL error when compiling: > > ********* > cd apps > nmake /nologo /f makefile.vc > cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE > /D_CRT_NONSTDC_N > O_DEPRECATE /DNDEBUG -I..\port -I..\ogr -I..\gcore -I..\alg > -I..\ogr\ogrsf_frmt > s -I..\frmts -I..\alg -I..\ogr -I..\ogr\ogrsf_frmts gdal_translate.cpp > "D:\So > ftware\MICROS~1.0\VC\lib\setargv.obj" ..\gdal_i.lib /link > gdal_translate.cpp > D:\Software\MICROS~1.0\VC\lib\setargv.obj : fatal error LNK1112: module > machine > type 'X86' conflicts with target machine type 'x64' > NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio > 9.0\VC\BIN\x86_ > amd64\cl.EXE"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio > 9.0\VC\BIN\nmak > e.EXE"' : return code '0x2' > Stop. > ********** > > If I don't enable setargv GDAL 64-bit compiles fine (using today's GDAL > trunk). (I have set GDAL's "WIN64" flag) > > Any ideas why this error is happening? > > -jeff > > > -- > Jeff McKenna > FOSS4G Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/ab672c61/attachment-0001.html From jmckenna at gatewaygeomatics.com Fri Mar 6 11:23:39 2009 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Fri Mar 6 11:30:22 2009 Subject: [gdal-dev] setargv with windows 64-bit In-Reply-To: References: <49B1370C.30506@gatewaygeomatics.com> Message-ID: <49B14E0B.4060404@gatewaygeomatics.com> That was exactly it, thanks very much Tamas. -jeff Tamas Szekeres wrote: > Jeff, > > I'm guessing you're linking against an incorrect version of setargv.obj. > I see the Win64 version can be found in: > C:\Program Files (x86)\Microsoft Visual Studio 8\VC\lib\amd64 > > if you use VC2008 for example. > > Best regards, > > Tamas > > > > 2009/3/6 Jeff McKenna > > > I am building a 64-bit GDAL on a 32-bit windows machine, and > enabling setargv throws this GDAL error when compiling: > > ********* > cd apps > nmake /nologo /f makefile.vc > cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE > /D_CRT_NONSTDC_N > O_DEPRECATE /DNDEBUG -I..\port -I..\ogr -I..\gcore -I..\alg > -I..\ogr\ogrsf_frmt > s -I..\frmts -I..\alg -I..\ogr -I..\ogr\ogrsf_frmts > gdal_translate.cpp "D:\So > ftware\MICROS~1.0\VC\lib\setargv.obj" ..\gdal_i.lib /link > gdal_translate.cpp > D:\Software\MICROS~1.0\VC\lib\setargv.obj : fatal error LNK1112: > module machine > type 'X86' conflicts with target machine type 'x64' > NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio > 9.0\VC\BIN\x86_ > amd64\cl.EXE"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"D:\Software\Microsoft Visual Studio > 9.0\VC\BIN\nmak > e.EXE"' : return code '0x2' > Stop. > ********** > > If I don't enable setargv GDAL 64-bit compiles fine (using today's > GDAL trunk). (I have set GDAL's "WIN64" flag) > > Any ideas why this error is happening? > > -jeff > > > -- > Jeff McKenna > FOSS4G Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ From lucafasano at interfree.it Fri Mar 6 12:33:05 2009 From: lucafasano at interfree.it (LFas) Date: Fri Mar 6 12:33:06 2009 Subject: [Gdal-dev] HDF5 library Message-ID: <1236360785653-2437048.post@n2.nabble.com> Hi list, I tried to create a dll only for hdf5 gdal files, i.e. 3 files in frmts/hdf5 which I modified. I use MS Visual Studio 2008 and tried to do it with makfile.vc and obviously included nmake.opt. Once I defined GDAL_ROOT, HDF5_DIR, SZIP_DIR, HDF5_LIB as $(HDF5_DIR)\dll\hdf5dll.lib \ $(SZIP_DIR)\dll\szlibdll.lib , I done nmake -f makefile.vc and it tells me the file "sys\types.h" cannot be found. In fact it isn't present in hdf5 folder. Where I'm wrong? Thanks -- View this message in context: http://n2.nabble.com/HDF5-library-tp2437048p2437048.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Fri Mar 6 12:44:43 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 6 12:45:11 2009 Subject: [Gdal-dev] HDF5 library In-Reply-To: <1236360785653-2437048.post@n2.nabble.com> References: <1236360785653-2437048.post@n2.nabble.com> Message-ID: <49B1610B.5010503@pobox.com> LFas wrote: > Hi list, > I tried to create a dll only for hdf5 gdal files, i.e. 3 files in frmts/hdf5 > which I modified. > I use MS Visual Studio 2008 and tried to do it with makfile.vc and obviously > included nmake.opt. Once I defined GDAL_ROOT, HDF5_DIR, SZIP_DIR, HDF5_LIB > as $(HDF5_DIR)\dll\hdf5dll.lib \ $(SZIP_DIR)\dll\szlibdll.lib , I done > nmake -f makefile.vc and it tells me the file "sys\types.h" cannot be found. > In fact it isn't present in hdf5 folder. Where I'm wrong? > Thanks Luca, I see that H5public.h has: #ifdef H5_HAVE_SYS_TYPES_H #include #endif I suspect that the settings for macros like H5_HAVE_SYS_TYPES_H in H5pubconf.h are not appropriate for your compiler (MSVC) which presumably lacks posix stuff like sys/types.h. I have attached the H5pubconf.h file used with the HDF5 development package for OSGeo4W. It might be possible for you to use it, but it might be better for you to review what you are using for HDF5 libraries and include files. In fact, you could likely fairly easily use the HDF5 packages prepared for OSGeo4W. I assume you are working to build an HDF5 plugin for GDAL? Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent -------------- next part -------------- A non-text attachment was scrubbed... Name: H5pubconf.h Type: text/x-chdr Size: 3192 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/81eda7e2/H5pubconf.bin From frankie at debian.org Fri Mar 6 15:47:36 2009 From: frankie at debian.org (Francesco Paolo Lovergine) Date: Fri Mar 6 15:49:11 2009 Subject: [gdal-dev] Building under gcc-4.3/libtool-2.2.4 (ubuntu intrepid) In-Reply-To: References: Message-ID: <20090306204735.GA3537@frankie.is-a-geek.org> On Wed, Mar 04, 2009 at 11:16:46PM +1300, Robert Coup wrote: > Hey folks, > I'm struggling to build either the 1.5 branch or trunk on Ubuntu Intrepid > with gcc 4.3.2 and libtool 2.2.4. The symptoms are the same as described in > http://trac.osgeo.org/gdal/ticket/2138 , except updating ltmain.sh doesn't > seem to help. And i get the same building the Debian v1.5.4 source package > under intrepid as well (how i got started down this track). > > I've run libtoolize/aclocal/autoconf/autogen/etc to redo the setup stuff, > but i still get the same error. I'm not an autotools expert though, so > advice would be appreciated. Building with gcc/g++ 4.1 errors out in the > same way. > http://trac.osgeo.org/gdal/ticket/1994#comment:4 -- Francesco P. Lovergine From support at satshot.com Fri Mar 6 15:42:19 2009 From: support at satshot.com (Avi Blackmore) Date: Fri Mar 6 16:10:28 2009 Subject: [gdal-dev] Histogram with Python 2.5 different than with 2.3.5 Message-ID: I've recently begun migrating my Python scripts which use GDAL/OGR to Python 2.5, and I noticed that GetHistogram?() returns a substantially different histogram for a given image under 2.5 from what it returns under 2.3.5. The file in question is a GeoTIFF, and in both cases I am calling GetHistogram?() on the same raster band, band 1. Under 2.3.5, this is the histogram I get: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 15, 93, 243, 253, 464, 988, 1127, 754, 982, 1348, 1501, 1251, 1808, 2318, 2607, 2940, 2629, 2366, 2427, 2498, 2021, 1698, 999, 579, 206, 148, 52, 35, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 65504] While, under 2.5, this is the result: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 35, 65, 98, 159, 204, 113, 177, 168, 340, 393, 475, 586, 531, 545, 341, 291, 268, 252, 258, 186, 125, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 12022] Any ideas on why this might be? -- Avi Blackmore Head Programmer/System Administrator Agri ImaGIS Technologies, Inc. From monshi at home.se Fri Mar 6 16:30:17 2009 From: monshi at home.se (Tomas R) Date: Fri Mar 6 16:30:39 2009 Subject: [gdal-dev] Building 64 bit, Swig Error Message-ID: Trying to build a 64 bit version of GDAL on a Vista 32 bit installation using Visual Studie Express C++ 2008. So how do I do, and how does it go. I start up the Visual Studio 2008 x64 Cross Tools Command Prompt. I set in nmake.opt WIN64= YES With this GDAL seems to compile ok, no errors and all files created as it should. I have no direct way of testing it since I only have a 32 bit installation of Vista but, as said, seems ok. Then I try to compile the C# Swig interface. First step nmake /f makefile.vc interface compiles but second step nmake /f makefile.vc throws an error cd .. csc /target:library /out:osr_csharp.dll osr\*.cs AssemblyInfo.cs csc ?r inte ett internt kommando, externt kommando, program eller kommandofil. NMAKE : fatal error U1077: 'csc' : return code '0x1' Stop. translates to about csc is not an internal commando, external commando, program or commando file What have I missed? Building 32-bit version, using the normal 32 bit version of VSE 2008 debug environment is no problem at all. Yours Tomas From monshi at home.se Fri Mar 6 17:01:00 2009 From: monshi at home.se (Tomas R) Date: Fri Mar 6 17:01:19 2009 Subject: [gdal-dev] Re: GDAL - CSharp In-Reply-To: References: <1234359681049-2308674.post@n2.nabble.com> <1234393584390-2312047.post@n2.nabble.com> <1234394486389-2312090.post@n2.nabble.com> Message-ID: Tamas, remember the detective work done last year. 32 bit C# interface won't mix at all with 64 bit runtime environment. or have you found a way around that? have not followed the list for some time, just now trying to create a 64-bit version of gdal. Yes, I have a problem too, and yes a q has been posted on this list. /Tomas Tamas Szekeres skrev: > You should provide further info about your environment: > > 1. Did you test your app by running from an IDE like VS2005 for example? > 2. What version of OS/IIS you intend to use when deploying the > application. > > You appdir and platform configuration (32/64) may be different > depending on your environment. > For example by using the VS IDE you'd probably use > WebDev.WebServer.exe as the host process which is running against the > 32 bit version of the .NET framework on a 64 bit machine. > > You might want to use SysInternals ProcMon.exe to make sure about the > expected locations of the dll files. > > Best regards, > > Tamas > > > > > 2009/2/12 Tri > > > > Tamas, > > I'm creating web services. This is first go on 64 bit machine - > plenty of > 32 bit web services to fall back on. The problem is I was using > FDO which > as far as I know has only 32 bit compiled code. So I set the > 'Enable 32 Bit > Application' to true, published the application, then tried to run > from > localhost. There were no problems with 64 bit, 32 bit conflicts > this way. > However, I then started getting an error that says: > > System.IO file not found. I'm not using System.IO file in the > web service. > > So, I thought I would use your compiled 64 bit GDAL / OGR code to > create a > new web service, but running into previously mentioned problem > taking this > approach. > > Thanks again..... > > > > > > > Tamas Szekeres wrote: > > > > What kind of application you develop Console/WinForms/ASP.NET > ? > > Wouldn't it be sufficient to use 32 bit binaries and compile > your app with > > the /platform:x86 option? > > > > Best regards, > > > > Tamas > > > > > > > > > > 2009/2/12 Tri > > > > >> > >> Hi Tamas and others - thanks for the help. > >> > >> By application executing directory - I've copied the files to > both the > >> bin > >> directory under the project and the obj, Debug directory under the > >> project. > >> When I run the application in debug mode, the same problem occurs: > >> > >> System.TypeInitializationException: The type initializer for > >> OSGeo.OGR.Ogr > >> threw an exception > >> > >> InnerException: The type initializer for OSGeo.OGR.OgrPINVOKE > threw an > >> excpetion > >> > >> I am using the 64 bit compiled code from you on Vista 64 bit > machine. > >> > >> Any more ideas? Thanks..... > >> > >> > >> > >> Tamas Szekeres wrote: > >> > > >> > Hi, > >> > > >> > You might have to copy all of the dll-s (*_csharp.dll, > *_wrap.dll, > >> > gdal16.dll, proj.dll etc.) to the application executing > directory. > >> > > >> > Best regards, > >> > > >> > Tamas > >> > > >> > > >> > > >> > 2009/2/11 Tri > > >> > > >> >> > >> >> Can't get GDAL / OGR to work with CSharp. Using the CSharp > dlls, I > >> keep > >> >> getting exceptions like: > >> >> > >> >> OgrPINVOKE, threw an exception. > >> >> > >> >> > >> >> TO TRY TO GET TO WORK I DID: > >> >> - Copied the csharp dlls into project, > >> >> - Created a reference to the dlls. > >> >> > >> >> What am I doing wrong? > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2308674.html > >> >> Sent from the GDAL - Dev mailing list archive at Nabble.com. > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > >> > >> -- > >> View this message in context: > >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2312047.html > >> Sent from the GDAL - Dev mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> 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 > > > > -- > View this message in context: > http://n2.nabble.com/GDAL---CSharp-tp2308674p2312090.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 From szekerest at gmail.com Fri Mar 6 17:08:30 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 6 17:08:32 2009 Subject: [gdal-dev] Building 64 bit, Swig Error In-Reply-To: References: Message-ID: Hi, There's something missing in your vcvars.bat (ie vcvarsx86_amd64.bat for the cross compiler version). Try to check the FrameworkDir and the PATH environment variables to match with the current locations within the batch file, like for example: ... @SET FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64 .... @set PATH=%VCINSTALLDIR%\BIN\amd64;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%Framework35Version%\Microsoft .NET Framework 3.5 (Pre-Release Version);%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\VCPackages;%VSINSTALLDIR%\Common7\IDE;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\Tools\bin;%PATH% @set INCLUDE=%VCINSTALLDIR%\ATLMFC\INCLUDE;%VCINSTALLDIR%\INCLUDE;%INCLUDE% @set LIB=%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIB% @set LIBPATH=%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIBPATH% Best regards, Tamas PS: You could also download the recent SDKs or precompiled binary packages for various compiler versions from this location: http://vbkto.dyndns.org:1280/sdk/index.html 2009/3/6 Tomas R > Trying to build a 64 bit version of GDAL on a Vista 32 bit installation > using Visual Studie Express C++ 2008. > > So how do I do, and how does it go. > I start up the Visual Studio 2008 x64 Cross Tools Command Prompt. I set in > nmake.opt WIN64= YES > With this GDAL seems to compile ok, no errors and all files created as it > should. I have no direct way of testing it since I only have a 32 bit > installation of Vista but, as said, seems ok. > > Then I try to compile the C# Swig interface. > First step > nmake /f makefile.vc interface > compiles > but second step > nmake /f makefile.vc > throws an error > cd .. > csc /target:library /out:osr_csharp.dll osr\*.cs AssemblyInfo.cs > csc ?r inte ett internt kommando, externt kommando, > program eller kommandofil. > NMAKE : fatal error U1077: 'csc' : return code '0x1' > Stop. > > translates to about > csc is not an internal commando, external commando, program or commando > file > > What have I missed? > Building 32-bit version, using the normal 32 bit version of VSE 2008 debug > environment is no problem at all. > > > Yours > Tomas > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/c0d4318c/attachment-0001.html From szekerest at gmail.com Fri Mar 6 17:22:38 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 6 17:22:41 2009 Subject: [gdal-dev] Re: GDAL - CSharp In-Reply-To: References: <1234359681049-2308674.post@n2.nabble.com> <1234393584390-2312047.post@n2.nabble.com> <1234394486389-2312090.post@n2.nabble.com> Message-ID: Hi Tomas, I don't remember what the exact problem was, however the situation remains the same, namely: 1. We can compile gdal either for x86 or x64. The x86 version could work natively with the x86 version on the .NET framework and the x64 compilation would work with the x64 version of the framework. 2. If the host process is developed by you, then you should use the /platform:x86 compiler optionand use the gdal x86 compilation. This setting will provide to force your application to run on x86 mode regardless of the environment which will work pretty well on each platform then. 3. ASP.NET application running on a Win64 OS use the x64 framework by default, therfore you'll have to use the Win64 compiled gdal binaries. However this is not the case when running the same application in the VS debugger since the debugger host process is running in x86 mode by default. Best regards, Tamas 2009/3/6 Tomas R > Tamas, remember the detective work done last year. > > 32 bit C# interface won't mix at all with 64 bit runtime environment. or > have you found a way around that? have not followed the list for some time, > just now trying to create a 64-bit version of gdal. > > Yes, I have a problem too, and yes a q has been posted on this list. > > /Tomas > > Tamas Szekeres skrev: > >> You should provide further info about your environment: >> >> 1. Did you test your app by running from an IDE like VS2005 for example? >> 2. What version of OS/IIS you intend to use when deploying the >> application. >> >> You appdir and platform configuration (32/64) may be different depending >> on your environment. >> For example by using the VS IDE you'd probably use WebDev.WebServer.exe as >> the host process which is running against the 32 bit version of the .NET >> framework on a 64 bit machine. >> >> You might want to use SysInternals ProcMon.exe to make sure about the >> expected locations of the dll files. >> >> Best regards, >> >> Tamas >> >> >> >> >> 2009/2/12 Tri > >> >> >> Tamas, >> >> I'm creating web services. This is first go on 64 bit machine - >> plenty of >> 32 bit web services to fall back on. The problem is I was using >> FDO which >> as far as I know has only 32 bit compiled code. So I set the >> 'Enable 32 Bit >> Application' to true, published the application, then tried to run >> from >> localhost. There were no problems with 64 bit, 32 bit conflicts >> this way. >> However, I then started getting an error that says: >> >> System.IO file not found. I'm not using System.IO file in the >> web service. >> >> So, I thought I would use your compiled 64 bit GDAL / OGR code to >> create a >> new web service, but running into previously mentioned problem >> taking this >> approach. >> >> Thanks again..... >> >> >> >> >> >> >> Tamas Szekeres wrote: >> > >> > What kind of application you develop Console/WinForms/ASP.NET >> ? >> > Wouldn't it be sufficient to use 32 bit binaries and compile >> your app with >> > the /platform:x86 option? >> > >> > Best regards, >> > >> > Tamas >> > >> > >> > >> > >> > 2009/2/12 Tri > > >> >> > >> >> >> >> Hi Tamas and others - thanks for the help. >> >> >> >> By application executing directory - I've copied the files to >> both the >> >> bin >> >> directory under the project and the obj, Debug directory under the >> >> project. >> >> When I run the application in debug mode, the same problem occurs: >> >> >> >> System.TypeInitializationException: The type initializer for >> >> OSGeo.OGR.Ogr >> >> threw an exception >> >> >> >> InnerException: The type initializer for OSGeo.OGR.OgrPINVOKE >> threw an >> >> excpetion >> >> >> >> I am using the 64 bit compiled code from you on Vista 64 bit >> machine. >> >> >> >> Any more ideas? Thanks..... >> >> >> >> >> >> >> >> Tamas Szekeres wrote: >> >> > >> >> > Hi, >> >> > >> >> > You might have to copy all of the dll-s (*_csharp.dll, >> *_wrap.dll, >> >> > gdal16.dll, proj.dll etc.) to the application executing >> directory. >> >> > >> >> > Best regards, >> >> > >> >> > Tamas >> >> > >> >> > >> >> > >> >> > 2009/2/11 Tri > > >> >> > >> >> >> >> >> >> Can't get GDAL / OGR to work with CSharp. Using the CSharp >> dlls, I >> >> keep >> >> >> getting exceptions like: >> >> >> >> >> >> OgrPINVOKE, threw an exception. >> >> >> >> >> >> >> >> >> TO TRY TO GET TO WORK I DID: >> >> >> - Copied the csharp dlls into project, >> >> >> - Created a reference to the dlls. >> >> >> >> >> >> What am I doing wrong? >> >> >> >> >> >> >> >> >> -- >> >> >> View this message in context: >> >> >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2308674.html >> >> >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> > >> >> >> >> -- >> >> View this message in context: >> >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2312047.html >> >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> -- >> View this message in context: >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2312090.html >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/7fa2b780/attachment.html From bclay at ball.com Fri Mar 6 15:51:36 2009 From: bclay at ball.com (Clay, Bruce) Date: Fri Mar 6 17:25:42 2009 Subject: [gdal-dev] OGR - Oracle problem Message-ID: When I issue the following SQL query through SqlPal I get 2 columns of what appears to be valid data select * from (select OBJECTID, sdo_nn_distance(1) Dist from GEONAMES_SDO a1 where DSG LIKE 'PPL%' AND sdo_nn(a1.shape, sdo_geometry(2001, null, sdo_point_type(-84.48500000,-21.98100000, NULL), null, null), 'sdo_num_res=100',1) = 'TRUE'); Results OBJECTID Dist 451323 .397194968358102 432828 .647925639080596 447967 .239182235498376 453566 .495207228227733 454057 .270980772175814 392983 .165016165538413 407235 .325487083888139 408026 .647925639080596 399747 .647925639080596 399036 .325487083888139 409567 .165016165538413 423135 .239182235498376 If I issue the same query through OGR ExecuteSql I get the first column (OBJECTID) as it appears in SqlPal but the second column which should be the distance comes back as type OFTInteger and the value is always zero reguardless of where I call GetFieldAsString or GetFieldAsDouble. Is there something else that has to be specified to get the correct data type on this type of a query where a column is created dynamically? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/33a6dab5/attachment-0001.html From monshi at home.se Fri Mar 6 17:54:21 2009 From: monshi at home.se (Tomas R) Date: Fri Mar 6 17:54:40 2009 Subject: [gdal-dev] Re: Building 64 bit, Swig Error In-Reply-To: References: Message-ID: Ah, thanks, will look it up more properly in the morning. A quick check now did not reveal what may be missing. Strange, it is a fresh installations of the VSE 2008 and SDK. It should work. Or? Well, probably the version you linked to is good enough for me and also a 64 bit version of Proj4 is found in the pack, nice. That would probably be my next question , how to compile a 64 bit version of Proj4 using VSE2008. Or even 32 bit version. But 32 version is easy to find (FWTools for example) so that would be necessary. Thanks, yours Tomas ps My vcvarsx86_amd64.bat looks like... if you find what is missing... @SET VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0 @SET VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0\VC @SET FrameworkDir=Framework32 @SET FrameworkVersion=v2.0.50727 @if "%VSINSTALLDIR%"=="" goto error_no_VSINSTALLDIR @if "%VCINSTALLDIR%"=="" goto error_no_VCINSTALLDIR @echo Setting environment for using Microsoft Visual Studio 2008 Beta2 x64 cross tools. @call :GetWindowsSdkDir @if not "%WindowsSdkDir%" == "" ( set "PATH=%WindowsSdkDir%bin;%PATH%" set "INCLUDE=%WindowsSdkDir%include;%INCLUDE%" set "LIB=%WindowsSdkDir%lib\x64;%LIB%" ) @rem @rem Root of Visual Studio IDE installed files. @rem @set DevEnvDir=%VSINSTALLDIR%\Common7\IDE @set PATH=%DevEnvDir%;%VCINSTALLDIR%\BIN\x86_amd64;%VCINSTALLDIR%\BIN;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR% \Common7\Tools\bin;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%Framework35Version%\Microsoft .NET Framework 3.5 (Pre-Release Version);%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\VCPackages;%PATH% @set INCLUDE=%VCINSTALLDIR%\ATLMFC\INCLUDE;%VCINSTALLDIR%\INCLUDE;%INCLUDE% @set LIB=%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIB% @set LIBPATH=%FrameworkDir%64\%Framework35Version%;%FrameworkDir%64\%FrameworkVersion%;%FrameworkDir%\% Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;% LIBPATH% Tamas Szekeres skrev: > Hi, > > There's something missing in your vcvars.bat (ie vcvarsx86_amd64.bat > for the cross compiler version). Try to check the FrameworkDir and the > PATH environment variables to match with the current locations within > the batch file, like for example: > > ... > @SET FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64 > .... > @set > PATH=%VCINSTALLDIR%\BIN\amd64;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%Framework35Version%\Microsoft > .NET Framework 3.5 (Pre-Release > Version);%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\VCPackages;%VSINSTALLDIR%\Common7\IDE;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\Tools\bin;%PATH% > @set > INCLUDE=%VCINSTALLDIR%\ATLMFC\INCLUDE;%VCINSTALLDIR%\INCLUDE;%INCLUDE% > @set LIB=%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIB% > > @set > LIBPATH=%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%FrameworkDir%\%Framework35Version%;%FrameworkDir%\%FrameworkVersion%;%VCINSTALLDIR%\ATLMFC\LIB\amd64;%VCINSTALLDIR%\LIB\amd64;%LIBPATH% > > > Best regards, > > Tamas > > > PS: You could also download the recent SDKs or precompiled binary > packages for various compiler versions from this location: > http://vbkto.dyndns.org:1280/sdk/index.html > > > > > 2009/3/6 Tomas R > > > Trying to build a 64 bit version of GDAL on a Vista 32 bit > installation using Visual Studie Express C++ 2008. > > So how do I do, and how does it go. > I start up the Visual Studio 2008 x64 Cross Tools Command Prompt. > I set in nmake.opt WIN64= YES > With this GDAL seems to compile ok, no errors and all files > created as it should. I have no direct way of testing it since I > only have a 32 bit installation of Vista but, as said, seems ok. > > Then I try to compile the C# Swig interface. > First step > nmake /f makefile.vc interface > compiles > but second step > nmake /f makefile.vc > throws an error > cd .. > csc /target:library /out:osr_csharp.dll osr\*.cs AssemblyInfo.cs > csc ?r inte ett internt kommando, externt kommando, > program eller kommandofil. > NMAKE : fatal error U1077: 'csc' : return code '0x1' > Stop. > > translates to about > csc is not an internal commando, external commando, program or > commando file > > What have I missed? > Building 32-bit version, using the normal 32 bit version of VSE > 2008 debug environment is no problem at all. > > > Yours > Tomas > > _______________________________________________ > 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 From monshi at home.se Fri Mar 6 18:01:32 2009 From: monshi at home.se (Tomas R) Date: Fri Mar 6 18:01:57 2009 Subject: [gdal-dev] Re: GDAL - CSharp In-Reply-To: References: <1234359681049-2308674.post@n2.nabble.com> <1234393584390-2312047.post@n2.nabble.com> <1234394486389-2312090.post@n2.nabble.com> Message-ID: 2. No, not in my control. So I will make use of the 64 bit version where necessary. If you wish refresh your memory, look back to my question in this list at 2008-02-29 with subject C#: Gdal on Win64 There you, somewhere in the thread, have provided an explanation Yours Tomas Tamas Szekeres skrev: > Hi Tomas, > > I don't remember what the exact problem was, however the situation > remains the same, namely: > > 1. We can compile gdal either for x86 or x64. The x86 version could > work natively with the x86 version on the .NET framework and the x64 > compilation would work with the x64 version of the framework. > 2. If the host process is developed by you, then you should use the > /platform:x86 compiler optionand use the gdal x86 compilation. This > setting will provide to force your application to run on x86 mode > regardless of the environment which will work pretty well on each > platform then. > 3. ASP.NET application running on a Win64 OS use the > x64 framework by default, therfore you'll have to use the Win64 > compiled gdal binaries. However this is not the case when running the > same application in the VS debugger since the debugger host process is > running in x86 mode by default. > > Best regards, > > Tamas > > > > > > 2009/3/6 Tomas R > > > Tamas, remember the detective work done last year. > > 32 bit C# interface won't mix at all with 64 bit runtime > environment. or have you found a way around that? have not > followed the list for some time, just now trying to create a > 64-bit version of gdal. > > Yes, I have a problem too, and yes a q has been posted on this list. > > /Tomas > > Tamas Szekeres skrev: > > You should provide further info about your environment: > > 1. Did you test your app by running from an IDE like VS2005 > for example? > 2. What version of OS/IIS you intend to use when deploying the > application. > > You appdir and platform configuration (32/64) may be different > depending on your environment. > For example by using the VS IDE you'd probably use > WebDev.WebServer.exe as the host process which is running > against the 32 bit version of the .NET framework on a 64 bit > machine. > > You might want to use SysInternals ProcMon.exe to make sure > about the expected locations of the dll files. > > Best regards, > > Tamas > > > > > 2009/2/12 Tri > >> > > > > Tamas, > > I'm creating web services. This is first go on 64 bit > machine - > plenty of > 32 bit web services to fall back on. The problem is I was > using > FDO which > as far as I know has only 32 bit compiled code. So I set the > 'Enable 32 Bit > Application' to true, published the application, then tried > to run > from > localhost. There were no problems with 64 bit, 32 bit > conflicts > this way. > However, I then started getting an error that says: > > System.IO file not found. I'm not using System.IO file in the > web service. > > So, I thought I would use your compiled 64 bit GDAL / OGR > code to > create a > new web service, but running into previously mentioned problem > taking this > approach. > > Thanks again..... > > > > > > > Tamas Szekeres wrote: > > > > What kind of application you develop > Console/WinForms/ASP.NET > ? > > > Wouldn't it be sufficient to use 32 bit binaries and compile > your app with > > the /platform:x86 option? > > > > Best regards, > > > > Tamas > > > > > > > > > > 2009/2/12 Tri > >> > > > > >> > >> Hi Tamas and others - thanks for the help. > >> > >> By application executing directory - I've copied the > files to > both the > >> bin > >> directory under the project and the obj, Debug directory > under the > >> project. > >> When I run the application in debug mode, the same > problem occurs: > >> > >> System.TypeInitializationException: The type > initializer for > >> OSGeo.OGR.Ogr > >> threw an exception > >> > >> InnerException: The type initializer for > OSGeo.OGR.OgrPINVOKE > threw an > >> excpetion > >> > >> I am using the 64 bit compiled code from you on Vista 64 bit > machine. > >> > >> Any more ideas? Thanks..... > >> > >> > >> > >> Tamas Szekeres wrote: > >> > > >> > Hi, > >> > > >> > You might have to copy all of the dll-s (*_csharp.dll, > *_wrap.dll, > >> > gdal16.dll, proj.dll etc.) to the application executing > directory. > >> > > >> > Best regards, > >> > > >> > Tamas > >> > > >> > > >> > > >> > 2009/2/11 Tri > >> > > >> > > >> >> > >> >> Can't get GDAL / OGR to work with CSharp. Using the > CSharp > dlls, I > >> keep > >> >> getting exceptions like: > >> >> > >> >> OgrPINVOKE, threw an exception. > >> >> > >> >> > >> >> TO TRY TO GET TO WORK I DID: > >> >> - Copied the csharp dlls into project, > >> >> - Created a reference to the dlls. > >> >> > >> >> What am I doing wrong? > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2308674.html > >> >> Sent from the GDAL - Dev mailing list archive at > Nabble.com. > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > >> > >> -- > >> View this message in context: > >> http://n2.nabble.com/GDAL---CSharp-tp2308674p2312047.html > >> Sent from the GDAL - Dev mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> 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 > > > > -- > View this message in context: > http://n2.nabble.com/GDAL---CSharp-tp2308674p2312090.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From szekerest at gmail.com Fri Mar 6 18:17:31 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 6 18:17:33 2009 Subject: [gdal-dev] Re: Building 64 bit, Swig Error In-Reply-To: References: Message-ID: 2009/3/6 Tomas R > Ah, thanks, will look it up more properly in the morning. > > A quick check now did not reveal what may be missing. Strange, it is a > fresh installations of the VSE 2008 and SDK. It should work. Or? > > Well, probably the version you linked to is good enough for me and also a > 64 bit version of Proj4 is found in the pack, nice. That would probably be > my next question , how to compile a 64 bit version of Proj4 using VSE2008. > Or even 32 bit version. But 32 version is easy to find (FWTools for example) > so that would be necessary. > If you use my SDK just download and extract the proj4 package (eg. proj-4.6.1) within the SDK root directory and use: nmake proj PROJ_DIR=proj-4.6.1 The Makefile will set the compiler version and the WIN64 setting seemlessly. It seems like the @SET FrameworkDir=Framework32 should point to the absolute path of the framework directory (ie C:\WINDOWS\Microsoft.NET\Framework) in your batch file. Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090307/50d27bf4/attachment.html From szekerest at gmail.com Fri Mar 6 18:37:31 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 6 18:37:33 2009 Subject: [gdal-dev] Re: GDAL - CSharp In-Reply-To: References: <1234359681049-2308674.post@n2.nabble.com> <1234393584390-2312047.post@n2.nabble.com> <1234394486389-2312090.post@n2.nabble.com> Message-ID: 2009/3/7 Tomas R > > If you wish refresh your memory, look back to my question in this list at > 2008-02-29 with subject C#: Gdal on Win64 > There you, somewhere in the thread, have provided an explanation > > I looked back and the issue have appeared to be solved by using the x64 binaries provided that time. The conclusion was that all of the dlls should match with the framework version (x86 or x64) used with the application to avoid the problems reported there. This is exactly the same that I've mentioned in my previous post in this thread :| Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090307/6b0135cb/attachment.html From izzybitsie at gmail.com Fri Mar 6 18:46:38 2009 From: izzybitsie at gmail.com (Dori) Date: Fri Mar 6 18:46:42 2009 Subject: [gdal-dev] FWTools 1.1.3 vs 2-0.6 gdal_translate Message-ID: <23e208430903061546n2c8697c5ne9558aab953d5045@mail.gmail.com> Hi, a while ago I wrote an application using gdal_translate to translate tags in a geotiff image. I used the following command: gdal_translate -a_srs $tagfn $infn $outfn where $tagfn is the file used to modify the tags, $infn is the input filename and $outfn is the output file name (with the tags required). I am running the same program with FWTools 2-0.6 on a new host. I noticed by running the gdalinfo that there are significant differences in Coordinate System between the 2 versions. I am no expert on the Geotiff area so, I cannot comprehend what changes done to GDAL might be affecting this translation. Any idea on how to resolve this issue would be apreciated. Thanks Isidora izzybitsie@gmail.com * With 1.1.3*: *Driver: GTiff/GeoTIFF Files: WO_SATIR_00_21Z.tif_denwxp1 Size is 7479, 3033 Coordinate System is: GEOGCS["unnamed", DATUM["unknown", SPHEROID["unretrievable - using WGS84",6378137,298.257223563]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]] Origin = (-179.999899999999997,73.000000000000000) Pixel Size = (0.048132577673166,-0.048139266469396) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND * *With 2-0.6* *Driver: GTiff/GeoTIFF Files: WO_SATIR_00_21Z.tif Size is 7479, 3033 Coordinate System is: LOCAL_CS["unnamed", UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (-179.999899999999997,73.000000000000000) Pixel Size = (0.048132577673166,-0.048139266469396) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND* *This is $tagfn:* *Geotiff_Information: Version: 1 Key_Revision: 1.0 Tagged_Information: ModelTiepointTag (2,3): 0 0 0 -179.9999 73 0 ModelPixelScaleTag (1,3): 0.0481125224 0.0481125224 0 End_Of_Tags. Keyed_Information: GTModelTypeGeoKey (Short,1): ModelTypeGeographic GTRasterTypeGeoKey (Short,1): RasterPixelIsArea GTCitationGeoKey (Ascii,8): "unnamed" GeographicTypeGeoKey (Short,1): GCS_WGS_84 GeogCitationGeoKey (Ascii,8): "unnamed" GeogAngularUnitsGeoKey (Short,1): Angular_Degree ProjectedCSTypeGeoKey (Short,1): User-Defined ProjectionGeoKey (Short,1): User-Defined ProjCoordTransGeoKey (Short,1): CT_Equirectangular ProjLinearUnitsGeoKey (Short,1): User-Defined ProjLinearUnitSizeGeoKey (Double,1): 0.0174532925 ProjFalseEastingGeoKey (Double,1): 0 ProjFalseNorthingGeoKey (Double,1): 0 ProjCenterLongGeoKey (Double,1): 142 ProjCenterLatGeoKey (Double,1): 30 End_Of_Keys. End_Of_Geotiff. Projection Method: CT_Equirectangular ProjCenterLatGeoKey: 30.000000 ( 30d 0' 0.00"N) ProjCenterLongGeoKey: 142.000000 (142d 0' 0.00"E) ProjFalseEastingGeoKey: 0.000000 m ProjFalseNorthingGeoKey: 0.000000 m GCS: 4326/WGS 84 Datum: 6326/World Geodetic System 1984 Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31) Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E) Corner Coordinates: Upper Left ( -180.000, 73.000) (141d59'53.28"E, 0d 0' 2.36"N) Lower Left ( -180.000, -73.022) (141d59'53.28"E, 0d 0' 2.36"S) Upper Right ( 179.978, 73.000) (142d 0' 6.72"E, 0d 0' 2.36"N) Lower Right ( 179.978, -73.022) (142d 0' 6.72"E, 0d 0' 2.36"S) Center ( -0.011, -0.011) (141d60' 0.00"E, 0d 0' 0.00"S)* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090306/058389cf/attachment-0001.html From lucafasano at interfree.it Sat Mar 7 07:34:02 2009 From: lucafasano at interfree.it (LFas) Date: Sat Mar 7 07:34:15 2009 Subject: [gdal-dev] Re: HDF5 library References: <1236360785653-2437048.post@n2.nabble.com> <49B1610B.5010503@pobox.com> Message-ID: Frank Warmerdam pobox.com> writes: > > LFas wrote: > > Hi list, > > I tried to create a dll only for hdf5 gdal files, i.e. 3 files in frmts/hdf5 > > which I modified. > > I use MS Visual Studio 2008 and tried to do it with makfile.vc and obviously > > included nmake.opt. Once I defined GDAL_ROOT, HDF5_DIR, SZIP_DIR, HDF5_LIB > > as $(HDF5_DIR)\dll\hdf5dll.lib \ $(SZIP_DIR)\dll\szlibdll.lib , I done > > nmake -f makefile.vc and it tells me the file "sys\types.h" cannot be found. > > In fact it isn't present in hdf5 folder. Where I'm wrong? > It might be > possible for you to use it, but it might be better for you to review > what you are using for HDF5 libraries and include files. > > In fact, you could likely fairly easily use the HDF5 packages prepared > for OSGeo4W. > > I assume you are working to build an HDF5 plugin for GDAL? > > Best regards, Yes, obviously I'm building an HDF5 plugin for GDAL with modified sources. As you suggested me, I've reviewed include files and they lacked in MSVC .h files. So I added them and now all seems to work correctly. Thanks Best regards From monshi at home.se Sat Mar 7 10:16:34 2009 From: monshi at home.se (Tomas R) Date: Sat Mar 7 10:16:49 2009 Subject: [gdal-dev] Re: Building 64 bit, Swig Error In-Reply-To: References: Message-ID: Thanks, it works. Just set the path. Proj4 I think I will grab from your compilation. Should work good enough. I will compile GDAL myself to keep it minimal. Only need the Proj4 library as far as I know. Sadly, it seems a straight upgrade from, 1.5 is not possible. That is, my use of GDAL is to create a plugin to SportTracks making GDAL available to other plugins. Plugins linked via csharp libraries to 1.5 version seems not to find the 1.6 version, they will need to be updated to work. That's just how it is I guess. Thanks /Tomas Tamas Szekeres skrev: > > > If you use my SDK just download and extract the proj4 package (eg. > proj-4.6.1) within the SDK root directory and use: > > nmake proj PROJ_DIR=proj-4.6.1 > > > The Makefile will set the compiler version and the WIN64 setting > seemlessly. > > It seems like the @SET FrameworkDir=Framework32 should point to the > absolute path of the framework directory (ie > C:\WINDOWS\Microsoft.NET\Framework) in your batch file. > > > Best regards, > > Tamas > > ------------------------------------------------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From szekerest at gmail.com Sat Mar 7 10:27:40 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Sat Mar 7 10:27:43 2009 Subject: [gdal-dev] Re: Building 64 bit, Swig Error In-Reply-To: References: Message-ID: I think you'd just have to replace the reference to this version of gdal_csharp.dll and recompile the project. Best regards, Tamas 2009/3/7 Tomas R > Thanks, it works. Just set the path. > > Proj4 I think I will grab from your compilation. Should work good enough. I > will compile GDAL myself to keep it minimal. Only need the Proj4 library as > far as I know. > > Sadly, it seems a straight upgrade from, 1.5 is not possible. That is, my > use of GDAL is to create a plugin to SportTracks making GDAL available to > other plugins. Plugins linked via csharp libraries to 1.5 version seems not > to find the 1.6 version, they will need to be updated to work. > That's just how it is I guess. > Thanks > /Tomas > > > Tamas Szekeres skrev: > >> >> >> If you use my SDK just download and extract the proj4 package (eg. >> proj-4.6.1) within the SDK root directory and use: >> >> nmake proj PROJ_DIR=proj-4.6.1 >> >> >> The Makefile will set the compiler version and the WIN64 setting >> seemlessly. >> >> It seems like the @SET FrameworkDir=Framework32 should point to the >> absolute path of the framework directory (ie >> C:\WINDOWS\Microsoft.NET\Framework) in your batch file. >> >> >> Best regards, >> >> Tamas >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090307/b9f38348/attachment.html From monshi at home.se Sat Mar 7 11:47:20 2009 From: monshi at home.se (Tomas R) Date: Sat Mar 7 11:47:40 2009 Subject: [gdal-dev] Re: Building 64 bit, Swig Error In-Reply-To: References: Message-ID: Yes, you are correct. But is not only me who make use of the GDAL-plugin. It not easy to get all plugin updated and get all users to updated both gdal and the plugins using gdal. /Tomas Tamas Szekeres skrev: > I think you'd just have to replace the reference to this version of > gdal_csharp.dll and recompile the project. > > Best regards, > > Tamas > > > > 2009/3/7 Tomas R > > > Thanks, it works. Just set the path. > > Proj4 I think I will grab from your compilation. Should work good > enough. I will compile GDAL myself to keep it minimal. Only need > the Proj4 library as far as I know. > > Sadly, it seems a straight upgrade from, 1.5 is not possible. That > is, my use of GDAL is to create a plugin to SportTracks making > GDAL available to other plugins. Plugins linked via csharp > libraries to 1.5 version seems not to find the 1.6 version, they > will need to be updated to work. > That's just how it is I guess. > Thanks > /Tomas > > > Tamas Szekeres skrev: > > > > If you use my SDK just download and extract the proj4 package > (eg. proj-4.6.1) within the SDK root directory and use: > > nmake proj PROJ_DIR=proj-4.6.1 > > > The Makefile will set the compiler version and the WIN64 > setting seemlessly. > > It seems like the @SET FrameworkDir=Framework32 should point > to the absolute path of the framework directory (ie > C:\WINDOWS\Microsoft.NET\Framework) in your batch file. > > > Best regards, > > Tamas > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From dgplinux at yahoo.com Sat Mar 7 22:49:44 2009 From: dgplinux at yahoo.com (x y) Date: Sat Mar 7 22:56:27 2009 Subject: [gdal-dev] Please stop sending mails Message-ID: <328753.42293.qm@web52812.mail.re2.yahoo.com> Dear Sir, I keep getting all GDAL forum queries.Can you stop sending them.Becuase my mail box is full of messages from GDAL community. Thank You From neteler at osgeo.org Sun Mar 8 00:33:21 2009 From: neteler at osgeo.org (Markus Neteler) Date: Sun Mar 8 00:33:24 2009 Subject: [gdal-dev] Please stop sending mails In-Reply-To: <328753.42293.qm@web52812.mail.re2.yahoo.com> References: <328753.42293.qm@web52812.mail.re2.yahoo.com> Message-ID: <86782b610903072133i26a9ace3i36e9cf462efbfe4f@mail.gmail.com> On Sun, Mar 8, 2009 at 4:49 AM, x y wrote: > > Dear Sir, > > ? ? ? ? ? ?I keep getting all GDAL forum queries.Can you stop sending them.Becuase my mail box is full of messages from GDAL community. You can unsubscribe here: http://lists.osgeo.org/mailman/listinfo/gdal-dev (see page bottom) Markus From peifer at gmx.eu Sun Mar 8 01:22:26 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Sun Mar 8 01:22:30 2009 Subject: [gdal-dev] ogr2ogr: shp > kml, coordinate precision and related kml file size Message-ID: <49B36422.3040908@gmx.eu> Hi All, I am experimenting with establishing a web-based shapefile-to-kml converter, where ogr2ogr is doing the actual conversion job in the background. I am interested in generating small kml files, as obviously both server and clients will appreciate. After some testing I see that I could easily reduce the kml file size to about half, if I could influence the precision of the transformed coordinate values (the transformation is always to WGS84). An example from a shp > kml conversion, including a SWEREF99 > WGS84 coordinate transformation: 13.457676473320388,55.803540172099304,-0.000071634377946 .... Question: In my context, Lat/Lon values with 6 decimals are just about enough precision. I feel that I am pumping a lot of meaningless numbers into the kml file, which makes it big. Is there an option to reduce the number of decimals for transformed coordinates? Another question, which is more a wild guess: My target SRS is EPSG:4326, in other words: a 2D CRS. However, ogr2ogr's kml file comes with height values like "-0.000071634377946". My guess is that the height coordinate is some transformation result related to the fact that WGS84 and SWEREF99 are using slightly different ellipsoids. However, and based on my limited understanding: I do not need 3 numbers to describe a point in a 2D system, do I? How can I strip the height coordinate (and why is it there in the first place?). Regards, Hermann Here the SWEREF prj info from the mentioned shapefile Layer SRS WKT: PROJCS["SWEREF99_TM", GEOGCS["GCS_SWEREF99", DATUM["SWEREF99", SPHEROID["GRS_1980",6378137.0,298.257222101]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",500000.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",15.0], PARAMETER["Scale_Factor",0.9996], PARAMETER["Latitude_Of_Origin",0.0], UNIT["Meter",1.0]] From antonio.valentino at tiscali.it Sun Mar 8 08:30:05 2009 From: antonio.valentino at tiscali.it (Antonio Valentino) Date: Sun Mar 8 08:31:25 2009 Subject: [gdal-dev] Creating derived raster bands using python In-Reply-To: <49AFE12B.2090601@pobox.com> References: <20090305145325.18b43c8c@valentinows> <49AFE12B.2090601@pobox.com> Message-ID: <20090308133005.5a260e27@tiscali.it> Il giorno Thu, 05 Mar 2009 09:26:51 -0500 Frank Warmerdam ha scritto: > Antonio Valentino wrote: > > Hi list, > > I'm trying to create a *Derived* raster band in a virtual dataset. > > > > All my attempts seems to fail: > > > >>>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) > > > > raises an exception while > > > >>>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') > >>>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) > > Antonio, > > I believe the correct syntax is: > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > The options should be a list of name=value pairs. Your extra double > quotes within the string will make the class name comparison fail > since you are effectively passing "\"VRTDerivedRasterBand\"" in C > terms. > > Best regards, Hi Frank, thanks for helping. I'm still having problems trying to create a derived raster bands via python. I'm using Ubuntu 8.10 $ uname -a Linux mac1 2.6.27-13-generic #1 SMP Thu Feb 26 07:31:49 UTC 2009 x86_64 GNU/Linux with GDAL 1.5.4 package from UbuntuGIS repo (python-gdal_1.5.4-2~intreid3). The execution of the following test script produces a segmentation fault: ### BEGIN CODE from osgeo import gdal driver = gdal.GetDriverByName('VRT') source_xml = ''' test.tif ''' md = {'Description': 'Magnitude', 'PixelFunctionType': 'module', 'source_0': source_xml} ds = driver.Create('test.vrt', 100, 100) b = ds.GetRasterBand(1) b.SetMetadata({'source_0': source_xml}, 'new_vrt_sources') ds.AddBand(options=['subClass=VRTDerivedRasterBand']) b = ds.GetRasterBand(2) b.SetMetadata(md, 'new_vrt_sources') del ds print open('test.vrt').read() ### END CODE $ python test_derivedband.py ERROR 1: Corrupt or empty VRT source XML document. Segmentation fault Maybe I'm still doing something wrong but the segfault is anomalous in any case. Should I create a ticket for this? Regards -- Antonio Valentino From peifer at gmx.eu Sun Mar 8 14:26:17 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Sun Mar 8 14:30:07 2009 Subject: [gdal-dev] ogr2ogr: Dataset creation option (format specific) Message-ID: Hi, The ogr2ogr man page has some limited documentation on the -dsco switch: -dsco NAME=VALUE: Dataset creation option (format specific) Can someone point me to some more specific information? Thanks in advance, Hermann From even.rouault at mines-paris.org Sun Mar 8 15:22:13 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 8 15:22:23 2009 Subject: [gdal-dev] ogr2ogr: Dataset creation option (format specific) In-Reply-To: References: Message-ID: <200903082022.13888.even.rouault@mines-paris.org> Hermann, As suggested by the man page of ogr2ogr, dataset creation options are specific to each driver. So you have to look at the documentation of the OGR driver you're interested in to see which dataset creation options it offers : http://gdal.org/ogr/ogr_formats.html Even Le Sunday 08 March 2009 19:26:17 Hermann Peifer, vous avez ?crit?: > Hi, > > The ogr2ogr man page has some limited documentation on the -dsco switch: > > -dsco NAME=VALUE: Dataset creation option (format specific) > > Can someone point me to some more specific information? > > Thanks in advance, Hermann > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Sun Mar 8 15:51:46 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 8 15:51:57 2009 Subject: [gdal-dev] Creating derived raster bands using python In-Reply-To: <20090308133005.5a260e27@tiscali.it> References: <20090305145325.18b43c8c@valentinows> <49AFE12B.2090601@pobox.com> <20090308133005.5a260e27@tiscali.it> Message-ID: <200903082051.47363.even.rouault@mines-paris.org> Antonio, There are 2 issues : - the "ERROR 1: Corrupt or empty VRT source XML document." comes from the line 'b.SetMetadata(md, 'new_vrt_sources')'. However I'm not sure how to achieve what you want to do. I've the feeling you can't really define the pixel function that way. You should call GDALAddDerivedBandPixelFunc to do that, but as it is not available in Python bindings, I think you're only solution is to generate the whole XML at hand. - the crash comes from the fact that you don't have defined a pixel function for the derived band. I've created ticket http://trac.osgeo.org/gdal/ticket/2877 about that one. Best regards, Even Le Sunday 08 March 2009 13:30:05 Antonio Valentino, vous avez ?crit?: > Il giorno Thu, 05 Mar 2009 09:26:51 -0500 > > Frank Warmerdam ha scritto: > > Antonio Valentino wrote: > > > Hi list, > > > I'm trying to create a *Derived* raster band in a virtual dataset. > > > > > > All my attempts seems to fail: > > >>>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) > > > > > > raises an exception while > > > > > >>>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') > > >>>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) > > > > Antonio, > > > > I believe the correct syntax is: > > > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > > > The options should be a list of name=value pairs. Your extra double > > quotes within the string will make the class name comparison fail > > since you are effectively passing "\"VRTDerivedRasterBand\"" in C > > terms. > > > > Best regards, > > Hi Frank, > thanks for helping. > > I'm still having problems trying to create a derived raster bands via > python. > I'm using Ubuntu 8.10 > > $ uname -a > Linux mac1 2.6.27-13-generic #1 SMP Thu Feb 26 07:31:49 UTC 2009 x86_64 > GNU/Linux > > with GDAL 1.5.4 package from UbuntuGIS repo > (python-gdal_1.5.4-2~intreid3). > > The execution of the following test script produces a segmentation > fault: > > ### BEGIN CODE > from osgeo import gdal > driver = gdal.GetDriverByName('VRT') > source_xml = ''' > test.tif > ''' > > md = {'Description': 'Magnitude', 'PixelFunctionType': 'module', > 'source_0': source_xml} > > ds = driver.Create('test.vrt', 100, 100) > b = ds.GetRasterBand(1) > b.SetMetadata({'source_0': source_xml}, 'new_vrt_sources') > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > b = ds.GetRasterBand(2) > b.SetMetadata(md, 'new_vrt_sources') > del ds > print open('test.vrt').read() > ### END CODE > > $ python test_derivedband.py > ERROR 1: Corrupt or empty VRT source XML document. > Segmentation fault > > > Maybe I'm still doing something wrong but the segfault is anomalous in > any case. > > Should I create a ticket for this? > > > Regards From even.rouault at mines-paris.org Sun Mar 8 16:01:15 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 8 16:01:24 2009 Subject: [gdal-dev] Creating derived raster bands using python In-Reply-To: <200903082051.47363.even.rouault@mines-paris.org> References: <20090305145325.18b43c8c@valentinows> <20090308133005.5a260e27@tiscali.it> <200903082051.47363.even.rouault@mines-paris.org> Message-ID: <200903082101.15484.even.rouault@mines-paris.org> Forget what I told about GDALAddDerivedBandPixelFunc ... This is certainly not the way to define the function name. Le Sunday 08 March 2009 20:51:46 Even Rouault, vous avez ?crit?: > Antonio, > > There are 2 issues : > - the "ERROR 1: Corrupt or empty VRT source XML document." comes from the > line 'b.SetMetadata(md, 'new_vrt_sources')'. However I'm not sure how to > achieve what you want to do. I've the feeling you can't really define the > pixel function that way. You should call GDALAddDerivedBandPixelFunc to do > that, but as it is not available in Python bindings, I think you're only > solution is to generate the whole XML at hand. > > - the crash comes from the fact that you don't have defined a pixel > function for the derived band. I've created ticket > http://trac.osgeo.org/gdal/ticket/2877 about that one. > > Best regards, > Even > > Le Sunday 08 March 2009 13:30:05 Antonio Valentino, vous avez ?crit?: > > Il giorno Thu, 05 Mar 2009 09:26:51 -0500 > > > > Frank Warmerdam ha scritto: > > > Antonio Valentino wrote: > > > > Hi list, > > > > I'm trying to create a *Derived* raster band in a virtual dataset. > > > > > > > > All my attempts seems to fail: > > > >>>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) > > > > > > > > raises an exception while > > > > > > > >>>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') > > > >>>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) > > > > > > Antonio, > > > > > > I believe the correct syntax is: > > > > > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > > > > > The options should be a list of name=value pairs. Your extra double > > > quotes within the string will make the class name comparison fail > > > since you are effectively passing "\"VRTDerivedRasterBand\"" in C > > > terms. > > > > > > Best regards, > > > > Hi Frank, > > thanks for helping. > > > > I'm still having problems trying to create a derived raster bands via > > python. > > I'm using Ubuntu 8.10 > > > > $ uname -a > > Linux mac1 2.6.27-13-generic #1 SMP Thu Feb 26 07:31:49 UTC 2009 x86_64 > > GNU/Linux > > > > with GDAL 1.5.4 package from UbuntuGIS repo > > (python-gdal_1.5.4-2~intreid3). > > > > The execution of the following test script produces a segmentation > > fault: > > > > ### BEGIN CODE > > from osgeo import gdal > > driver = gdal.GetDriverByName('VRT') > > source_xml = ''' > > test.tif > > ''' > > > > md = {'Description': 'Magnitude', 'PixelFunctionType': 'module', > > 'source_0': source_xml} > > > > ds = driver.Create('test.vrt', 100, 100) > > b = ds.GetRasterBand(1) > > b.SetMetadata({'source_0': source_xml}, 'new_vrt_sources') > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > b = ds.GetRasterBand(2) > > b.SetMetadata(md, 'new_vrt_sources') > > del ds > > print open('test.vrt').read() > > ### END CODE > > > > $ python test_derivedband.py > > ERROR 1: Corrupt or empty VRT source XML document. > > Segmentation fault > > > > > > Maybe I'm still doing something wrong but the segfault is anomalous in > > any case. > > > > Should I create a ticket for this? > > > > > > Regards > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From antonio.valentino at tiscali.it Sun Mar 8 16:41:55 2009 From: antonio.valentino at tiscali.it (Antonio Valentino) Date: Sun Mar 8 16:42:22 2009 Subject: [gdal-dev] Creating derived raster bands using python In-Reply-To: <200903082051.47363.even.rouault@mines-paris.org> References: <20090305145325.18b43c8c@valentinows> <49AFE12B.2090601@pobox.com> <20090308133005.5a260e27@tiscali.it> <200903082051.47363.even.rouault@mines-paris.org> Message-ID: <20090308214155.2c874ff3@tiscali.it> Il giorno Sun, 8 Mar 2009 20:51:46 +0100 Even Rouault ha scritto: > Antonio, > > There are 2 issues : [cut] > - the crash comes from the fact that you don't have defined a pixel > function for the derived band. I've created ticket > http://trac.osgeo.org/gdal/ticket/2877 about that one. Even, I didn't say in previous post but the test.tif actually exists and the pixel function "module" is defined. I did it via a fake plugin that registers pixel-functions and then put it in the GDAL_DRIVER_PATH. If I manually write the VRT file all works well: $ cat test1.vrt Magnitude module test.tif 1 $ gdal_translate test1.vrt out.tif Input file size is 100, 100 0...10...20...30...40...50...60...70...80...90...100 - done. I'm just not able to write the VRT file using python. thanks for help > Le Sunday 08 March 2009 13:30:05 Antonio Valentino, vous avez ?crit?: > > Il giorno Thu, 05 Mar 2009 09:26:51 -0500 > > > > Frank Warmerdam ha scritto: > > > Antonio Valentino wrote: > > > > Hi list, > > > > I'm trying to create a *Derived* raster band in a virtual > > > > dataset. > > > > > > > > All my attempts seems to fail: > > > >>>> ds.AddBand(options={'subClass': 'VRTDerivedRasterBand'}) > > > > > > > > raises an exception while > > > > > > > >>>> ds.AddBand(options='subClass="VRTDerivedRasterBand"') > > > >>>> ds.AddBand(options=['subClass="VRTDerivedRasterBand"']) > > > > > > Antonio, > > > > > > I believe the correct syntax is: > > > > > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > > > > > The options should be a list of name=value pairs. Your extra > > > double quotes within the string will make the class name > > > comparison fail since you are effectively passing > > > "\"VRTDerivedRasterBand\"" in C terms. > > > > > > Best regards, > > > > Hi Frank, > > thanks for helping. > > > > I'm still having problems trying to create a derived raster bands > > via python. > > I'm using Ubuntu 8.10 > > > > $ uname -a > > Linux mac1 2.6.27-13-generic #1 SMP Thu Feb 26 07:31:49 UTC 2009 > > x86_64 GNU/Linux > > > > with GDAL 1.5.4 package from UbuntuGIS repo > > (python-gdal_1.5.4-2~intreid3). > > > > The execution of the following test script produces a segmentation > > fault: > > > > ### BEGIN CODE > > from osgeo import gdal > > driver = gdal.GetDriverByName('VRT') > > source_xml = ''' > > test.tif > > ''' > > > > md = {'Description': 'Magnitude', 'PixelFunctionType': 'module', > > 'source_0': source_xml} > > > > ds = driver.Create('test.vrt', 100, 100) > > b = ds.GetRasterBand(1) > > b.SetMetadata({'source_0': source_xml}, 'new_vrt_sources') > > ds.AddBand(options=['subClass=VRTDerivedRasterBand']) > > b = ds.GetRasterBand(2) > > b.SetMetadata(md, 'new_vrt_sources') > > del ds > > print open('test.vrt').read() > > ### END CODE > > > > $ python test_derivedband.py > > ERROR 1: Corrupt or empty VRT source XML document. > > Segmentation fault > > > > > > Maybe I'm still doing something wrong but the segfault is anomalous > > in any case. > > > > Should I create a ticket for this? > > > > > > Regards > > -- Antonio Valentino From legeochen at gmail.com Sun Mar 8 23:00:58 2009 From: legeochen at gmail.com (legeochen) Date: Sun Mar 8 23:01:01 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: References: Message-ID: Wow: I have tried your suggestion. but it won't work. It seems the shp file create by ogr is a little different from which generated with shplib. reading shp file ceated by ogr with shplib gives me warning like the dbf. containe different record than shp. Actually, only the first geometry can be read out. 2009/3/3 legeochen > Wow: > Tanks for your suggestion! Yeaph! That maybe where the rub is. I will try > it out soon. > cheers! > > 2009/3/3 wow <27949218@qq.com> > > Hi, >> Your code looks like that you didn't create any field for the feature. At >> least create one field would ensure success. >> Like this: >> OGRFieldDefn oField( "Name", OFTString ); >> oField.SetWidth(32); >> if( pLayer->CreateField( &oField ) != OGRERR_NONE ) >> { >> printf( "Creating Name field failed.\n" ); >> exit( 1 ); >> } >> >> Xuexia Chen >> ------------------ >> To the world you're little, but to a person, maybe you're the world. >> >> >> >> >> ------------------ Original ------------------ >> *From: * "legeochen"; >> *Date: * Fri, Feb 27, 2009 09:47 PM >> *To: * "Gdal-Dev"; >> *Subject: * [gdal-dev] create 25D MultiPolygon how to >> >> Hi All >> I try to create some multipolygons?with OGR.?After creating them, but when >> I want view them in arcscene, it just make arcscene crash! Then I tried >> osgviewer with ESRI Shapefile, I was warned: >> ESRIShape loader: .dbf file containe different record number that .shp >> file. >> ???????????????????????????? .dbf record skipped. >> Actually, only one feature in the dataset had been readed out. >> Then, I tried osgviewer with ogr, got warnings like this: >> Warning something wrong with a polygon in a multi polygon. >> And, the result is not quite as expected! >> Here is?my code: >> ?const char* pszDriverName = "ESRI Shapefile"; >> ?OGRSFDriver *poDriver; >> ?OGRRegisterAll(); >> ??? poDriver = OGRSFDriverRegistrar::GetRegistrar()->GetDriverByName( >> ??????????????? pszDriverName ); >> ??? if( poDriver == NULL ) >> ??? { >> ??????? printf( "%s driver not available.\n", pszDriverName ); >> ??????? return false; >> ??? } >> ?OGRDataSource *poDS; >> ?poDS = poDriver->Open(shpfile,TRUE); >> ?if(poDS == NULL) >> ??poDS = poDriver->CreateDataSource(shpfile,NULL); >> ?if(poDS == NULL) >> ?{ >> ??printf("Creation of output file failed.\n"); >> ??return false; >> ?} >> ?OGRLayer* poLayer = poDS->GetLayerByName (layername); >> ?if(poLayer == NULL) >> ?{ >> ??if( !poDS->TestCapability( ODsCCreateLayer ) ) >> ??????? { >> ??????????? fprintf( stderr, >> ????????????? "Layer Roadway not found, and CreateLayer not supported by >> driver." ); >> ??????????? return FALSE; >> ??????? } >> ??CPLErrorReset(); >> ??poLayer = poDS->CreateLayer(layername,NULL,wkbMultiPolygon25D,NULL); >> ??if(poLayer == NULL) >> ??{ >> ???printf( "Layer creation failed.\n" ); >> ???return false; >> ??} >> ?} >> >> ?for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != >> _roadwayArr.end();itrw++) >> ?{ >> ??OGRFeature *poFeature; >> ?? >> ??OGRMultiPolygon multiPoly; >> ??poFeature = OGRFeature::CreateFeature(poLayer->GetLayerDefn()); >> ??Roadway::Triangle_list tris = (*itrw)->getTrianglelist(); >> ??for(Triangle_list::const_iterator ittri = tris.begin();ittri != >> tris.end();ittri++) >> ??{ >> ???OGRPolygon polygon; >> ???OGRLinearRing poRing; >> ???poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); >> ???poRing.addPoint((*ittri).b().x(),(*ittri).b().y(),(*ittri).b().z()); >> ???poRing.addPoint((*ittri).c().x(),(*ittri).c().y(),(*ittri).c().z()); >> ???poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); >> ??? >> ???polygon.addRing(&poRing); >> ???multiPoly.addGeometry(&polygon); >> ??? >> ??} >> ??poFeature->SetGeometry(&multiPoly); >> ??if( poLayer->CreateFeature( poFeature ) != OGRERR_NONE ) >> ??{ >> ???printf( "Failed to create feature in shapefile.\n" );?????? >> ???return false; >> ??} >> ??OGRFeature::DestroyFeature( poFeature ); >> ?} >> ?OGRDataSource::DestroyDataSource( poDS ); >> Any help is appreciated!!? >> ? >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090309/7febb5c2/attachment-0001.html From peifer at gmx.eu Mon Mar 9 02:27:27 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Mon Mar 9 02:27:45 2009 Subject: [gdal-dev] Re: ogr2ogr: Dataset creation option (format specific) In-Reply-To: <200903082022.13888.even.rouault@mines-paris.org> References: <200903082022.13888.even.rouault@mines-paris.org> Message-ID: Even Rouault wrote: > Hermann, > > As suggested by the man page of ogr2ogr, dataset creation options are specific > to each driver. So you have to look at the documentation of the OGR driver > you're interested in to see which dataset creation options it offers : > http://gdal.org/ogr/ogr_formats.html > Even, Thanks for the hint. I should have been able to find this page myself. I was actually hoping to find some KML driver options which would allow me to remove meaningless coordinate precision from the KML output. Unfortunately there aren't any such options at http://gdal.org/ogr/drv_kml.html Hermann From warmerdam at pobox.com Mon Mar 9 11:48:31 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 9 11:48:33 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer Message-ID: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Motion: Chaitanya Kumar CH is granted GDAL commit permissions. -- Chaitanya has provided several patches including for the BSB driver. He has also been tracking down various other bugs. I am also hoping to present him shortly as a candidate for the GDAL paid maintainer role. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Mon Mar 9 12:11:26 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 9 12:11:27 2009 Subject: [gdal-dev] Re: Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: <931f8ea90903090911g18d1f072m1902faba0c06af68@mail.gmail.com> On Mon, Mar 9, 2009 at 11:48 AM, Frank Warmerdam wrote: > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. Folks, I meant to mention that Chaitanya has review the RFC on committer guidelines and has agreed to adhere to them. I am +1 on the motion. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From szekerest at gmail.com Mon Mar 9 12:16:24 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Mon Mar 9 12:16:27 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: +1 Tamas 2009/3/9 Frank Warmerdam > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. > > -- > > Chaitanya has provided several patches including for the BSB driver. > He has also been tracking down various other bugs. > > I am also hoping to present him shortly as a candidate for the > GDAL paid maintainer role. > > Best regards, > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090309/d454624e/attachment.html From condit at sdsc.edu Mon Mar 9 13:25:42 2009 From: condit at sdsc.edu (Christopher Condit) Date: Mon Mar 9 13:25:44 2009 Subject: [gdal-dev] ogr2ogr: shp > kml, coordinate precision and related kml file size In-Reply-To: <49B36422.3040908@gmx.eu> References: <49B36422.3040908@gmx.eu> Message-ID: <845AADAC1106E44996327D62097E4C6B012BB5DD@et.ad.sdsc.edu> Hi Hermann, > In my context, Lat/Lon values with 6 decimals are just about enough > precision. I feel that I am pumping a lot of meaningless numbers into > the kml file, which makes it big. Is there an option to reduce the > number of decimals for transformed coordinates? See http://trac.osgeo.org/gdal/ticket/2461 for information about this... > However, and based on my limited understanding: I do not need 3 numbers > to describe a point in a 2D system, do I? How can I strip the height > coordinate (and why is it there in the first place?). I think you can use the nlt option to at least make the input 2.5 D and then strip the Z value off, effectively removing the height. It may be related to the CS transformation but I'm not sure without seeing your actual input file. -Chris From hobu.inc at gmail.com Mon Mar 9 13:36:56 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Mon Mar 9 13:37:01 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: <8C561077-8794-4D11-B619-8E7A151398F3@gmail.com> +1 Howard On Mar 9, 2009, at 11:16 AM, Tamas Szekeres wrote: > +1 > > Tamas > > > > 2009/3/9 Frank Warmerdam > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. > > -- > > Chaitanya has provided several patches including for the BSB driver. > He has also been tracking down various other bugs. > > I am also hoping to present him shortly as a candidate for the > GDAL paid maintainer role. > > Best regards, > -- > --------------------------------------- > +-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@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 mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From peifer at gmx.eu Mon Mar 9 14:12:07 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Mon Mar 9 14:13:52 2009 Subject: [gdal-dev] ogr2ogr: shp > kml,coordinate precision and related kml file size In-Reply-To: <845AADAC1106E44996327D62097E4C6B012BB5DD@et.ad.sdsc.edu> References: <49B36422.3040908@gmx.eu> <845AADAC1106E44996327D62097E4C6B012BB5DD@et.ad.sdsc.edu> Message-ID: <49B55BF7.6060005@gmx.eu> Christopher Condit wrote: > See http://trac.osgeo.org/gdal/ticket/2461 for information about this... > I can only confirm with what is stated at the end of this page: > We should attempt to preserve the original precision by default, > and potentially offer an option to reduce the precision. > I think you can use the nlt option to at least make the input 2.5 D and > then strip the Z value off, effectively removing the height. It may be > related to the CS transformation but I'm not sure without seeing your > actual input file. > Thanks for the hint. I will give it a try. For an input file, you could take any shapefile at: http://tinyurl.com/c56uch Hermann From even.rouault at mines-paris.org Mon Mar 9 14:35:53 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 9 14:36:04 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: <200903091935.54242.even.rouault@mines-paris.org> +1 Best regards, Even Le Monday 09 March 2009 16:48:31 Frank Warmerdam, vous avez ?crit?: > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. > > -- > > Chaitanya has provided several patches including for the BSB driver. > He has also been tracking down various other bugs. > > I am also hoping to present him shortly as a candidate for the > GDAL paid maintainer role. > > Best regards, From even.rouault at mines-paris.org Mon Mar 9 14:57:42 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 9 14:57:50 2009 Subject: [gdal-dev] Re: gdal - java In-Reply-To: <200903091953.36078.even.rouault@mines-paris.org> References: <8b07782c0903090629h437e56d8j5520bd9bb508c829@mail.gmail.com> <931f8ea90903090752h4a74aac9if6ad0602e5aaf322@mail.gmail.com> <200903091953.36078.even.rouault@mines-paris.org> Message-ID: <200903091957.42485.even.rouault@mines-paris.org> Wanted to CC the list in the first place as it might be of general interest... Le Monday 09 March 2009 19:53:35, vous avez ?crit?: > Paul, > > Frank has already almost said everything ;-) > > You need to be able to build (or get): > - GDAL/OGR with OGDI support > - the Java bindings by folllowing the hints given on the wiki > http://trac.osgeo.org/gdal/wiki/GdalOgrInJava. > > http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogrinfo.java > is indeed the closest example for your needs. > > I'm currently in the process to feed the Javadoc of the Java bindings. They > can be found at http://gdal.org/java/. The OGR part, the one you want to > use, is still incomplete however, but it should be relatively > straightforward to guess what a Java method does by reading the doc of the > corresponding C++ method at : http://gdal.org/ogr/hierarchy.html. > You should also be aware that some methods in them only apply to the > current development versions,. > > As Frank noted, the state of the Java bindings in recent released versions > of GDAL/OGR is partly broken/incomplete. The above ogrinfo.java in its > current state will not compile out of the box with GDAL/OGR <= 1.6.0, > although you should be able to get the gist of it to work by > adapting/commenting out some parts. > > Best regards > > Le Monday 09 March 2009 15:52:09 Frank Warmerdam, vous avez ?crit?: > > On Mon, Mar 9, 2009 at 9:29 AM, Paul Malm wrote: > > > Mr Warmedam, > > > I'm sorry to bother you again, I got your mail about VPF readers in > > > java. I have not found any good ones yet... but I can see that you have > > > a java version of your GDAL/OGR library. The problem is that I do not > > > understand how to use it, is there a explanation on some wiki or > > > likewise? I can't understand how to use the Java bindings from > > > http://trac.osgeo.org/gdal/wiki/GdalOgrInJava > > > I would be happy to just read maps/charts in VPF/S57 format. > > > > Paul, > > > > There is VPF reading code in OpenMap from BBN, and I was > > vaguely under the impression there was VPF support in > > GeoTools as well (both in Java). > > > > Using the GDAL Java bindings can be moderately involved. > > > > The url you quote is a good start for example Java code, and > > (I think) build hints. You will still need to be familiar with the > > general OGR data model, and API which are described at: > > > > http://www.gdal.org/ogr/ogr_arch.html > > http://www.gdal.org/ogr/ogr_apitut.html > > > > Possibly the best example Java OGR program is: > > > > http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogrinfo.java > > > > It is sometimes difficult to get a build of all the components to > > use GDAL/OGR from Java. The OSGeo4W distribution includes > > Java bindings support, but it is a bit outdated and is windows > > only. If that is sufficient for your needs you can find OSGeo4W > > at the following url, and you would need the gdal, and gdal-java > > packages (through advanced install): > > > > http://osgeo4w.osgeo.org/ > > > > There have been many improvements by Even Rouault > > to the Java bindings in recent weeks, but you would need > > to build things from source which is not always easy. It > > might be best to followup with Even (perhaps on the gdal-dev > > mailing list) if you have additional questions. > > > > Best regards, > > > > ---------------------------------------+--------------------------------- > >-- --- I set the clouds in motion - turn up | Frank Warmerdam, > > warmerdam@pobox.com light and sound - activate the windows | > > http://pobox.com/~warmerdam and watch the world go round - Rush | > > Geospatial Programmer for Rent From didier.richard at ign.fr Mon Mar 9 15:41:03 2009 From: didier.richard at ign.fr (RICHARD Didier) Date: Mon Mar 9 15:41:16 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <8C561077-8794-4D11-B619-8E7A151398F3@gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> <8C561077-8794-4D11-B619-8E7A151398F3@gmail.com> Message-ID: <33874.87.231.96.39.1236627663.squirrel@webmail.ign.fr> +1 didier > +1 > > Howard > > On Mar 9, 2009, at 11:16 AM, Tamas Szekeres wrote: > >> +1 >> >> Tamas >> >> >> >> 2009/3/9 Frank Warmerdam >> Motion: Chaitanya Kumar CH is granted GDAL commit permissions. >> >> -- >> >> Chaitanya has provided several patches including for the BSB driver. >> He has also been tracking down various other bugs. >> >> I am also hoping to present him shortly as a candidate for the >> GDAL paid maintainer role. >> >> Best regards, >> -- >> --------------------------------------- >> +-------------------------------------- >> I set the clouds in motion - turn up | Frank Warmerdam, >> warmerdam@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 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 > -- RICHARD Didier - Chef du p?le technique du G?oportail 2/4, avenue Pasteur - 94165 Saint Mand? Cedex T?l : +33 (0) 1 43 98 83 23 From bclay at ball.com Mon Mar 9 15:44:12 2009 From: bclay at ball.com (Clay, Bruce) Date: Mon Mar 9 15:45:03 2009 Subject: FW: [gdal-dev] OGR - Oracle problem Message-ID: Follow up I am not sure which is a better solution speed wise but I did find 2 solutions to the problem I was having - The first solution that appears to work is to cast the returned distance field to a real in the outer select statement select OBJECTID, cast(Dist as real) from (select OBJECTID, sdo_nn_distance(1) Dist from GEONAMES_SDO a1 where DSG LIKE 'PPL%' AND sdo_nn(a1.shape, sdo_geometry(2001, null, sdo_point_type((-84.48500000,-21.98100000, NULL), null, null), 'sdo_num_res=100',1) = 'TRUE') where Dist <= 0.09633643; The second approach that appeared to work id from as code perspective is to set the field type after the Execute SQL. I am not sure how stable this method is because the firt time I tried it after the first GetNextFeature it did not work on the first feature but did work on the rest. I guess that indicates that the change has to be performed before requesting the feature not before requesting the attribute. OGRLayer *queryLayer = outputDataSrc->ExecuteSQL(sqlquery, NULL, "generic"); if (queryLayer != NULL) { OGRFeatureDefn *featureDef = queryLayer->GetLayerDefn(); if (featureDef != NULL) { OGRFieldDefn *fieldDef = featureDef->GetFieldDefn(1); if (fieldDef != NULL) { fieldDef->SetType(OFTReal); } queryLayer->ResetReading(); OGRFeature *feature = queryLayer->GetNextFeature(); while (feature != NULL) { Bruce ________________________________ From: gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Clay, Bruce Sent: Friday, March 06, 2009 3:52 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] OGR - Oracle problem When I issue the following SQL query through SqlPal I get 2 columns of what appears to be valid data select * from (select OBJECTID, sdo_nn_distance(1) Dist from GEONAMES_SDO a1 where DSG LIKE 'PPL%' AND sdo_nn(a1.shape, sdo_geometry(2001, null, sdo_point_type(-84.48500000,-21.98100000, NULL), null, null), 'sdo_num_res=100',1) = 'TRUE'); Results OBJECTID Dist 451323 .397194968358102 432828 .647925639080596 447967 .239182235498376 453566 .495207228227733 454057 .270980772175814 392983 .165016165538413 407235 .325487083888139 408026 .647925639080596 399747 .647925639080596 399036 .325487083888139 409567 .165016165538413 423135 .239182235498376 If I issue the same query through OGR ExecuteSql I get the first column (OBJECTID) as it appears in SqlPal but the second column which should be the distance comes back as type OFTInteger and the value is always zero reguardless of where I call GetFieldAsString or GetFieldAsDouble. Is there something else that has to be specified to get the correct data type on this type of a query where a column is created dynamically? 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090309/91260fe0/attachment-0001.html From dmorissette at mapgears.com Mon Mar 9 16:13:05 2009 From: dmorissette at mapgears.com (Daniel Morissette) Date: Mon Mar 9 16:21:34 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: <49B57851.1080805@mapgears.com> Frank Warmerdam wrote: > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. > +1. Provided that he confirms on this list his understanding and acceptance of the committer guidelines in RFC 3: http://trac.osgeo.org/gdal/wiki/rfc3_commiters Daniel -- Daniel Morissette http://www.mapgears.com/ From chaitanya.ch at gmail.com Tue Mar 10 00:20:17 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Tue Mar 10 00:20:21 2009 Subject: [gdal-dev] Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <49B57851.1080805@mapgears.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> <49B57851.1080805@mapgears.com> Message-ID: I have read and understood the GDAL Commiter Guildlines in RFC 3 and the GDAL/OGR Licensing information at /trunk/gdal/LICENSE.TXT I accept all the guidelines and the individual licenses. I appreciate all the confidence the project steering committee has in me. Best regards, -- Chaitanya kumar CH. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Address: Chaitanya kumar CH # 7-2-165, Khammam, AP, 507001, India Mobile: +91-98481 67848 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From wroberts at csir.co.za Tue Mar 10 03:07:04 2009 From: wroberts at csir.co.za (Wesley Roberts) Date: Tue Mar 10 03:08:23 2009 Subject: [gdal-dev] ogr2ogr changes attribute table after projection Message-ID: <49B62DB80200007300019757@pta-emo.csir.co.za> Dear Colleagues, I have an ESRI shapefile with approximately 20 000 polygons in a geographic projection (WGS84). I have used the following command to convert the shapefile to a utm34s projection. ogr2ogr wckznwimsextract_utm34s.shp wckznwimsextract.shp -t_srs EPSG:32734 -s_srs EPSG:4326 the coordinate transformation works perfectly however the attribute data in the new shapefile is incorrect. In fact very little of the original data is present, dates in the original data are now null (two different formats 2009-01-01 & 23-Mar-2008) with other text and numerical attributes also now removed. All columns from the original data are present but none of the original data remains. If anyone could comment on this problem and or suggest a solution I would greatly appreciate it. Many thanks and kind regards, Wesley Wesley Roberts MSc. Researcher: Earth Observation (Ecosystems) Natural Resources and the Environment CSIR Tel: +27 (21) 888-2490 Fax: +27 (21) 888-2693 "To know the road ahead, ask those coming back." - Chinese proverb -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From anders.moe at geocap.no Tue Mar 10 09:49:28 2009 From: anders.moe at geocap.no (Anders Moe) Date: Tue Mar 10 09:49:30 2009 Subject: [Gdal-dev] No support for widestrings in ArcSDE driver for OGR ? In-Reply-To: <49062572.3020800@pobox.com> References: <738927440810271317h4131f91era7526ea1b3cb9481@mail.gmail.com> <49062572.3020800@pobox.com> Message-ID: <1236692968786-2455262.post@n2.nabble.com> Hi I'd be happy to test this out for for ArcSDE 9.2 (9.3 a bit later). I've just pulled the latest stable and saw no change to the ArcSDE driver related to widestrings I applied my own private patch as a workaround (attached). Regards, Anders. > I would fix it myself and submit a patch, but ironically enough, I don't > have a way to test it or compile it since I don't have ArcSDE nor ArcGIS > anywhere... should I submit a ticket? Ragi, I'm in the same position - no SDE instance to test against. A patch might be good if either Howard or Anders are willing to commit to testing it out. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@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 http://n2.nabble.com/file/n2455262/d.txt d.txt -- View this message in context: http://n2.nabble.com/No-support-for-widestrings-in-ArcSDE-driver-for-OGR---tp2036034p2455262.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From hobu.inc at gmail.com Tue Mar 10 09:54:33 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Tue Mar 10 09:54:39 2009 Subject: [Gdal-dev] No support for widestrings in ArcSDE driver for OGR ? In-Reply-To: <1236692968786-2455262.post@n2.nabble.com> References: <738927440810271317h4131f91era7526ea1b3cb9481@mail.gmail.com> <49062572.3020800@pobox.com> <1236692968786-2455262.post@n2.nabble.com> Message-ID: <23BB26CD-2247-4453-9E8D-056E3C53532C@gmail.com> Is there a ticket for this issue? If not, could you please file one and attach the patch to it? Howard On Mar 10, 2009, at 8:49 AM, Anders Moe wrote: > > Hi > > I'd be happy to test this out for for ArcSDE 9.2 (9.3 a bit later). > I've > just pulled the latest stable and saw no change to the ArcSDE driver > related > to widestrings I applied my own private patch as a workaround > (attached). > > Regards, > Anders. > >> I would fix it myself and submit a patch, but ironically enough, I >> don't >> have a way to test it or compile it since I don't have ArcSDE nor >> ArcGIS >> anywhere... should I submit a ticket? > > Ragi, > > I'm in the same position - no SDE instance to test against. A patch > might > be good if either Howard or Anders are willing to commit to testing > it out. > > Best regards, > > -- > --------------------------------------- > +-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@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 > > > http://n2.nabble.com/file/n2455262/d.txt d.txt > -- > View this message in context: http://n2.nabble.com/No-support-for-widestrings-in-ArcSDE-driver-for-OGR---tp2036034p2455262.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From simone.giannecchini at geo-solutions.it Tue Mar 10 13:37:12 2009 From: simone.giannecchini at geo-solutions.it (Simone Giannecchini) Date: Tue Mar 10 13:37:14 2009 Subject: [gdal-dev] Re: gdal - java In-Reply-To: <200903091957.42485.even.rouault@mines-paris.org> References: <8b07782c0903090629h437e56d8j5520bd9bb508c829@mail.gmail.com> <931f8ea90903090752h4a74aac9if6ad0602e5aaf322@mail.gmail.com> <200903091953.36078.even.rouault@mines-paris.org> <200903091957.42485.even.rouault@mines-paris.org> Message-ID: <961f4d9e0903101037y4fa1797biaefb879198ff940e@mail.gmail.com> I just notice this message therefore I thought I would share some thoughts. There has been an experiment in geotools a while ago in order to support ogr as a datastore to access more formats (s57 where are you :-) ), the result is an unsupported module in our svn http://svn.osgeo.org/geotools/trunk/modules/unsupported/ogr/ It might be worth stepping up and taking care of it so that you would get all the needed community support and actually you would also take advantage of the geotools infrastructure that's already there. Similar work, in much better status though, has been done for GDAL, but I will probably send a separate email soon for that. Ciao, Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Mon, Mar 9, 2009 at 7:57 PM, Even Rouault wrote: > Wanted to CC the list in the first place as it might be of general interest... > > Le Monday 09 March 2009 19:53:35, vous avez ?crit?: >> Paul, >> >> Frank has already almost said everything ;-) >> >> You need to be able to build (or get): >> - GDAL/OGR with OGDI support >> - the Java bindings by folllowing the hints given on the wiki >> http://trac.osgeo.org/gdal/wiki/GdalOgrInJava. >> >> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogrinfo.java >> is indeed the closest example for your needs. >> >> I'm currently in the process to feed the Javadoc of the Java bindings. They >> can be found at http://gdal.org/java/. The OGR part, the one you want to >> use, is still incomplete however, but it should be relatively >> straightforward to guess what a Java method does by reading the doc of the >> corresponding C++ method at : http://gdal.org/ogr/hierarchy.html. >> You should also be aware that some methods in them only apply to the >> current development versions,. >> >> As Frank noted, the state of the Java bindings in recent released versions >> of GDAL/OGR is partly broken/incomplete. The above ogrinfo.java in its >> current state will not compile out of the box with GDAL/OGR <= 1.6.0, >> although you should be able to get the gist of it to work by >> adapting/commenting out some parts. >> >> Best regards >> >> Le Monday 09 March 2009 15:52:09 Frank Warmerdam, vous avez ?crit?: >> > On Mon, Mar 9, 2009 at 9:29 AM, Paul Malm wrote: >> > > Mr Warmedam, >> > > I'm sorry to bother you again, I got your mail about VPF readers in >> > > java. I have not found any good ones yet... but I can see that you have >> > > a java version of your GDAL/OGR library. The problem is that I do not >> > > understand how to use it, is there a explanation on some wiki or >> > > likewise? I can't understand how to use the Java bindings from >> > > http://trac.osgeo.org/gdal/wiki/GdalOgrInJava >> > > I would be happy to just read maps/charts in VPF/S57 format. >> > >> > Paul, >> > >> > There is VPF reading code in OpenMap from BBN, and I was >> > vaguely under the impression there was VPF support in >> > GeoTools as well (both in Java). >> > >> > Using the GDAL Java bindings can be moderately involved. >> > >> > The url you quote is a good start for example Java code, and >> > (I think) build hints. ?You will still need to be familiar with the >> > general OGR data model, and API which are described at: >> > >> > ? http://www.gdal.org/ogr/ogr_arch.html >> > ? http://www.gdal.org/ogr/ogr_apitut.html >> > >> > Possibly the best example Java OGR program is: >> > >> > http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogrinfo.java >> > >> > It is sometimes difficult to get a build of all the components to >> > use GDAL/OGR from Java. ?The OSGeo4W distribution includes >> > Java bindings support, but it is a bit outdated and is windows >> > only. ?If that is sufficient for your needs you can find OSGeo4W >> > at the following url, and you would need the gdal, and gdal-java >> > packages (through advanced install): >> > >> > ? http://osgeo4w.osgeo.org/ >> > >> > There have been many improvements by Even Rouault >> > to the Java bindings in recent weeks, but you would need >> > to build things from source which is not always easy. ?It >> > might be best to followup with Even (perhaps on the gdal-dev >> > mailing list) if you have additional questions. >> > >> > Best regards, >> > >> > ---------------------------------------+--------------------------------- >> >-- --- I set the clouds in motion - turn up ? | Frank Warmerdam, >> > warmerdam@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 > From a.r.ferreira at gmail.com Tue Mar 10 14:03:07 2009 From: a.r.ferreira at gmail.com (Adriano Ferreira) Date: Tue Mar 10 14:09:59 2009 Subject: [gdal-dev] OGR question on geometric computations Message-ID: <73ddeb6c0903101103h499a8402hf6246366fa1710f7@mail.gmail.com> Hi, I am working with GDAL Swig interface to Perl and have a doubt I could not resolve by myself from what I read up to now. (Warning: This is a newbye question.) I am working with polygons defined with lat/long points according to NAD83 (more specifically, EPSG:4269 as SRS). I need to do some computations with them and also with points given as input. The GDAL/OGR methods like Contains, Overlaps, etc. are pretty handy and easy to use. But what geometry does it use? Does it make difference? I am not sure that in set operations like Contains, Overlaps, etc. it does make difference if a simple Euclidian geometry used in the (lat, long) pairs will give me a different answer than if using a geometry over the spherical approximation of the Earth. And I think it does not (though I should re-read some math books before taking it for sure :-) ). But my concern is with the Distance method. What does it compute? Euclidean distance? It can compute great circle distance if I use the correct Spatial Reference objects with the OGR objects? I am not sure this question is clear: but as an example, given an polygon "P" built of (lat, long) points (given in degrees) and a a point "pt", the return of P.Distance(pt) is just the length of the minimum Euclidean length between the polygon points and "pt"? Thanks for any help. Adriano Ferreira From gdal-dev at billz.fastmail.fm Tue Mar 10 22:29:07 2009 From: gdal-dev at billz.fastmail.fm (Bill Zissimopoulos) Date: Tue Mar 10 22:37:02 2009 Subject: [gdal-dev] ogr2ogr on SDTS/DLG creates wrong geometries Message-ID: <31628446-29B3-4516-AA1C-E6EC6C587B2F@billz.fastmail.fm> Hello, list: I am using ogr2ogr to convert SDTS/DLG files to SHP for further processing. The command I use is as follows: wget http://edcftp.cr.usgs.gov/pub/data/DLG/100K/S/seattle-w_WA/hydrography/1431327.HY.sdts.tar.gz tar xzf 1431327.HY.sdts.tar.gz ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:4326 . *CATD.DDF This downloads the hydrography for the area west of Seattle, extracts it and runs ogr2ogr to convert to Shapefile format. Unfortunately some of the produced area geometries appear to be problematic. For example, the result file PC04.shp contains some weird "empty" geometries: these seem to be comprised of a big "fill" polygon and a number of "hole" polygons such that their difference is an empty geometry. The most obvious such example is the "sea" area behind Bainbridge island (ENTITY_LAB 0500116). I have verified that the original SDTS/DLG file renders properly under software capable of reading such files (e.g. GlobalMapper). Is this a problem with ogr2ogr or am I misusing/misunderstanding the tools? Thank you for any help. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090310/ef53791c/attachment.html From s.normann at gmx.com Wed Mar 11 13:34:37 2009 From: s.normann at gmx.com (Simmer) Date: Wed Mar 11 13:34:40 2009 Subject: [Gdal-dev] How to read GeoTIFF dimensions? In-Reply-To: References: <1236000508901-2409146.post@n2.nabble.com> Message-ID: <1236792877583-2462711.post@n2.nabble.com> Jonah Duckles wrote: > Looks like you're on windows, but if you have sed and grep installed in > your > path you could run: > gdalinfo image.tif |grep ^Size | sed 's/Size is//g;s/ //g'. Sorry for the late reply. This is exactly what I was looking for and saves me lot of work. Thanks a million! Simmer -- View this message in context: http://n2.nabble.com/How-to-read-GeoTIFF-dimensions--tp2409146p2462711.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Wed Mar 11 15:32:37 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Mar 11 15:32:39 2009 Subject: [gdal-dev] Re: Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> Message-ID: <931f8ea90903111232q150df6ecn3483c1cb80ff269a@mail.gmail.com> On Mon, Mar 9, 2009 at 11:48 AM, Frank Warmerdam wrote: > Motion: Chaitanya Kumar CH is granted GDAL commit permissions. Folks, I declare this motion passed with support from EvenR, TamasS, FrankW, HowardB, and DanielM. Welcome about Chaitanya! Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From vali.system at free.fr Wed Mar 11 15:56:21 2009 From: vali.system at free.fr (ValiSystem) Date: Wed Mar 11 15:56:30 2009 Subject: [gdal-dev] gdal contour, output polygon Message-ID: <49B81765.4020303@free.fr> Hello ! I'm trying to generate polygons from gdal contour output. Most of the linestrings generated where closed, so it's not a too bad start. The problem is to define interior and exterior of the polygon : it seems that interior and exterior has no consistent meaning from the linestrings (it makes sense though - a line has no interior nor than exterior). So what i need would be a method to recreate the meaning of the polygon : the inside is where i have ground. To make it work, i just would have to transform the polygon to an interior ring of a wider (whole area) polygon when appropriate (when it does not contain a polygon with a higher altitude). What do you think about this ? is there a better/known way to achieve that ? From mateusz at loskot.net Wed Mar 11 18:44:02 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed Mar 11 18:44:10 2009 Subject: [gdal-dev] Re: Motion: Chaitanya Kumar CH as a GDAL committer In-Reply-To: <931f8ea90903111232q150df6ecn3483c1cb80ff269a@mail.gmail.com> References: <931f8ea90903090848p4303efb8p46c54cc386e70c87@mail.gmail.com> <931f8ea90903111232q150df6ecn3483c1cb80ff269a@mail.gmail.com> Message-ID: <49B83EB2.9070507@loskot.net> Frank Warmerdam wrote: > On Mon, Mar 9, 2009 at 11:48 AM, Frank Warmerdam wrote: >> Motion: Chaitanya Kumar CH is granted GDAL commit permissions. > > Folks, > > I declare this motion passed with support from EvenR, TamasS, > FrankW, HowardB, and DanielM. Dear PSC, This is great news! > Welcome about Chaitanya! Chaitanya, as previous maintainer ,let me to wish you all the best and good luck! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From nicholas.g.lawrence at mainroads.qld.gov.au Wed Mar 11 21:43:30 2009 From: nicholas.g.lawrence at mainroads.qld.gov.au (nicholas.g.lawrence@mainroads.qld.gov.au) Date: Wed Mar 11 21:58:47 2009 Subject: [gdal-dev] netCDF format Message-ID: Hello All, I have some data in netCDF format. I'm pretty sure it is longitude/latitude. Is anyone familiar with this format? Is it something GDAL can handle? What sort of format is it? A raster? or a grid with multiple values? Regards, nick *********************************************************************** WARNING: This e-mail (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this e-mail without appropriate authority. If this e-mail was not intended for you and was sent to you by mistake, please telephone or e-mail me immediately, destroy any hardcopies of this e-mail and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this e-mail is not waived or destroyed by that mistake. It is your responsibility to ensure that this e-mail does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. *********************************************************************** From chaitanya.ch at gmail.com Thu Mar 12 02:53:44 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 12 02:53:48 2009 Subject: [gdal-dev] netCDF format In-Reply-To: References: Message-ID: Nick, NetCDF is a raster format and is supported by GDAL. Please refer to http://www.gdal.org/frmt_netcdf.html for details on GDAL's NetCDF driver. Regards, Chaitanya On Thu, Mar 12, 2009 at 7:13 AM, wrote: > > Hello All, > > I have some data in netCDF format. > > I'm pretty sure it is longitude/latitude. > > Is anyone familiar with this format? > > Is it something GDAL can handle? > > What sort of format is it? A raster? or a grid with multiple values? > > Regards, > nick > > > *********************************************************************** > WARNING: This e-mail (including any attachments) may contain legally > privileged, confidential or private information and may be protected by > copyright. You may only use it if you are the person(s) it was intended > to be sent to and if you use it in an authorised way. ?No one is > allowed to use, review, alter, transmit, disclose, distribute, print > or copy this e-mail without appropriate authority. > > If this e-mail was not intended for you and was sent to you by mistake, > please telephone or e-mail me immediately, destroy any hardcopies of > this e-mail and delete it and any copies of it from your computer > system. Any right which the sender may have under copyright law, and > any legal privilege and confidentiality attached to this e-mail is not > waived or destroyed by that mistake. > > It is your responsibility to ensure that this e-mail does not contain > and is not affected by computer viruses, defects or interference by > third parties or replication problems (including incompatibility with > your computer system). > > Opinions contained in this e-mail do not necessarily reflect the > opinions of the Queensland Department of Main Roads, Queensland > Transport or Maritime Safety Queensland, or endorsed organisations > utilising the same infrastructure. > *********************************************************************** > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From gregor.fikoczek at wheregroup.com Thu Mar 12 04:29:21 2009 From: gregor.fikoczek at wheregroup.com (Gregor Fikoczek) Date: Thu Mar 12 04:29:26 2009 Subject: [gdal-dev] GDAL / PROJ.4 Transformation (cs2cs) - several results by =?utf-8?q?=C2=A0PROJ=2E4-Versions?= (DHDN/GK2 => ETRS89/UTM32) Message-ID: <200903120929.21187.gregor.fikoczek@wheregroup.com> Hi list, i am using the PROJ.4 (cs2cs, GDAL/OGR, UMN MapServer) for transformation from CS to CS. start-point (DHDN / GK 2 => epsg:31466) 5216100002;2552401,862;5616707,524 correct destination-point (ETRS89 / UTM 32 => epsg:25832) 32340408.033 ?5617072.487 example: cs2cs +init=epsg:31466 +to +init=epsg:25832 ?2552401.862 5616707.524 ----------------- Result with PROJ.4 version 4.5.0: 340411,268580576754175;5617068,431440304964781 => difference to the correct destination point in ETRS89: ~ 5 m => fine Result with PROJ.4 version 4.6 and 4.6.1: 340463.83???????5617207.67 => not so fine / wrong => difference to the correct destination point in ETRS89: > 100m ---------------- ====> Why the difference in PROJ.4 Version 4.6 and 4.6.1 is the much? epsg-FILE: --- # ETRS89 / UTM zone 32N <25832> +proj=utm +zone=32 +ellps=GRS80 +units=m +no_defs ?<> # DHDN / Gauss-Kruger zone 2 <31466> +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs ?<> --- ############### When i modified the epsg file like this (add parameter +datum=WGS84 to EPSG:25832): from # ETRS89 / UTM zone 32N <25832> +proj=utm +zone=32 +ellps=GRS80 +units=m +no_defs ?<> to # ETRS89 / UTM zone 32N <25832> +proj=utm +zone=32 +ellps=GRS80 +datum=WGS84 +units=m +no_defs ?<> ... the result is as expected and equal like by the PROJ.4 Version 4.5.0. --- cs2cs +init=epsg:31466 +to +init=epsg:25832 2552401.862 5616707.524 Result: ?340411.27??????5617068.43 ==> fine --- So is there a difference between PROJ.4-Versions (Version > 4.5 needs +datum-Parameter?) or am i doing something wrong? Best Regards, Greg -- Mit freundlichen Gr??en / Kind regards Gregor Fikoczek --------------------------------------- WhereGroup GmbH & Co. KG Siemensstra?e 8 53121 Bonn Germany Gregor Fikoczek Email: gregor.fikoczek@wheregroup.com Fon: +49 (0)228 / 90 90 38 - 25 Fax: +49 (0)228 / 90 90 38 - 11 info@wheregroup.com www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplement?rin: WhereGroup Verwaltungs GmbH vertreten durch: Olaf Knopp, Peter Stamm --------------------------------------- From jrepetto at free.fr Thu Mar 12 06:55:50 2009 From: jrepetto at free.fr (Jean-Claude Repetto) Date: Thu Mar 12 07:26:13 2009 Subject: [gdal-dev] GDAL / PROJ.4 Transformation (cs2cs) - several results by PROJ.4-Versions (DHDN/GK2 => ETRS89/UTM32) In-Reply-To: <200903120929.21187.gregor.fikoczek@wheregroup.com> References: <200903120929.21187.gregor.fikoczek@wheregroup.com> Message-ID: <49B8EA36.1010605@free.fr> Gregor Fikoczek wrote : > So is there a difference between PROJ.4-Versions (Version > 4.5 needs > +datum-Parameter?) or am i doing something wrong? > Hello, In the prog 4.6.0 release notes, one can read : o MAJOR: Rework pj_transform() to avoid applying ellipsoid to ellipsoid transformations as a datum shift when no datum info is available. So yes, a datum definition is mandatory if you want to perform a transformation. The definition of epsg::25832 in the epsg file is incorrect. Regards, Jean-Claude From gregor.fikoczek at wheregroup.com Thu Mar 12 07:40:31 2009 From: gregor.fikoczek at wheregroup.com (Gregor Fikoczek) Date: Thu Mar 12 07:40:42 2009 Subject: [gdal-dev] GDAL / PROJ.4 Transformation (cs2cs) - several results by PROJ.4-Versions (DHDN/GK2 => ETRS89/UTM32) In-Reply-To: <49B8EA36.1010605@free.fr> References: <200903120929.21187.gregor.fikoczek@wheregroup.com> <49B8EA36.1010605@free.fr> Message-ID: <200903121240.31463.gregor.fikoczek@wheregroup.com> hi Jean-Claude, thanks for the information, Best regards, Greq Am Donnerstag 12 M?rz 2009 11:55:50 schrieb Jean-Claude Repetto: > Gregor Fikoczek wrote : > > So is there a difference between PROJ.4-Versions (Version > 4.5 needs > > +datum-Parameter?) or am i doing something wrong? > > Hello, > > In the prog 4.6.0 release notes, one can read : > > o MAJOR: Rework pj_transform() to avoid applying ellipsoid to ellipsoid > transformations as a datum shift when no datum info is available. > > So yes, a datum definition is mandatory if you want to perform a > transformation. > The definition of epsg::25832 in the epsg file is incorrect. > > Regards, > Jean-Claude --------------------------------------- WhereGroup GmbH & Co. KG Siemensstra?e 8 53121 Bonn Germany Gregor Fikoczek Email: gregor.fikoczek@wheregroup.com Fon: +49 (0)228 / 90 90 38 - 25 Fax: +49 (0)228 / 90 90 38 - 11 info@wheregroup.com www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplement?rin: WhereGroup Verwaltungs GmbH vertreten durch: Olaf Knopp, Peter Stamm --------------------------------------- From vali.system at free.fr Thu Mar 12 12:02:04 2009 From: vali.system at free.fr (ValiSystem) Date: Thu Mar 12 12:02:14 2009 Subject: [gdal-dev] gdal contour, output polygon In-Reply-To: References: <49B81765.4020303@free.fr> Message-ID: <49B931FC.90400@free.fr> Hum, i'm working with a world wide data set, it may add some strange artifacts around the 180, but i'll give it a try, it's very likely that the average data will be much better. thanks for the help ! (sorry for the dupe :/ ) On 11/03/09 21:14, Chaitanya kumar CH wrote: > Vali, > > I don't know about a better way but here is a quick and dirty method > to avoid lines. > Surround the whole map with a pixel wide strip with elevation of every > pixel set to minimum (or maximum) altitude. > This method probably adds one more polygon along the border. > > Regards, > From jaadfoo at gmail.com Thu Mar 12 12:26:07 2009 From: jaadfoo at gmail.com (Jamie Adams) Date: Thu Mar 12 12:26:09 2009 Subject: [gdal-dev] gdal contour, output polygon In-Reply-To: <49B81765.4020303@free.fr> References: <49B81765.4020303@free.fr> Message-ID: You could also try using gdal_polygonize, but you'd need to find a way to reclass your source raster to discrete groups (i.e, elevation ranges). This could be done pretty easily using python, maybe something like val_repl.py. -Jamie On Wed, Mar 11, 2009 at 12:56 PM, ValiSystem wrote: > Hello ! > > I'm trying to generate polygons from gdal contour output. Most of the > linestrings generated where closed, so it's not a too bad start. The problem > is to define interior and exterior of the polygon : it seems that interior > and exterior has no consistent meaning from the linestrings (it makes sense > though - a line has no interior nor than exterior). > > So what i need would be a method to recreate the meaning of the polygon : > the inside is where i have ground. To make it work, i just would have to > transform the polygon to an interior ring of a wider (whole area) polygon > when appropriate (when it does not contain a polygon with a higher > altitude). > > What do you think about this ? is there a better/known way to achieve that > ? > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090312/5e135ec2/attachment.html From vali.system at free.fr Thu Mar 12 13:46:18 2009 From: vali.system at free.fr (ValiSystem) Date: Thu Mar 12 13:46:29 2009 Subject: [gdal-dev] gdal contour, output polygon In-Reply-To: References: <49B81765.4020303@free.fr> Message-ID: <49B94A6A.5000401@free.fr> that's a very interesting option ! I think i could write a tool in C++ to do the grouping, and use the original line strings for the elevation lines/text. thanks a lot On 12/03/09 17:26, Jamie Adams wrote: > You could also try using gdal_polygonize > , but you'd need to find a > way to reclass your source raster to discrete groups (i.e, elevation > ranges). This could be done pretty easily using python, maybe > something like val_repl.py > . > > -Jamie > > On Wed, Mar 11, 2009 at 12:56 PM, ValiSystem > wrote: > > Hello ! > > I'm trying to generate polygons from gdal contour output. Most of > the linestrings generated where closed, so it's not a too bad > start. The problem is to define interior and exterior of the > polygon : it seems that interior and exterior has no consistent > meaning from the linestrings (it makes sense though - a line has > no interior nor than exterior). > > So what i need would be a method to recreate the meaning of the > polygon : the inside is where i have ground. To make it work, i > just would have to transform the polygon to an interior ring of a > wider (whole area) polygon when appropriate (when it does not > contain a polygon with a higher altitude). > > What do you think about this ? is there a better/known way to > achieve that ? > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090312/ff153a9b/attachment.html From bfraser at geoanalytic.com Thu Mar 12 14:58:14 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Thu Mar 12 14:58:36 2009 Subject: [gdal-dev] gdalbuildvrt and location, Location, LOCATION Message-ID: <49B95B46.6090001@geoanalytic.com> I'm trying to use gdalbuildvrt (v1.6.0) to create a vrt file from a tileindex shapefile. The tileindex shapefile was created using gdaltindex, and dbfinfo reports: 1 Columns, 16 Records in file LOCATION string (254,0) Doing: gdalbuildvrt 082h04w2.vrt 082h04w.shp reports: This shapefile seems to be a tile index of OGR features and not GDAL products. Unable to find field `location' in DBF file `082h04w.shp'. But when doing: gdalbuildvrt -tileindex LOCATION 082h04w2.vrt 082h04w.shp I successfully get my vrt file. So either the message should be changed (since the index WAS built using GDAL products), or the default should be changed to LOCATION (my preference). I'd be happy to file a bug report if someone has a strong feeling either way.. Thanks! Brent Fraser From even.rouault at mines-paris.org Thu Mar 12 16:31:39 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 12 16:31:51 2009 Subject: [gdal-dev] gdalbuildvrt and location, Location, LOCATION In-Reply-To: <49B95B46.6090001@geoanalytic.com> References: <49B95B46.6090001@geoanalytic.com> Message-ID: <200903122131.40383.even.rouault@mines-paris.org> By default, gdaltindex produces a DBF with 'location' (lowercase) and ogrtindex 'LOCATION' (uppercase). So I think I've added this check so that people don't try to use ogrtindex output. The '-tileindex' option is indeed done for those specific cases where non-standard GDAL tileindex must be used. Le Thursday 12 March 2009 19:58:14 Brent Fraser, vous avez ?crit?: > ? So either the message should be changed (since the index WAS built using > GDAL products), or the default should be changed to LOCATION (my > preference). ?I'd be happy to file a bug report if someone has a strong > feeling either way.. From bfraser at geoanalytic.com Thu Mar 12 16:46:02 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Thu Mar 12 16:46:23 2009 Subject: [gdal-dev] gdalbuildvrt and location, Location, LOCATION In-Reply-To: <200903122131.40383.even.rouault@mines-paris.org> References: <49B95B46.6090001@geoanalytic.com> <200903122131.40383.even.rouault@mines-paris.org> Message-ID: <49B9748A.8020807@geoanalytic.com> Hmm, my gdaltindex creates a DBF with "LOCATION", even though I see that gdaltindex.c sets the default to "location" on line 71: const char *tile_index = "location"; I'll have to step through the code with the debugger... Thanks! Brent Even Rouault wrote: > By default, gdaltindex produces a DBF with 'location' (lowercase) and > ogrtindex 'LOCATION' (uppercase). So I think I've added this check so that > people don't try to use ogrtindex output. The '-tileindex' option is indeed > done for those specific cases where non-standard GDAL tileindex must be used. > > Le Thursday 12 March 2009 19:58:14 Brent Fraser, vous avez ?crit : >> So either the message should be changed (since the index WAS built using >> GDAL products), or the default should be changed to LOCATION (my >> preference). I'd be happy to file a bug report if someone has a strong >> feeling either way.. > > > From ari.jolma at tkk.fi Thu Mar 12 16:52:04 2009 From: ari.jolma at tkk.fi (Ari Jolma) Date: Thu Mar 12 16:52:12 2009 Subject: [gdal-dev] OGR question on geometric computations In-Reply-To: <73ddeb6c0903101103h499a8402hf6246366fa1710f7@mail.gmail.com> References: <73ddeb6c0903101103h499a8402hf6246366fa1710f7@mail.gmail.com> Message-ID: <49B975F4.7010200@tkk.fi> Adriano, These questions seem to be specifically about GEOS functionality, which OGR provides (and in your case you use them from Perl) but neither OGR nor Perl really matter in this case. I'm not such an expert on GEOS that I dare to answer, I suggest you check first GEOS documentation and then perhaps GEOS email list - or that of JTS, as GEOS is a C++ port of JTS, which is "the mother". Start from http://trac.osgeo.org/geos/ Cheers, Ari Adriano Ferreira kirjoitti: > Hi, I am working with GDAL Swig interface to Perl and have a doubt I > could not resolve by myself from what I read up to now. (Warning: This > is a newbye question.) > > I am working with polygons defined with lat/long points according to > NAD83 (more specifically, EPSG:4269 as SRS). I need to do some > computations with them and also with points given as input. The > GDAL/OGR methods like Contains, Overlaps, etc. are pretty handy and > easy to use. But what geometry does it use? Does it make difference? > > I am not sure that in set operations like Contains, Overlaps, etc. it > does make difference if a simple Euclidian geometry used in the (lat, > long) pairs will give me a different answer than if using a geometry > over the spherical approximation of the Earth. And I think it does not > (though I should re-read some math books before taking it for sure :-) > ). > > But my concern is with the Distance method. What does it compute? > Euclidean distance? It can compute great circle distance if I use the > correct Spatial Reference objects with the OGR objects? > > I am not sure this question is clear: but as an example, given an > polygon "P" built of (lat, long) points (given in degrees) and a a > point "pt", the return of > > P.Distance(pt) > > is just the length of the minimum Euclidean length between the polygon > points and "pt"? > > Thanks for any help. > > Adriano Ferreira > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi From sarko at asf.alaska.edu Thu Mar 12 17:10:41 2009 From: sarko at asf.alaska.edu (Scott Arko) Date: Thu Mar 12 17:29:05 2009 Subject: [gdal-dev] Lossless JPEG in GDAL Message-ID: <49B97A51.9020600@asf.alaska.edu> An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090312/7fccbea6/attachment.html From bfraser at geoanalytic.com Thu Mar 12 17:36:34 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Thu Mar 12 17:37:04 2009 Subject: [gdal-dev] gdalbuildvrt and location, Location, LOCATION In-Reply-To: <49B9748A.8020807@geoanalytic.com> References: <49B95B46.6090001@geoanalytic.com> <200903122131.40383.even.rouault@mines-paris.org> <49B9748A.8020807@geoanalytic.com> Message-ID: <49B98062.6080001@geoanalytic.com> Yep, my fault. gdaltindex and gdalbuiltvrt are just fine the way they are... Sorry for the noise, Brent Brent Fraser wrote: > Hmm, my gdaltindex creates a DBF with "LOCATION", even though I see that > gdaltindex.c sets the default to "location" on line 71: > const char *tile_index = "location"; > > I'll have to step through the code with the debugger... > > Thanks! > Brent > > > Even Rouault wrote: >> By default, gdaltindex produces a DBF with 'location' (lowercase) and >> ogrtindex 'LOCATION' (uppercase). So I think I've added this check so >> that >> people don't try to use ogrtindex output. The '-tileindex' option is >> indeed done for those specific cases where non-standard GDAL tileindex >> must be used. >> >> Le Thursday 12 March 2009 19:58:14 Brent Fraser, vous avez ?crit : >>> So either the message should be changed (since the index WAS built >>> using >>> GDAL products), or the default should be changed to LOCATION (my >>> preference). I'd be happy to file a bug report if someone has a strong >>> feeling either way.. >> >> >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From warmerdam at pobox.com Thu Mar 12 21:23:59 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 12 22:24:33 2009 Subject: [gdal-dev] ogr2ogr on SDTS/DLG creates wrong geometries In-Reply-To: <31628446-29B3-4516-AA1C-E6EC6C587B2F@billz.fastmail.fm> References: <31628446-29B3-4516-AA1C-E6EC6C587B2F@billz.fastmail.fm> Message-ID: <49B9B5AF.9010801@pobox.com> Bill Zissimopoulos wrote: > Hello, list: > > I am using ogr2ogr to convert SDTS/DLG files to SHP for further > processing. The command I use is as follows: > wget http://edcftp.cr.usgs.gov/pub/data/DLG/100K/S/seattle-w_WA/hydrography/1431327.HY.sdts.tar.gz > tar xzf 1431327.HY.sdts.tar.gz > ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:4326 . *CATD.DDF > > This downloads the hydrography for the area west of Seattle, extracts it > and runs ogr2ogr to convert to Shapefile format. > > Unfortunately some of the produced area geometries appear to be > problematic. For example, the result file PC04.shp contains some weird > "empty" geometries: these seem to be comprised of a big "fill" polygon > and a number of "hole" polygons such that their difference is an empty > geometry. The most obvious such example is the "sea" area behind > Bainbridge island (ENTITY_LAB 0500116). > > I have verified that the original SDTS/DLG file renders properly under > software capable of reading such files (e.g. GlobalMapper). Is this a > problem with ogr2ogr or am I misusing/misunderstanding the tools? > Bill, I have downloaded the 1431327.HY file you referenced, but ogrinfo on the PC04 layer does not show anything fundy about the 0500116 polygon. I also converted to shapefile format and examined that with no odd results. I neglected to reproject to EPSG:4326 I see. Perhaps you could file a ticket on the issue, being very specific about the software version and platform you worked on. Also, please check if a direct ogrinfo report on the original SDTS file shows a similar problem. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From qi-shan.lim at koordinates.com Thu Mar 12 23:41:11 2009 From: qi-shan.lim at koordinates.com (Qi-Shan Lim) Date: Thu Mar 12 23:46:58 2009 Subject: [gdal-dev] MapInfo Datum lookup bug, CSV data for drivers Message-ID: Hi all, I'm new to GDAL/OGR development and have run up against an existing bug with the MapInfo driver, which I'm willing to help fix. Details are at http://trac.osgeo.org/gdal/ticket/481#comment:8 with a comment which I'll reproduce here for convenience: I'm hitting this problem as well and really need to get it resolved. Only just started working with gdal/ogr so comments would be appreciated on this proposal: --- 1. Change asDatumInfoList to include the EPSG code for the datum. I imagine this could be accomplished with a mixture of pattern-matching the names and some manual intervention. 2. Change SetSpatialRef? to look up the data based on the datum's EPSG code instead of name i.e. use poSpatialRef->GetAuthorityCode?("DATUM") instead of poSpatialRef->GetAttrValue?("DATUM") 3. (Optional) Move asDatumInfoList (and the other hard-coded data, I guess) into a csv file. Is this going to work or am I talking rubbish? If it sounds reasonable I'll go ahead and do up a patch. --- I'm posting to the list as point 3 seems to be a general question - is it acceptable for drivers that required this sort of data to stick it into a csv file to put into the data/ directory? Also, if this data is to be generated in some sort of semi-automated way using a script of some sort, should this script be committed to the source tree? Would appreciate any advice/help as I get familiar with the code base. Cheers, --Qi-Shan From ludovic.mercier at gmail.com Fri Mar 13 04:54:12 2009 From: ludovic.mercier at gmail.com (lidiriel) Date: Fri Mar 13 04:54:14 2009 Subject: [gdal-dev] Access to MetaData in driver implementation Message-ID: <69c87df5-d9e1-4608-984c-d2e5ee3e9f6f@w9g2000yqa.googlegroups.com> Hello, I work on th create method for ISIS2 file (PDS driver). I can write raster file but i have a problem with meta data. In the case where the user would be use "poDriver->CreateCopy" i try to copy and write metaData in the new file. But now i get metadata with the method "char** metaData = GetMetadata();" But the list of string is not easy to handling. Is there another solution for access to the metadata for creating a new (or updated copy) of header ? Construct and access to an XML tree (like TrySaveXML) ? or another method ? Regards From dkazimirov at issart.com Fri Mar 13 06:19:01 2009 From: dkazimirov at issart.com (Dmitry Kazimirov) Date: Fri Mar 13 06:24:47 2009 Subject: [gdal-dev] Issue with Lambert Conformal projection with GDAL Message-ID: <632453990903130319l5c1fa1e3oe03d08f8c6dd5015@mail.gmail.com> Greetings, I currently trying to convert image data in grib2 format (specification is here if someone interested- http://www.weather.gov/forecasts/graphical/docs/grib_design.html, my datafeed is using 'Template 30' i.e. Lambert Conform Conic Projection) and rewarp it to other projection I have data about projection(they are sometimes changed) Lambert Conformal: (614 x 428) input WE:SN output WE:SN res 8 mode 8 Lat1 12.190000 - latitude of first grid point Lon1 226.541000 - longitude of first grid point LoV 265.000000 - Orientation longitude (?) LatD 25.000000 - "Latitude where grid spacing is defined" Latin1 25.000000 Latin1, first secant latitude Latin2 25.000000 Latin2, second secant latitude ( LatSP -90.000000 LonSP 0.000000 - Latitude and longitude of southern pole (?) Dx 12190.528000 m - Dx, X-direction grid length Dy 12190.590000 m - Dy, Y-direction grid length GDAL Georeference's SetLCC require parameters SetLCC ( double dfStdP1, double dfStdP2, double dfCenterLat, double dfCenterLong, double dfFalseEasting, double dfFalseNorthing ) (uncommented at all) how I use my parameters to with GDAL? I understood that dfStdP1/P2 is 1st/2nd standard parallel(25.0000 in my case) What I should use fort dfCenterLat/Long? for falseEasting/Northing? Could anyone help? -- -- Best Regards, Dmitriy Kazimirov, Senior C++/C# Developer of ISS Art, Ltd., Omsk, Russia Web: http://www.issart.com E-mail: dkazimirov@issart.com ICQ:148916984 Yahoo Messenger:dmitriy_kazimirov From ismail at namtrac.org Fri Mar 13 07:38:20 2009 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Fri Mar 13 07:44:29 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED Message-ID: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> Hi all; I have a rather big (3.1G) USGSDEM file. I need to convert it to GTOP30 DEM format or to a series of DTED files to be read by a 3rd party library which does not support USGSDEM files. I looked around and apparently gdal does not support exporting to GTOP30 DEM format. So I wonder if there is a way to convert USGSDEM file into a DTED file which will cover _all_ area, ie. gdal_translate -of DTED input.dem out.dt0 just creates a one point with 1201x1201 area. Any help is appreciated. Regards. -- ?smail D?NMEZ From jgomezdans at gmail.com Fri Mar 13 10:23:58 2009 From: jgomezdans at gmail.com (Jose =?iso-8859-1?q?G=F3mez-Dans?=) Date: Fri Mar 13 10:24:03 2009 Subject: [gdal-dev] GRIB driver crashes with large numbers of bands Message-ID: <200903131423.58108.jgomezdans@gmail.com> Hi, I have some GRIB datasets downloaded from ECMWF . The files contain many bands (19728). When I try gdalinfo on these datasets, it waits for a long time. The python bindings segfault. The driver does fine with a smaller dataset (around a third of the layers, some 6500). Is this a bug or is this a limitation of the grib driver? Thanks! Jose From warmerdam at pobox.com Fri Mar 13 11:35:00 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 13 11:35:22 2009 Subject: [gdal-dev] GRIB driver crashes with large numbers of bands In-Reply-To: <200903131423.58108.jgomezdans@gmail.com> References: <200903131423.58108.jgomezdans@gmail.com> Message-ID: <49BA7D24.3010300@pobox.com> Jose G?mez-Dans wrote: > Hi, > I have some GRIB datasets downloaded from ECMWF > . The files contain many > bands (19728). When I try gdalinfo on these datasets, it waits for a long > time. The python bindings segfault. The driver does fine with a smaller > dataset (around a third of the layers, some 6500). > > Is this a bug or is this a limitation of the grib driver? Jose, I would appreciate it if you could file a ticket on this with a pointer to a specific dataset to test with. I'm not surprised that things perform poorly with such a dataset, but we would like it to at least error out cleanly rather than crash. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Fri Mar 13 11:58:11 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 13 11:58:30 2009 Subject: [gdal-dev] Access to MetaData in driver implementation In-Reply-To: <69c87df5-d9e1-4608-984c-d2e5ee3e9f6f@w9g2000yqa.googlegroups.com> References: <69c87df5-d9e1-4608-984c-d2e5ee3e9f6f@w9g2000yqa.googlegroups.com> Message-ID: <49BA8293.60104@pobox.com> lidiriel wrote: > Hello, > > I work on th create method for ISIS2 file (PDS driver). I can write > raster file but i have a problem with meta data. > In the case where the user would be use "poDriver->CreateCopy" i try > to copy and write metaData in the new file. But now i get metadata > with the method "char** metaData = GetMetadata();" > But the list of string is not easy to handling. > Is there another solution for access to the metadata for creating a new > (or updated copy) of header ? > Construct and access to an XML tree (like TrySaveXML) ? or another > method ? Lidiriel, You can also request individual items from the source dataset using GetMetadataItem(). The functions CSLFetchNameValue(), and CPLParseNameValue() from gdal/port/cpl_string.h should also make it fairly easily to search for particular keys in a string list and to decompose an entry into it's name and value portions. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From matt.wilkie at gov.yk.ca Fri Mar 13 11:47:57 2009 From: matt.wilkie at gov.yk.ca (Matt Wilkie) Date: Fri Mar 13 12:03:04 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> Message-ID: <49BA802D.8090307@gov.yk.ca> > So I wonder if there is a way to convert USGSDEM file into a DTED file > which will cover _all_ area, ie. I don't believe this is possible. I think the DTED specification states a single dted file must be of fixed pixel dimensions: 1201x1201 (2402x1201 north/south of 70?). Certainly thats the case for CDED which was derived from DTED. best regards, matt wilkie -------------------------------------------- Geographic Information, Information Management and Technology, Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ -------------------------------------------- ?smail D?nmez wrote: > Hi all; > > I have a rather big (3.1G) USGSDEM file. I need to convert it to > GTOP30 DEM format or to a series of DTED files to be read by a 3rd > party library which does not support USGSDEM files. I looked around > and apparently gdal does not support exporting to GTOP30 DEM format. > > gdal_translate -of DTED input.dem out.dt0 > > just creates a one point with 1201x1201 area. > > Any help is appreciated. Regards. > From ismail at namtrac.org Fri Mar 13 14:10:02 2009 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Fri Mar 13 14:10:05 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <49BA802D.8090307@gov.yk.ca> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> <49BA802D.8090307@gov.yk.ca> Message-ID: <19e566510903131110h431e5f19m722cc05bf83eca77@mail.gmail.com> Hi, On Fri, Mar 13, 2009 at 5:47 PM, Matt Wilkie wrote: >> So I wonder if there is a way to convert USGSDEM file into a DTED file >> which will cover _all_ area, ie. > > I don't believe this is possible. I think the DTED specification states > a single dted file must be of fixed pixel dimensions: 1201x1201 > (2402x1201 north/south of 70?). Certainly thats the case for CDED which > was derived from DTED. Then I wonder if there is an automated way to convert a DEM into a bunch of DTEDs? Some formula based on dimensions of the original DEM. Regards. -- ?smail D?NMEZ From JERICKS at co.pierce.wa.us Fri Mar 13 13:55:20 2009 From: JERICKS at co.pierce.wa.us (Jared Erickson) Date: Fri Mar 13 14:15:38 2009 Subject: [gdal-dev] gdal2tiles with bounding box and resolutions Message-ID: <20090313T105520Z_AF1300010000@co.pierce.wa.us> Hello, I am trying to tile cache an ArcSDE Raster using gdal2tiles. I have other tile caches already created with specific a bounding box and resolutions. How can I use gdal2tiles to build a tile cache with these same parameters? I tried create a VRT with the specific bounding box: gdalwarp -of "VRT" -te 1048974.00 473455.00 1453419.00 798937.00 "SDE:my_arcsde_connection_string_here" ortho.vrt This worked (or atleast I end up with ortho.vrt). Next, I tried getting the specifc image size needed for my tile cache (necessary to get the correct resolution...I think...): gdal_translate -of "GTiff" -outsize 4096 4096 ortho_2008.vrt ortho.tiff This doesn't seem to work. I wait a few minutes and kill the process because it doesn't seem to be doing anything. Any ideas? Thanks, Jared -------------- next part -------------- Skipped content of type multipart/related From bfraser at geoanalytic.com Fri Mar 13 14:47:30 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Fri Mar 13 14:47:49 2009 Subject: [gdal-dev] Transparency using gdalbuildvrt In-Reply-To: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> References: <2c4bbbeb0903040805k59544176j1d4adf9738fdcb64@mail.gmail.com> Message-ID: <49BAAA42.2030508@geoanalytic.com> Jason, I'm doing some similar things with vrt and DEMs. I can't comment about the alpha/RGBA thing but I was able to get the no-data setting used for the source data by editing the vrt file. gdalbuildvrt creates a "SimpleSource" type of VRT: ----------------- -3.27670000000000E+004 082\082a13_0102_deme.dem 1 : ----------------- I edited the VRT to be a "ComplexSource" type, and added a tag for each source entry: ----------------- -3.27670000000000E+004 082\082a13_0102_deme.dem 1 -32767 : ----------------- Best Regards, Brent Fraser Jason Beverage wrote: > Hi all, > > I've been playing around with gdalbuildvrt lately and it has proven to > be a very useful tool:) > > What I'm attempting to do is take multiple RGB images and treat them as > a single image using the VRT. This works great, but since the images > are RGB, areas where there is no data are coming back as black. Is > there a way that I can modify the VRT or the code to treat the VRT as an > RGBA dataset and somehow say "If there is no data in any bands, the > alpha is 0"? > > Thanks! > > Jason > > > ------------------------------------------------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Fri Mar 13 15:18:10 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 13 15:18:23 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> Message-ID: <200903132018.11919.even.rouault@mines-paris.org> Yes, this is possible but you need to adhere strictfully to the DTED specification. A DTED tile covers exactly a 1 degree x 1 degree area and the corners coordinates must be aligned on integer. As far as I remember, DTED0 has a 30 second x 30 second resolution below latitude 50?, 60'' x 30'' between 50 and 70, 90'' x 30'' between 70 and 75, etc (read the spec). So you will have to produce several DTED files if your input area is over several 1? x 1? square. You should use the -prjwin to just select the right area for each tile, like : gdal_translate -of DTED input.dem n40e2.dt0 -prjwin 41 2 40 3 gdal_translate -of DTED input.dem n40e3.dt0 -prjwin 41 3 40 4 etc.. With a little of scripting (Python for examle), you could automate that by reading the extent of the source . You must be sure that your source input has the same resolution as the produced DTED, otherwise you'll need to adjust it by specifying the right destination size with -outsize 1201 1201 (below 50? latitude). I see in GDAL source tree that there's a (not compiled) utility that seems to do you want. The main file is frmts/dted/dted_test.c, but it relies on the other C files of the DTED driver. You would need to fiddle a bit with the makefiles and the header to compile it (I see that some necessary symbols might not be exported). It is moderately involved provided that you have some experience with C. But if your third-party app supports 16bit GeoTIFF as a possible source for DEM, it would be easier to translate to GeoTIFF. Also by reading the documentation of the EHdr driver, I see GDAL can read GTOPO30 through the EHdr driver. So it could be possible to take the output of the EHdr driver as a GTOPO30 data (no guarantee ...), but we only output one kind of EHdr data which is maybe not the layout of GTOPO30. You would need checking the GTOPO30 spec too. Even Le Friday 13 March 2009 12:38:20 ?smail D?nmez, vous avez ?crit?: > Hi all; > > I have a rather big (3.1G) USGSDEM file. I need to convert it to > GTOP30 DEM format or to a series of DTED files to be read by a 3rd > party library which does not support USGSDEM files. I looked around > and apparently gdal does not support exporting to GTOP30 DEM format. > So I wonder if there is a way to convert USGSDEM file into a DTED file > which will cover _all_ area, ie. > > gdal_translate -of DTED input.dem out.dt0 > > just creates a one point with 1201x1201 area. > > Any help is appreciated. Regards. From peifer at gmx.eu Sat Mar 14 10:23:33 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Sat Mar 14 10:23:48 2009 Subject: [gdal-dev] Re: ogr2ogr: shp > kml, coordinate precision and related kml file size In-Reply-To: <845AADAC1106E44996327D62097E4C6B012BB5DD@et.ad.sdsc.edu> References: <49B36422.3040908@gmx.eu> <845AADAC1106E44996327D62097E4C6B012BB5DD@et.ad.sdsc.edu> Message-ID: Christopher Condit wrote: > Hi Hermann, > >> In my context, Lat/Lon values with 6 decimals are just about enough >> precision. I feel that I am pumping a lot of meaningless numbers into >> the kml file, which makes it big. Is there an option to reduce the >> number of decimals for transformed coordinates? > > See http://trac.osgeo.org/gdal/ticket/2461 for information about this... > >> However, and based on my limited understanding: I do not need 3 numbers >> to describe a point in a 2D system, do I? How can I strip the height >> coordinate (and why is it there in the first place?). > > I think you can use the nlt option to at least make the input 2.5 D and > then strip the Z value off, effectively removing the height. It may be > related to the CS transformation but I'm not sure without seeing your > actual input file. > > -Chris I now noticed: my earlier coordinate transformation example with a non-zero height value was done on another computer, with an older version of libproj (4.5.0, from 2006). 13.457676473320388,55.803540172099304,-0.000071634377946 After updating to libproj 4.6.1, the height is always 0, is as expected. 13.457535814437861,55.800578762055501,0 From warmerdam at pobox.com Sat Mar 14 12:46:06 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Sat Mar 14 12:46:24 2009 Subject: [gdal-dev] Lossless JPEG in GDAL In-Reply-To: <49B97A51.9020600@asf.alaska.edu> References: <49B97A51.9020600@asf.alaska.edu> Message-ID: <49BBDF4E.30506@pobox.com> Scott Arko wrote: > Hello, > > > > I am wondering if there is a way to compile support for lossless JPEG > into GDAL. I have installed the libjpeg patch for lossless JPEG and > recompiled/installed libjpeg. Following this I compiled GDAL using the > updated libjpeg, however, I cannot read the lossless JPEG files. I'm > not even sure this is possible, but I would appreciate any thoughts > people might have. Scott, I have not tried this myself, but I would be interested in hearing about any other results or findings. You might want to file a GDAL ticket on the issue as a focus. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ismail at namtrac.org Sat Mar 14 14:31:36 2009 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Sat Mar 14 14:31:39 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <200903132018.11919.even.rouault@mines-paris.org> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> <200903132018.11919.even.rouault@mines-paris.org> Message-ID: <19e566510903141131gdfa736em6a4d6772971336ec@mail.gmail.com> Hi, On Fri, Mar 13, 2009 at 9:18 PM, Even Rouault wrote: > Yes, this is possible but you need to adhere strictfully to the DTED > specification. A DTED tile covers exactly a 1 degree x 1 degree area and the > corners coordinates must be aligned on integer. As far as I remember, DTED0 > has a 30 second x 30 second resolution below latitude 50?, 60'' x 30'' > between 50 and 70, 90'' x 30'' between 70 and 75, etc (read the spec). > > So you will have to produce several DTED files if your input area is over > several 1? x 1? square. You should use the -prjwin to just select the right > area for each tile, like : > gdal_translate -of DTED input.dem n40e2.dt0 -prjwin 41 2 40 3 > gdal_translate -of DTED input.dem n40e3.dt0 -prjwin 41 3 40 4 > etc.. > > With a little of scripting (Python for examle), you could automate that by > reading the extent of the source . > > You must be sure that your source input has the same resolution as the > produced DTED, otherwise you'll need to adjust it by specifying the right > destination size with -outsize 1201 1201 (below 50? latitude). > > I see in GDAL source tree that there's a (not compiled) utility that seems to > do you want. The main file is frmts/dted/dted_test.c, but it relies on the > other C files of the DTED driver. You would need to fiddle a bit with the > makefiles and the header to compile it (I see that some necessary symbols > might not be exported). It is moderately involved provided that you have some > experience with C. This is a very nice recipe, thanks! > But if your third-party app supports 16bit GeoTIFF as a possible source for > DEM, it would be easier to translate to GeoTIFF. Wouldn't that lose elevation information? Regards. -- ?smail D?NMEZ From even.rouault at mines-paris.org Sat Mar 14 14:41:07 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sat Mar 14 14:41:18 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <19e566510903141131gdfa736em6a4d6772971336ec@mail.gmail.com> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> <200903132018.11919.even.rouault@mines-paris.org> <19e566510903141131gdfa736em6a4d6772971336ec@mail.gmail.com> Message-ID: <200903141941.08818.even.rouault@mines-paris.org> > > But if your third-party app supports 16bit GeoTIFF as a possible source > > for DEM, it would be easier to translate to GeoTIFF. > > Wouldn't that lose elevation information? No, not at all. GeoTIFF can carry many data types. > > Regards. From ismail at namtrac.org Sat Mar 14 14:44:00 2009 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Sat Mar 14 14:44:03 2009 Subject: [gdal-dev] Converting USGSDEM into GTOP30 DEM or DTED In-Reply-To: <200903141941.08818.even.rouault@mines-paris.org> References: <19e566510903130438j4e171951q298d21104e31af10@mail.gmail.com> <200903132018.11919.even.rouault@mines-paris.org> <19e566510903141131gdfa736em6a4d6772971336ec@mail.gmail.com> <200903141941.08818.even.rouault@mines-paris.org> Message-ID: <19e566510903141144y452a2251p1806617126780312@mail.gmail.com> Hi, On Sat, Mar 14, 2009 at 8:41 PM, Even Rouault wrote: >> > But if your third-party app supports 16bit GeoTIFF as a possible source >> > for DEM, it would be easier to translate to GeoTIFF. >> >> Wouldn't that lose elevation information? > > No, not at all. GeoTIFF can carry many data types. WoW didn't know that. Thats very good news, since the app supports (supposed to according to its documentation at least) GeoTiff files, thank you very much. Regards. -- ?smail D?NMEZ From sarko at asf.alaska.edu Sat Mar 14 14:46:15 2009 From: sarko at asf.alaska.edu (Scott Arko) Date: Sat Mar 14 14:46:08 2009 Subject: [gdal-dev] Lossless JPEG in GDAL In-Reply-To: <49BBDF4E.30506@pobox.com> References: <49B97A51.9020600@asf.alaska.edu> <49BBDF4E.30506@pobox.com> Message-ID: <49BBFB77.4000003@asf.alaska.edu> An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090314/a94c608e/attachment.html From elias.luttinen at gmail.com Sat Mar 14 15:16:47 2009 From: elias.luttinen at gmail.com (Elias Luttinen) Date: Sat Mar 14 15:16:50 2009 Subject: [gdal-dev] Buildig OpenEV with GDAL 1.6.0 In-Reply-To: <265100.68575.qm@web57807.mail.re3.yahoo.com> References: <265100.68575.qm@web57807.mail.re3.yahoo.com> Message-ID: <443236e20903141216t6dfbc0blce1baa8beba84717@mail.gmail.com> Hi, Did you type 'make install' after 'make' when installing the GDAL? 'make install' creates include and lib directories under --prefix, which OpenEV configure is trying to find. Br, Elias 2009/1/30 Vali Poncos : > Hi folks, > > I built GDAL 1.6.0 then I tried to build OpenEV. OpenEV seem to find GDAL > but not GDALOpen. I checked Internet and I see that there is a GDALOpen.cpp > file which it seems to be missing in the latest GDAL build. I found though > the GDALOpen as a method in gdaldataset.cpp in version 1.6.0. > What would be the problem here? > Thanks, > Vali > > > configure: Found local > GDAL_HOME=/media/Data/Work/K-SAR/openev_source/../gdal > checking for GDALOpen in -lgdal... no > checking for GDALOpen in -lgdal... (cached) no > checking for GDALOpen in -lgdal... (cached) no > configure: error: > OpenEV requires GDAL library, but it was not found.? Please download > and install it.? See http://www.remotesensing.org/gdal > ________________________________ > Looking for the perfect gift? Give the gift of Flickr! > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From jukka.rahkonen at mmmtike.fi Sun Mar 15 10:08:37 2009 From: jukka.rahkonen at mmmtike.fi (Jukka Rahkonen) Date: Sun Mar 15 10:08:49 2009 Subject: [gdal-dev] Re: Lossless JPEG in GDAL References: <49B97A51.9020600@asf.alaska.edu> <49BBDF4E.30506@pobox.com> <49BBFB77.4000003@asf.alaska.edu> Message-ID: Scott Arko asf.alaska.edu> writes: > > > Frank, > Thanks for the idea on filing a ticket.? I will do that.? I tried > another suggestion to install Jasper and see if I could load my images > as lossless JPEG2000 images, however, this does not seem to work.? For > the time being I think I will just write a quick converter using > libjpeg, but it would be nice to have support for this in GDAL.? I > don't imagine many people run into this file format, though.? > Best Regards, > Scott Hi, Lossless JPEG2000 images work for me with JP2KAK and JP2MrSID drivers. JP2ECW works partially, only problem being that it makes a lossy output from lossless image. I have never played woth lossless JPEG. -Jukka Rahkonen- From anders.moe at geocap.no Sun Mar 15 17:54:39 2009 From: anders.moe at geocap.no (Anders Moe) Date: Sun Mar 15 17:55:44 2009 Subject: [gdal-dev] SDE driver reports rasters as layers Message-ID: Hi all, I've noticed that the SDE driver includes rasters in the set of "layers" in the OGR data source, found when querying the OGRDataSource. Is this the intent ? Using calls like OGRSFDRIVER::CopyDataSource ( ... ) fails with malloc exception probably because (in my case) some of the images are huge. Anyway, I dont see what those images are doing in the list of polygonal data that you expect to find in a OGR data source (?). Is there any way to filter out the rasters when reading layers from the OGRDataSource ? Thanks, Best regards, Anders _________________________________________________________________ Kom i gang med festen - Windows Live Events. http://events.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090315/567f9a8b/attachment.html From warmerdam at pobox.com Sun Mar 15 23:53:03 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Sun Mar 15 23:53:15 2009 Subject: [gdal-dev] ogr2ogr changes attribute table after projection In-Reply-To: <49B62DB80200007300019757@pta-emo.csir.co.za> References: <49B62DB80200007300019757@pta-emo.csir.co.za> Message-ID: <49BDCD1F.7010205@pobox.com> Wesley Roberts wrote: > Dear Colleagues, > > I have an ESRI shapefile with approximately 20 000 polygons in a geographic > projection (WGS84). I have used the following command to convert the > shapefile to a utm34s projection. > > ogr2ogr wckznwimsextract_utm34s.shp wckznwimsextract.shp -t_srs EPSG:32734 > -s_srs EPSG:4326 > > the coordinate transformation works perfectly however the attribute data in > the new shapefile is incorrect. In fact very little of the original data is > present, dates in the original data are now null (two different formats > 2009-01-01 & 23-Mar-2008) with other text and numerical attributes also now > removed. All columns from the original data are present but none of the > original data remains. > > If anyone could comment on this problem and or suggest a solution I would > greatly appreciate it. Wesley, I think you would need to file a ticket, and make the data available for us to effectively address this issue. We have encountered some shapefiles (well dbf files) with dates formatted in unconventional formats that has defeated the date parsing in the shapefile driver. Perhaps you are running into this. There has been some progress in GDAL "trunk". But it is hard to provide meaningful info without seeing the problem "up close". Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From ivan.lucena at pmldnet.com Mon Mar 16 01:37:56 2009 From: ivan.lucena at pmldnet.com (Ivan Lucena) Date: Mon Mar 16 01:37:40 2009 Subject: [gdal-dev] Re: Lossless JPEG in GDAL In-Reply-To: References: <49B97A51.9020600@asf.alaska.edu> <49BBDF4E.30506@pobox.com> <49BBFB77.4000003@asf.alaska.edu> Message-ID: <49BDE5B4.5070601@pmldnet.com> Scott, Jukka, Frank, The attached file "structure.doc" belongs to the IJG libjpeg source code distribution and says: "The library does not support the lossless (spatial) JPEG process. Lossless JPEG shares little or no code with lossy JPEG, and would normally be used without the extensive pre- and post-processing provided by this library. We feel that lossless JPEG is better handled by a separate library." Best regards, Ivan Jukka Rahkonen wrote: > Scott Arko asf.alaska.edu> writes: > >> >> Frank, >> Thanks for the idea on filing a ticket. I will do that. I tried >> another suggestion to install Jasper and see if I could load my images >> as lossless JPEG2000 images, however, this does not seem to work. For >> the time being I think I will just write a quick converter using >> libjpeg, but it would be nice to have support for this in GDAL. I >> don't imagine many people run into this file format, though. >> Best Regards, >> Scott > > > Hi, > > Lossless JPEG2000 images work for me with JP2KAK and JP2MrSID drivers. JP2ECW > works partially, only problem being that it makes a lossy output from lossless > image. I have never played woth lossless JPEG. > > -Jukka Rahkonen- > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > From ludovic.mercier at gmail.com Mon Mar 16 08:24:23 2009 From: ludovic.mercier at gmail.com (lidiriel) Date: Mon Mar 16 08:34:17 2009 Subject: [gdal-dev] Re: Access to MetaData in driver implementation In-Reply-To: <49BA8293.60104@pobox.com> References: <69c87df5-d9e1-4608-984c-d2e5ee3e9f6f@w9g2000yqa.googlegroups.com> <49BA8293.60104@pobox.com> Message-ID: Thanks Frank, I CPLParseNameValue is usefull. Now it's work i have a new version of ISIS2 (Pds driver) that read and write pds file. But it's only for a detached label at this moment. Best regards. On 13 mar, 16:58, Frank Warmerdam wrote: > lidiriel wrote: > > Hello, > > > I work on th create method for ISIS2 file (PDS driver). I can write > > raster file but i have a problem with meta data. > > In the case where the user would be use "poDriver->CreateCopy" i try > > to copy and write metaData in the new file. But now i get metadata > > with the method "char** metaData = GetMetadata();" > > But the list of string is not easy to handling. > > Is there another solution for access to the metadata for creating a new > > (or updated copy) of header ? > > Construct and access to an XML tree (like TrySaveXML) ? or another > > method ? > > Lidiriel, > > You can also request individual items from the source dataset > using GetMetadataItem(). ?The functions CSLFetchNameValue(), and > CPLParseNameValue() from gdal/port/cpl_string.h should also make > it fairly easily to search for particular keys in a string list and > to decompose an entry into it's name and value portions. > > 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-...@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev From chaitanya.ch at gmail.com Mon Mar 16 10:15:50 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Mon Mar 16 10:15:53 2009 Subject: [gdal-dev] MapInfo Datum lookup bug, CSV data for drivers In-Reply-To: References: Message-ID: Qi-Shan, As per point 3; the data is not going to be changed often. Reading a data file may complicate things. Just thinking out loud here... Regards, -- Chaitanya kumar CH. On Fri, Mar 13, 2009 at 9:11 AM, Qi-Shan Lim wrote: > Hi all, > > I'm new to GDAL/OGR development and have run up against an existing > bug with the MapInfo driver, which I'm willing to help fix. Details > are at http://trac.osgeo.org/gdal/ticket/481#comment:8 with a comment > which I'll reproduce here for convenience: > > I'm hitting this problem as well and really need to get it resolved. > Only just started working with gdal/ogr so comments would be > appreciated on this proposal: > > --- > 1. Change asDatumInfoList to include the EPSG code for the datum. I > imagine this could be accomplished with a mixture of pattern-matching > the names and some manual intervention. > > 2. Change SetSpatialRef? to look up the data based on the datum's EPSG > code instead of name i.e. use poSpatialRef->GetAuthorityCode?("DATUM") > instead of poSpatialRef->GetAttrValue?("DATUM") > > 3. (Optional) Move asDatumInfoList (and the other hard-coded data, I > guess) into a csv file. > > Is this going to work or am I talking rubbish? If it sounds reasonable > I'll go ahead and do up a patch. > --- > > I'm posting to the list as point 3 seems to be a general question - is > it acceptable for drivers that required this sort of data to stick it > into a csv file to put into the data/ directory? Also, if this data is > to be generated in some sort of semi-automated way using a script of > some sort, should this script be committed to the source tree? > > Would appreciate any advice/help as I get familiar with the code base. > > Cheers, > > --Qi-Shan > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From paul.malm at saabgroup.com Mon Mar 16 11:38:40 2009 From: paul.malm at saabgroup.com (Malm Paul) Date: Mon Mar 16 11:43:47 2009 Subject: [gdal-dev] ogr2ogr VPF->postgis In-Reply-To: <48C6A1F2.9050400@pobox.com> References: <48C69CE2.9020502@unc.edu> <48C6A1F2.9050400@pobox.com> Message-ID: <9CE1BBC0D3132A43A391263616F51E7D601C52B2DE@corpappl079.corp.saab.se> Hi! I'm trying to read in VPF data to my postgreSQL/PostGis database with ogr2ogr.exe in WinXP The lht file is placed in c:\test\vmap\v0eur_5\vmaplv0\eurnasia The database is called testgis This is what I typed in on the command prompt: ogr2ogr -f PostgreSQL PG:"dbname='testgis' user='cvfc' passwd='pwd'" gltp:\vrf\test\vmap\v0eur_5\vmaplv0\eurnasia -lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line' This is what I got: FAILURE: Unable to open datasource `gltp:\vrftest\vmap\v0eur_5\vmaplv0\eurnasia' with the following drivers. -> ESRI Shapefile -> MapInfo File -> UK .NTF -> SDTS -> TIGER -> S57 -> DGN -> VRT -> REC -> Memory -> BNA -> CSV -> GML -> GPX -> KML -> GeoJSON -> GMT -> ODBC -> PGeo -> AVCBin What have I missed? Is it possible to load all featuretypes in a Postgis database at once? Kind regards, Paul From creta.kano at gmail.com Mon Mar 16 12:04:37 2009 From: creta.kano at gmail.com (sophia parafina) Date: Mon Mar 16 12:04:40 2009 Subject: [gdal-dev] ogr2ogr VPF->postgis In-Reply-To: <9CE1BBC0D3132A43A391263616F51E7D601C52B2DE@corpappl079.corp.saab.se> References: <48C69CE2.9020502@unc.edu> <48C6A1F2.9050400@pobox.com> <9CE1BBC0D3132A43A391263616F51E7D601C52B2DE@corpappl079.corp.saab.se> Message-ID: <3fbc61530903160904q33f4d2b3r896a666a96fe3173@mail.gmail.com> slashes are incorrect, e.g. gltp:[//]//:: On Mon, Mar 16, 2009 at 11:38 AM, Malm Paul wrote: > Hi! > I'm trying to read in VPF data to my postgreSQL/PostGis database with > ogr2ogr.exe in WinXP > > The lht file is placed in c:\test\vmap\v0eur_5\vmaplv0\eurnasia > The database is called testgis > > This is what I typed in on the command prompt: > ogr2ogr -f PostgreSQL PG:"dbname='testgis' user='cvfc' passwd='pwd'" > gltp:\vrf\test\vmap\v0eur_5\vmaplv0\eurnasia -lco OVERWRITE=yes -nln > polbndl_bnd 'polbndl@bnd(*)_line' > > This is what I got: > FAILURE: > Unable to open datasource `gltp:\vrftest\vmap\v0eur_5\vmaplv0\eurnasia' > with the following drivers. > -> ESRI Shapefile > -> MapInfo File > -> UK .NTF > -> SDTS > -> TIGER > -> S57 > -> DGN > -> VRT > -> REC > -> Memory > -> BNA > -> CSV > -> GML > -> GPX > -> KML > -> GeoJSON > -> GMT > -> ODBC > -> PGeo > -> AVCBin > > What have I missed? > > Is it possible to load all featuretypes in a Postgis database at once? > > Kind regards, > Paul_______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090316/7a8c3e48/attachment.html From paul.malm at saabgroup.com Mon Mar 16 12:10:58 2009 From: paul.malm at saabgroup.com (Malm Paul) Date: Mon Mar 16 12:11:07 2009 Subject: [gdal-dev] ogr2ogr VPF->postgis In-Reply-To: <3fbc61530903160904q33f4d2b3r896a666a96fe3173@mail.gmail.com> References: <48C69CE2.9020502@unc.edu> <48C6A1F2.9050400@pobox.com> <9CE1BBC0D3132A43A391263616F51E7D601C52B2DE@corpappl079.corp.saab.se> <3fbc61530903160904q33f4d2b3r896a666a96fe3173@mail.gmail.com> Message-ID: <9CE1BBC0D3132A43A391263616F51E7D601C52B2E6@corpappl079.corp.saab.se> I saw that i should use FWTOOLS to get the postgres driver and then I tried this without any success: ogr2ogr -f "PostgreSQL" PG:"host=localhost dbname=testgis user=cvfc PG:passwd=pwd" gltp:/vrf/test/vmap/v0eur_5/vmaplv0/eurnasia -lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line' ERROR 1: PQconnectdb failed. invalid connection option "PG:passwd" ERROR 1: PostgreSQL driver doesn't currently support database creation. Please create database with the `createdb' command. PostgreSQL driver failed to create PG:host=localhost dbname=testgis user=postgres PG:passwd=postgrespwd Kind regards, Paul ________________________________ From: sophia parafina [mailto:creta.kano@gmail.com] Sent: den 16 mars 2009 17:05 To: Malm Paul Cc: gdal-dev Subject: Re: [gdal-dev] ogr2ogr VPF->postgis slashes are incorrect, e.g. gltp:[//]//:: On Mon, Mar 16, 2009 at 11:38 AM, Malm Paul > wrote: Hi! I'm trying to read in VPF data to my postgreSQL/PostGis database with ogr2ogr.exe in WinXP The lht file is placed in c:\test\vmap\v0eur_5\vmaplv0\eurnasia The database is called testgis This is what I typed in on the command prompt: ogr2ogr -f PostgreSQL PG:"dbname='testgis' user='cvfc' passwd='pwd'" gltp:\vrf\test\vmap\v0eur_5\vmaplv0\eurnasia -lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line' This is what I got: FAILURE: Unable to open datasource `gltp:\vrftest\vmap\v0eur_5\vmaplv0\eurnasia' with the following drivers. -> ESRI Shapefile -> MapInfo File -> UK .NTF -> SDTS -> TIGER -> S57 -> DGN -> VRT -> REC -> Memory -> BNA -> CSV -> GML -> GPX -> KML -> GeoJSON -> GMT -> ODBC -> PGeo -> AVCBin What have I missed? Is it possible to load all featuretypes in a Postgis database at once? Kind regards, Paul_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090316/eda4c547/attachment.html From paul.malm at saabgroup.com Mon Mar 16 12:21:24 2009 From: paul.malm at saabgroup.com (Malm Paul) Date: Mon Mar 16 12:21:33 2009 Subject: [gdal-dev] ogr2ogr VPF->postgis In-Reply-To: <3fbc61530903160904q33f4d2b3r896a666a96fe3173@mail.gmail.com> References: <48C69CE2.9020502@unc.edu> <48C6A1F2.9050400@pobox.com> <9CE1BBC0D3132A43A391263616F51E7D601C52B2DE@corpappl079.corp.saab.se> <3fbc61530903160904q33f4d2b3r896a666a96fe3173@mail.gmail.com> Message-ID: <9CE1BBC0D3132A43A391263616F51E7D601C52B2EA@corpappl079.corp.saab.se> I'm sorry, I rwad on postgis example on internet where it stood passwd instead of password. Now it works. Thank you, Sophia! ________________________________ From: sophia parafina [mailto:creta.kano@gmail.com] Sent: den 16 mars 2009 17:05 To: Malm Paul Cc: gdal-dev Subject: Re: [gdal-dev] ogr2ogr VPF->postgis slashes are incorrect, e.g. gltp:[//]//:: On Mon, Mar 16, 2009 at 11:38 AM, Malm Paul > wrote: Hi! I'm trying to read in VPF data to my postgreSQL/PostGis database with ogr2ogr.exe in WinXP The lht file is placed in c:\test\vmap\v0eur_5\vmaplv0\eurnasia The database is called testgis This is what I typed in on the command prompt: ogr2ogr -f PostgreSQL PG:"dbname='testgis' user='cvfc' passwd='pwd'" gltp:\vrf\test\vmap\v0eur_5\vmaplv0\eurnasia -lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line' This is what I got: FAILURE: Unable to open datasource `gltp:\vrftest\vmap\v0eur_5\vmaplv0\eurnasia' with the following drivers. -> ESRI Shapefile -> MapInfo File -> UK .NTF -> SDTS -> TIGER -> S57 -> DGN -> VRT -> REC -> Memory -> BNA -> CSV -> GML -> GPX -> KML -> GeoJSON -> GMT -> ODBC -> PGeo -> AVCBin What have I missed? Is it possible to load all featuretypes in a Postgis database at once? Kind regards, Paul_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090316/2dc21c5c/attachment.html From randre at gmail.com Mon Mar 16 12:22:55 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Mon Mar 16 12:22:57 2009 Subject: [gdal-dev] gdal, netCDF and projection Message-ID: <9c2015090903160922o4b52216en180041e80b6f22af@mail.gmail.com> Hi all, Just a couple quick netCDF related questions: 1) Is there any way to include projection information in a netCDF file so that gdal can properly read it? It appears that georeferencing is handled correctly, but not projection info. This causes problems with the whole "north/south origin shift" between the netCDF and other raster formats when gdal is used to convert the .nc file into a GeoTIFF. Most notably, I'm not sure how to assign the data a projection - either for display in MapServer, or to reproject it to EPSG:4326: See example below. File created with ArcGIS 9.3: $ gdalinfo fwdir_bas.nc Driver: netCDF/Network Common Data Format Files: fwdir_bas.nc Size is 42000, 42000 Coordinate System is `' Origin = (65.000000000000000,5.000000000028436) Pixel Size = (0.000833333333333,0.000833333333333) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#Source_Software=ESRI ArcGIS Fwdir_bas#long_name=Fwdir_bas Fwdir_bas#esri_pe_string=GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] Fwdir_bas#coordinates=lon lat Fwdir_bas#units=Degree Fwdir_bas#missing_value= lon#long_name=longitude coordinate lon#standard_name=longitude lon#units=degrees_east lat#long_name=latitude coordinate lat#standard_name=latitude lat#units=degrees_north Corner Coordinates: Upper Left ( 65.0000000, 5.0000000) Lower Left ( 65.0000000, 40.0000000) Upper Right ( 100.0000000, 5.0000000) Lower Right ( 100.0000000, 40.0000000) Center ( 82.5000000, 22.5000000) Band 1 Block=42000x1 Type=Byte, ColorInterp=Undefined NoData Value=0 Metadata: NETCDF_VARNAME=Fwdir_bas - After translation to GeoTIFF: $ gdalinfo fwdir_bas.tif Driver: GTiff/GeoTIFF Files: fwdir_bas.tif Size is 42000, 42000 Coordinate System is `' Origin = (65.000000000000000,5.000000000028436) Pixel Size = (0.000833333333333,0.000833333333333) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#Source_Software=ESRI ArcGIS Fwdir_bas#long_name=Fwdir_bas Fwdir_bas#esri_pe_string=GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] Fwdir_bas#coordinates=lon lat Fwdir_bas#units=Degree lon#long_name=longitude coordinate lon#standard_name=longitude lon#units=degrees_east lat#long_name=latitude coordinate lat#standard_name=latitude lat#units=degrees_north Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 65.0000000, 5.0000000) Lower Left ( 65.0000000, 40.0000000) Upper Right ( 100.0000000, 5.0000000) Lower Right ( 100.0000000, 40.0000000) Center ( 82.5000000, 22.5000000) Band 1 Block=42000x1 Type=Byte, ColorInterp=Gray NoData Value=0 Metadata: NETCDF_VARNAME=Fwdir_bas 2) Is there any continuing work being done in the gdal community with regards to the GALEON project? As far as I can see, all gdal posts related to this are from 2005 - 2006, yet recent articles in some industry rags suggest that GALEON is still on the OGC's radar. I'd be interested in working on this with anyone else who already is to help resolve some of the remaining hiccups that are left in getting netCDF files to work more easily with gdal. Feel free to contact me off-list regarding this. Roger From aborruso at tin.it Mon Mar 16 12:50:31 2009 From: aborruso at tin.it (iomeneandrei) Date: Mon Mar 16 12:50:33 2009 Subject: [Gdal-dev] branched objects Message-ID: <1237222231485-2487194.post@n2.nabble.com> Dear all, is there a way, using some ogr utilities, to split a branched object into simple (non-branched) objects? For example, a single, branched area object composed of three "islands" will be split into three separate area objects. Thank you very much, Andrea ----- Andrea Borruso ---------------------------------------------------- email: aborruso@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.storytlr.com/ feed: http://feeds2.feedburner.com/Tanto 38? 7' 48" N, 13? 21' 9" E ---------------------------------------------------- -- View this message in context: http://n2.nabble.com/branched-objects-tp2487194p2487194.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Mon Mar 16 12:51:44 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 16 12:52:03 2009 Subject: [gdal-dev] gdal, netCDF and projection In-Reply-To: <9c2015090903160922o4b52216en180041e80b6f22af@mail.gmail.com> References: <9c2015090903160922o4b52216en180041e80b6f22af@mail.gmail.com> Message-ID: <49BE83A0.5090904@pobox.com> Roger Andr? wrote: > Hi all, > > Just a couple quick netCDF related questions: > > 1) Is there any way to include projection information in a netCDF > file so that gdal can properly read it? It appears that > georeferencing is handled correctly, but not projection info. This > causes problems with the whole "north/south origin shift" between the > netCDF and other raster formats when gdal is used to convert the .nc > file into a GeoTIFF. Most notably, I'm not sure how to assign the > data a projection - either for display in MapServer, or to reproject > it to EPSG:4326: See example below. > > File created with ArcGIS 9.3: > $ gdalinfo fwdir_bas.nc > Driver: netCDF/Network Common Data Format > Files: fwdir_bas.nc > Size is 42000, 42000 > Coordinate System is `' > Origin = (65.000000000000000,5.000000000028436) > Pixel Size = (0.000833333333333,0.000833333333333) > Metadata: > NC_GLOBAL#Conventions=CF-1.0 > NC_GLOBAL#Source_Software=ESRI ArcGIS > Fwdir_bas#long_name=Fwdir_bas > Fwdir_bas#esri_pe_string=GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] > Fwdir_bas#coordinates=lon lat > Fwdir_bas#units=Degree > Fwdir_bas#missing_value= > lon#long_name=longitude coordinate > lon#standard_name=longitude > lon#units=degrees_east > lat#long_name=latitude coordinate > lat#standard_name=latitude > lat#units=degrees_north Roger, The above example is not projected as far as I can see. It is geographic. So I'm not sure what this was intended to be an example of. If I use gdal_translate to convert a utm GeoTIFF file to Netcdf I get a gdalinfo report like below. Driver: netCDF/Network Common Data Format Files: out.nc Size is 512, 512 Coordinate System is: PROJCS["NAD27 / UTM zone 11N", GEOGCS["NAD27", DATUM["North_American_Datum_1927", SPHEROID["Clarke 1866",6378206.4,294.9786982139006, AUTHORITY["EPSG","7008"]], AUTHORITY["EPSG","6267"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4267"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-117], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","26711"]] Origin = (440720.000000000000000,3751320.000000000000000) Pixel Size = (60.000000000000000,-60.000000000000000) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#AREA_OR_POINT=Area Band1#grid_mapping=transverse_mercator Band1#long_name=GDAL Band Number 1 transverse_mercator#Northernmost_Northing=3.75132e+06 transverse_mercator#Southernmost_Northing=3.7206e+06 transverse_mercator#Easternmost_Easting=471440 transverse_mercator#Westernmost_Easting=440720 transverse_mercator#spatial_ref=PROJCS["NAD27 / UTM zone 11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke 1866",6378206.4,294.9786982139006,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26711"]] transverse_mercator#GeoTransform=440720 60 0 3.75132e+06 0 -60 transverse_mercator#grid_mapping_name=transverse_mercator transverse_mercator#latitude_of_projection_origin=0.000000e+00 transverse_mercator#central_meridian=-1.170000e+02 transverse_mercator#scale_factor_at_central_meridian=9.996000e-01 transverse_mercator#false_easting=5.000000e+05 transverse_mercator#false_northing=0.000000e+00 Corner Coordinates: Upper Left ( 440720.000, 3751320.000) (117d38'28.21"W, 33d54'8.47"N) Lower Left ( 440720.000, 3720600.000) (117d38'20.79"W, 33d37'31.04"N) Upper Right ( 471440.000, 3751320.000) (117d18'32.07"W, 33d54'13.08"N) Lower Right ( 471440.000, 3720600.000) (117d18'28.50"W, 33d37'35.61"N) Center ( 456080.000, 3735960.000) (117d28'27.39"W, 33d45'52.46"N) Band 1 Block=512x1 Type=Byte, ColorInterp=Undefined NoData Value=0 Metadata: NETCDF_VARNAME=Band1 It is my understanding that with some limitations GDAL is producing NetCDF files conforming to the CF-1.0 conventions, including those for coordinate systems. We also insert the spatial_ref item with the GDAL WKT string for more accurate preservation of the coordinate system. I just tried removing the spatial_ref from the netcdf file and I see that GDAL does *not* successfully read back the coordinate system definition. Grr. Well, that is presumably a bug and should be corrected. I have filed a ticket on this: http://trac.osgeo.org/gdal/ticket/2893 and assigned it to Chaitanya to work on since Denis does not really have time to maintain the netcdf driver anymore. > 2) Is there any continuing work being done in the gdal community with > regards to the GALEON project? As far as I can see, all gdal posts > related to this are from 2005 - 2006, yet recent articles in some > industry rags suggest that GALEON is still on the OGC's radar. I'd be > interested in working on this with anyone else who already is to help > resolve some of the remaining hiccups that are left in getting netCDF > files to work more easily with gdal. Feel free to contact me off-list > regarding this. I have not been following the GALEON work much lately though I'm still on a related mailing list I believe. I am keen on getting our netcdf support into good enough shape that we can use it for serving and consuming netcdf over WCS smoothly. I just can't spend much of my time on it. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Mon Mar 16 13:23:18 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 16 13:23:36 2009 Subject: [gdal-dev] Issue with Lambert Conformal projection with GDAL In-Reply-To: <632453990903130319l5c1fa1e3oe03d08f8c6dd5015@mail.gmail.com> References: <632453990903130319l5c1fa1e3oe03d08f8c6dd5015@mail.gmail.com> Message-ID: <49BE8B06.6070000@pobox.com> Dmitry Kazimirov wrote: > Greetings, > > I currently trying to convert image data in grib2 format > (specification is here if someone interested- > http://www.weather.gov/forecasts/graphical/docs/grib_design.html, my > datafeed is using 'Template 30' i.e. Lambert Conform Conic Projection) > and rewarp it to other projection > I have data about projection(they are sometimes changed) > Lambert Conformal: (614 x 428) input WE:SN output WE:SN res 8 mode 8 > > > Lat1 12.190000 - latitude of first grid point > Lon1 226.541000 - longitude of first grid point > LoV 265.000000 - Orientation longitude (?) > LatD 25.000000 - "Latitude where grid spacing is defined" > Latin1 25.000000 Latin1, first secant latitude > Latin2 25.000000 Latin2, second secant latitude ( > LatSP -90.000000 LonSP 0.000000 - Latitude and longitude of southern pole (?) > Dx 12190.528000 m - Dx, X-direction grid length > Dy 12190.590000 m - Dy, Y-direction grid length > > GDAL Georeference's SetLCC require parameters > SetLCC ( double dfStdP1, > double dfStdP2, > double dfCenterLat, > double dfCenterLong, > double dfFalseEasting, > double dfFalseNorthing > ) > (uncommented at all) > how I use my parameters to with GDAL? > I understood that dfStdP1/P2 is 1st/2nd standard parallel(25.0000 in my case) > What I should use fort dfCenterLat/Long? > for falseEasting/Northing? > Could anyone help? Dmitry, I don't have any good help. I find the way that the GRIB folks describe coordinate systems *very* hard to relate to normal GIS/Cartography terminology. I will note that the grib driver has this logic for some LCC coordinate systems: case GS3_LAMBERT: oSRS.SetLCC(meta->gds.scaleLat1, meta->gds.scaleLat2, 0.0, meta->gds.orientLon, 0.0, 0.0); // set projection I don't know if that helps at all or not. Good luck, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Mon Mar 16 13:26:40 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 16 13:26:57 2009 Subject: [gdal-dev] MapInfo Datum lookup bug, CSV data for drivers In-Reply-To: References: Message-ID: <49BE8BD0.3030502@pobox.com> Qi-Shan Lim wrote: > Hi all, > > I'm new to GDAL/OGR development and have run up against an existing > bug with the MapInfo driver, which I'm willing to help fix. Details > are at http://trac.osgeo.org/gdal/ticket/481#comment:8 with a comment > which I'll reproduce here for convenience: > > I'm hitting this problem as well and really need to get it resolved. > Only just started working with gdal/ogr so comments would be > appreciated on this proposal: > > --- > 1. Change asDatumInfoList to include the EPSG code for the datum. I > imagine this could be accomplished with a mixture of pattern-matching > the names and some manual intervention. Qi-Shan, I agree that this would be a good idea. The MITAB code predates some of the EPSG support in OGR (particularly the use of authority[] nodes, and so it was not included originally. Populating the column may not always be practical though. > 2. Change SetSpatialRef? to look up the data based on the datum's EPSG > code instead of name i.e. use poSpatialRef->GetAuthorityCode?("DATUM") > instead of poSpatialRef->GetAttrValue?("DATUM") Seems reasonable where available. > 3. (Optional) Move asDatumInfoList (and the other hard-coded data, I > guess) into a csv file. I'm not too keen on moving it into a CSV file as currently MITAB in standalone mode has no dependency on external files which keeps it's use quite a bit simplier than would otherwise be the case. > Is this going to work or am I talking rubbish? If it sounds reasonable > I'll go ahead and do up a patch. Thanks. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From randre at gmail.com Mon Mar 16 14:05:30 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Mon Mar 16 14:05:33 2009 Subject: [gdal-dev] gdal, netCDF and projection In-Reply-To: <49BE83A0.5090904@pobox.com> References: <9c2015090903160922o4b52216en180041e80b6f22af@mail.gmail.com> <49BE83A0.5090904@pobox.com> Message-ID: <9c2015090903161105s3f9e412ega7c6dd2e360a8a56@mail.gmail.com> Hi Frank, Sorry for being unclear about the projection stuff. I guess what I was asking was how to go about defining the "South-up" nature of the data. But I guess it doesn't matter, so long as the corner coords and pixel dimensions are correct. I used "gdal_translate -a_srs "EPSG:4326"" on the GeoTIFF I created earlier, and it seems to have assigned the SRS properly and kept a positive Y axis pixel size. This "South-Up" stuff is just weird to me, I guess. $ gdalinfo wgs84_fwdir_bas.tif Driver: GTiff/GeoTIFF Files: wgs84_fwdir_bas.tif Size is 42000, 42000 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (65.000000000000000,5.000000000028436) Pixel Size = (0.000833333333333,0.000833333333333) Metadata: Thanks for confirming that there is a bug in reading coordinate system info from netCDF files. We're trying to make sure that some of our netCDF's in Lambert projection are correctly written - specifically so I can read them with gdal, and could not figure out what values to assign them. I think you're very close to having the netCDF driver working well enough to be used for serving and consuming WCS, but there are still a few issues to work out. What can I do to help? Setup sample problems, test, write use-cases? I'm trying to get a MapServer-based WCS system up at work that uses tiled netCDF's with time series data, so I think I've hit most of the remaining issues along the way. Roger -- On Mon, Mar 16, 2009 at 9:51 AM, Frank Warmerdam wrote: > Roger Andr? wrote: >> >> Hi all, >> >> Just a couple quick netCDF related questions: >> >> 1) ?Is there any way to include projection information in a netCDF >> file so that gdal can properly read it? ?It appears that >> georeferencing is handled correctly, but not projection info. ?This >> causes problems with the whole "north/south origin shift" between the >> netCDF and other raster formats when gdal is used to convert the .nc >> file into a GeoTIFF. ?Most notably, I'm not sure how to assign the >> data a projection - either for display in MapServer, or to reproject >> it to EPSG:4326: ?See example below. >> >> File created with ArcGIS 9.3: >> $ gdalinfo fwdir_bas.nc >> Driver: netCDF/Network Common Data Format >> Files: fwdir_bas.nc >> Size is 42000, 42000 >> Coordinate System is `' >> Origin = (65.000000000000000,5.000000000028436) >> Pixel Size = (0.000833333333333,0.000833333333333) >> Metadata: >> ?NC_GLOBAL#Conventions=CF-1.0 >> ?NC_GLOBAL#Source_Software=ESRI ArcGIS >> ?Fwdir_bas#long_name=Fwdir_bas >> >> ?Fwdir_bas#esri_pe_string=GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] >> ?Fwdir_bas#coordinates=lon lat >> ?Fwdir_bas#units=Degree >> ?Fwdir_bas#missing_value= >> ?lon#long_name=longitude coordinate >> ?lon#standard_name=longitude >> ?lon#units=degrees_east >> ?lat#long_name=latitude coordinate >> ?lat#standard_name=latitude >> ?lat#units=degrees_north > > Roger, > > The above example is not projected as far as I can see. ?It is > geographic. ?So I'm not sure what this was intended to be an > example of. > > If I use gdal_translate to convert a utm GeoTIFF file to > Netcdf I get a gdalinfo report like below. > > Driver: netCDF/Network Common Data Format > Files: out.nc > Size is 512, 512 > Coordinate System is: > PROJCS["NAD27 / UTM zone 11N", > ? ?GEOGCS["NAD27", > ? ? ? ?DATUM["North_American_Datum_1927", > ? ? ? ? ? ?SPHEROID["Clarke 1866",6378206.4,294.9786982139006, > ? ? ? ? ? ? ? ?AUTHORITY["EPSG","7008"]], > ? ? ? ? ? ?AUTHORITY["EPSG","6267"]], > ? ? ? ?PRIMEM["Greenwich",0], > ? ? ? ?UNIT["degree",0.0174532925199433], > ? ? ? ?AUTHORITY["EPSG","4267"]], > ? ?PROJECTION["Transverse_Mercator"], > ? ?PARAMETER["latitude_of_origin",0], > ? ?PARAMETER["central_meridian",-117], > ? ?PARAMETER["scale_factor",0.9996], > ? ?PARAMETER["false_easting",500000], > ? ?PARAMETER["false_northing",0], > ? ?UNIT["metre",1, > ? ? ? ?AUTHORITY["EPSG","9001"]], > ? ?AUTHORITY["EPSG","26711"]] > Origin = (440720.000000000000000,3751320.000000000000000) > Pixel Size = (60.000000000000000,-60.000000000000000) > Metadata: > ?NC_GLOBAL#Conventions=CF-1.0 > ?NC_GLOBAL#AREA_OR_POINT=Area > ?Band1#grid_mapping=transverse_mercator > ?Band1#long_name=GDAL Band Number 1 > ?transverse_mercator#Northernmost_Northing=3.75132e+06 > ?transverse_mercator#Southernmost_Northing=3.7206e+06 > ?transverse_mercator#Easternmost_Easting=471440 > ?transverse_mercator#Westernmost_Easting=440720 > ?transverse_mercator#spatial_ref=PROJCS["NAD27 / UTM zone > 11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke > 1866",6378206.4,294.9786982139006,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26711"]] > ?transverse_mercator#GeoTransform=440720 60 0 3.75132e+06 0 -60 > ?transverse_mercator#grid_mapping_name=transverse_mercator > ?transverse_mercator#latitude_of_projection_origin=0.000000e+00 > ?transverse_mercator#central_meridian=-1.170000e+02 > ?transverse_mercator#scale_factor_at_central_meridian=9.996000e-01 > ?transverse_mercator#false_easting=5.000000e+05 > ?transverse_mercator#false_northing=0.000000e+00 > Corner Coordinates: > Upper Left ?( ?440720.000, 3751320.000) (117d38'28.21"W, 33d54'8.47"N) > Lower Left ?( ?440720.000, 3720600.000) (117d38'20.79"W, 33d37'31.04"N) > Upper Right ( ?471440.000, 3751320.000) (117d18'32.07"W, 33d54'13.08"N) > Lower Right ( ?471440.000, 3720600.000) (117d18'28.50"W, 33d37'35.61"N) > Center ? ? ?( ?456080.000, 3735960.000) (117d28'27.39"W, 33d45'52.46"N) > Band 1 Block=512x1 Type=Byte, ColorInterp=Undefined > ?NoData Value=0 > ?Metadata: > ? ?NETCDF_VARNAME=Band1 > > It is my understanding that with some limitations GDAL > is producing NetCDF files conforming to the CF-1.0 > conventions, including those for coordinate systems. > We also insert the spatial_ref item with the GDAL WKT > string for more accurate preservation of the coordinate > system. > > I just tried removing the spatial_ref from the netcdf > file and I see that GDAL does *not* successfully read back > the coordinate system definition. ?Grr. ?Well, that is > presumably a bug and should be corrected. > > I have filed a ticket on this: > > ?http://trac.osgeo.org/gdal/ticket/2893 > > and assigned it to Chaitanya to work on since Denis does not really > have time to maintain the netcdf driver anymore. > >> 2) ?Is there any continuing work being done in the gdal community with >> regards to the GALEON project? ?As far as I can see, all gdal posts >> related to this are from 2005 - 2006, yet recent articles in some >> industry rags suggest that GALEON is still on the OGC's radar. ?I'd be >> interested in working on this with anyone else who already is to help >> resolve some of the remaining hiccups that are left in getting netCDF >> files to work more easily with gdal. ?Feel free to contact me off-list >> regarding this. > > I have not been following the GALEON work much lately though I'm still > on a related mailing list I believe. ?I am keen on getting our netcdf > support into good enough shape that we can use it for serving and > consuming netcdf over WCS smoothly. ? I just can't spend much of my > time on it. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up ? | Frank Warmerdam, > warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush ? ?| Geospatial Programmer for Rent > > From warmerdam at pobox.com Mon Mar 16 14:13:56 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 16 14:14:11 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint Message-ID: <49BE96E4.7090903@pobox.com> Motion: Authorize $500 Sponsorship of the Toronto Code Sprint There had been some previous discussion of GDAL sponsoring the Toronto Code Sprint (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009). It did not appear this was needed; however, it turned out that feeding hungry developers proved more expensive than expected, and I made a an offer-in-principle for the project to become a sponsor of the event. To that end, I am proposing we spend up to $500 USD to sponsor the event to balance the books. +1 FrankW Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From even.rouault at mines-paris.org Mon Mar 16 14:32:21 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 16 14:32:36 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint In-Reply-To: <49BE96E4.7090903@pobox.com> References: <49BE96E4.7090903@pobox.com> Message-ID: <200903161932.23845.even.rouault@mines-paris.org> +1 for the feeding of hungry and productive developers ;-) Le Monday 16 March 2009 19:13:56 Frank Warmerdam, vous avez ?crit?: > Motion: Authorize $500 Sponsorship of the Toronto Code Sprint > > There had been some previous discussion of GDAL sponsoring the > Toronto Code Sprint (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009). > It did not appear this was needed; however, it turned out that feeding > hungry developers proved more expensive than expected, and I made a an > offer-in-principle for the project to become a sponsor of the event. > > To that end, I am proposing we spend up to $500 USD to sponsor the event > to balance the books. > > +1 FrankW > > Best regards, From even.rouault at mines-paris.org Mon Mar 16 14:54:01 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 16 14:54:17 2009 Subject: [gdal-dev] ARM platform compatibility In-Reply-To: <499A3B8A.7040505@arvus.com.br> References: <4999B62F.5050209@arvus.com.br> <499A1B4F.8090204@gmx.de> <499A3B8A.7040505@arvus.com.br> Message-ID: <200903161954.03016.even.rouault@mines-paris.org> Hi Adriano, Recently, I came through reading the http://wiki.debian.org/ArmEabiPort page and it appears that you must run a debian version with "old" ARM ABI, which has this weird byte ordering related to floating point emulation. The new ARM EABI of the armel architecture guarantees that floating point values use IEEE-754 representation, so GDAL should be happy with that architecture and consider it as standard little-endian host. So I'd encourage you to test Lenny armel then, as I'm not sure we really want to hack GDAL in the many places where it is assumed that float and double values read from/written to the disk are IEEE-754 (module little endian/big endian ordering)... Shapefile driver is one of this instance, but there are many other GDAL raster drivers that should be patched too. Le Tuesday 17 February 2009 05:22:34 Adriano C Naspolini, vous avez ?crit?: > Hi Tom, > I was trying with 1.5.3 (Debian etch, gcc-4.1), now changed to 1.6.0, > but no success. > > About 1.5.2 version, didn't work neither. > > By default, configuration sets up "msb2lsb" (big-wordian). Forcing the > configuration (changing configure file) to be "lsb2msb" make no > difference (maybe because the problem is exactly there). > > The next step I'll do is to apply Etienne's patch manually, because it > became incompatible with newer versions of shpopen.c... > > > Thanks, > > Adriano > > Tom Kazimiers escreveu: > > Hi Adriano, > > > > which version of CGAL did you compile for ARM? > > > > I use 1.5.2 and reading shapefiles works very well. > > > > Regards, > > Tom > > > > Adriano C Naspolini schrieb: > >> Hi, > >> I developed an application and it runs perfectly over X86. However, > >> when i try to run it on ARM it stops reading shapefiles (actually it > >> reads wrong coordinates). I wrote a simple program to tell just the > >> first "point" coordinates. > >> > >> On X86: > >> x=: -53.1275 y= -31.8682 > >> > >> On ARM: > >> x=: -1.00226e-13 y= -1.76938e+52 > >> > >> > >> Looking for the problem here, i found a thread from Etienne Dube on > >> (2004-04-07 05:12:55 GMT), saying it's a byte ordering problem. > >> "Each 32-bit word in the 64-bit double value is stored little-endian, > >> but the most significative 32-bit word comes last in memory > >> ("big-wordian")." > >> > >> Changing the word-order for the first feature inside the ".shp" ("11 > >> 36 3c bd 52 90 4a c0" to "52 90 4a c0 11 36 3c bd") and running it > >> again: > >> > >> under X86: > >> x=: -1.00226e-13 y= -31.8682 > >> > >> under ARM > >> x=: -53.1275 y= -1.76938e+52 > >> > >> So, clearly, i have the same problem then Etienne. He sent a patch, > >> but didn't made many tests... > >> Is there a "final"solution for the problem? I couldn't see any answer > >> to him. > >> > >> Regards, > >> > >> Adriano > >> _______________________________________________ > >> 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 From dmorissette at mapgears.com Mon Mar 16 16:07:38 2009 From: dmorissette at mapgears.com (Daniel Morissette) Date: Mon Mar 16 16:13:30 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint In-Reply-To: <49BE96E4.7090903@pobox.com> References: <49BE96E4.7090903@pobox.com> Message-ID: <49BEB18A.8050807@mapgears.com> +1 Daniel Frank Warmerdam wrote: > Motion: Authorize $500 Sponsorship of the Toronto Code Sprint > > There had been some previous discussion of GDAL sponsoring the > Toronto Code Sprint (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009). > It did not appear this was needed; however, it turned out that feeding > hungry developers proved more expensive than expected, and I made a an > offer-in-principle for the project to become a sponsor of the event. > > To that end, I am proposing we spend up to $500 USD to sponsor the event > to balance the books. > > +1 FrankW > > Best regards, -- Daniel Morissette http://www.mapgears.com/ From szekerest at gmail.com Mon Mar 16 16:40:09 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Mon Mar 16 16:40:15 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint In-Reply-To: <49BE96E4.7090903@pobox.com> References: <49BE96E4.7090903@pobox.com> Message-ID: +1 Tamas 2009/3/16 Frank Warmerdam > Motion: Authorize $500 Sponsorship of the Toronto Code Sprint > > There had been some previous discussion of GDAL sponsoring the > Toronto Code Sprint (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009). > It did not appear this was needed; however, it turned out that feeding > hungry developers proved more expensive than expected, and I made a an > offer-in-principle for the project to become a sponsor of the event. > > To that end, I am proposing we spend up to $500 USD to sponsor the event > to balance the books. > > +1 FrankW > > Best regards, > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090316/f14bef2a/attachment.html From randre at gmail.com Mon Mar 16 17:16:01 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Mon Mar 16 17:16:03 2009 Subject: [gdal-dev] Re: gdal2tiles dateline gap In-Reply-To: <49BD9235.6030806@customweather.com> References: <49BD9235.6030806@customweather.com> Message-ID: <9c2015090903161416k1b0dc361s20209e959ad5ec11@mail.gmail.com> Hi Jeff, Adding list, just in case there is additional input on this. Yes, but the solution I found may not be applicable to your use-case. I needed to create Google Map tiles in spherical mercator projection, not Google Earth KML, so I was able to use TileCache with MapServer to generate them. I found that I had more flexibility using that solution, than I did using the gdal2tiles tool. I should also add that when I used input data that was already in sperical mercator projection, I was unable to get data all the way out to the edges of their defined extents. You might try converting the input data to EPSG:4326 first, then see what you get out of gdal2tiles. I believe it can handle the reprojection for you on-the-fly. Roger -- On Sun, Mar 15, 2009 at 4:41 PM, Jeff Logan wrote: > Hi Roger, > > Gdal2tiles output ?is chopping off New Zealand from a global data set...the > input spherical mercator global image has New Zealand intact. Did you > discover a solution after posting to 'gdal.dev' nine weeks ago? > > Thanks, Jeff > > From saith at arcor.de Tue Mar 17 04:15:38 2009 From: saith at arcor.de (saith@arcor.de) Date: Tue Mar 17 04:15:41 2009 Subject: [gdal-dev] How to use gdal DXF-Patch (Trac #2555) Message-ID: <32708017.1237277738501.JavaMail.ngmail@webmail19.ha2.local> Hi list, I tried to use the DXF-patch (http://trac.osgeo.org/gdal/ticket/2555) to get DXF-support in my gdal. Using the patchfile works fine. After this step I installed the dxflib and copied the lib-files into the new ogr/ogrsf_frmts/dxf folder. I used ./configure in the gdal-src folder with the --prefix - option, to install in a new directory. After make and make install gdal works fine, but without any DXF-support. Where is my mistake? Thanks Mathias Richter Zerrei?en Sie die Netze der Phisher, Hacker und Betr?ger! Ihre Internet-Sicherheits-Seiten auf Arcor.de bieten alle Infos und Hilfsmittel, die Sie zum sicheren Surfen brauchen! Play it safe! http://www.arcor.de/footer-sicherheit/ From klokan at klokan.cz Tue Mar 17 06:07:57 2009 From: klokan at klokan.cz (=?ISO-8859-2?Q?Klokan_Petr_P=F8idal?=) Date: Tue Mar 17 06:08:00 2009 Subject: [gdal-dev] Re: gdal2tiles dateline gap In-Reply-To: <9c2015090903161416k1b0dc361s20209e959ad5ec11@mail.gmail.com> References: <49BD9235.6030806@customweather.com> <9c2015090903161416k1b0dc361s20209e959ad5ec11@mail.gmail.com> Message-ID: <6e41d95b0903170307g266296e5y236a486508bc4251@mail.gmail.com> Jeff and others, >> Gdal2tiles output is chopping off New Zealand from a global data set...the >> input spherical mercator global image has New Zealand intact. Did you >> discover a solution after posting to 'gdal.dev' nine weeks ago? In such case just call gdal2tiles with specified srs for Shperical Mercator: gdal2tiles --s_srs epsg:900913 yourinput.tif This way gdal2tiles will not do the reprojection but it just creates tiles from your input as it is. Chopping off some areas happens when gdal2tiles is doing the internal reprojection of the global dataset himself, because of the default behavior of AutoCreateWarpedVRT in GDAL - this also happens when you call gdalwarp from command line without extra parameters and doing reprojection on global datasets. The whole problem and it's temporary solution step by step is described here: http://code.google.com/p/maptiler/issues/detail?id=6 I am working on a patch for gdal2tiles, which will fix this global reprojection chopping problem as well as problem with pixel inprecise warping coming out of gdal2tiles for tiles in deep zoom levels. Because gdal does not expose much functionality to python I have to do that by editing of the warping VRT (XML) in the postprocessing step, after AutoCreateWarpedVRT is called... Klokan On Mon, Mar 16, 2009 at 10:16 PM, Roger Andr? wrote: > Hi Jeff, > > Adding list, just in case there is additional input on this. > > Yes, but the solution I found may not be applicable to your use-case. > I needed to create Google Map tiles in spherical mercator projection, > not Google Earth KML, so I was able to use TileCache with MapServer to > generate them. ?I found that I had more flexibility using that > solution, than I did using the gdal2tiles tool. > > I should also add that when I used input data that was already in > sperical mercator projection, I was unable to get data all the way out > to the edges of their defined extents. ?You might try converting the > input data to EPSG:4326 first, then see what you get out of > gdal2tiles. ?I believe it can handle the reprojection for you > on-the-fly. > > Roger > -- > >> >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ From hobu.inc at gmail.com Tue Mar 17 10:43:07 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Tue Mar 17 10:43:13 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint In-Reply-To: References: <49BE96E4.7090903@pobox.com> Message-ID: <3D3D0B5B-B4C4-469D-99A3-B054D36F8B8E@gmail.com> > > 2009/3/16 Frank Warmerdam > Motion: Authorize $500 Sponsorship of the Toronto Code Sprint > > There had been some previous discussion of GDAL sponsoring the > Toronto Code Sprint (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009 > ). > It did not appear this was needed; however, it turned out that feeding > hungry developers proved more expensive than expected, and I made a an > offer-in-principle for the project to become a sponsor of the event. > > To that end, I am proposing we spend up to $500 USD to sponsor the > event > to balance the books. > > +1 FrankW > +1 Howard From atompkins at fastmail.fm Tue Mar 17 15:07:43 2009 From: atompkins at fastmail.fm (Andy Tompkins) Date: Tue Mar 17 15:15:57 2009 Subject: [gdal-dev] Feature Style Message-ID: <1237316863.3761.1305908093@webmail.messagingengine.com> Hi, I have just started to use the feature styles in ogr_featurestyle.h, documented at http://www.gdal.org/ogr/ogr_feature_style.html. I really like them. I have a few questions: How much are they supported? Are they widely used? The OGRStyleSymbol does not quite match the document. The code has a place for fontname and the doc has a place for outline style. I assume the doc is correct? How is the angle for a symbol interpreted? I assume as an absolute angle. I would like to draw arrows along a line to show direction, but each arrow symbol would need a different angle to match the tangent of the line. Can I represent this with a SYMBOL string? Thanks in advance, Andy Tompkins From dev at geoaspects.com Tue Mar 17 16:04:09 2009 From: dev at geoaspects.com (Geo Aspects Development) Date: Tue Mar 17 16:04:02 2009 Subject: [gdal-dev] Feature Style In-Reply-To: <1237316863.3761.1305908093@webmail.messagingengine.com> References: <1237316863.3761.1305908093@webmail.messagingengine.com> Message-ID: <3809329E-1FC2-4A23-BA98-8500640BFE29@geoaspects.com> hi, The only format I have found which supports feature styles is MapInfo tab files The spec is hardly supported at all, infact even the dataSource/layer/ feature hierarchy is not supported - everything is at feature level I would guess they are not widely used (for example, you cannot even list the available styles (from either a StyleManager or a StyleTable) - something which is almost mandatory when writing a UI application) There is no "interpretation" as such - the string is parsed into parts or tools - its up to you how you interpret these components in the UI Although I realize its a complex area I must confess that I have had more problems with this part of the API than the rest of OGR and GDAL put together! Regards Tim On Mar 17, 2009, at 8:07 PM, Andy Tompkins wrote: > Hi, > > I have just started to use the feature styles in ogr_featurestyle.h, > documented at http://www.gdal.org/ogr/ogr_feature_style.html. I > really > like them. > > I have a few questions: > How much are they supported? > Are they widely used? > The OGRStyleSymbol does not quite match the document. The code has a > place for fontname and the doc has a place for outline style. I > assume > the doc is correct? > How is the angle for a symbol interpreted? I assume as an absolute > angle. I would like to draw arrows along a line to show direction, > but > each arrow symbol would need a different angle to match the tangent of > the line. Can I represent this with a SYMBOL string? > > Thanks in advance, > Andy Tompkins > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From izzybitsie at gmail.com Tue Mar 17 16:21:36 2009 From: izzybitsie at gmail.com (Dori) Date: Tue Mar 17 16:21:38 2009 Subject: [gdal-dev] gdal_merge.py stitched output image intermittent projection info loss Message-ID: <23e208430903171321o675f90c4w2ba4b4c6e95c6a4f@mail.gmail.com> Hi, I have used gdal_merge.py to stitch geotiff images created with a 3rd party software for a couple of years now. These programs were moved to new hosts a while ago and from there on, although the stitching works the output image seems to loose the projection information when they are created at certain times of day but not at some other times. When the projection info is lost, the image cannot be viewed in the 3rd party software used to create the images been stitched, making it useless. However, all images can be displayed with ImageMagick or openEV. Is there any command I could use to make sure the projection information is stored in the output image at all times? I think my intermittent problem might be cause by some memory shortage on the new hosts at certain times of the day . The input images are not very big ~4 Mb each and there is 16 of them. The output images are not that huge either:~22Mb If this is true then, there is not much I could do to resolve my immediate problems. I am no expert so, I may be missing the real cause of the problem. What makes it hard to guess what it is is the fact that there are no errors logged as the program work all the time. Thanks This is the projection info for output map when cannot be viewed using 3rd party soft.: Size is 7479, 3033^M Coordinate System is:^M LOCAL_CS["unnamed",^M UNIT["metre",1,^M AUTHORITY["EPSG","9001"]]]^M Origin = (-179.999899999999997,73.000000000000000)^M Pixel Size = (0.048132577673166,-0.048139266469396)^M Metadata:^M AREA_OR_POINT=Area^M Image Structure Metadata:^M This is the projection info for output image when it CAN be viewed using 3rd party software: Size is 2400, 1800^M Coordinate System is:^M GEOGCS["unnamed",^M DATUM["WGS_1984",^M SPHEROID["WGS 84",6378137,298.2572235629972,^M AUTHORITY["EPSG","7030"]],^M AUTHORITY["EPSG","6326"]],^M PRIMEM["Greenwich",0],^M UNIT[,0.0174532925199433]]^M This is the projection info for the input images: Coordinate System is: GEOGCS["unnamed", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT[,0.0174532925199433]] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090317/ee4ba05a/attachment.html From warmerdam at pobox.com Tue Mar 17 17:19:55 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 17 17:20:16 2009 Subject: [gdal-dev] gdal_merge.py stitched output image intermittent projection info loss In-Reply-To: <23e208430903171321o675f90c4w2ba4b4c6e95c6a4f@mail.gmail.com> References: <23e208430903171321o675f90c4w2ba4b4c6e95c6a4f@mail.gmail.com> Message-ID: <49C013FB.6090000@pobox.com> Dori wrote: > Hi, > I have used gdal_merge.py to stitch geotiff images created with a 3rd > party software for a couple of years now. > These programs were moved to new hosts a while ago and from there on, > although the stitching works the output image seems to loose the > projection information when they are created at certain times of day but > not at some other times. > When the projection info is lost, the image cannot be viewed in the 3rd > party software used to create the images been stitched, making it > useless. However, all images can be displayed with ImageMagick or openEV. > > Is there any command I could use to make sure the projection information > is stored in the output image at all times? Dori, You can use gdalinfo to check the projection information. > I think my intermittent problem might be cause by some memory shortage > on the new hosts at certain times of the day . The input images are not > very big ~4 Mb each and there is 16 of them. The output images are not > that huge either:~22Mb > If this is true then, there is not much I could do to resolve my > immediate problems. > I am no expert so, I may be missing the real cause of the problem. > > What makes it hard to guess what it is is the fact that there are no > errors logged as the program work all the time. I *suspect* you are running into problems that have now been fixed in GDAL and libtiff. Are you using GDAL 1.6.0? Are you using the latest libtiff distributed with GDAL or a recent libtiff 4 beta? If not, I would suggest you upgrade. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Tue Mar 17 17:31:48 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 17 17:32:06 2009 Subject: [gdal-dev] Motion: Negotiate Maintainer Contract with Chaitanya Kumar CH Message-ID: <49C016C4.4020407@pobox.com> Motion: The GDAL PSC authorizes Frank Warmerdam to negotiate a contract for GDAL maintenance services for 500 hours over 5 months at $12USD/hr for a maximum of $6000USD with Chaitanya Kumar CH. The work will be done pursuant to the terms described in RFC 9: GDAL Paid Maintainer Guidelines with Frank Warmerdam acting as supervisor for the maintainer. -- Chaitanya has been doing GDAL maintenance work for me privately for the last two months or so, and I have been satisfied with his work. He has demonstrated reasonable understanding of GDAL, and ability to work within the maintainer role. Particular focus points in the coming months will be to ensure that the Python test suite is properly maintained as fixes are made, and to provide additional support for users on the mailing list. +1 FrankW Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From noreply at ci.faniq.com Tue Mar 17 18:24:05 2009 From: noreply at ci.faniq.com (Subramaniam S) Date: Tue Mar 17 18:24:06 2009 Subject: [gdal-dev] Subramaniam S has sent you a private message Message-ID: <20090317222405.430AEE002A0@lists.osgeo.org> An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090317/d48f5361/attachment.html From izzybitsie at gmail.com Tue Mar 17 18:49:52 2009 From: izzybitsie at gmail.com (Dori) Date: Tue Mar 17 18:49:55 2009 Subject: [gdal-dev] Re: gdal_merge.py stitched output image intermittent projection info loss In-Reply-To: <23e208430903171321o675f90c4w2ba4b4c6e95c6a4f@mail.gmail.com> References: <23e208430903171321o675f90c4w2ba4b4c6e95c6a4f@mail.gmail.com> Message-ID: <23e208430903171549s68ad512bt5c8c89dfcf09ddc2@mail.gmail.com> Forgot to specify: the programs run hourly and they run OK at all hours but some. On some days they run OK at all times but 0,3,6,9,18,21,23 UTC(GMT) and on some days they also failed at 12 and 15 UTC. However, they run OK throughout the rest of the hours. This is why I am convinced this must be something happening at the times the programs create the output images without Projection info. ImageMagick and openEV display all images even the ones not been displayed by the 3rd party software also used to create the input images. In all cases those are grey scaled satellite pictures i.e. not very big images. Thanks again for any help On Tue, Mar 17, 2009 at 1:21 PM, Dori wrote: > Hi, > I have used gdal_merge.py to stitch geotiff images created with a 3rd party > software for a couple of years now. > These programs were moved to new hosts a while ago and from there on, > although the stitching works the output image seems to loose the projection > information when they are created at certain times of day but not at some > other times. > When the projection info is lost, the image cannot be viewed in the 3rd > party software used to create the images been stitched, making it useless. > However, all images can be displayed with ImageMagick or openEV. > > Is there any command I could use to make sure the projection information is > stored in the output image at all times? > > I think my intermittent problem might be cause by some memory shortage on > the new hosts at certain times of the day . The input images are not very > big ~4 Mb each and there is 16 of them. The output images are not that huge > either:~22Mb > If this is true then, there is not much I could do to resolve my immediate > problems. > I am no expert so, I may be missing the real cause of the problem. > > What makes it hard to guess what it is is the fact that there are no errors > logged as the program work all the time. > > > > Thanks > > > This is the projection info for output map when cannot be viewed using 3rd > party soft.: > > Size is 7479, 3033^M > Coordinate System is:^M > LOCAL_CS["unnamed",^M > UNIT["metre",1,^M > AUTHORITY["EPSG","9001"]]]^M > Origin = (-179.999899999999997,73.000000000000000)^M > Pixel Size = (0.048132577673166,-0.048139266469396)^M > Metadata:^M > AREA_OR_POINT=Area^M > Image Structure Metadata:^M > > > > This is the projection info for output image when it CAN be viewed using > 3rd party software: > Size is 2400, 1800^M > Coordinate System is:^M > GEOGCS["unnamed",^M > DATUM["WGS_1984",^M > SPHEROID["WGS 84",6378137,298.2572235629972,^M > AUTHORITY["EPSG","7030"]],^M > AUTHORITY["EPSG","6326"]],^M > PRIMEM["Greenwich",0],^M > UNIT[,0.0174532925199433]]^M > > > This is the projection info for the input images: > Coordinate System is: > GEOGCS["unnamed", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.2572235629972, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT[,0.0174532925199433]] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090317/6100943a/attachment-0001.html From even.rouault at mines-paris.org Tue Mar 17 19:33:57 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Tue Mar 17 19:34:17 2009 Subject: [gdal-dev] [SOLVED] GDAL crashing on Ubuntu 8.10 Message-ID: <200903180034.00231.even.rouault@mines-paris.org> Hi all, Several users have reported over the past few weeks various crashes when running GDAL, in particular in OGRFeature::GetFieldAsString(). It has been finally identified that it was due to stricter guard logic in GCC that was enabled in Ubuntu 8.10 and later versions because -D_FORTIFY_SOURCE=2 is set by default and is activated when -O is set to 2 or higher. A similar issue was detected in DTEDDataset::CreateCopy() a few weeks ago and was also fixed. The fixes have been applied to current development version, 1.6 stable branch and 1.5 branch. Please refer to http://trac.osgeo.org/gdal/ticket/2896 and http://trac.osgeo.org/gdal/ticket/2824 if you need to apply the relevant patches without waiting for next stable releases. However, it might be possible that similar issues still remain, especially in less popular drivers, so please report it. Best regards, Even From hobu.inc at gmail.com Tue Mar 17 20:30:59 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Tue Mar 17 20:38:09 2009 Subject: [gdal-dev] Motion: Negotiate Maintainer Contract with Chaitanya Kumar CH In-Reply-To: <49C016C4.4020407@pobox.com> References: <49C016C4.4020407@pobox.com> Message-ID: On Mar 17, 2009, at 4:31 PM, Frank Warmerdam wrote: > Motion: The GDAL PSC authorizes Frank Warmerdam to negotiate a > contract > for GDAL maintenance services for 500 hours over 5 months at $12USD/ > hr for > a maximum of $6000USD with Chaitanya Kumar CH. The work will be done > pursuant to the terms described in RFC 9: GDAL Paid Maintainer > Guidelines > with Frank Warmerdam acting as supervisor for the maintainer. > > -- > > Chaitanya has been doing GDAL maintenance work for me privately for > the > last two months or so, and I have been satisfied with his work. He > has > demonstrated reasonable understanding of GDAL, and ability to work > within > the maintainer role. > > Particular focus points in the coming months will be to ensure that > the > Python test suite is properly maintained as fixes are made, and to > provide additional support for users on the mailing list. > > +1 FrankW +1 Howard From szekerest at gmail.com Wed Mar 18 05:09:22 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Wed Mar 18 05:09:24 2009 Subject: [gdal-dev] Motion: Negotiate Maintainer Contract with Chaitanya Kumar CH In-Reply-To: <49C016C4.4020407@pobox.com> References: <49C016C4.4020407@pobox.com> Message-ID: +1 Best regards, Tamas 2009/3/17 Frank Warmerdam > Motion: The GDAL PSC authorizes Frank Warmerdam to negotiate a contract > for GDAL maintenance services for 500 hours over 5 months at $12USD/hr for > a maximum of $6000USD with Chaitanya Kumar CH. The work will be done > pursuant to the terms described in RFC 9: GDAL Paid Maintainer Guidelines > with Frank Warmerdam acting as supervisor for the maintainer. > > -- > > Chaitanya has been doing GDAL maintenance work for me privately for the > last two months or so, and I have been satisfied with his work. He has > demonstrated reasonable understanding of GDAL, and ability to work within > the maintainer role. > > Particular focus points in the coming months will be to ensure that the > Python test suite is properly maintained as fixes are made, and to > provide additional support for users on the mailing list. > > +1 FrankW > > Best regards, > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > warmerdam@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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090318/224795b7/attachment.html From fhillen at uni-osnabrueck.de Wed Mar 18 08:18:29 2009 From: fhillen at uni-osnabrueck.de (Florian Hillen) Date: Wed Mar 18 08:40:05 2009 Subject: [gdal-dev] GDAL warp problem Message-ID: <2254.131.173.65.74.1237378709.squirrel@webmail.rz.uni-osnabrueck.de> Hi list, I'm currently working on a gdal reproject plugin for quantum gis. I'm confronted with following problem: I found a warp tutorial [1] for a simple reprojection yesterday, but it doesn't work as it should. The code creates a new GTiff with a new coordinate system, but the warp seems to fail, because the coordinates are the same as in the origin. The function GDALSuggestedWarpOutput already calculates the wrong output size, so I think the error must be somewhere around the function GDALCreateGenImgProjTransformer. If I warp the image with console-based gdalwarp (gdalwarp -s_srs epsg:31467 -t_srs epsg:4326 src dst) everything works out fine. I read somewhere in the web, that it might caused by a wrong path to the gdal or proj libary, but I tried both dll paths (msys\bin and msys\lib). Does anyone of you can support me in that? Best regards, Florian [1] http://www.gdal.org/warptut.html From dmorissette at mapgears.com Wed Mar 18 08:34:20 2009 From: dmorissette at mapgears.com (Daniel Morissette) Date: Wed Mar 18 08:41:25 2009 Subject: [gdal-dev] Motion: Negotiate Maintainer Contract with Chaitanya Kumar CH In-Reply-To: <49C016C4.4020407@pobox.com> References: <49C016C4.4020407@pobox.com> Message-ID: <49C0EA4C.1020804@mapgears.com> Frank Warmerdam wrote: > Motion: The GDAL PSC authorizes Frank Warmerdam to negotiate a contract > for GDAL maintenance services for 500 hours over 5 months at $12USD/hr for > a maximum of $6000USD with Chaitanya Kumar CH. The work will be done > pursuant to the terms described in RFC 9: GDAL Paid Maintainer Guidelines > with Frank Warmerdam acting as supervisor for the maintainer. > +1 Daniel -- Daniel Morissette http://www.mapgears.com/ From wroberts at csir.co.za Wed Mar 18 09:27:58 2009 From: wroberts at csir.co.za (Wesley Roberts) Date: Wed Mar 18 09:28:49 2009 Subject: [gdal-dev] gdal_fillnodata error Message-ID: <49C112FE0200007300019DC9@pta-emo.csir.co.za> Dear List, Yesterday I did an install of the latest svn gdal release (think it is 1.7) to my local machine. I am interested in using the gdal_fillnodata.py application to fill some lines in my Landsat 7 ETM data. When I run the code python gdal_fillnodata.py -md 400 /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.img /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.fill.img I get the following error gdal.FillNodata() not available. You are likely using "old gen" bindings or an older version of the next gen bindings. I am not sure what this means, could somebody suggest a solution or work around. I am currently trying r.fillnulls in Grass and that is taking a really long time. Many thanks for your help and input, Wesley Wesley Roberts MSc. Researcher: Earth Observation (Ecosystems) Natural Resources and the Environment CSIR Tel: +27 (21) 888-2490 Fax: +27 (21) 888-2693 "To know the road ahead, ask those coming back." - Chinese proverb -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From even.rouault at mines-paris.org Wed Mar 18 14:24:50 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 18 14:25:03 2009 Subject: [gdal-dev] Motion: Negotiate Maintainer Contract with Chaitanya Kumar CH In-Reply-To: <49C016C4.4020407@pobox.com> References: <49C016C4.4020407@pobox.com> Message-ID: <200903181924.51616.even.rouault@mines-paris.org> +1 Best regards, Even Le Tuesday 17 March 2009 22:31:48 Frank Warmerdam, vous avez ?crit?: > Motion: The GDAL PSC authorizes Frank Warmerdam to negotiate a contract > for GDAL maintenance services for 500 hours over 5 months at $12USD/hr for > a maximum of $6000USD with Chaitanya Kumar CH. The work will be done > pursuant to the terms described in RFC 9: GDAL Paid Maintainer Guidelines > with Frank Warmerdam acting as supervisor for the maintainer. > > -- > > Chaitanya has been doing GDAL maintenance work for me privately for the > last two months or so, and I have been satisfied with his work. He has > demonstrated reasonable understanding of GDAL, and ability to work within > the maintainer role. > > Particular focus points in the coming months will be to ensure that the > Python test suite is properly maintained as fixes are made, and to > provide additional support for users on the mailing list. > > +1 FrankW > > Best regards, From bdesc100 at gmail.com Wed Mar 18 15:48:01 2009 From: bdesc100 at gmail.com (Benjamin Deschamps) Date: Wed Mar 18 15:48:03 2009 Subject: [Gdal-dev] Problems with RS2 driver for import to grass Message-ID: <1237405681599-2499302.post@n2.nabble.com> I'm having a few issues importing RADARSAT-2 data to GRASS. I used: r.in.gdal input=RADARSAT_2_CALIB:SIGMA0:/Users/Benjamin/Desktop/PK6621_DK406_FQ9_20080405_124900_HH_VV_HV_VH_SLC_(Altona_Promo)/product.xml output=altona to import the sigma nought calibrated data. For some reason this only imports 31 GCPs out of 350, and the values of the resulting GRASS layer are limited to -1, 0 and 1, so the map doesn't look like anything understandable. If I import uncalibrated values instead (RADARSAT_2_CALIB:UNCALIB:etc) I get a much more appropriate range of values, and all 350 GCPs are included. How can I get all GCPs and a more appropriate range of values for the sigma nough subdataset? The dataset is available as part of the RADARSAT-2 demo dataset at ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip Thanks, Benjamin -- View this message in context: http://n2.nabble.com/Problems-with-RS2-driver-for-import-to-grass-tp2499302p2499302.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From atompkins at fastmail.fm Wed Mar 18 16:05:03 2009 From: atompkins at fastmail.fm (Andy Tompkins) Date: Wed Mar 18 16:05:05 2009 Subject: [gdal-dev] Feature Style In-Reply-To: <3809329E-1FC2-4A23-BA98-8500640BFE29@geoaspects.com> References: <1237316863.3761.1305908093@webmail.messagingengine.com> <3809329E-1FC2-4A23-BA98-8500640BFE29@geoaspects.com> Message-ID: <1237406703.8867.1306124369@webmail.messagingengine.com> Hi Thank you for the information! At my work, we have a proprietary spatial database. We have outgrown our current structure used to describe the style of features as we want to more richly describe the style. Can you suggest a replacement for us? What do others use? Thanks, Andy. On Tue, 17 Mar 2009 21:04 +0100, "Geo Aspects Development" wrote: > hi, > > The only format I have found which supports feature styles is MapInfo > tab files The spec is hardly supported at all, infact even the > dataSource/layer/ feature hierarchy is not supported - everything is > at feature level I would guess they are not widely used (for example, > you cannot even list the available styles (from either a StyleManager > or a StyleTable) > - something which is almost mandatory when writing a UI application) > There is no "interpretation" as such - the string is parsed into > parts or tools - its up to you how you interpret these components in > the UI > > Although I realize its a complex area I must confess that I have had > more problems with this part of the API than the rest of OGR and GDAL > put together! > > Regards Tim > > On Mar 17, 2009, at 8:07 PM, Andy Tompkins wrote: > > > Hi, > > > > I have just started to use the feature styles in ogr_featurestyle.h, > > documented at http://www.gdal.org/ogr/ogr_feature_style.html. I > > really like them. > > > > I have a few questions: How much are they supported? Are they widely > > used? The OGRStyleSymbol does not quite match the document. The > > code has a place for fontname and the doc has a place for outline > > style. I assume the doc is correct? How is the angle for a symbol > > interpreted? I assume as an absolute angle. I would like to draw > > arrows along a line to show direction, but each arrow symbol would > > need a different angle to match the tangent of the line. Can I > > represent this with a SYMBOL string? > > > > Thanks in advance, Andy Tompkins > > _______________________________________________ > > gdal-dev mailing list gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > From bdesc100 at gmail.com Wed Mar 18 16:23:13 2009 From: bdesc100 at gmail.com (Benjamin Deschamps) Date: Wed Mar 18 16:23:27 2009 Subject: [Gdal-dev] Problems with RS2 driver for import to grass In-Reply-To: <20090318200634.GA31648@cowpig.ca> References: <1237405681599-2499302.post@n2.nabble.com> <20090318200634.GA31648@cowpig.ca> Message-ID: <46D2C312-778B-48FE-8B74-D26538D7DCBF@gmail.com> Phil, I am using GDAL 1.6.0-5 and GRASS 6.4.0RC3. I guess my question was more whether it was possible to keep the data in complex format, with two layers per channel for imaginary and real components. I'm having a hard time getting the image to look and have the values of a "real" radarsat-2 image... I don't understand how the data can be used in integer format (-1,0,1). Benjamin On 18-Mar-09, at 4:06 PM, Philippe Vachon wrote: > Hi Ben, > > I can't recall the exact details of how the GRASS r.in.gdal mechanism > works, but the results you describe are similar to importing > calibrated > data into an integer raster. Calibrated SAR data is typically > represented as floats, as many of the values are in [0, 1), if I am > not > mistaken. As such, the values when cast to integers will be clamped > to 0 > or 1 (or -1, in the case of the complex values). > > I'm not certain about the GCP issue, since I can import all of the > GCPs > in the Altona dataset using a little app I just whipped up. Perhaps it > could be something specific to GRASS that I'm not aware of. Happen to > know what version of GDAL you're using? > > Cheers, > Phil > > On Wed, Mar 18, 2009 at 12:48:01PM -0700, Benjamin Deschamps wrote: >> >> I'm having a few issues importing RADARSAT-2 data to GRASS. I used: >> >> r.in.gdal >> input=RADARSAT_2_CALIB:SIGMA0:/Users/Benjamin/Desktop/ >> PK6621_DK406_FQ9_20080405_124900_HH_VV_HV_VH_SLC_(Altona_Promo)/ >> product.xml >> output=altona >> >> to import the sigma nought calibrated data. For some reason this only >> imports 31 GCPs out of 350, and the values of the resulting GRASS >> layer are >> limited to -1, 0 and 1, so the map doesn't look like anything >> understandable. If I import uncalibrated values instead >> (RADARSAT_2_CALIB:UNCALIB:etc) I get a much more appropriate range of >> values, and all 350 GCPs are included. >> >> How can I get all GCPs and a more appropriate range of values for >> the sigma >> nough subdataset? The dataset is available as part of the >> RADARSAT-2 demo >> dataset at >> ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip >> ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip >> >> Thanks, Benjamin >> -- >> View this message in context: http://n2.nabble.com/Problems-with-RS2-driver-for-import-to-grass-tp2499302p2499302.html >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From philippe at cowpig.ca Wed Mar 18 16:06:34 2009 From: philippe at cowpig.ca (Philippe Vachon) Date: Wed Mar 18 16:35:26 2009 Subject: [Gdal-dev] Problems with RS2 driver for import to grass In-Reply-To: <1237405681599-2499302.post@n2.nabble.com> References: <1237405681599-2499302.post@n2.nabble.com> Message-ID: <20090318200634.GA31648@cowpig.ca> Hi Ben, I can't recall the exact details of how the GRASS r.in.gdal mechanism works, but the results you describe are similar to importing calibrated data into an integer raster. Calibrated SAR data is typically represented as floats, as many of the values are in [0, 1), if I am not mistaken. As such, the values when cast to integers will be clamped to 0 or 1 (or -1, in the case of the complex values). I'm not certain about the GCP issue, since I can import all of the GCPs in the Altona dataset using a little app I just whipped up. Perhaps it could be something specific to GRASS that I'm not aware of. Happen to know what version of GDAL you're using? Cheers, Phil On Wed, Mar 18, 2009 at 12:48:01PM -0700, Benjamin Deschamps wrote: > > I'm having a few issues importing RADARSAT-2 data to GRASS. I used: > > r.in.gdal > input=RADARSAT_2_CALIB:SIGMA0:/Users/Benjamin/Desktop/PK6621_DK406_FQ9_20080405_124900_HH_VV_HV_VH_SLC_(Altona_Promo)/product.xml > output=altona > > to import the sigma nought calibrated data. For some reason this only > imports 31 GCPs out of 350, and the values of the resulting GRASS layer are > limited to -1, 0 and 1, so the map doesn't look like anything > understandable. If I import uncalibrated values instead > (RADARSAT_2_CALIB:UNCALIB:etc) I get a much more appropriate range of > values, and all 350 GCPs are included. > > How can I get all GCPs and a more appropriate range of values for the sigma > nough subdataset? The dataset is available as part of the RADARSAT-2 demo > dataset at > ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip > ftp://ftp.mda.ca/Fine%20Quad-Pol%20Dataset/Altona_%20R2_FineQuad9_HH_VV_HV_VH_SLC.zip > > Thanks, Benjamin > -- > View this message in context: http://n2.nabble.com/Problems-with-RS2-driver-for-import-to-grass-tp2499302p2499302.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From dev at geoaspects.com Wed Mar 18 17:21:25 2009 From: dev at geoaspects.com (Geo Aspects Development) Date: Wed Mar 18 17:26:20 2009 Subject: [gdal-dev] Feature Style In-Reply-To: <1237406703.8867.1306124369@webmail.messagingengine.com> References: <1237316863.3761.1305908093@webmail.messagingengine.com> <3809329E-1FC2-4A23-BA98-8500640BFE29@geoaspects.com> <1237406703.8867.1306124369@webmail.messagingengine.com> Message-ID: <3A5573D4-7AD9-407F-B616-A6C33BA5E313@geoaspects.com> Hello, If you are using OGR, because certain drivers support reading/writing of FeatureStyles, you should probably try to build on top of them (which is what I have done - linking into the Quartz API of OS X with my own style clases) OGCs web mapping standards use a format called SLD, web (vector) graphics use SVG. Flash is also a possibility. But none of these are supported by OGR. I have not found any support for feature styles Oracle Spatial but PostGIS looks more promising (I have no experience of using it though) There is also some movement on osgeo to set up a symbology database. hope this helps! Tim On Mar 18, 2009, at 9:05 PM, Andy Tompkins wrote: > Hi > > Thank you for the information! > > At my work, we have a proprietary spatial database. We have outgrown > our current structure used to describe the style of features as we > want > to more richly describe the style. > > Can you suggest a replacement for us? What do others use? > > Thanks, > > Andy. > > On Tue, 17 Mar 2009 21:04 +0100, "Geo Aspects Development" > wrote: >> hi, >> >> The only format I have found which supports feature styles is MapInfo >> tab files The spec is hardly supported at all, infact even the >> dataSource/layer/ feature hierarchy is not supported - everything is >> at feature level I would guess they are not widely used (for example, >> you cannot even list the available styles (from either a StyleManager >> or a StyleTable) >> - something which is almost mandatory when writing a UI application) >> There is no "interpretation" as such - the string is parsed into >> parts or tools - its up to you how you interpret these components in >> the UI >> >> Although I realize its a complex area I must confess that I have had >> more problems with this part of the API than the rest of OGR and GDAL >> put together! >> >> Regards Tim >> >> On Mar 17, 2009, at 8:07 PM, Andy Tompkins wrote: >> >>> Hi, >>> >>> I have just started to use the feature styles in ogr_featurestyle.h, >>> documented at http://www.gdal.org/ogr/ogr_feature_style.html. I >>> really like them. >>> >>> I have a few questions: How much are they supported? Are they widely >>> used? The OGRStyleSymbol does not quite match the document. The >>> code has a place for fontname and the doc has a place for outline >>> style. I assume the doc is correct? How is the angle for a symbol >>> interpreted? I assume as an absolute angle. I would like to draw >>> arrows along a line to show direction, but each arrow symbol would >>> need a different angle to match the tangent of the line. Can I >>> represent this with a SYMBOL string? >>> >>> Thanks in advance, Andy Tompkins >>> _______________________________________________ >>> 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 From even.rouault at mines-paris.org Wed Mar 18 17:48:46 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 18 17:48:57 2009 Subject: Fwd: Re: [gdal-dev] [SOLVED] GDAL crashing on Ubuntu 8.10 Message-ID: <200903182248.47546.even.rouault@mines-paris.org> Thanks Markus. However I'm a bit concerned that this bug appears to have been known since a few months by some distro, not only Ubuntu... Distro bug trackers are certainly a useful thing, but unfortunately what comes in them has a high change of getting unnoticed here. Not sure how that could get improved, as some bugs may also be very distro specific and would probably not interest us much. Frustrating situation... -------------- next part -------------- An embedded message was scrubbed... From: Markus Neteler Subject: Re: [gdal-dev] [SOLVED] GDAL crashing on Ubuntu 8.10 Date: Wed, 18 Mar 2009 21:44:05 +0100 Size: 4446 Url: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090318/f8163d17/attachment-0001.mht From neteler at osgeo.org Wed Mar 18 17:53:59 2009 From: neteler at osgeo.org (Markus Neteler) Date: Wed Mar 18 17:54:02 2009 Subject: [gdal-dev] [SOLVED] GDAL crashing on Ubuntu 8.10 In-Reply-To: <200903182248.47546.even.rouault@mines-paris.org> References: <200903182248.47546.even.rouault@mines-paris.org> Message-ID: <86782b610903181453n7eb6a0fct4d59ec1e4764148e@mail.gmail.com> 2009/3/18 Even Rouault : > Thanks Markus. > > However I'm a bit concerned that this bug appears to have been known since a > few months by some distro, not only Ubuntu... Distro bug trackers are > certainly a useful thing, but unfortunately what comes in them has a high > change of getting unnoticed here. Not sure how that could get improved, as > some bugs may also be very distro specific and would probably not interest us > much. Frustrating situation... Well, in this case I was watching them because these complaints came to us ("GRASS failing on Ubuntu") which turned out to be a GDAL problem which then triggered the bug and I looked at it and posted back your notice.. :-) Indeed, not that bad (I was too lazy to also post it to the Fedora tracker). Yes, the link between OSGeo projects and *some* distro trackers is to be improved while other distros already started to better communicate (it should be in *their* interest, too!). Best Markus From phyu108 at gmail.com Thu Mar 19 00:58:03 2009 From: phyu108 at gmail.com (Pwint Phyu Aung) Date: Thu Mar 19 00:58:05 2009 Subject: [gdal-dev] gdal make error : installing map server Message-ID: <446aa160903182158k2f79d4c3y22a81cf5067496dd@mail.gmail.com> Hi there! I'd an install error about gdal-1.6.0. I tried to install Map server on my solaris 10 intel server. I 'd already installed all the necessary packages like gcc, php, mysql etc. Then I configure gdal like ./configure --with-mysql=/usr/local/mysql/bin/mysql_config --without-python --without-ogr --without-pg --with-php and I got the error message in make stage: ld: fatal: Symbol referencing errors. No output written to .libs/gdalinfo collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/gdal-1.6.0/apps' make: *** [apps-target] Error 2 Then I tried to configure by enabling ogr ./configure --with-mysql=/usr/local/mysql/bin/mysql_config --without-python --without-pg --with-php but still got the same error. How to fix that one? Please help me. And I've no idea exactly for what is the difference for enabling ogr or not? If anyone know, please advice me. Hope anyone can give me a helping hand. Thanks. Pwint -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090319/cddfe1f5/attachment.html From giohappy at gmail.com Thu Mar 19 05:12:19 2009 From: giohappy at gmail.com (G. Allegri) Date: Thu Mar 19 05:12:22 2009 Subject: [gdal-dev] error with jpeglib while compiling 1.5.4 with MinGW Message-ID: Hi. I'm trying to compile gdal 1.5.4 with msys+mingw 5.4.1. I have problems linking the jpeglib, as internal. My configure command is: ./configure --prefix=/usr/local --without-grass --with-sqlite3=/usr/local/sqlite --with-pg=/usr/local/bin/pg_config.exe --with-local=/usr/local (I have set --with-local to solve the problem for tiffio, while compilig it couldn't be found...) I receive the following error: *** Warning: This system can not link to static lib archive /usr/local/lib/ libjpeg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This system can not link to static lib archive /usr/local/lib/ libjpeg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. libtool: link: rm -fr .libs/libgdal.dll.a .libs/libgdal.la.lnkscript libtool: link: creating GNU ld script: .libs/libgdal.la.lnkscript libtool: link: g++ -shared -nostdlib C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../dllcrt2.o C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/crtbegin.o .libs/libgdal.la.lnkscript -L/usr/local/sqlite/lib /usr/local/sqlite/lib/libsqlite3.dll.a -L/usr/local/lib /usr/local/lib/libexpat.dll.a /usr/local/lib/libtiff.dll.a -L/usr/local/bin -LC:/msys/local/lib -lpq -lz -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5 -LC:/msys/mingw/bin/../lib/gcc -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../.. -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/crtend.o -o .libs/libgdal-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgdal.dll.a ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD2Ev': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined reference to `jpeg_abort_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined reference to `jpeg_destroy_decompress' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD1Ev': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined reference to `jpeg_abort_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined reference to `jpeg_destroy_decompress' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD0Ev': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined reference to `jpeg_abort_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined reference to `jpeg_destroy_decompress' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset17LoadDefaultTablesEi': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1134: undefined reference to `jpeg_alloc_quant_table' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1149: undefined reference to `jpeg_alloc_huff_table' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1168: undefined reference to `jpeg_alloc_huff_table' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset7RestartEv': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1196: undefined reference to `jpeg_abort_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1197: undefined reference to `jpeg_destroy_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1198: undefined reference to `jpeg_CreateDecompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1211: undefined reference to `jpeg_read_header' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1215: undefined reference to `jpeg_start_decompress' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset12LoadScanlineEi': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:964: undefined reference to `jpeg_start_decompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1005: undefined reference to `jpeg_read_scanlines' ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset4OpenEP12GDALOpenInfo': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1448: undefined reference to `jpeg_std_error' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1452: undefined reference to `jpeg_CreateDecompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1485: undefined reference to `jpeg_read_header' ./frmts/o/.libs/jpgdataset.o: In function `Z14JPEGCreateCopyPKcP11GDALDatasetiPPcPFidS0_PvES5_': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1953: undefined reference to `jpeg_std_error' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1954: undefined reference to `jpeg_CreateCompress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1971: undefined reference to `jpeg_set_defaults' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1986: undefined reference to `jpeg_set_quality' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1991: undefined reference to `jpeg_start_compress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2022: undefined reference to `jpeg_write_scanlines' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2041: undefined reference to `jpeg_destroy_compress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2040: undefined reference to `jpeg_finish_compress' C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1989: undefined reference to `jpeg_simple_progression' ./frmts/o/.libs/nitfdataset.o: In function `ZN11NITFDataset14NITFCreateCopyEPKcP11GDALDatasetiPPcPFidS1_PvES6_': C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3202: undefined reference to `jpeg_std_error' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3203: undefined reference to `jpeg_CreateCompress' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3221: undefined reference to `jpeg_set_defaults' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3237: undefined reference to Creating library file: .libs/libgdal.dll.a `jpeg_set_quality' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3240: undefined reference to `jpeg_simple_progression' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3242: undefined reference to `jpeg_start_compress' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3291: undefined reference to `jpeg_finish_compress' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3292: undefined reference to `jpeg_destroy_compress' C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3273: undefined reference to `jpeg_write_scanlines' ./frmts/o/.libs/vsidataio.o: In function `Z14jpeg_vsiio_srcP22jpeg_decompress_structP6_iobuf': C:/msys/local/src/gdal-1.5.4/frmts/jpeg/vsidataio.cpp:224: undefined reference to `jpeg_resync_to_restart' collect2: ld returned 1 exit status make[1]: *** [libgdal.la] Error 1 make[1]: Leaving directory `/usr/local/src/gdal-1.5.4' make: *** [check-lib] Error 2 What's wrong? giovanni -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090319/03edc031/attachment.html From giohappy at gmail.com Thu Mar 19 05:41:20 2009 From: giohappy at gmail.com (G. Allegri) Date: Thu Mar 19 05:41:22 2009 Subject: [gdal-dev] Re: error with jpeglib while compiling 1.5.4 with MinGW In-Reply-To: References: Message-ID: I've solved using --with-jpeg=internal option. The problem seems to be the presence of jpeglib external libraries in the libs path. I've compiled jpeg by myself, so I woud expect that gdal could link it... but it fails, following the Warning on top of the output I've reported. Forcing the configure to internal exlude my jpeglib, but it's not the solution I would like! Any hint? 2009/3/19 G. Allegri : > Hi. > I'm trying to compile gdal 1.5.4 with msys+mingw 5.4.1. I have problems > linking the jpeglib, as internal. > My configure command is: > > ./configure --prefix=/usr/local --without-grass > --with-sqlite3=/usr/local/sqlite --with-pg=/usr/local/bin/pg_config.exe > --with-local=/usr/local > > (I have set --with-local to solve the problem for tiffio, while compilig it > couldn't be found...) > I receive the following error: > > > *** Warning: This system can not link to static lib archive > /usr/local/lib/libjpeg.la. > *** I have the capability to make that library automatically link in when > *** you link to this library.? But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** Warning: This system can not link to static lib archive > /usr/local/lib/libjpeg.la. > *** I have the capability to make that library automatically link in when > *** you link to this library.? But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > libtool: link: rm -fr? .libs/libgdal.dll.a .libs/libgdal.la.lnkscript > libtool: link: creating GNU ld script: .libs/libgdal.la.lnkscript > libtool: link: g++ -shared -nostdlib > C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../dllcrt2.o > C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/crtbegin.o > .libs/libgdal.la.lnkscript? -L/usr/local/sqlite/lib > /usr/local/sqlite/lib/libsqlite3.dll.a -L/usr/local/lib > /usr/local/lib/libexpat.dll.a /usr/local/lib/libtiff.dll.a -L/usr/local/bin > -LC:/msys/local/lib -lpq -lz -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5 > -LC:/msys/mingw/bin/../lib/gcc > -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib > -LC:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../.. -lstdc++ -lmingw32 > -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 > -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt > C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/crtend.o?????????? -o > .libs/libgdal-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib > -Xlinker .libs/libgdal.dll.a > ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD2Ev': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined > reference to `jpeg_abort_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined > reference to `jpeg_destroy_decompress' > ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD1Ev': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined > reference to `jpeg_abort_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined > reference to `jpeg_destroy_decompress' > ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDatasetD0Ev': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:936: undefined > reference to `jpeg_abort_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:937: undefined > reference to `jpeg_destroy_decompress' > ./frmts/o/.libs/jpgdataset.o: In function > `ZN10JPGDataset17LoadDefaultTablesEi': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1134: undefined > reference to `jpeg_alloc_quant_table' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1149: undefined > reference to `jpeg_alloc_huff_table' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1168: undefined > reference to `jpeg_alloc_huff_table' > ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset7RestartEv': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1196: undefined > reference to `jpeg_abort_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1197: undefined > reference to `jpeg_destroy_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1198: undefined > reference to `jpeg_CreateDecompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1211: undefined > reference to `jpeg_read_header' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1215: undefined > reference to `jpeg_start_decompress' > ./frmts/o/.libs/jpgdataset.o: In function `ZN10JPGDataset12LoadScanlineEi': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:964: undefined > reference to `jpeg_start_decompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1005: undefined > reference to `jpeg_read_scanlines' > ./frmts/o/.libs/jpgdataset.o: In function > `ZN10JPGDataset4OpenEP12GDALOpenInfo': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1448: undefined > reference to `jpeg_std_error' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1452: undefined > reference to `jpeg_CreateDecompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1485: undefined > reference to `jpeg_read_header' > ./frmts/o/.libs/jpgdataset.o: In function > `Z14JPEGCreateCopyPKcP11GDALDatasetiPPcPFidS0_PvES5_': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1953: undefined > reference to `jpeg_std_error' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1954: undefined > reference to `jpeg_CreateCompress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1971: undefined > reference to `jpeg_set_defaults' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1986: undefined > reference to `jpeg_set_quality' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1991: undefined > reference to `jpeg_start_compress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2022: undefined > reference to `jpeg_write_scanlines' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2041: undefined > reference to `jpeg_destroy_compress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:2040: undefined > reference to `jpeg_finish_compress' > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/jpgdataset.cpp:1989: undefined > reference to `jpeg_simple_progression' > ./frmts/o/.libs/nitfdataset.o: In function > `ZN11NITFDataset14NITFCreateCopyEPKcP11GDALDatasetiPPcPFidS1_PvES6_': > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3202: undefined > reference to `jpeg_std_error' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3203: undefined > reference to `jpeg_CreateCompress' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3221: undefined > reference to `jpeg_set_defaults' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3237: undefined > reference to Creating library file: .libs/libgdal.dll.a > `jpeg_set_quality' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3240: undefined > reference to `jpeg_simple_progression' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3242: undefined > reference to `jpeg_start_compress' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3291: undefined > reference to `jpeg_finish_compress' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3292: undefined > reference to `jpeg_destroy_compress' > C:/msys/local/src/gdal-1.5.4/frmts/nitf/nitfdataset.cpp:3273: undefined > reference to `jpeg_write_scanlines' > ./frmts/o/.libs/vsidataio.o: In function > `Z14jpeg_vsiio_srcP22jpeg_decompress_structP6_iobuf': > C:/msys/local/src/gdal-1.5.4/frmts/jpeg/vsidataio.cpp:224: undefined > reference to `jpeg_resync_to_restart' > collect2: ld returned 1 exit status > make[1]: *** [libgdal.la] Error 1 > make[1]: Leaving directory `/usr/local/src/gdal-1.5.4' > make: *** [check-lib] Error 2 > > > What's wrong? > giovanni > From frankie at debian.org Thu Mar 19 05:44:32 2009 From: frankie at debian.org (Francesco P. Lovergine) Date: Thu Mar 19 05:44:38 2009 Subject: [gdal-dev] [SOLVED] GDAL crashing on Ubuntu 8.10 In-Reply-To: <86782b610903181453n7eb6a0fct4d59ec1e4764148e@mail.gmail.com> References: <200903182248.47546.even.rouault@mines-paris.org> <86782b610903181453n7eb6a0fct4d59ec1e4764148e@mail.gmail.com> Message-ID: <20090319094432.GA1691@ba.issia.cnr.it> On Wed, Mar 18, 2009 at 10:53:59PM +0100, Markus Neteler wrote: > > Yes, the link between OSGeo projects and *some* distro trackers is to > be improved while other distros already started to better communicate (it > should be in *their* interest, too!). > Some distros communicates, some others not. In this specific case, Debian did not enable the same flags, so it has been unnoticed here. UbuntuGis efforts restarted very recently I would hope more hints would come on that side... -- Francesco P. Lovergine From woodbri at swoodbridge.com Thu Mar 19 13:14:38 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 12:13:09 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image Message-ID: <49C27D7E.60208@swoodbridge.com> Hi all, This is my annual wake-up got to do something with rasters and forgot the finer details of the last time I did a problem similar to it. I have a bunch of LandSat mrsid imagery, they are in multiple UTM zone projections and I want to convert them to geographic projection, WGS84, and into tiff files. The files are too large to convert into a single tif, so I plan to quarter each file into 4 pieces. So I wrote a script the reads the files and collects info about them, then generates 4 gdalwarp commands to reproject each quarter of the file (perl included below). A typical command looks like: gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:32642 -t_srs EPSG:4326 -te 68.9999676729652 24.9707453133203 72.7715338115736 27.4799559407707 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co "TILED=YES" ./GeoCover2000/n-42-25.sid ./af/n-42-25_1-0.tif The reprojection seems to have worked fine, but the bounds seem to be off because of the black (nodata) areas. You can see my poor results here: http://imaptools.com/downloads/raster.gif Is there a better way to do this? I seem to remember a tool to generate tiles. Does this need to be done in two steps? How? Did I mess up my logic below? I've been over it multiple times and do not see any errors. Any help would be appreciated. Thanks, -Steve $ gdalinfo -nomd ./GeoCover2000/n-42-25.sid Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) Files: ./GeoCover2000/n-42-25.sid Size is 51078, 39090 Coordinate System is `' Origin = (136066.125000000000000,3323577.375000000000000) Pixel Size = (14.250000000000000,-14.250000000000000) Corner Coordinates: Upper Left ( 136066.125, 3323577.375) Lower Left ( 136066.125, 2766544.875) Upper Right ( 863927.625, 3323577.375) Lower Right ( 863927.625, 2766544.875) Center ( 499996.875, 3045061.125) Band 1 Block=1024x128 Type=Byte, ColorInterp=Red Minimum=0.000, Maximum=226.000, Mean=109.610, StdDev=39.202 Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, 799x611, 400x306, 200x153 Band 2 Block=1024x128 Type=Byte, ColorInterp=Green Minimum=0.000, Maximum=229.000, Mean=125.833, StdDev=31.828 Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, 799x611, 400x306, 200x153 Band 3 Block=1024x128 Type=Byte, ColorInterp=Blue Minimum=0.000, Maximum=227.000, Mean=107.092, StdDev=37.230 Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, 799x611, 400x306, 200x153 $ cat ./GeoCover2000/n-42-25.prj Projection UTM Datum WGS84 Zunits NO Units METERS Zone 42 Xshift 0.000000 Yshift 0.000000 Parameters Perl snippet: foreach my $sid (@files) { next unless $wanted && $sid =~ /$wanted/i; if (! -r $sid) { warn "SKIPPING: $sid is not readable!\n"; next; } my $gdalinfo = `gdalinfo -nomd $sid`; # parse out the strings that we need $gdalinfo =~ /Upper Left \((\s*[^,]+),\s*([^\)]+)/s || warn "Upper Left parse error\n"; my $ul = [$1, $2]; $gdalinfo =~ /Lower Left \((\s*[^,]+),\s*([^\)]+)/s || warn "Lower Left parse error\n"; my $ll = [$1, $2]; $gdalinfo =~ /Upper Right \((\s*[^,]+),\s*([^\)]+)/s || warn "Upper Right error\n"; my $ur = [$1, $2]; $gdalinfo =~ /Lower Right \((\s*[^,]+),\s*([^\)]+)/s || warn "Lower Right error\n"; my $lr = [$1, $2]; my $outf = $sid; $outf =~ s/\.sid//; $outf =~ m/\/([^\/]+)$/; $outf = $1; my $prj = $sid; $prj =~ s/\.sid/.prj/; if (! -r $prj) { warn "SKIPPING: $prj is not readable!\n"; next; } my $projinfo = `grep Zone $prj`; if ($projinfo =~ /^Zone\s*([-+]?\d+)/) { my $znum = $1; if ($znum < 0) { $epsg = 32700 - $znum; } else { $epsg = 32600 + $znum; } } else { warn "SKIPPING: could not find zone or epsg in $prj\n"; next; } my $proj = sprintf("+init=epsg:%d", $epsg); print "Using projection: $proj for $projinfo" if $DEBUG; my $pj = Geo::Proj4->new($proj); if (! $pj) { warn "SKIPPING: Geo::Proj4 error: " . Geo::Proj4->error . "\n"; next; } $ul = [reverse $pj->inverse(@$ul)]; $ll = [reverse $pj->inverse(@$ll)]; $ur = [reverse $pj->inverse(@$ur)]; $lr = [reverse $pj->inverse(@$lr)]; # this is probably a parallelgram in latlong if ($DEBUG) { printf("ul = %11.6f, %11.6f\n", @$ul); printf("ll = %11.6f, %11.6f\n", @$ll); printf("ur = %11.6f, %11.6f\n", @$ur); printf("lr = %11.6f, %11.6f\n", @$lr); } # Get the bbox of the parallelgram my $xmin = $ul->[0]<$ll->[0]?$ul->[0]:$ll->[0]; my $xmax = $ur->[0]>$lr->[0]?$ur->[0]:$lr->[0]; my $ymin = $ll->[1]<$lr->[1]?$ll->[1]:$lr->[1]; my $ymax = $ul->[1]>$ur->[1]?$ul->[1]:$ur->[1]; my $tiled = '-co "TILED=YES"'; $tiled = '' if -e $outf; my $nparts = 2; my $dx = ($xmax - $xmin) / $nparts; my $dy = ($ymax - $ymin) / $nparts; my ($x0, $x1, $y0, $y1); for (my $i=0, $x0=$xmin; $i<$nparts; $i++, $x0 += $dx) { $x1 = $x0 + $dx; for (my $j=0, $y0=$ymin; $j<$nparts; $j++, $y0 += $dy) { $y1 = $y0 + $dy; my $tif = sprintf("%s/%s/%s_%d-%d.tif", $work, $outd, $outf, $i, $j); my $cmd = sprintf("gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:%d -t_srs EPSG:4326 -te $x0 $y0 $x1 $y1 -rb -wm 250 --config GDAL_ONE_BIG_READ ON $tiled $sid $tif\n", $epsg); print "$cmd\n"; my $rc = system($cmd); print "SYSTEM returned: " . sprintf("%lx\n", ($rc & 0xffff)) if $DEBUG } } } From chaitanya.ch at gmail.com Thu Mar 19 12:47:50 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Thu Mar 19 12:47:55 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image In-Reply-To: <49C27D7E.60208@swoodbridge.com> References: <49C27D7E.60208@swoodbridge.com> Message-ID: Steve, The -te option mentions the extents of the output file, not the input file. As of now there is no option in gdalwrap to specify the input file extents. Regards, -- Chaitanya kumar CH. On Thu, Mar 19, 2009 at 10:44 PM, Stephen Woodbridge wrote: > Hi all, > > This is my annual wake-up got to do something with rasters and forgot the > finer details of the last time I did a problem similar to it. > > I have a bunch of LandSat mrsid imagery, they are in multiple UTM zone > projections and I want to convert them to geographic projection, WGS84, and > into tiff files. The files are too large to convert into a single tif, so I > plan to quarter each file into 4 pieces. > > So I wrote a script the reads the files and collects info about them, then > generates 4 gdalwarp commands to reproject each quarter of the file (perl > included below). A typical command looks like: > > gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:32642 -t_srs EPSG:4326 > -te 68.9999676729652 24.9707453133203 72.7715338115736 27.4799559407707 -rb > -wm 250 --config GDAL_ONE_BIG_READ ON -co "TILED=YES" > ./GeoCover2000/n-42-25.sid ./af/n-42-25_1-0.tif > > > The reprojection seems to have worked fine, but the bounds seem to be off > because of the black (nodata) areas. > > You can see my poor results here: > http://imaptools.com/downloads/raster.gif > > Is there a better way to do this? I seem to remember a tool to generate > tiles. > Does this need to be done in two steps? How? > Did I mess up my logic below? I've been over it multiple times and do not > see any errors. > > Any help would be appreciated. > > Thanks, > ?-Steve > > $ gdalinfo -nomd ./GeoCover2000/n-42-25.sid > Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) > Files: ./GeoCover2000/n-42-25.sid > Size is 51078, 39090 > Coordinate System is `' > Origin = (136066.125000000000000,3323577.375000000000000) > Pixel Size = (14.250000000000000,-14.250000000000000) > Corner Coordinates: > Upper Left ?( ?136066.125, 3323577.375) > Lower Left ?( ?136066.125, 2766544.875) > Upper Right ( ?863927.625, 3323577.375) > Lower Right ( ?863927.625, 2766544.875) > Center ? ? ?( ?499996.875, 3045061.125) > Band 1 Block=1024x128 Type=Byte, ColorInterp=Red > ?Minimum=0.000, Maximum=226.000, Mean=109.610, StdDev=39.202 > ?Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 2 Block=1024x128 Type=Byte, ColorInterp=Green > ?Minimum=0.000, Maximum=229.000, Mean=125.833, StdDev=31.828 > ?Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 3 Block=1024x128 Type=Byte, ColorInterp=Blue > ?Minimum=0.000, Maximum=227.000, Mean=107.092, StdDev=37.230 > ?Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > > > $ cat ./GeoCover2000/n-42-25.prj > Projection ? ? UTM > Datum ? ? ? ? ?WGS84 > Zunits ? ? ? ? NO > Units ? ? ? ? ?METERS > Zone ? ? ? ? ? 42 > Xshift ? ? ? ? 0.000000 > Yshift ? ? ? ? 0.000000 > Parameters > > > > Perl snippet: > > ? ?foreach my $sid (@files) { > > ? ? ? ?next unless $wanted && $sid =~ /$wanted/i; > > ? ? ? ?if (! -r $sid) { > ? ? ? ? ? ?warn "SKIPPING: $sid is not readable!\n"; > ? ? ? ? ? ?next; > ? ? ? ?} > > ? ? ? ?my $gdalinfo = `gdalinfo -nomd $sid`; > > ? ? ? ?# parse out the strings that we need > > ? ? ? ?$gdalinfo =~ /Upper Left ?\((\s*[^,]+),\s*([^\)]+)/s || warn "Upper > Left parse error\n"; > ? ? ? ?my $ul = [$1, $2]; > ? ? ? ?$gdalinfo =~ /Lower Left ?\((\s*[^,]+),\s*([^\)]+)/s || warn "Lower > Left parse error\n"; > ? ? ? ?my $ll = [$1, $2]; > ? ? ? ?$gdalinfo =~ /Upper Right \((\s*[^,]+),\s*([^\)]+)/s || warn "Upper > Right error\n"; > ? ? ? ?my $ur = [$1, $2]; > ? ? ? ?$gdalinfo =~ /Lower Right \((\s*[^,]+),\s*([^\)]+)/s || warn "Lower > Right error\n"; > ? ? ? ?my $lr = [$1, $2]; > > ? ? ? ?my $outf = $sid; > ? ? ? ?$outf =~ s/\.sid//; > ? ? ? ?$outf =~ m/\/([^\/]+)$/; > ? ? ? ?$outf = $1; > > ? ? ? ?my $prj = $sid; > ? ? ? ?$prj =~ s/\.sid/.prj/; > ? ? ? ?if (! -r $prj) { > ? ? ? ? ? ?warn "SKIPPING: $prj is not readable!\n"; > ? ? ? ? ? ?next; > ? ? ? ?} > ? ? ? ?my $projinfo = `grep Zone $prj`; > ? ? ? ?if ($projinfo =~ /^Zone\s*([-+]?\d+)/) { > ? ? ? ? ? ?my $znum = $1; > ? ? ? ? ? ?if ($znum < 0) { > ? ? ? ? ? ? ? ?$epsg = 32700 - $znum; > ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ?$epsg = 32600 + $znum; > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ?else { > ? ? ? ? ? ?warn "SKIPPING: ?could not find zone or epsg in $prj\n"; > ? ? ? ? ? ?next; > ? ? ? ?} > > ? ? ? ?my $proj = sprintf("+init=epsg:%d", $epsg); > ? ? ? ?print "Using projection: $proj for $projinfo" if $DEBUG; > > ? ? ? ?my $pj = Geo::Proj4->new($proj); > ? ? ? ?if (! $pj) { > ? ? ? ? ? ?warn "SKIPPING: Geo::Proj4 error: " . Geo::Proj4->error . "\n"; > ? ? ? ? ? ?next; > ? ? ? ?} > > ? ? ? ?$ul = [reverse $pj->inverse(@$ul)]; > ? ? ? ?$ll = [reverse $pj->inverse(@$ll)]; > ? ? ? ?$ur = [reverse $pj->inverse(@$ur)]; > ? ? ? ?$lr = [reverse $pj->inverse(@$lr)]; > > ? ? ? ?# this is probably a parallelgram in latlong > ? ? ? ?if ($DEBUG) { > ? ? ? ? ? ?printf("ul = %11.6f, %11.6f\n", @$ul); > ? ? ? ? ? ?printf("ll = %11.6f, %11.6f\n", @$ll); > ? ? ? ? ? ?printf("ur = %11.6f, %11.6f\n", @$ur); > ? ? ? ? ? ?printf("lr = %11.6f, %11.6f\n", @$lr); > ? ? ? ?} > > ? ? ? ?# Get the bbox of the parallelgram > ? ? ? ?my $xmin = $ul->[0]<$ll->[0]?$ul->[0]:$ll->[0]; > ? ? ? ?my $xmax = $ur->[0]>$lr->[0]?$ur->[0]:$lr->[0]; > ? ? ? ?my $ymin = $ll->[1]<$lr->[1]?$ll->[1]:$lr->[1]; > ? ? ? ?my $ymax = $ul->[1]>$ur->[1]?$ul->[1]:$ur->[1]; > > ? ? ? ?my $tiled = '-co "TILED=YES"'; > ? ? ? ?$tiled = '' if -e $outf; > > ? ? ? ?my $nparts = 2; > ? ? ? ?my $dx = ($xmax - $xmin) / $nparts; > ? ? ? ?my $dy = ($ymax - $ymin) / $nparts; > ? ? ? ?my ($x0, $x1, $y0, $y1); > ? ? ? ?for (my $i=0, $x0=$xmin; $i<$nparts; $i++, $x0 += $dx) { > ? ? ? ? ? ?$x1 = $x0 + $dx; > ? ? ? ? ? ?for (my $j=0, $y0=$ymin; $j<$nparts; $j++, $y0 += $dy) { > ? ? ? ? ? ? ? ?$y1 = $y0 + $dy; > ? ? ? ? ? ? ? ?my $tif = sprintf("%s/%s/%s_%d-%d.tif", $work, $outd, $outf, > $i, $j); > ? ? ? ? ? ? ? ?my $cmd = sprintf("gdalwarp -srcnodata 0 -dstnodata 0 -s_srs > +init=epsg:%d -t_srs EPSG:4326 -te $x0 $y0 $x1 $y1 -rb -wm 250 --config > GDAL_ONE_BIG_READ ON $tiled $sid $tif\n", $epsg); > > ? ? ? ? ? ? ? ?print "$cmd\n"; > ? ? ? ? ? ? ? ?my $rc = system($cmd); > ? ? ? ? ? ? ? ?print "SYSTEM returned: " . sprintf("%lx\n", ($rc & 0xffff)) > ? ? ? ? ? ? ? ? ? ?if $DEBUG > ? ? ? ? ? ?} > ? ? ? ?} > ? ?} > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From fhillen at uni-osnabrueck.de Thu Mar 19 13:25:23 2009 From: fhillen at uni-osnabrueck.de (Florian Hillen) Date: Thu Mar 19 13:25:26 2009 Subject: [gdal-dev] GDALGetProjectionRef delivers wrong CS Message-ID: <2457.79.205.34.215.1237483523.squirrel@webmail.rz.uni-osnabrueck.de> Hi, I use GDALGetProjectionRef as it is shown in the GDAL Warp API Tutorial, but it delivers a wrong CS. gdalinfo delivers the following: Coordinate System is: PROJCS["DHDN / Gauss-Kruger zone 3", GEOGCS["DHDN", DATUM["Deutsches_Hauptdreiecksnetz", SPHEROID["Bessel 1841",6377397.155,299.1528128000009, ... GDALGetProjectionRef delivers this: PROJCS["unnamed",GEOGCS["DHDN",DATUM["unknown",SPHEROID["unretrievable - using WGS84",6378137,298.257223563]] ,PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]] ,UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","31467"]] I think that this is the reason why the warp doesn't work. Can anyone of you help me with that? Best regards, Florian From bfraser at geoanalytic.com Thu Mar 19 14:43:53 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Thu Mar 19 14:44:23 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image In-Reply-To: <49C27D7E.60208@swoodbridge.com> References: <49C27D7E.60208@swoodbridge.com> Message-ID: <49C29269.2080208@geoanalytic.com> Steve, My general strategy when doing this (on terabytes of raster data) is: 1. Create a tileindex of input data. Since you've got multiple zones of raster data, you'll need to create one tileindex for each zone (using gdaltindex), de-project them to geographic, and concatenate them (use ogr2ogr or PostGIS). 2. Create a geographic tileindex of output files (via your own script) The size, extents, and amount of overlap are up to you. It doesn't have to be a tileindex; it could be just a list of extents for use in steps 3 and 5 below. 3. Do a spatial select for each output tile on the input tileindex to create a "mini" tileindex for each output tile. I use a hacked version of shputils to do this, but I expect PostGIS or ogr2ogr + SQL would be a better way to go. 4. Convert all the mini tileindexes to vrt files (see the new gdalbuildvrt app!) 5 Use gdal_translate with the extents from step 2 to extract the output tile pixels from its corresponding vrt. Convoluted yes, but very "scalable". And no Null pixels in the output tiles. Brent Fraser GeoAnalytic Inc. Stephen Woodbridge wrote: > Hi all, > > This is my annual wake-up got to do something with rasters and forgot > the finer details of the last time I did a problem similar to it. > > I have a bunch of LandSat mrsid imagery, they are in multiple UTM zone > projections and I want to convert them to geographic projection, WGS84, > and into tiff files. The files are too large to convert into a single > tif, so I plan to quarter each file into 4 pieces. > > So I wrote a script the reads the files and collects info about them, > then generates 4 gdalwarp commands to reproject each quarter of the file > (perl included below). A typical command looks like: > > gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:32642 -t_srs > EPSG:4326 -te 68.9999676729652 24.9707453133203 72.7715338115736 > 27.4799559407707 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co > "TILED=YES" ./GeoCover2000/n-42-25.sid ./af/n-42-25_1-0.tif > > > The reprojection seems to have worked fine, but the bounds seem to be > off because of the black (nodata) areas. > > You can see my poor results here: > http://imaptools.com/downloads/raster.gif > > Is there a better way to do this? I seem to remember a tool to generate > tiles. > Does this need to be done in two steps? How? > Did I mess up my logic below? I've been over it multiple times and do > not see any errors. > > Any help would be appreciated. > > Thanks, > -Steve > > $ gdalinfo -nomd ./GeoCover2000/n-42-25.sid > Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) > Files: ./GeoCover2000/n-42-25.sid > Size is 51078, 39090 > Coordinate System is `' > Origin = (136066.125000000000000,3323577.375000000000000) > Pixel Size = (14.250000000000000,-14.250000000000000) > Corner Coordinates: > Upper Left ( 136066.125, 3323577.375) > Lower Left ( 136066.125, 2766544.875) > Upper Right ( 863927.625, 3323577.375) > Lower Right ( 863927.625, 2766544.875) > Center ( 499996.875, 3045061.125) > Band 1 Block=1024x128 Type=Byte, ColorInterp=Red > Minimum=0.000, Maximum=226.000, Mean=109.610, StdDev=39.202 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 2 Block=1024x128 Type=Byte, ColorInterp=Green > Minimum=0.000, Maximum=229.000, Mean=125.833, StdDev=31.828 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 3 Block=1024x128 Type=Byte, ColorInterp=Blue > Minimum=0.000, Maximum=227.000, Mean=107.092, StdDev=37.230 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > > > $ cat ./GeoCover2000/n-42-25.prj > Projection UTM > Datum WGS84 > Zunits NO > Units METERS > Zone 42 > Xshift 0.000000 > Yshift 0.000000 > Parameters > > > > Perl snippet: > > foreach my $sid (@files) { > > next unless $wanted && $sid =~ /$wanted/i; > > if (! -r $sid) { > warn "SKIPPING: $sid is not readable!\n"; > next; > } > > my $gdalinfo = `gdalinfo -nomd $sid`; > > # parse out the strings that we need > > $gdalinfo =~ /Upper Left \((\s*[^,]+),\s*([^\)]+)/s || warn > "Upper Left parse error\n"; > my $ul = [$1, $2]; > $gdalinfo =~ /Lower Left \((\s*[^,]+),\s*([^\)]+)/s || warn > "Lower Left parse error\n"; > my $ll = [$1, $2]; > $gdalinfo =~ /Upper Right \((\s*[^,]+),\s*([^\)]+)/s || warn > "Upper Right error\n"; > my $ur = [$1, $2]; > $gdalinfo =~ /Lower Right \((\s*[^,]+),\s*([^\)]+)/s || warn > "Lower Right error\n"; > my $lr = [$1, $2]; > > my $outf = $sid; > $outf =~ s/\.sid//; > $outf =~ m/\/([^\/]+)$/; > $outf = $1; > > my $prj = $sid; > $prj =~ s/\.sid/.prj/; > if (! -r $prj) { > warn "SKIPPING: $prj is not readable!\n"; > next; > } > my $projinfo = `grep Zone $prj`; > if ($projinfo =~ /^Zone\s*([-+]?\d+)/) { > my $znum = $1; > if ($znum < 0) { > $epsg = 32700 - $znum; > } else { > $epsg = 32600 + $znum; > } > } > else { > warn "SKIPPING: could not find zone or epsg in $prj\n"; > next; > } > > my $proj = sprintf("+init=epsg:%d", $epsg); > print "Using projection: $proj for $projinfo" if $DEBUG; > > my $pj = Geo::Proj4->new($proj); > if (! $pj) { > warn "SKIPPING: Geo::Proj4 error: " . Geo::Proj4->error . "\n"; > next; > } > > $ul = [reverse $pj->inverse(@$ul)]; > $ll = [reverse $pj->inverse(@$ll)]; > $ur = [reverse $pj->inverse(@$ur)]; > $lr = [reverse $pj->inverse(@$lr)]; > > # this is probably a parallelgram in latlong > if ($DEBUG) { > printf("ul = %11.6f, %11.6f\n", @$ul); > printf("ll = %11.6f, %11.6f\n", @$ll); > printf("ur = %11.6f, %11.6f\n", @$ur); > printf("lr = %11.6f, %11.6f\n", @$lr); > } > > # Get the bbox of the parallelgram > my $xmin = $ul->[0]<$ll->[0]?$ul->[0]:$ll->[0]; > my $xmax = $ur->[0]>$lr->[0]?$ur->[0]:$lr->[0]; > my $ymin = $ll->[1]<$lr->[1]?$ll->[1]:$lr->[1]; > my $ymax = $ul->[1]>$ur->[1]?$ul->[1]:$ur->[1]; > > my $tiled = '-co "TILED=YES"'; > $tiled = '' if -e $outf; > > my $nparts = 2; > my $dx = ($xmax - $xmin) / $nparts; > my $dy = ($ymax - $ymin) / $nparts; > my ($x0, $x1, $y0, $y1); > for (my $i=0, $x0=$xmin; $i<$nparts; $i++, $x0 += $dx) { > $x1 = $x0 + $dx; > for (my $j=0, $y0=$ymin; $j<$nparts; $j++, $y0 += $dy) { > $y1 = $y0 + $dy; > my $tif = sprintf("%s/%s/%s_%d-%d.tif", $work, $outd, > $outf, $i, $j); > my $cmd = sprintf("gdalwarp -srcnodata 0 -dstnodata 0 > -s_srs +init=epsg:%d -t_srs EPSG:4326 -te $x0 $y0 $x1 $y1 -rb -wm 250 > --config GDAL_ONE_BIG_READ ON $tiled $sid $tif\n", $epsg); > > print "$cmd\n"; > my $rc = system($cmd); > print "SYSTEM returned: " . sprintf("%lx\n", ($rc & > 0xffff)) > if $DEBUG > } > } > } > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From woodbri at swoodbridge.com Thu Mar 19 16:19:06 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 15:17:36 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image In-Reply-To: <49C27D7E.60208@swoodbridge.com> References: <49C27D7E.60208@swoodbridge.com> Message-ID: <49C2A8BA.40004@swoodbridge.com> OK, to respond to my own post, I forgot to add OFFSITE to my mapfile layer definition. So I think all is good now. -Steve Stephen Woodbridge wrote: > Hi all, > > This is my annual wake-up got to do something with rasters and forgot > the finer details of the last time I did a problem similar to it. > > I have a bunch of LandSat mrsid imagery, they are in multiple UTM zone > projections and I want to convert them to geographic projection, WGS84, > and into tiff files. The files are too large to convert into a single > tif, so I plan to quarter each file into 4 pieces. > > So I wrote a script the reads the files and collects info about them, > then generates 4 gdalwarp commands to reproject each quarter of the file > (perl included below). A typical command looks like: > > gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:32642 -t_srs > EPSG:4326 -te 68.9999676729652 24.9707453133203 72.7715338115736 > 27.4799559407707 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co > "TILED=YES" ./GeoCover2000/n-42-25.sid ./af/n-42-25_1-0.tif > > > The reprojection seems to have worked fine, but the bounds seem to be > off because of the black (nodata) areas. > > You can see my poor results here: > http://imaptools.com/downloads/raster.gif > > Is there a better way to do this? I seem to remember a tool to generate > tiles. > Does this need to be done in two steps? How? > Did I mess up my logic below? I've been over it multiple times and do > not see any errors. > > Any help would be appreciated. > > Thanks, > -Steve > > $ gdalinfo -nomd ./GeoCover2000/n-42-25.sid > Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) > Files: ./GeoCover2000/n-42-25.sid > Size is 51078, 39090 > Coordinate System is `' > Origin = (136066.125000000000000,3323577.375000000000000) > Pixel Size = (14.250000000000000,-14.250000000000000) > Corner Coordinates: > Upper Left ( 136066.125, 3323577.375) > Lower Left ( 136066.125, 2766544.875) > Upper Right ( 863927.625, 3323577.375) > Lower Right ( 863927.625, 2766544.875) > Center ( 499996.875, 3045061.125) > Band 1 Block=1024x128 Type=Byte, ColorInterp=Red > Minimum=0.000, Maximum=226.000, Mean=109.610, StdDev=39.202 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 2 Block=1024x128 Type=Byte, ColorInterp=Green > Minimum=0.000, Maximum=229.000, Mean=125.833, StdDev=31.828 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > Band 3 Block=1024x128 Type=Byte, ColorInterp=Blue > Minimum=0.000, Maximum=227.000, Mean=107.092, StdDev=37.230 > Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, > 799x611, 400x306, 200x153 > > > $ cat ./GeoCover2000/n-42-25.prj > Projection UTM > Datum WGS84 > Zunits NO > Units METERS > Zone 42 > Xshift 0.000000 > Yshift 0.000000 > Parameters > > > > Perl snippet: > > foreach my $sid (@files) { > > next unless $wanted && $sid =~ /$wanted/i; > > if (! -r $sid) { > warn "SKIPPING: $sid is not readable!\n"; > next; > } > > my $gdalinfo = `gdalinfo -nomd $sid`; > > # parse out the strings that we need > > $gdalinfo =~ /Upper Left \((\s*[^,]+),\s*([^\)]+)/s || warn > "Upper Left parse error\n"; > my $ul = [$1, $2]; > $gdalinfo =~ /Lower Left \((\s*[^,]+),\s*([^\)]+)/s || warn > "Lower Left parse error\n"; > my $ll = [$1, $2]; > $gdalinfo =~ /Upper Right \((\s*[^,]+),\s*([^\)]+)/s || warn > "Upper Right error\n"; > my $ur = [$1, $2]; > $gdalinfo =~ /Lower Right \((\s*[^,]+),\s*([^\)]+)/s || warn > "Lower Right error\n"; > my $lr = [$1, $2]; > > my $outf = $sid; > $outf =~ s/\.sid//; > $outf =~ m/\/([^\/]+)$/; > $outf = $1; > > my $prj = $sid; > $prj =~ s/\.sid/.prj/; > if (! -r $prj) { > warn "SKIPPING: $prj is not readable!\n"; > next; > } > my $projinfo = `grep Zone $prj`; > if ($projinfo =~ /^Zone\s*([-+]?\d+)/) { > my $znum = $1; > if ($znum < 0) { > $epsg = 32700 - $znum; > } else { > $epsg = 32600 + $znum; > } > } > else { > warn "SKIPPING: could not find zone or epsg in $prj\n"; > next; > } > > my $proj = sprintf("+init=epsg:%d", $epsg); > print "Using projection: $proj for $projinfo" if $DEBUG; > > my $pj = Geo::Proj4->new($proj); > if (! $pj) { > warn "SKIPPING: Geo::Proj4 error: " . Geo::Proj4->error . "\n"; > next; > } > > $ul = [reverse $pj->inverse(@$ul)]; > $ll = [reverse $pj->inverse(@$ll)]; > $ur = [reverse $pj->inverse(@$ur)]; > $lr = [reverse $pj->inverse(@$lr)]; > > # this is probably a parallelgram in latlong > if ($DEBUG) { > printf("ul = %11.6f, %11.6f\n", @$ul); > printf("ll = %11.6f, %11.6f\n", @$ll); > printf("ur = %11.6f, %11.6f\n", @$ur); > printf("lr = %11.6f, %11.6f\n", @$lr); > } > > # Get the bbox of the parallelgram > my $xmin = $ul->[0]<$ll->[0]?$ul->[0]:$ll->[0]; > my $xmax = $ur->[0]>$lr->[0]?$ur->[0]:$lr->[0]; > my $ymin = $ll->[1]<$lr->[1]?$ll->[1]:$lr->[1]; > my $ymax = $ul->[1]>$ur->[1]?$ul->[1]:$ur->[1]; > > my $tiled = '-co "TILED=YES"'; > $tiled = '' if -e $outf; > > my $nparts = 2; > my $dx = ($xmax - $xmin) / $nparts; > my $dy = ($ymax - $ymin) / $nparts; > my ($x0, $x1, $y0, $y1); > for (my $i=0, $x0=$xmin; $i<$nparts; $i++, $x0 += $dx) { > $x1 = $x0 + $dx; > for (my $j=0, $y0=$ymin; $j<$nparts; $j++, $y0 += $dy) { > $y1 = $y0 + $dy; > my $tif = sprintf("%s/%s/%s_%d-%d.tif", $work, $outd, > $outf, $i, $j); > my $cmd = sprintf("gdalwarp -srcnodata 0 -dstnodata 0 > -s_srs +init=epsg:%d -t_srs EPSG:4326 -te $x0 $y0 $x1 $y1 -rb -wm 250 > --config GDAL_ONE_BIG_READ ON $tiled $sid $tif\n", $epsg); > > print "$cmd\n"; > my $rc = system($cmd); > print "SYSTEM returned: " . sprintf("%lx\n", ($rc & > 0xffff)) > if $DEBUG > } > } > } > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From randre at gmail.com Thu Mar 19 15:26:54 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Thu Mar 19 15:26:56 2009 Subject: [gdal-dev] gdaltindex and netCDF files Message-ID: <9c2015090903191226h7f55dc02x22f68d439ac04d70@mail.gmail.com> Hi All, Is it possible to use gdaltindex to create a shapefile index of a group of netCDF files? Specifivally, I need to index a specific netCDF variable that exists in all of the files. I just tried running it on a single file, using the variable selection syntax that seems to work with the other gdal utilities, but can't seem to make it work. gdaltindex netcdf_index.shp ./NETCDF:"N35E115_5x5_19970101000000_20070102230000.ttnc":elev ERROR 4: `./NETCDF:N35E115_5x5_19970101000000_20070102230000.ttnc:elev' does not exist in the file system, and is not recognised as a supported dataset name. Unable to open ./NETCDF:N35E115_5x5_19970101000000_20070102230000.ttnc:elev, skipping. Thanks, Roger From mohwawang at yahoo.com Thu Mar 19 16:15:12 2009 From: mohwawang at yahoo.com (mohwawang@yahoo.com) Date: Thu Mar 19 16:21:55 2009 Subject: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW Message-ID: <77255.38559.qm@web32608.mail.mud.yahoo.com> Hi all, I have successfully used the Reproject of openEV_FW (FWTools 2.2.8) to reproject an AST_L1B geo jpg file (ast_geo.jpg with an ast_geo.jpgw file) to a NITF file. I wonder if there is any gdal-1.6\apps executable that is equivalent to Reproject of Tools of openEV_FW? I tried gdal_translate.exe but failed as: > gdal_translate -of nitf ast_geo.jpg new.ntf Input flle size is 5896, 4714 0...10...20...30...40...50...60...70...80...90...100 - done ERROR 6: Apparently no space reserved for IGEOLO info in NITF file. NITFWriteIGEOGLO() fails. I guess the key is to use the info in the jpgw file as parameters in the equivalent executable if exists. What? How? Below are the info of the jpg file and the content of the jpgw file. > gdalinfo ast_geo.jpg Driver: JPEG/JPEG JFIF Files: ast_geo.jpg Size is 5896, 4714 Coordinate System is `' Origin = (-113.281421452980040,33.477365682899951) Pixel Size = (0.000153055144450,-0.000142760639120) Image Structure Metadata: ? SOURCE_COLOR_SPACE=YCbCr ? INTERLEAVE=PIXEL ? COMPRESSION=JPEG Corner Coordinates: Upper Left? (-113.2814215,? 33.4773657) Lower Left? (-113.2814215,? 32.8043920) Upper Right (-112.3790083,? 33.4773657) Lower Right (-112.3790083,? 32.8043920) Center? ? ? (-112.8302149,? 33.1408789) Band 1 Block=5896x1 Type=Byte, ColorInterp=Red ? Image Structure Metadata: ? ? COMPRESSION=JPEG Band 2 Block=5896x1 Type=Byte, ColorInterp=Green ? Image Structure Metadata: ? ? COMPRESSION=JPEG Band 3 Block=5896x1 Type=Byte, ColorInterp=Blue ? Image Structure Metadata: ? ? COMPRESSION=JPEG > type ast_geo.jpgw ? ? ? ? ? ? ? ? ???0.00015305514445 ? ? ? ? ? ? ? ? ???0.00000000000000 ? ? ? ? ? ? ? ? ???0.00000000000000 ? ? ? ? ? ? ? ? ? -0.00014276063912 ? ? ? ? ? ? ? ? -113.28134492540782 ? ? ? ? ? ? ? ? ? 33.47729430258039 Tiff File AST_L1B_00309192003182059_10032003135534_VNIR_geo.tif/n Image width = 5896 height = 4714 bands = 3/n Image_UL = 33.465445 -113.085740 Image_UR = 33.371366 -112.428675/n Image_LL = 32.910820 -113.234051 Image_LR = 32.817455 -112.581118/n Image_UL_Loc =? ???1278? ? ???83 Image_UR_Loc =? ???5571? ? ? 742 Image_LL_Loc =? ? ? 309? ???3968 Image_LR_Loc =? ???4575? ???4622 Thanks. Best Regards, Mo Wang From even.rouault at mines-paris.org Thu Mar 19 16:27:39 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 19 16:27:52 2009 Subject: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW In-Reply-To: <77255.38559.qm@web32608.mail.mud.yahoo.com> References: <77255.38559.qm@web32608.mail.mud.yahoo.com> Message-ID: <200903192127.40691.even.rouault@mines-paris.org> Mo, here's the documentation of the NITF driver : http://gdal.org/frmt_nitf.html You probably need to define the ICORDS=G creation option : gdal_translate -of NITF ast_geo.jpg new.ntf -co ICORDS=G Best regards, Even Le Thursday 19 March 2009 21:15:12 mohwawang@yahoo.com, vous avez ?crit?: > Hi all, > > I have successfully used the Reproject of openEV_FW (FWTools 2.2.8) to reproject an AST_L1B geo jpg file (ast_geo.jpg with an ast_geo.jpgw file) to a NITF file. I wonder if there is any gdal-1.6\apps executable that is equivalent to Reproject of Tools of openEV_FW? I tried gdal_translate.exe but failed as: > > gdal_translate -of nitf ast_geo.jpg new.ntf > > Input flle size is 5896, 4714 > 0...10...20...30...40...50...60...70...80...90...100 - done > ERROR 6: Apparently no space reserved for IGEOLO info in NITF file. > NITFWriteIGEOGLO() fails. > > I guess the key is to use the info in the jpgw file as parameters in the > equivalent executable if exists. What? How? Below are the info of the jpg > file and the content of the jpgw file. > > > gdalinfo ast_geo.jpg > > Driver: JPEG/JPEG JFIF > Files: ast_geo.jpg > Size is 5896, 4714 > Coordinate System is `' > Origin = (-113.281421452980040,33.477365682899951) > Pixel Size = (0.000153055144450,-0.000142760639120) > Image Structure Metadata: > ? SOURCE_COLOR_SPACE=YCbCr > ? INTERLEAVE=PIXEL > ? COMPRESSION=JPEG > Corner Coordinates: > Upper Left? (-113.2814215,? 33.4773657) > Lower Left? (-113.2814215,? 32.8043920) > Upper Right (-112.3790083,? 33.4773657) > Lower Right (-112.3790083,? 32.8043920) > Center? ? ? (-112.8302149,? 33.1408789) > Band 1 Block=5896x1 Type=Byte, ColorInterp=Red > ? Image Structure Metadata: > ? ? COMPRESSION=JPEG > Band 2 Block=5896x1 Type=Byte, ColorInterp=Green > ? Image Structure Metadata: > ? ? COMPRESSION=JPEG > Band 3 Block=5896x1 Type=Byte, ColorInterp=Blue > ? Image Structure Metadata: > ? ? COMPRESSION=JPEG > > > type ast_geo.jpgw > > ? ? ? ? ? ? ? ? ???0.00015305514445 > ? ? ? ? ? ? ? ? ???0.00000000000000 > ? ? ? ? ? ? ? ? ???0.00000000000000 > ? ? ? ? ? ? ? ? ? -0.00014276063912 > ? ? ? ? ? ? ? ? -113.28134492540782 > ? ? ? ? ? ? ? ? ? 33.47729430258039 > Tiff File AST_L1B_00309192003182059_10032003135534_VNIR_geo.tif/n Image > width = 5896 height = 4714 bands = 3/n Image_UL = 33.465445 -113.085740 > Image_UR = 33.371366 -112.428675/n Image_LL = 32.910820 -113.234051 > Image_LR = 32.817455 -112.581118/n Image_UL_Loc =? ???1278? ? ???83 > Image_UR_Loc =? ???5571? ? ? 742 Image_LL_Loc =? ? ? 309? ???3968 > Image_LR_Loc =? ???4575? ???4622 > > Thanks. > > Best Regards, > > Mo Wang > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From woodbri at swoodbridge.com Thu Mar 19 17:41:53 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 16:40:21 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo Message-ID: <49C2BC21.8030901@swoodbridge.com> Hi, I just created a bunch of tif files from a mrsid file and when I use gdaladdo file.tif 2 4 8 16 32 64 128 256 I get over a 1000 errors like: ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1536 ERROR 1: TIFFReadEncodedTile() failed. ERROR 1: IReadBlock failed at X offset 12, Y offset 7 ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1664 ERROR 1: TIFFReadEncodedTile() failed. ERROR 1: IReadBlock failed at X offset 13, Y offset 7 ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 Is this because of the number of overviews I requested? ot something else? Is it safe to ignore these? -Steve From even.rouault at mines-paris.org Thu Mar 19 17:56:30 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 19 17:56:41 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C2BC21.8030901@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> Message-ID: <200903192256.31125.even.rouault@mines-paris.org> Hi, no those warnings don't sound good at all ! The number of overviews should be fine too. Could you precise the version of GDAL you're using and if you have built with internal libtiff or external libtiff ? (Such warnings could happen with older libtiff, especially with TIFF compression) Could you just check gdalinfo -checksum file.tif on your original file before running gdaladdo and check that it doesn't throw similar errors ? Best regards, Even Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit?: > Hi, > > I just created a bunch of tif files from a mrsid file and when I use > gdaladdo file.tif 2 4 8 16 32 64 128 256 > > I get over a 1000 errors like: > > ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1536 > ERROR 1: TIFFReadEncodedTile() failed. > ERROR 1: IReadBlock failed at X offset 12, Y offset 7 > ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 > ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1664 > ERROR 1: TIFFReadEncodedTile() failed. > ERROR 1: IReadBlock failed at X offset 13, Y offset 7 > ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 > > > > Is this because of the number of overviews I requested? ot something > else? Is it safe to ignore these? > > -Steve > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From mohwawang at yahoo.com Thu Mar 19 18:01:59 2009 From: mohwawang at yahoo.com (mohwawang) Date: Thu Mar 19 18:02:01 2009 Subject: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW Message-ID: <786202.13337.qm@web32607.mail.mud.yahoo.com> Even, It is getting better: with -co ICORDS=G gdal_translate ran through without error message. But, the output image does not have the correct coordinates (nearly zero for lat/lon for all the pixels when displayed by openEV_FW). I tried -co ICORDS=N instead and still got the same wrong coordinates. I feel some how the info in the jpgw (its content is at the bottom of the email) should be input as parameters for running gdal_translate. But I don't know how. I know that I need both ast_geo.jpg and ast_geo.jpgw to run openEV_FW. Without the jpgw file the Reproject of openEV_FW will fail. Thanks. Mo --- On Thu, 3/19/09, Even Rouault wrote: > From: Even Rouault > Subject: Re: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW > To: gdal-dev@lists.osgeo.org, mohwawang@yahoo.com > Date: Thursday, March 19, 2009, 4:27 PM > > -----Inline Attachment Follows----- > > Mo, > > here's the documentation of the NITF driver : http://gdal.org/frmt_nitf.html > > You probably need to define the ICORDS=G creation option : > > gdal_translate -of NITF ast_geo.jpg new.ntf -co ICORDS=G > > Best regards, > > Even > > Le Thursday 19 March 2009 21:15:12 mohwawang@yahoo.com, > vous avez ?crit?: > > Hi all, > > > > I have successfully used the Reproject of openEV_FW > (FWTools 2.2.8) to > reproject an AST_L1B geo jpg file (ast_geo.jpg with an > ast_geo.jpgw file) to > a NITF file. I wonder if there is any gdal-1.6\apps > executable that is > equivalent to Reproject of Tools of openEV_FW? I tried > gdal_translate.exe but > failed as: > > > gdal_translate -of nitf ast_geo.jpg new.ntf > > > > Input flle size is 5896, 4714 > > 0...10...20...30...40...50...60...70...80...90...100 - > done > > ERROR 6: Apparently no space reserved for IGEOLO info > in NITF file. > > NITFWriteIGEOGLO() fails. > > > > I guess the key is to use the info in the jpgw file as > parameters in the > > equivalent executable if exists. What? How? Below are > the info of the jpg > > file and the content of the jpgw file. > > > > > gdalinfo ast_geo.jpg > > > > Driver: JPEG/JPEG JFIF > > Files: ast_geo.jpg > > Size is 5896, 4714 > > Coordinate System is `' > > Origin = (-113.281421452980040,33.477365682899951) > > Pixel Size = (0.000153055144450,-0.000142760639120) > > Image Structure Metadata: > > ? SOURCE_COLOR_SPACE=YCbCr > > ? INTERLEAVE=PIXEL > > ? COMPRESSION=JPEG > > Corner Coordinates: > > Upper Left? (-113.2814215,? 33.4773657) > > Lower Left? (-113.2814215,? 32.8043920) > > Upper Right (-112.3790083,? 33.4773657) > > Lower Right (-112.3790083,? 32.8043920) > > Center? ? ? (-112.8302149,? 33.1408789) > > Band 1 Block=5896x1 Type=Byte, ColorInterp=Red > > ? Image Structure Metadata: > > ? ? COMPRESSION=JPEG > > Band 2 Block=5896x1 Type=Byte, ColorInterp=Green > > ? Image Structure Metadata: > > ? ? COMPRESSION=JPEG > > Band 3 Block=5896x1 Type=Byte, ColorInterp=Blue > > ? Image Structure Metadata: > > ? ? COMPRESSION=JPEG > > > > > type ast_geo.jpgw > > > > ? ? ? ? ? ? ? ? ???0.00015305514445 > > ? ? ? ? ? ? ? ? ???0.00000000000000 > > ? ? ? ? ? ? ? ? ???0.00000000000000 > > ? ? ? ? ? ? ? ? ? -0.00014276063912 > > ? ? ? ? ? ? ? ? -113.28134492540782 > > ? ? ? ? ? ? ? ? ? 33.47729430258039 > > Tiff File > AST_L1B_00309192003182059_10032003135534_VNIR_geo.tif/n > Image > > width = 5896 height = 4714 bands = 3/n Image_UL = > 33.465445 -113.085740 > > Image_UR = 33.371366 -112.428675/n Image_LL = > 32.910820 -113.234051 > > Image_LR = 32.817455 -112.581118/n Image_UL_Loc =? > ???1278? ? ???83 > > Image_UR_Loc =? ???5571? ? ? 742 Image_LL_Loc > =? ? ? 309? ???3968 > > Image_LR_Loc =? ???4575? ???4622 > > > > Thanks. > > > > Best Regards, > > > > Mo Wang > > > > > > > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > From woodbri at swoodbridge.com Thu Mar 19 19:07:23 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 18:05:52 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C2BC21.8030901@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> Message-ID: <49C2D02B.1020602@swoodbridge.com> Stephen Woodbridge wrote: > Hi, > > I just created a bunch of tif files from a mrsid file and when I use > gdaladdo file.tif 2 4 8 16 32 64 128 256 > > I get over a 1000 errors like: > > ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1536 > ERROR 1: TIFFReadEncodedTile() failed. > ERROR 1: IReadBlock failed at X offset 12, Y offset 7 > ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 > ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1664 > ERROR 1: TIFFReadEncodedTile() failed. > ERROR 1: IReadBlock failed at X offset 13, Y offset 7 > ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 > > > > Is this because of the number of overviews I requested? ot something > else? Is it safe to ignore these? These errors appear to be symptomatic of generating some nasty artifacts on the images at some zoom levels. So not safe to ignore. Any thoughts on what is causing these, and how to avoid them? $ gdalinfo --version GDAL 1.5.2, released 2008/05/29 Running on Debian Lenny $ uname -a Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 GNU/Linux -Steve From even.rouault at mines-paris.org Thu Mar 19 18:12:35 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 19 18:12:44 2009 Subject: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW In-Reply-To: <786202.13337.qm@web32607.mail.mud.yahoo.com> References: <786202.13337.qm@web32607.mail.mud.yahoo.com> Message-ID: <200903192312.35260.even.rouault@mines-paris.org> Maybe you also need to add -a_srs EPSG:4326 to your command line to specify that the georeferenced coordinates are longitude/latitude WGS84 (provided that's the case !) Le Thursday 19 March 2009 23:01:59 mohwawang, vous avez ?crit?: > Even, > > It is getting better: with -co ICORDS=G gdal_translate ran through without > error message. But, the output image does not have the correct coordinates > (nearly zero for lat/lon for all the pixels when displayed by openEV_FW). I > tried -co ICORDS=N instead and still got the same wrong coordinates. > > I feel some how the info in the jpgw (its content is at the bottom of the > email) should be input as parameters for running gdal_translate. But I > don't know how. I know that I need both ast_geo.jpg and ast_geo.jpgw to run > openEV_FW. Without the jpgw file the Reproject of openEV_FW will fail. > > Thanks. > > Mo > > --- On Thu, 3/19/09, Even Rouault wrote: > > From: Even Rouault > > Subject: Re: [gdal-dev] Is there any gdal\apps executable that is > > equivalent to Reproject of openEV_FW To: gdal-dev@lists.osgeo.org, > > mohwawang@yahoo.com > > Date: Thursday, March 19, 2009, 4:27 PM > > > > -----Inline Attachment Follows----- > > > > Mo, > > > > here's the documentation of the NITF driver : > > http://gdal.org/frmt_nitf.html > > > > You probably need to define the ICORDS=G creation option : > > > > gdal_translate -of NITF ast_geo.jpg new.ntf -co ICORDS=G > > > > Best regards, > > > > Even > > > > Le Thursday 19 March 2009 21:15:12 mohwawang@yahoo.com, > > > > vous avez ?crit?: > > > Hi all, > > > > > > I have successfully used the Reproject of openEV_FW > > > > (FWTools 2.2.8) to > > reproject an AST_L1B geo jpg file (ast_geo.jpg with an > > ast_geo.jpgw file) to > > a NITF file. I wonder if there is any gdal-1.6\apps > > executable that is > > equivalent to Reproject of Tools of openEV_FW? I tried > > gdal_translate.exe but > > > > failed as: > > > > gdal_translate -of nitf ast_geo.jpg new.ntf > > > > > > Input flle size is 5896, 4714 > > > 0...10...20...30...40...50...60...70...80...90...100 - > > > > done > > > > > ERROR 6: Apparently no space reserved for IGEOLO info > > > > in NITF file. > > > > > NITFWriteIGEOGLO() fails. > > > > > > I guess the key is to use the info in the jpgw file as > > > > parameters in the > > > > > equivalent executable if exists. What? How? Below are > > > > the info of the jpg > > > > > file and the content of the jpgw file. > > > > > > > gdalinfo ast_geo.jpg > > > > > > Driver: JPEG/JPEG JFIF > > > Files: ast_geo.jpg > > > Size is 5896, 4714 > > > Coordinate System is `' > > > Origin = (-113.281421452980040,33.477365682899951) > > > Pixel Size = (0.000153055144450,-0.000142760639120) > > > Image Structure Metadata: > > > ? SOURCE_COLOR_SPACE=YCbCr > > > ? INTERLEAVE=PIXEL > > > ? COMPRESSION=JPEG > > > Corner Coordinates: > > > Upper Left? (-113.2814215,? 33.4773657) > > > Lower Left? (-113.2814215,? 32.8043920) > > > Upper Right (-112.3790083,? 33.4773657) > > > Lower Right (-112.3790083,? 32.8043920) > > > Center? ? ? (-112.8302149,? 33.1408789) > > > Band 1 Block=5896x1 Type=Byte, ColorInterp=Red > > > ? Image Structure Metadata: > > > ? ? COMPRESSION=JPEG > > > Band 2 Block=5896x1 Type=Byte, ColorInterp=Green > > > ? Image Structure Metadata: > > > ? ? COMPRESSION=JPEG > > > Band 3 Block=5896x1 Type=Byte, ColorInterp=Blue > > > ? Image Structure Metadata: > > > ? ? COMPRESSION=JPEG > > > > > > > type ast_geo.jpgw > > > > > > ? ? ? ? ? ? ? ? ???0.00015305514445 > > > ? ? ? ? ? ? ? ? ???0.00000000000000 > > > ? ? ? ? ? ? ? ? ???0.00000000000000 > > > ? ? ? ? ? ? ? ? ? -0.00014276063912 > > > ? ? ? ? ? ? ? ? -113.28134492540782 > > > ? ? ? ? ? ? ? ? ? 33.47729430258039 > > > Tiff File > > > > AST_L1B_00309192003182059_10032003135534_VNIR_geo.tif/n > > Image > > > > > width = 5896 height = 4714 bands = 3/n Image_UL = > > > > 33.465445 -113.085740 > > > > > Image_UR = 33.371366 -112.428675/n Image_LL = > > > > 32.910820 -113.234051 > > > > > Image_LR = 32.817455 -112.581118/n Image_UL_Loc =? > > > > ???1278? ? ???83 > > > > > Image_UR_Loc =? ???5571? ? ? 742 Image_LL_Loc > > > > =? ? ? 309? ???3968 > > > > > Image_LR_Loc =? ???4575? ???4622 > > > > > > Thanks. > > > > > > Best Regards, > > > > > > Mo Wang > > > > > > > > > > > > > > > _______________________________________________ > > > gdal-dev mailing list > > > gdal-dev@lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev From woodbri at swoodbridge.com Thu Mar 19 19:16:24 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 18:14:55 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image In-Reply-To: <49C29269.2080208@geoanalytic.com> References: <49C27D7E.60208@swoodbridge.com> <49C29269.2080208@geoanalytic.com> Message-ID: <49C2D248.6030708@swoodbridge.com> Brent Fraser wrote: > Steve, > > My general strategy when doing this (on terabytes of raster data) is: > > 1. Create a tileindex of input data. > Since you've got multiple zones of raster data, you'll need to create > one tileindex for each zone (using gdaltindex), de-project them to > geographic, and concatenate them (use ogr2ogr or PostGIS). Turns out I already had a set of de-projected bboxes for each image file. I was going to do this when I found the shapefiles. > 2. Create a geographic tileindex of output files (via your own script) > The size, extents, and amount of overlap are up to you. It doesn't have > to be a tileindex; it could be just a list of extents for use in steps 3 > and 5 below. > > 3. Do a spatial select for each output tile on the input tileindex to > create a "mini" tileindex for each output tile. > I use a hacked version of shputils to do this, but I expect PostGIS or > ogr2ogr + SQL would be a better way to go. I loaded the geographic shapefiles into postgis along with my country boundary polygon and used that to select the tiles the intersected it. > 4. Convert all the mini tileindexes to vrt files (see the new > gdalbuildvrt app!) Oh, I have not seen this. but this is a good idea. I have not use vrt files much, I need to get them into my thought process. > 5 Use gdal_translate with the extents from step 2 to extract the output > tile pixels from its corresponding vrt. Hmmmm, where do you reproject the raster images? I thought you had to use gdalwarp for that. Or is that step 6? > Convoluted yes, but very "scalable". And no Null pixels in the output > tiles. This would be good considering that the tif files are about 1.5-1.7GB each. -Steve > Brent Fraser > GeoAnalytic Inc. > > > Stephen Woodbridge wrote: >> Hi all, >> >> This is my annual wake-up got to do something with rasters and forgot >> the finer details of the last time I did a problem similar to it. >> >> I have a bunch of LandSat mrsid imagery, they are in multiple UTM zone >> projections and I want to convert them to geographic projection, >> WGS84, and into tiff files. The files are too large to convert into a >> single tif, so I plan to quarter each file into 4 pieces. >> >> So I wrote a script the reads the files and collects info about them, >> then generates 4 gdalwarp commands to reproject each quarter of the >> file (perl included below). A typical command looks like: >> >> gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:32642 -t_srs >> EPSG:4326 -te 68.9999676729652 24.9707453133203 72.7715338115736 >> 27.4799559407707 -rb -wm 250 --config GDAL_ONE_BIG_READ ON -co >> "TILED=YES" ./GeoCover2000/n-42-25.sid ./af/n-42-25_1-0.tif >> >> >> The reprojection seems to have worked fine, but the bounds seem to be >> off because of the black (nodata) areas. >> >> You can see my poor results here: >> http://imaptools.com/downloads/raster.gif >> >> Is there a better way to do this? I seem to remember a tool to >> generate tiles. >> Does this need to be done in two steps? How? >> Did I mess up my logic below? I've been over it multiple times and do >> not see any errors. >> >> Any help would be appreciated. >> >> Thanks, >> -Steve >> >> $ gdalinfo -nomd ./GeoCover2000/n-42-25.sid >> Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) >> Files: ./GeoCover2000/n-42-25.sid >> Size is 51078, 39090 >> Coordinate System is `' >> Origin = (136066.125000000000000,3323577.375000000000000) >> Pixel Size = (14.250000000000000,-14.250000000000000) >> Corner Coordinates: >> Upper Left ( 136066.125, 3323577.375) >> Lower Left ( 136066.125, 2766544.875) >> Upper Right ( 863927.625, 3323577.375) >> Lower Right ( 863927.625, 2766544.875) >> Center ( 499996.875, 3045061.125) >> Band 1 Block=1024x128 Type=Byte, ColorInterp=Red >> Minimum=0.000, Maximum=226.000, Mean=109.610, StdDev=39.202 >> Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, >> 799x611, 400x306, 200x153 >> Band 2 Block=1024x128 Type=Byte, ColorInterp=Green >> Minimum=0.000, Maximum=229.000, Mean=125.833, StdDev=31.828 >> Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, >> 799x611, 400x306, 200x153 >> Band 3 Block=1024x128 Type=Byte, ColorInterp=Blue >> Minimum=0.000, Maximum=227.000, Mean=107.092, StdDev=37.230 >> Overviews: 25539x19545, 12770x9773, 6385x4887, 3193x2444, 1597x1222, >> 799x611, 400x306, 200x153 >> >> >> $ cat ./GeoCover2000/n-42-25.prj >> Projection UTM >> Datum WGS84 >> Zunits NO >> Units METERS >> Zone 42 >> Xshift 0.000000 >> Yshift 0.000000 >> Parameters >> >> >> >> Perl snippet: >> >> foreach my $sid (@files) { >> >> next unless $wanted && $sid =~ /$wanted/i; >> >> if (! -r $sid) { >> warn "SKIPPING: $sid is not readable!\n"; >> next; >> } >> >> my $gdalinfo = `gdalinfo -nomd $sid`; >> >> # parse out the strings that we need >> >> $gdalinfo =~ /Upper Left \((\s*[^,]+),\s*([^\)]+)/s || warn >> "Upper Left parse error\n"; >> my $ul = [$1, $2]; >> $gdalinfo =~ /Lower Left \((\s*[^,]+),\s*([^\)]+)/s || warn >> "Lower Left parse error\n"; >> my $ll = [$1, $2]; >> $gdalinfo =~ /Upper Right \((\s*[^,]+),\s*([^\)]+)/s || warn >> "Upper Right error\n"; >> my $ur = [$1, $2]; >> $gdalinfo =~ /Lower Right \((\s*[^,]+),\s*([^\)]+)/s || warn >> "Lower Right error\n"; >> my $lr = [$1, $2]; >> >> my $outf = $sid; >> $outf =~ s/\.sid//; >> $outf =~ m/\/([^\/]+)$/; >> $outf = $1; >> >> my $prj = $sid; >> $prj =~ s/\.sid/.prj/; >> if (! -r $prj) { >> warn "SKIPPING: $prj is not readable!\n"; >> next; >> } >> my $projinfo = `grep Zone $prj`; >> if ($projinfo =~ /^Zone\s*([-+]?\d+)/) { >> my $znum = $1; >> if ($znum < 0) { >> $epsg = 32700 - $znum; >> } else { >> $epsg = 32600 + $znum; >> } >> } >> else { >> warn "SKIPPING: could not find zone or epsg in $prj\n"; >> next; >> } >> >> my $proj = sprintf("+init=epsg:%d", $epsg); >> print "Using projection: $proj for $projinfo" if $DEBUG; >> >> my $pj = Geo::Proj4->new($proj); >> if (! $pj) { >> warn "SKIPPING: Geo::Proj4 error: " . Geo::Proj4->error . >> "\n"; >> next; >> } >> >> $ul = [reverse $pj->inverse(@$ul)]; >> $ll = [reverse $pj->inverse(@$ll)]; >> $ur = [reverse $pj->inverse(@$ur)]; >> $lr = [reverse $pj->inverse(@$lr)]; >> >> # this is probably a parallelgram in latlong >> if ($DEBUG) { >> printf("ul = %11.6f, %11.6f\n", @$ul); >> printf("ll = %11.6f, %11.6f\n", @$ll); >> printf("ur = %11.6f, %11.6f\n", @$ur); >> printf("lr = %11.6f, %11.6f\n", @$lr); >> } >> >> # Get the bbox of the parallelgram >> my $xmin = $ul->[0]<$ll->[0]?$ul->[0]:$ll->[0]; >> my $xmax = $ur->[0]>$lr->[0]?$ur->[0]:$lr->[0]; >> my $ymin = $ll->[1]<$lr->[1]?$ll->[1]:$lr->[1]; >> my $ymax = $ul->[1]>$ur->[1]?$ul->[1]:$ur->[1]; >> >> my $tiled = '-co "TILED=YES"'; >> $tiled = '' if -e $outf; >> >> my $nparts = 2; >> my $dx = ($xmax - $xmin) / $nparts; >> my $dy = ($ymax - $ymin) / $nparts; >> my ($x0, $x1, $y0, $y1); >> for (my $i=0, $x0=$xmin; $i<$nparts; $i++, $x0 += $dx) { >> $x1 = $x0 + $dx; >> for (my $j=0, $y0=$ymin; $j<$nparts; $j++, $y0 += $dy) { >> $y1 = $y0 + $dy; >> my $tif = sprintf("%s/%s/%s_%d-%d.tif", $work, $outd, >> $outf, $i, $j); >> my $cmd = sprintf("gdalwarp -srcnodata 0 -dstnodata 0 >> -s_srs +init=epsg:%d -t_srs EPSG:4326 -te $x0 $y0 $x1 $y1 -rb -wm 250 >> --config GDAL_ONE_BIG_READ ON $tiled $sid $tif\n", $epsg); >> >> print "$cmd\n"; >> my $rc = system($cmd); >> print "SYSTEM returned: " . sprintf("%lx\n", ($rc & >> 0xffff)) >> if $DEBUG >> } >> } >> } >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> From mateusz at loskot.net Thu Mar 19 18:17:52 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu Mar 19 18:17:58 2009 Subject: [gdal-dev] [Fwd: [USN-742-1] JasPer vulnerabilities] Message-ID: <49C2C490.4060504@loskot.net> Hi, Perhaps this is something interesting for GDAL users -- Mateusz -------- Original Message -------- Subject: [USN-742-1] JasPer vulnerabilities Date: Thu, 19 Mar 2009 14:02:46 -0400 From: Marc Deslauriers Reply-To: ubuntu-users@lists.ubuntu.com, Ubuntu Security To: ubuntu-security-announce@lists.ubuntu.com CC: full-disclosure@lists.grok.org.uk, bugtraq@securityfocus.com =========================================================== Ubuntu Security Notice USN-742-1 March 19, 2009 jasper vulnerabilities CVE-2008-3520, CVE-2008-3521, CVE-2008-3522 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 7.10 Ubuntu 8.04 LTS Ubuntu 8.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libjasper-1.701-1 1.701.0-2ubuntu0.6.06.1 Ubuntu 7.10: libjasper1 1.900.1-3ubuntu0.7.10.1 Ubuntu 8.04 LTS: libjasper1 1.900.1-3ubuntu0.8.04.1 Ubuntu 8.10: libjasper1 1.900.1-5ubuntu0.1 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: It was discovered that JasPer did not correctly handle memory allocation when parsing certain malformed JPEG2000 images. If a user were tricked into opening a specially crafted image with an application that uses libjasper, an attacker could cause a denial of service and possibly execute arbitrary code with the user's privileges. (CVE-2008-3520) It was discovered that JasPer created temporary files in an insecure way. Local users could exploit a race condition and cause a denial of service in libjasper applications. (CVE-2008-3521) It was discovered that JasPer did not correctly handle certain formatting operations. If a user were tricked into opening a specially crafted image with an application that uses libjasper, an attacker could cause a denial of service and possibly execute arbitrary code with the user's privileges. (CVE-2008-3522) Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.701.0-2ubuntu0.6.06.1.diff.gz Size/MD5: 34544 cce3c647820e55fae518eb081a77545a http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.701.0-2ubuntu0.6.06.1.dsc Size/MD5: 715 3f7c5d2155ab4f259aab9bcc8aa64c0a http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.701.0.orig.tar.gz Size/MD5: 1084413 ceed8e5e4fc58ac8faca0bd4be8a7b7d amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-1_1.701.0-2ubuntu0.6.06.1_amd64.deb Size/MD5: 146814 020471e3651a9c2fafd6eefedadb3f75 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-dev_1.701.0-2ubuntu0.6.06.1_amd64.deb Size/MD5: 636044 a614b7cd20832821f75ae66bcf639675 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.701.0-2ubuntu0.6.06.1_amd64.deb Size/MD5: 24296 a799121b0c020afa47dda1454c777aa8 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-1_1.701.0-2ubuntu0.6.06.1_i386.deb Size/MD5: 133552 7b3aebd21e1506b8cde1d0ab2602b685 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-dev_1.701.0-2ubuntu0.6.06.1_i386.deb Size/MD5: 619430 c5739e01e9d69506da8e6d956d05af96 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.701.0-2ubuntu0.6.06.1_i386.deb Size/MD5: 21890 6f01dc80f5a3dbd14325935e755301ee powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-1_1.701.0-2ubuntu0.6.06.1_powerpc.deb Size/MD5: 142700 e1253e0a77c84326db1dac4317ca196d http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-dev_1.701.0-2ubuntu0.6.06.1_powerpc.deb Size/MD5: 624160 fec9bc6cacf18fb5fbe42183e9dbdf08 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.701.0-2ubuntu0.6.06.1_powerpc.deb Size/MD5: 27932 31413f853f0a0ce38ed6355200f377f5 sparc architecture (Sun SPARC/UltraSPARC): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-1_1.701.0-2ubuntu0.6.06.1_sparc.deb Size/MD5: 133302 a9f4ba112f2bf58554120454072b57a8 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-1.701-dev_1.701.0-2ubuntu0.6.06.1_sparc.deb Size/MD5: 623384 a5863b651eaedfdff5c9deaacb26dbb9 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.701.0-2ubuntu0.6.06.1_sparc.deb Size/MD5: 22492 f711a38841e73fd99ef8146d8aca8eae Updated packages for Ubuntu 7.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-3ubuntu0.7.10.1.diff.gz Size/MD5: 49782 f6b41bf096b45f95964bde8822419e22 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-3ubuntu0.7.10.1.dsc Size/MD5: 787 84f1be39211afbf546f4865aa2c93b93 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1.orig.tar.gz Size/MD5: 1143400 4ae3dd938fd15f22f30577db5c9f27e9 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.7.10.1_amd64.deb Size/MD5: 560066 121337bb5de35638aee77f2e6f5b4175 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.7.10.1_amd64.deb Size/MD5: 151764 304a3001b55dda77b03b87b58dcce17e http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.7.10.1_amd64.deb Size/MD5: 25552 6cf1e402a960a58ee076513f7224bd93 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.7.10.1_i386.deb Size/MD5: 548268 51fd5964f1593d5c5652d82f94be2f65 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.7.10.1_i386.deb Size/MD5: 144134 4051b7784cf9167f394bc0543758aadc http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.7.10.1_i386.deb Size/MD5: 23126 f1c103e3b437b004c62044e77a6fd789 lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.7.10.1_lpia.deb Size/MD5: 548046 03c662544f78e41aa52b4eb0cef88f5e http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.7.10.1_lpia.deb Size/MD5: 145604 f163501caa0ec88be92150e27177be07 http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.7.10.1_lpia.deb Size/MD5: 23288 b231d9da0cd70d816dc8aa0324d02f81 powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.7.10.1_powerpc.deb Size/MD5: 554840 6ed5498df3429753a6b8149ff35d9713 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.7.10.1_powerpc.deb Size/MD5: 156696 6d6301d54dcfcb54351c8b7a29cd0e98 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.7.10.1_powerpc.deb Size/MD5: 31970 64002762586577cd40494a75daf072c6 sparc architecture (Sun SPARC/UltraSPARC): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.7.10.1_sparc.deb Size/MD5: 546862 bad1d4f79ac9a0abfe4b722ca94299a9 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.7.10.1_sparc.deb Size/MD5: 138864 059db193b061fe0152be74ff6f7afe0d http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.7.10.1_sparc.deb Size/MD5: 24654 3f7c1c3623b76ef1bf87a4e269ce0959 Updated packages for Ubuntu 8.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-3ubuntu0.8.04.1.diff.gz Size/MD5: 49784 140289a8237818c78c094142470562be http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-3ubuntu0.8.04.1.dsc Size/MD5: 787 d110d94a13ba861e16d5a53d2fa06a0d http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1.orig.tar.gz Size/MD5: 1143400 4ae3dd938fd15f22f30577db5c9f27e9 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.8.04.1_amd64.deb Size/MD5: 560628 5ad790436c98d5b9cf0a6d4b31676999 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.8.04.1_amd64.deb Size/MD5: 149284 3e91312e9bfec2f8f15cbb6c7137276c http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.8.04.1_amd64.deb Size/MD5: 25430 b587ab277fd41171e0f1f1576e2d9ca8 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.8.04.1_i386.deb Size/MD5: 548014 81bfeab149dd028ab86b682910248264 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.8.04.1_i386.deb Size/MD5: 140772 099c812e2107df16ec5f448fd4dd24ee http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.8.04.1_i386.deb Size/MD5: 23250 5c4bb207c9eab2d64e7d2012f2adebe7 lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.8.04.1_lpia.deb Size/MD5: 547934 4f03a5626dde55be41d3403b07aacb27 http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.8.04.1_lpia.deb Size/MD5: 142492 a07e3596c6b2d436402a1658582b3e06 http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.8.04.1_lpia.deb Size/MD5: 23258 e280973f4522be895b4e3c06fcdf7a6f powerpc architecture (Apple Macintosh G3/G4/G5): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.8.04.1_powerpc.deb Size/MD5: 554736 e51d72ed422e517dd93602585732713a http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.8.04.1_powerpc.deb Size/MD5: 151722 c11f4cdae73aac0cb3b265ba59fbfff0 http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.8.04.1_powerpc.deb Size/MD5: 32328 d168c11f56f84810e7ed072c615497a3 sparc architecture (Sun SPARC/UltraSPARC): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-3ubuntu0.8.04.1_sparc.deb Size/MD5: 545368 e32366827751c4747af02d1706f23192 http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-3ubuntu0.8.04.1_sparc.deb Size/MD5: 136120 f6b6f67d4d6ce88fb1edc6f4528bb678 http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-3ubuntu0.8.04.1_sparc.deb Size/MD5: 24538 f8aba59b6f69e220cf6e68a3bfb71d37 Updated packages for Ubuntu 8.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-5ubuntu0.1.diff.gz Size/MD5: 52688 1b4d2d4ee9a459a451913b675b263d62 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1-5ubuntu0.1.dsc Size/MD5: 1187 fb314df8a6f5247edb747987f8d76f02 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/jasper_1.900.1.orig.tar.gz Size/MD5: 1143400 4ae3dd938fd15f22f30577db5c9f27e9 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-5ubuntu0.1_amd64.deb Size/MD5: 562142 c2f25e04c912a1b64c4dfce1eb7dd3d5 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-5ubuntu0.1_amd64.deb Size/MD5: 151868 6e8b66b557cc7a794c6c14fb6d588d81 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-5ubuntu0.1_amd64.deb Size/MD5: 25758 ca74bf783944c89242555b641b2e5f90 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper-dev_1.900.1-5ubuntu0.1_i386.deb Size/MD5: 550168 812497f62590b915fd0329e810295675 http://security.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-5ubuntu0.1_i386.deb Size/MD5: 143290 d9c1b2e6abca55d5fc8bd2a0408887d9 http://security.ubuntu.com/ubuntu/pool/universe/j/jasper/libjasper-runtime_1.900.1-5ubuntu0.1_i386.deb Size/MD5: 23616 af8d3d8dcdf8ec7e92b470bd3e0edfc5 lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-5ubuntu0.1_lpia.deb Size/MD5: 549832 8be0a5f2995b25b20cdb0bd8608a9b2d http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-5ubuntu0.1_lpia.deb Size/MD5: 144942 6655936af1cd1a43455b25b5fca92c7e http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-5ubuntu0.1_lpia.deb Size/MD5: 23516 dc7791cea2c443a07c9eba67944873b8 powerpc architecture (Apple Macintosh G3/G4/G5): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-5ubuntu0.1_powerpc.deb Size/MD5: 557240 da2293d915a7fe54cb28af6d1c492dda http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-5ubuntu0.1_powerpc.deb Size/MD5: 154072 885f88a8d11e3b2375fd7633b0d18f60 http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-5ubuntu0.1_powerpc.deb Size/MD5: 31458 f17ad2b7f030b844ef1bc01db1b07cd5 sparc architecture (Sun SPARC/UltraSPARC): http://ports.ubuntu.com/pool/main/j/jasper/libjasper-dev_1.900.1-5ubuntu0.1_sparc.deb Size/MD5: 545474 cb6fdbec36215740768dde9466434151 http://ports.ubuntu.com/pool/main/j/jasper/libjasper1_1.900.1-5ubuntu0.1_sparc.deb Size/MD5: 136986 1940aab6c284ec22bd70b4a5ee6b432a http://ports.ubuntu.com/pool/universe/j/jasper/libjasper-runtime_1.900.1-5ubuntu0.1_sparc.deb Size/MD5: 24666 2716a795c39dea1835cd9f69f9e061c3 -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090319/4e56283b/signature-0001.bin From bfraser at geoanalytic.com Thu Mar 19 18:59:53 2009 From: bfraser at geoanalytic.com (Brent Fraser) Date: Thu Mar 19 19:01:28 2009 Subject: [gdal-dev] Splitting and projecting a large .sid image In-Reply-To: <49C2D248.6030708@swoodbridge.com> References: <49C27D7E.60208@swoodbridge.com> <49C29269.2080208@geoanalytic.com> <49C2D248.6030708@swoodbridge.com> Message-ID: <.68.144.5.189.1237503593.squirrel@68.144.5.189> >> 5 Use gdal_translate with the extents from step 2 to extract the output >> tile pixels from its corresponding vrt. > > Hmmmm, where do you reproject the raster images? I thought you had to > use gdalwarp for that. Or is that step 6? Oops. Yep, use gdalwarp (I was looking at my DEM processing script; its geo-to-geo). Brent From woodbri at swoodbridge.com Thu Mar 19 21:14:45 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Thu Mar 19 20:13:16 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <200903192256.31125.even.rouault@mines-paris.org> References: <49C2BC21.8030901@swoodbridge.com> <200903192256.31125.even.rouault@mines-paris.org> Message-ID: <49C2EE05.1040804@swoodbridge.com> Even, I ran gdalinfo -checksum on all 51GB of images and none of them reported any errors. And none of the images are compressed. I'm using Debian Lenny packages. There is an ldd output below. $ uname -a Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 GNU/Linux $ gdalinfo --version GDAL 1.5.2, released 2008/05/29 $ apt-cache show libtiff4 Package: libtiff4 Priority: optional Section: libs Installed-Size: 484 Maintainer: Jay Berkenbilt Architecture: amd64 Source: tiff Version: 3.8.2-11 Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb Size: 169372 MD5sum: 8c0019eef3a752760dca8f14c80c3820 SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f SHA256: e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 Description: Tag Image File Format (TIFF) library libtiff is a library providing support for the Tag Image File Format (TIFF), a widely used format for storing image data. This package includes the shared library. Homepage: http://libtiff.maptools.org Tag: role::shared-lib, works-with::image:raster A typical gdalinfo on one of the files is: $ gdalinfo -checksum n-41-25_0-0.tif Files: n-41-25_0-0.tif Size is 27192, 18091 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235630016, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (59.228401534356898,27.479955940770701) Pixel Size = (0.000138699063483,-0.000138699063483) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) Band 1 Block=256x256 Type=Byte, ColorInterp=Red Checksum=29566 NoData Value=0 Band 2 Block=256x256 Type=Byte, ColorInterp=Green Checksum=34905 NoData Value=0 Band 3 Block=256x256 Type=Byte, ColorInterp=Blue Checksum=24337 NoData Value=0 woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo linux-vdso.so.1 => (0x00007fff937fe000) libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 (0x00002ac017605000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00002ac018adf000) libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00002ac018d55000) libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 (0x00002ac0193e7000) libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 (0x00002ac019c3a000) libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 (0x00002ac01bba1000) libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0x00002ac01bde0000) /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00002ac01d99a000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00002ac01dbec000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00002ac01e42c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00002ac01e890000) libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002ac01f1ce000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00002ac01f3e6000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00002ac01f60d000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00002ac020056000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00002ac02015a000) Even Rouault wrote: > Hi, > > no those warnings don't sound good at all ! The number of overviews should be > fine too. > > Could you precise the version of GDAL you're using and if you have built with > internal libtiff or external libtiff ? > (Such warnings could happen with older libtiff, especially with TIFF > compression) > Could you just check gdalinfo -checksum file.tif on your original file before > running gdaladdo and check that it doesn't throw similar errors ? > > Best regards, > Even > > Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit : >> Hi, >> >> I just created a bunch of tif files from a mrsid file and when I use >> gdaladdo file.tif 2 4 8 16 32 64 128 256 >> >> I get over a 1000 errors like: >> >> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1536 >> ERROR 1: TIFFReadEncodedTile() failed. >> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 >> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 >> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline 1664 >> ERROR 1: TIFFReadEncodedTile() failed. >> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 >> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 >> >> >> >> Is this because of the number of overviews I requested? ot something >> else? Is it safe to ignore these? >> >> -Steve >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > From mohwawang at yahoo.com Thu Mar 19 21:37:30 2009 From: mohwawang at yahoo.com (mohwawang) Date: Thu Mar 19 21:37:32 2009 Subject: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW Message-ID: <70174.87896.qm@web32603.mail.mud.yahoo.com> Even, You are right on. Following your suggestion I have resolved the problem. Thank you very much. Best Regards, Mo Wang --- On Thu, 3/19/09, Even Rouault wrote: > From: Even Rouault > Subject: Re: [gdal-dev] Is there any gdal\apps executable that is equivalent to Reproject of openEV_FW > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Thursday, March 19, 2009, 6:12 PM > > -----Inline Attachment Follows----- > > Maybe you also need to add -a_srs > EPSG:4326 to your command line to specify > that the georeferenced coordinates are longitude/latitude > WGS84 (provided > that's the case !) > > Le Thursday 19 March 2009 23:01:59 mohwawang, vous avez > ?crit?: > > Even, > > > > It is getting better: with -co ICORDS=G gdal_translate > ran through without > > error message. But, the output image does not have the > correct coordinates > > (nearly zero for lat/lon for all the pixels when > displayed by openEV_FW). I > > tried -co ICORDS=N instead and still got the same > wrong coordinates. > > > > I feel some how the info in the jpgw (its content is > at the bottom of the > > email) should be input as parameters for running > gdal_translate. But I > > don't know how. I know that I need both ast_geo.jpg > and ast_geo.jpgw to run > > openEV_FW. Without the jpgw file the Reproject of > openEV_FW will fail. > > > > Thanks. > > > > Mo > > > > --- On Thu, 3/19/09, Even Rouault > wrote: > > > From: Even Rouault > > > Subject: Re: [gdal-dev] Is there any gdal\apps > executable that is > > > equivalent to Reproject of openEV_FW To: gdal-dev@lists.osgeo.org, > > > mohwawang@yahoo.com > > > Date: Thursday, March 19, 2009, 4:27 PM > > > > > > -----Inline Attachment Follows----- > > > > > > Mo, > > > > > > here's the documentation of the NITF driver : > > > http://gdal.org/frmt_nitf.html > > > > > > You probably need to define the ICORDS=G creation > option : > > > > > > gdal_translate -of NITF ast_geo.jpg new.ntf -co > ICORDS=G > > > > > > Best regards, > > > > > > Even > > > > > > Le Thursday 19 March 2009 21:15:12 mohwawang@yahoo.com, > > > > > > vous avez ?crit?: > > > > Hi all, > > > > > > > > I have successfully used the Reproject of > openEV_FW > > > > > > (FWTools 2.2.8) to > > > reproject an AST_L1B geo jpg file (ast_geo.jpg > with an > > > ast_geo.jpgw file) to > > > a NITF file. I wonder if there is any > gdal-1.6\apps > > > executable that is > > > equivalent to Reproject of Tools of openEV_FW? I > tried > > > gdal_translate.exe but > > > > > > failed as: > > > > > gdal_translate -of nitf ast_geo.jpg > new.ntf > > > > > > > > Input flle size is 5896, 4714 > > > > > 0...10...20...30...40...50...60...70...80...90...100 - > > > > > > done > > > > > > > ERROR 6: Apparently no space reserved for > IGEOLO info > > > > > > in NITF file. > > > > > > > NITFWriteIGEOGLO() fails. > > > > > > > > I guess the key is to use the info in the > jpgw file as > > > > > > parameters in the > > > > > > > equivalent executable if exists. What? How? > Below are > > > > > > the info of the jpg > > > > > > > file and the content of the jpgw file. > > > > > > > > > gdalinfo ast_geo.jpg > > > > > > > > Driver: JPEG/JPEG JFIF > > > > Files: ast_geo.jpg > > > > Size is 5896, 4714 > > > > Coordinate System is `' > > > > Origin = > (-113.281421452980040,33.477365682899951) > > > > Pixel Size = > (0.000153055144450,-0.000142760639120) > > > > Image Structure Metadata: > > > > ? SOURCE_COLOR_SPACE=YCbCr > > > > ? INTERLEAVE=PIXEL > > > > ? COMPRESSION=JPEG > > > > Corner Coordinates: > > > > Upper Left? (-113.2814215,? 33.4773657) > > > > Lower Left? (-113.2814215,? 32.8043920) > > > > Upper Right (-112.3790083,? 33.4773657) > > > > Lower Right (-112.3790083,? 32.8043920) > > > > Center? ? ? (-112.8302149,? 33.1408789) > > > > Band 1 Block=5896x1 Type=Byte, > ColorInterp=Red > > > > ? Image Structure Metadata: > > > > ? ? COMPRESSION=JPEG > > > > Band 2 Block=5896x1 Type=Byte, > ColorInterp=Green > > > > ? Image Structure Metadata: > > > > ? ? COMPRESSION=JPEG > > > > Band 3 Block=5896x1 Type=Byte, > ColorInterp=Blue > > > > ? Image Structure Metadata: > > > > ? ? COMPRESSION=JPEG > > > > > > > > > type ast_geo.jpgw > > > > > > > > ? ? ? ? ? ? ? ? > ???0.00015305514445 > > > > ? ? ? ? ? ? ? ? > ???0.00000000000000 > > > > ? ? ? ? ? ? ? ? > ???0.00000000000000 > > > > ? ? ? ? ? ? ? ? ? > -0.00014276063912 > > > > ? ? ? ? ? ? ? ? -113.28134492540782 > > > > ? ? ? ? ? ? ? ? ? > 33.47729430258039 > > > > Tiff File > > > > > > > AST_L1B_00309192003182059_10032003135534_VNIR_geo.tif/n > > > Image > > > > > > > width = 5896 height = 4714 bands = 3/n > Image_UL = > > > > > > 33.465445 -113.085740 > > > > > > > Image_UR = 33.371366 -112.428675/n Image_LL > = > > > > > > 32.910820 -113.234051 > > > > > > > Image_LR = 32.817455 -112.581118/n > Image_UL_Loc =? > > > > > > ???1278? ? ???83 > > > > > > > Image_UR_Loc =? ???5571? ? ? 742 > Image_LL_Loc > > > > > > =? ? ? 309? ???3968 > > > > > > > Image_LR_Loc =? ???4575? ???4622 > > > > > > > > Thanks. > > > > > > > > Best Regards, > > > > > > > > Mo Wang > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > gdal-dev mailing list > > > > gdal-dev@lists.osgeo.org > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > From woodbri at swoodbridge.com Fri Mar 20 18:25:28 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Fri Mar 20 17:24:00 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C2EE05.1040804@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> <200903192256.31125.even.rouault@mines-paris.org> <49C2EE05.1040804@swoodbridge.com> Message-ID: <49C417D8.6030101@swoodbridge.com> So is the conclusion on this issue, that Debian has old/bad? libtiff libraries? What version libtiff do I need to make this work correctly? Is gdal 1.5.2 a reasonable version to be running under? I would like to stay under the package management system as much as possible. But I also need to resolve this issue. Thanks, -Steve Stephen Woodbridge wrote: > Even, > > I ran gdalinfo -checksum on all 51GB of images and none of them reported > any errors. And none of the images are compressed. > > I'm using Debian Lenny packages. There is an ldd output below. > > $ uname -a > Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 > GNU/Linux > > $ gdalinfo --version > GDAL 1.5.2, released 2008/05/29 > > $ apt-cache show libtiff4 > Package: libtiff4 > Priority: optional > Section: libs > Installed-Size: 484 > Maintainer: Jay Berkenbilt > Architecture: amd64 > Source: tiff > Version: 3.8.2-11 > Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) > Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb > Size: 169372 > MD5sum: 8c0019eef3a752760dca8f14c80c3820 > SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f > SHA256: e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 > Description: Tag Image File Format (TIFF) library > libtiff is a library providing support for the Tag Image File Format > (TIFF), a widely used format for storing image data. This package > includes the shared library. > Homepage: http://libtiff.maptools.org > Tag: role::shared-lib, works-with::image:raster > > A typical gdalinfo on one of the files is: > > $ gdalinfo -checksum n-41-25_0-0.tif > Files: n-41-25_0-0.tif > Size is 27192, 18091 > Coordinate System is: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.2572235630016, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > Origin = (59.228401534356898,27.479955940770701) > Pixel Size = (0.000138699063483,-0.000138699063483) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=PIXEL > Corner Coordinates: > Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) > Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) > Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) > Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) > Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) > Band 1 Block=256x256 Type=Byte, ColorInterp=Red > Checksum=29566 > NoData Value=0 > Band 2 Block=256x256 Type=Byte, ColorInterp=Green > Checksum=34905 > NoData Value=0 > Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > Checksum=24337 > NoData Value=0 > > > woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo > linux-vdso.so.1 => (0x00007fff937fe000) > libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 > (0x00002ac017605000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) > libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) > libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) > libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) > libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00002ac018adf000) > libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00002ac018d55000) > libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0x00002ac018fb1000) > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ac0191be000) > libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 > (0x00002ac0193e7000) > libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) > libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 > (0x00002ac019c3a000) > libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) > libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) > libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) > libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) > libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) > libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) > libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) > libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) > libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) > librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) > libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) > libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 > (0x00002ac01bba1000) > libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 > (0x00002ac01bde0000) > /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) > libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so (0x00002ac01c1eb000) > libltdl.so.3 => /usr/lib/libltdl.so.3 (0x00002ac01c53a000) > libicuuc.so.38 => /usr/lib/libicuuc.so.38 (0x00002ac01c741000) > libicudata.so.38 => /usr/lib/libicudata.so.38 (0x00002ac01ca82000) > libproj.so.0 => /usr/lib/libproj.so.0 (0x00002ac01d759000) > libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00002ac01d99a000) > libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 > (0x00002ac01dbec000) > libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) > libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 > (0x00002ac01e42c000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) > libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 > (0x00002ac01e890000) > libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00002ac01ed0c000) > libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00002ac01ef1b000) > libnsl.so.1 => /lib/libnsl.so.1 (0x00002ac01f1ce000) > libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00002ac01f3e6000) > libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 > (0x00002ac01f60d000) > libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) > libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) > libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) > libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 > (0x00002ac020056000) > libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00002ac02015a000) > > > Even Rouault wrote: >> Hi, >> >> no those warnings don't sound good at all ! The number of overviews >> should be fine too. >> >> Could you precise the version of GDAL you're using and if you have >> built with internal libtiff or external libtiff ? >> (Such warnings could happen with older libtiff, especially with TIFF >> compression) >> Could you just check gdalinfo -checksum file.tif on your original file >> before running gdaladdo and check that it doesn't throw similar errors ? >> >> Best regards, >> Even >> >> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit : >>> Hi, >>> >>> I just created a bunch of tif files from a mrsid file and when I use >>> gdaladdo file.tif 2 4 8 16 32 64 128 256 >>> >>> I get over a 1000 errors like: >>> >>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>> 1536 >>> ERROR 1: TIFFReadEncodedTile() failed. >>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 >>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 >>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>> 1664 >>> ERROR 1: TIFFReadEncodedTile() failed. >>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 >>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 >>> >>> >>> >>> Is this because of the number of overviews I requested? ot something >>> else? Is it safe to ignore these? >>> >>> -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 From even.rouault at mines-paris.org Fri Mar 20 17:24:10 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 20 17:24:27 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C310EB.8030904@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> <49C2EE05.1040804@swoodbridge.com> <49C310EB.8030904@swoodbridge.com> Message-ID: <200903202224.13322.even.rouault@mines-paris.org> Stephen, I've managed to reproduce your issue with GDAL 1.5 compiled with libtiff 3.8.2 (and I'm not so surprised, as I remember that it was a known issue). But when built with internal libtiff or against external libtiff 3.9.0 (CVS head version), it works fine. So it is due to some bug in libtiff 3.8.2. So you could either compile GDAL with internal libtiff support, or just build libtiff 3.9.0 and trick GDAL to link against it by using LD_LIBRARY_PATH. You'll need to create a symlink from the generated libtiff.so to libtiff.so.4 which is expected by the Debian libgdal.so. I've tried that and it works fine. Best regards, Even Le Friday 20 March 2009 04:43:39 Stephen Woodbridge, vous avez ?crit?: > Even, > > So I just happened to have made a backup copy of the tif files before > adding the overviews. And as a said, all the files without overviews did > not report errors with gdalinfo -checksum file.tif. I also check all > the files with the overviews and some of them, not all, do report > errors. I'm seeing reported: > > Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" > field, ignoring and calculating from imagelength > > on some of the files that have overviews added. I went back and checked > output from the gdaladdo and it shows up in places there also. > > This is the file without overviews added: > > woodbri@mappy:/u/leaddog-200903013/af-bck$ gdalinfo -checksum > n-41-35_0-0.tif > Driver: GTiff/GeoTIFF > Files: n-41-35_0-0.tif > Size is 26688, 16853 > Coordinate System is: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.2572235630016, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > Origin = (59.025339626823701,37.469898080618897) > Pixel Size = (0.000148923698721,-0.000148923698721) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=PIXEL > Corner Coordinates: > Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) > Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) > Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) > Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) > Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) > Band 1 Block=256x256 Type=Byte, ColorInterp=Red > Checksum=4400 > NoData Value=0 > Band 2 Block=256x256 Type=Byte, ColorInterp=Green > Checksum=18333 > NoData Value=0 > Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > Checksum=64262 > NoData Value=0 > > And here is the samefile after adding the overviews: > > woodbri@mappy:/u/leaddog-200903013/af-bck$ cd ../af > woodbri@mappy:/u/leaddog-200903013/af$ gdalinfo -checksum n-41-35_0-0.tif > Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" > field, ignoring and calculating from imagelength > Driver: GTiff/GeoTIFF > Files: n-41-35_0-0.tif > Size is 26688, 16853 > Coordinate System is: > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.2572235630016, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > Origin = (59.025339626823701,37.469898080618897) > Pixel Size = (0.000148923698721,-0.000148923698721) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=PIXEL > Corner Coordinates: > Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) > Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) > Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) > Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) > Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) > Band 1 Block=256x256 Type=Byte, ColorInterp=Red > Checksum=4400 > NoData Value=0 > Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > 417x264, 209x132, 105x66 > Band 2 Block=256x256 Type=Byte, ColorInterp=Green > Checksum=18333 > NoData Value=0 > Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > 417x264, 209x132, 105x66 > Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > Checksum=64262 > NoData Value=0 > Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > 417x264, 209x132, 105x66 > Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" > field, ignoring and calculating from imagelength > > Stephen Woodbridge wrote: > > Even, > > > > I ran gdalinfo -checksum on all 51GB of images and none of them reported > > any errors. And none of the images are compressed. > > > > I'm using Debian Lenny packages. There is an ldd output below. > > > > $ uname -a > > Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 > > GNU/Linux > > > > $ gdalinfo --version > > GDAL 1.5.2, released 2008/05/29 > > > > $ apt-cache show libtiff4 > > Package: libtiff4 > > Priority: optional > > Section: libs > > Installed-Size: 484 > > Maintainer: Jay Berkenbilt > > Architecture: amd64 > > Source: tiff > > Version: 3.8.2-11 > > Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) > > Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb > > Size: 169372 > > MD5sum: 8c0019eef3a752760dca8f14c80c3820 > > SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f > > SHA256: e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 > > Description: Tag Image File Format (TIFF) library > > libtiff is a library providing support for the Tag Image File Format > > (TIFF), a widely used format for storing image data. This package > > includes the shared library. > > Homepage: http://libtiff.maptools.org > > Tag: role::shared-lib, works-with::image:raster > > > > A typical gdalinfo on one of the files is: > > > > $ gdalinfo -checksum n-41-25_0-0.tif > > Files: n-41-25_0-0.tif > > Size is 27192, 18091 > > Coordinate System is: > > GEOGCS["WGS 84", > > DATUM["WGS_1984", > > SPHEROID["WGS 84",6378137,298.2572235630016, > > AUTHORITY["EPSG","7030"]], > > AUTHORITY["EPSG","6326"]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433], > > AUTHORITY["EPSG","4326"]] > > Origin = (59.228401534356898,27.479955940770701) > > Pixel Size = (0.000138699063483,-0.000138699063483) > > Metadata: > > AREA_OR_POINT=Area > > Image Structure Metadata: > > INTERLEAVE=PIXEL > > Corner Coordinates: > > Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) > > Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) > > Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) > > Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) > > Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) > > Band 1 Block=256x256 Type=Byte, ColorInterp=Red > > Checksum=29566 > > NoData Value=0 > > Band 2 Block=256x256 Type=Byte, ColorInterp=Green > > Checksum=34905 > > NoData Value=0 > > Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > > Checksum=24337 > > NoData Value=0 > > > > > > woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo > > linux-vdso.so.1 => (0x00007fff937fe000) > > libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 > > (0x00002ac017605000) > > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) > > libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) > > libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) > > libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) > > libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00002ac018adf000) > > libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00002ac018d55000) > > libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 > > (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 > > (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 > > (0x00002ac0193e7000) > > libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) > > libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 > > (0x00002ac019c3a000) > > libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) > > libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) > > libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) > > libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) > > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) > > libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) > > libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) > > libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) > > libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) > > libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) > > libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) > > librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) > > libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) > > libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 > > (0x00002ac01bba1000) > > libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 > > (0x00002ac01bde0000) > > /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) > > libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so > > (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 > > (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 > > (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 > > (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 > > (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 > > (0x00002ac01d99a000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 > > (0x00002ac01dbec000) > > libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) > > libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) > > libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 > > (0x00002ac01e42c000) > > libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) > > libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 > > (0x00002ac01e890000) > > libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) > > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 > > (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 > > (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002ac01f1ce000) > > libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 > > (0x00002ac01f3e6000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 > > (0x00002ac01f60d000) > > libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) > > libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) > > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) > > libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) > > libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 > > (0x00002ac020056000) > > libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00002ac02015a000) > > > > Even Rouault wrote: > >> Hi, > >> > >> no those warnings don't sound good at all ! The number of overviews > >> should be fine too. > >> > >> Could you precise the version of GDAL you're using and if you have > >> built with internal libtiff or external libtiff ? > >> (Such warnings could happen with older libtiff, especially with TIFF > >> compression) > >> Could you just check gdalinfo -checksum file.tif on your original file > >> before running gdaladdo and check that it doesn't throw similar errors ? > >> > >> Best regards, > >> Even > >> > >> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit : > >>> Hi, > >>> > >>> I just created a bunch of tif files from a mrsid file and when I use > >>> gdaladdo file.tif 2 4 8 16 32 64 128 256 > >>> > >>> I get over a 1000 errors like: > >>> > >>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline > >>> 1536 > >>> ERROR 1: TIFFReadEncodedTile() failed. > >>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 > >>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 > >>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline > >>> 1664 > >>> ERROR 1: TIFFReadEncodedTile() failed. > >>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 > >>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 > >>> > >>> > >>> > >>> Is this because of the number of overviews I requested? ot something > >>> else? Is it safe to ignore these? > >>> > >>> -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 From giohappy at gmail.com Fri Mar 20 18:45:04 2009 From: giohappy at gmail.com (G. Allegri) Date: Fri Mar 20 18:50:47 2009 Subject: [gdal-dev] gdb debug for grass g.proj crash in Windows Vista Message-ID: About the ticket http://trac.osgeo.org/grass/ticket/537, I've run gdb to make a simple traceback. This is what I get: (gdb) run -w Starting program: c:\OSGeo4W\apps\grass\grass-6.5.svn\bin/g.proj.exe -w [New thread 2856.0x364] Program received signal SIGTRAP, Trace/breakpoint trap. 0x77d47dff in ntdll!DbgUiConvertStateChangeStructure () from C:\Windows\system32\ntdll.dll (gdb) warning: Lowest section in C:\Windows\system32\odbcint.dll is .rsrc at 00401000 warning: Invalid parameter passed to C runtime function. warning: HEAP[g.proj.exe]: warning: Invalid address specified to RtlFreeHeap( 01430000, 015E4700 ) giovanni From noreply at ci.faniq.com Fri Mar 20 20:17:25 2009 From: noreply at ci.faniq.com (Subramaniam S) Date: Fri Mar 20 20:17:26 2009 Subject: [gdal-dev] Your private message from Subramaniam is about to expire Message-ID: <20090321001725.4F27BE00B5B@lists.osgeo.org> An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090320/3bc82e1d/attachment-0001.html From woodbri at swoodbridge.com Fri Mar 20 23:10:18 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Fri Mar 20 22:08:49 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <200903202224.13322.even.rouault@mines-paris.org> References: <49C2BC21.8030901@swoodbridge.com> <49C2EE05.1040804@swoodbridge.com> <49C310EB.8030904@swoodbridge.com> <200903202224.13322.even.rouault@mines-paris.org> Message-ID: <49C45A9A.5090208@swoodbridge.com> Even, Thank you for all the extra work you did, I very much appreciate it. Looks like I get to spend my weekend trying to rebuild the Lenny Source package for libtiff based on 3.9.0. This is probably not the right list, but looking at: ftp://ftp.remotesensing.org/pub/libtiff/ 3.9.0 looks to be beta since 7/13/2007 4.0.0 looks to be beta since 1/21/2009 Did these ever get released? Am I looking at the correct site? Thanks again for you assistance. -Steve Even Rouault wrote: > Stephen, > > I've managed to reproduce your issue with GDAL 1.5 compiled with libtiff 3.8.2 > (and I'm not so surprised, as I remember that it was a known issue). But when > built with internal libtiff or against external libtiff 3.9.0 (CVS head > version), it works fine. So it is due to some bug in libtiff 3.8.2. > So you could either compile GDAL with internal libtiff support, or just build > libtiff 3.9.0 and trick GDAL to link against it by using LD_LIBRARY_PATH. > You'll need to create a symlink from the generated libtiff.so to libtiff.so.4 > which is expected by the Debian libgdal.so. I've tried that and it works > fine. > > Best regards, > > Even > > Le Friday 20 March 2009 04:43:39 Stephen Woodbridge, vous avez ?crit : >> Even, >> >> So I just happened to have made a backup copy of the tif files before >> adding the overviews. And as a said, all the files without overviews did >> not report errors with gdalinfo -checksum file.tif. I also check all >> the files with the overviews and some of them, not all, do report >> errors. I'm seeing reported: >> >> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >> field, ignoring and calculating from imagelength >> >> on some of the files that have overviews added. I went back and checked >> output from the gdaladdo and it shows up in places there also. >> >> This is the file without overviews added: >> >> woodbri@mappy:/u/leaddog-200903013/af-bck$ gdalinfo -checksum >> n-41-35_0-0.tif >> Driver: GTiff/GeoTIFF >> Files: n-41-35_0-0.tif >> Size is 26688, 16853 >> Coordinate System is: >> GEOGCS["WGS 84", >> DATUM["WGS_1984", >> SPHEROID["WGS 84",6378137,298.2572235630016, >> AUTHORITY["EPSG","7030"]], >> AUTHORITY["EPSG","6326"]], >> PRIMEM["Greenwich",0], >> UNIT["degree",0.0174532925199433], >> AUTHORITY["EPSG","4326"]] >> Origin = (59.025339626823701,37.469898080618897) >> Pixel Size = (0.000148923698721,-0.000148923698721) >> Metadata: >> AREA_OR_POINT=Area >> Image Structure Metadata: >> INTERLEAVE=PIXEL >> Corner Coordinates: >> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) >> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) >> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) >> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) >> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) >> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >> Checksum=4400 >> NoData Value=0 >> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >> Checksum=18333 >> NoData Value=0 >> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >> Checksum=64262 >> NoData Value=0 >> >> And here is the samefile after adding the overviews: >> >> woodbri@mappy:/u/leaddog-200903013/af-bck$ cd ../af >> woodbri@mappy:/u/leaddog-200903013/af$ gdalinfo -checksum n-41-35_0-0.tif >> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >> field, ignoring and calculating from imagelength >> Driver: GTiff/GeoTIFF >> Files: n-41-35_0-0.tif >> Size is 26688, 16853 >> Coordinate System is: >> GEOGCS["WGS 84", >> DATUM["WGS_1984", >> SPHEROID["WGS 84",6378137,298.2572235630016, >> AUTHORITY["EPSG","7030"]], >> AUTHORITY["EPSG","6326"]], >> PRIMEM["Greenwich",0], >> UNIT["degree",0.0174532925199433], >> AUTHORITY["EPSG","4326"]] >> Origin = (59.025339626823701,37.469898080618897) >> Pixel Size = (0.000148923698721,-0.000148923698721) >> Metadata: >> AREA_OR_POINT=Area >> Image Structure Metadata: >> INTERLEAVE=PIXEL >> Corner Coordinates: >> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) >> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) >> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) >> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) >> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) >> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >> Checksum=4400 >> NoData Value=0 >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >> 417x264, 209x132, 105x66 >> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >> Checksum=18333 >> NoData Value=0 >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >> 417x264, 209x132, 105x66 >> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >> Checksum=64262 >> NoData Value=0 >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >> 417x264, 209x132, 105x66 >> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >> field, ignoring and calculating from imagelength >> >> Stephen Woodbridge wrote: >>> Even, >>> >>> I ran gdalinfo -checksum on all 51GB of images and none of them reported >>> any errors. And none of the images are compressed. >>> >>> I'm using Debian Lenny packages. There is an ldd output below. >>> >>> $ uname -a >>> Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 >>> GNU/Linux >>> >>> $ gdalinfo --version >>> GDAL 1.5.2, released 2008/05/29 >>> >>> $ apt-cache show libtiff4 >>> Package: libtiff4 >>> Priority: optional >>> Section: libs >>> Installed-Size: 484 >>> Maintainer: Jay Berkenbilt >>> Architecture: amd64 >>> Source: tiff >>> Version: 3.8.2-11 >>> Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) >>> Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb >>> Size: 169372 >>> MD5sum: 8c0019eef3a752760dca8f14c80c3820 >>> SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f >>> SHA256: e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 >>> Description: Tag Image File Format (TIFF) library >>> libtiff is a library providing support for the Tag Image File Format >>> (TIFF), a widely used format for storing image data. This package >>> includes the shared library. >>> Homepage: http://libtiff.maptools.org >>> Tag: role::shared-lib, works-with::image:raster >>> >>> A typical gdalinfo on one of the files is: >>> >>> $ gdalinfo -checksum n-41-25_0-0.tif >>> Files: n-41-25_0-0.tif >>> Size is 27192, 18091 >>> Coordinate System is: >>> GEOGCS["WGS 84", >>> DATUM["WGS_1984", >>> SPHEROID["WGS 84",6378137,298.2572235630016, >>> AUTHORITY["EPSG","7030"]], >>> AUTHORITY["EPSG","6326"]], >>> PRIMEM["Greenwich",0], >>> UNIT["degree",0.0174532925199433], >>> AUTHORITY["EPSG","4326"]] >>> Origin = (59.228401534356898,27.479955940770701) >>> Pixel Size = (0.000138699063483,-0.000138699063483) >>> Metadata: >>> AREA_OR_POINT=Area >>> Image Structure Metadata: >>> INTERLEAVE=PIXEL >>> Corner Coordinates: >>> Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) >>> Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) >>> Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) >>> Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) >>> Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) >>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>> Checksum=29566 >>> NoData Value=0 >>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>> Checksum=34905 >>> NoData Value=0 >>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>> Checksum=24337 >>> NoData Value=0 >>> >>> >>> woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo >>> linux-vdso.so.1 => (0x00007fff937fe000) >>> libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 >>> (0x00002ac017605000) >>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) >>> libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) >>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) >>> libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) >>> libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) >>> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00002ac018adf000) >>> libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00002ac018d55000) >>> libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 >>> (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 >>> (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 >>> (0x00002ac0193e7000) >>> libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) >>> libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 >>> (0x00002ac019c3a000) >>> libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) >>> libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) >>> libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) >>> libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) >>> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) >>> libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) >>> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) >>> libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) >>> libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) >>> libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) >>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) >>> librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) >>> libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) >>> libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 >>> (0x00002ac01bba1000) >>> libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 >>> (0x00002ac01bde0000) >>> /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) >>> libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so >>> (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 >>> (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 >>> (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 >>> (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 >>> (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 >>> (0x00002ac01d99a000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 >>> (0x00002ac01dbec000) >>> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) >>> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) >>> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 >>> (0x00002ac01e42c000) >>> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) >>> libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 >>> (0x00002ac01e890000) >>> libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) >>> liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 >>> (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 >>> (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002ac01f1ce000) >>> libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 >>> (0x00002ac01f3e6000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 >>> (0x00002ac01f60d000) >>> libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) >>> libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) >>> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) >>> libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) >>> libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 >>> (0x00002ac020056000) >>> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00002ac02015a000) >>> >>> Even Rouault wrote: >>>> Hi, >>>> >>>> no those warnings don't sound good at all ! The number of overviews >>>> should be fine too. >>>> >>>> Could you precise the version of GDAL you're using and if you have >>>> built with internal libtiff or external libtiff ? >>>> (Such warnings could happen with older libtiff, especially with TIFF >>>> compression) >>>> Could you just check gdalinfo -checksum file.tif on your original file >>>> before running gdaladdo and check that it doesn't throw similar errors ? >>>> >>>> Best regards, >>>> Even >>>> >>>> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit : >>>>> Hi, >>>>> >>>>> I just created a bunch of tif files from a mrsid file and when I use >>>>> gdaladdo file.tif 2 4 8 16 32 64 128 256 >>>>> >>>>> I get over a 1000 errors like: >>>>> >>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>>>> 1536 >>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 >>>>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 >>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>>>> 1664 >>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 >>>>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 >>>>> >>>>> >>>>> >>>>> Is this because of the number of overviews I requested? ot something >>>>> else? Is it safe to ignore these? >>>>> >>>>> -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 > > From even.rouault at mines-paris.org Sat Mar 21 05:21:11 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sat Mar 21 05:21:30 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C45A9A.5090208@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> <200903202224.13322.even.rouault@mines-paris.org> <49C45A9A.5090208@swoodbridge.com> Message-ID: <200903211021.14562.even.rouault@mines-paris.org> Steve, yes you're looking at the correct site. None of those versions have been released yet. But they are both in a state close to being released. For the test, I didn't use the .tar.gz but the CVS version. To get libtiff 3.9 CVS head (Extract from http://www.remotesensing.org/libtiff/) : export CVSROOT=:pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot cvs login (use empty password) cvs checkout -r branch-3-9 libtiff Note that you cannot use directly libtiff 4.0 as a replacement of the libtiff 3.X series as there have been changes to the API/ABI that make it incompatible with a GDAL compiled against libtiff 3.X. If you want to use libtiff 4.0 (mainly to get BigTIFF support), you'd need to compile GDAL from the source against it (or just build GDAL with internal libtiff support, which has been sync'ed with libtiff 4.0 development since GDAL 1.5). Even Le Saturday 21 March 2009 04:10:18 Stephen Woodbridge, vous avez ?crit?: > Even, > > Thank you for all the extra work you did, I very much appreciate it. > Looks like I get to spend my weekend trying to rebuild the Lenny Source > package for libtiff based on 3.9.0. > > This is probably not the right list, but looking at: > > ftp://ftp.remotesensing.org/pub/libtiff/ > > 3.9.0 looks to be beta since 7/13/2007 > 4.0.0 looks to be beta since 1/21/2009 > > Did these ever get released? Am I looking at the correct site? > > Thanks again for you assistance. > > -Steve > > Even Rouault wrote: > > Stephen, > > > > I've managed to reproduce your issue with GDAL 1.5 compiled with libtiff > > 3.8.2 (and I'm not so surprised, as I remember that it was a known > > issue). But when built with internal libtiff or against external libtiff > > 3.9.0 (CVS head version), it works fine. So it is due to some bug in > > libtiff 3.8.2. So you could either compile GDAL with internal libtiff > > support, or just build libtiff 3.9.0 and trick GDAL to link against it by > > using LD_LIBRARY_PATH. You'll need to create a symlink from the generated > > libtiff.so to libtiff.so.4 which is expected by the Debian libgdal.so. > > I've tried that and it works fine. > > > > Best regards, > > > > Even > > > > Le Friday 20 March 2009 04:43:39 Stephen Woodbridge, vous avez ?crit : > >> Even, > >> > >> So I just happened to have made a backup copy of the tif files before > >> adding the overviews. And as a said, all the files without overviews did > >> not report errors with gdalinfo -checksum file.tif. I also check all > >> the files with the overviews and some of them, not all, do report > >> errors. I'm seeing reported: > >> > >> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" > >> field, ignoring and calculating from imagelength > >> > >> on some of the files that have overviews added. I went back and checked > >> output from the gdaladdo and it shows up in places there also. > >> > >> This is the file without overviews added: > >> > >> woodbri@mappy:/u/leaddog-200903013/af-bck$ gdalinfo -checksum > >> n-41-35_0-0.tif > >> Driver: GTiff/GeoTIFF > >> Files: n-41-35_0-0.tif > >> Size is 26688, 16853 > >> Coordinate System is: > >> GEOGCS["WGS 84", > >> DATUM["WGS_1984", > >> SPHEROID["WGS 84",6378137,298.2572235630016, > >> AUTHORITY["EPSG","7030"]], > >> AUTHORITY["EPSG","6326"]], > >> PRIMEM["Greenwich",0], > >> UNIT["degree",0.0174532925199433], > >> AUTHORITY["EPSG","4326"]] > >> Origin = (59.025339626823701,37.469898080618897) > >> Pixel Size = (0.000148923698721,-0.000148923698721) > >> Metadata: > >> AREA_OR_POINT=Area > >> Image Structure Metadata: > >> INTERLEAVE=PIXEL > >> Corner Coordinates: > >> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) > >> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) > >> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) > >> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) > >> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) > >> Band 1 Block=256x256 Type=Byte, ColorInterp=Red > >> Checksum=4400 > >> NoData Value=0 > >> Band 2 Block=256x256 Type=Byte, ColorInterp=Green > >> Checksum=18333 > >> NoData Value=0 > >> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > >> Checksum=64262 > >> NoData Value=0 > >> > >> And here is the samefile after adding the overviews: > >> > >> woodbri@mappy:/u/leaddog-200903013/af-bck$ cd ../af > >> woodbri@mappy:/u/leaddog-200903013/af$ gdalinfo -checksum > >> n-41-35_0-0.tif Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong > >> "StripByteCounts" field, ignoring and calculating from imagelength > >> Driver: GTiff/GeoTIFF > >> Files: n-41-35_0-0.tif > >> Size is 26688, 16853 > >> Coordinate System is: > >> GEOGCS["WGS 84", > >> DATUM["WGS_1984", > >> SPHEROID["WGS 84",6378137,298.2572235630016, > >> AUTHORITY["EPSG","7030"]], > >> AUTHORITY["EPSG","6326"]], > >> PRIMEM["Greenwich",0], > >> UNIT["degree",0.0174532925199433], > >> AUTHORITY["EPSG","4326"]] > >> Origin = (59.025339626823701,37.469898080618897) > >> Pixel Size = (0.000148923698721,-0.000148923698721) > >> Metadata: > >> AREA_OR_POINT=Area > >> Image Structure Metadata: > >> INTERLEAVE=PIXEL > >> Corner Coordinates: > >> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) > >> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) > >> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) > >> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) > >> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) > >> Band 1 Block=256x256 Type=Byte, ColorInterp=Red > >> Checksum=4400 > >> NoData Value=0 > >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > >> 417x264, 209x132, 105x66 > >> Band 2 Block=256x256 Type=Byte, ColorInterp=Green > >> Checksum=18333 > >> NoData Value=0 > >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > >> 417x264, 209x132, 105x66 > >> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > >> Checksum=64262 > >> NoData Value=0 > >> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, > >> 417x264, 209x132, 105x66 > >> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" > >> field, ignoring and calculating from imagelength > >> > >> Stephen Woodbridge wrote: > >>> Even, > >>> > >>> I ran gdalinfo -checksum on all 51GB of images and none of them > >>> reported any errors. And none of the images are compressed. > >>> > >>> I'm using Debian Lenny packages. There is an ldd output below. > >>> > >>> $ uname -a > >>> Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 > >>> GNU/Linux > >>> > >>> $ gdalinfo --version > >>> GDAL 1.5.2, released 2008/05/29 > >>> > >>> $ apt-cache show libtiff4 > >>> Package: libtiff4 > >>> Priority: optional > >>> Section: libs > >>> Installed-Size: 484 > >>> Maintainer: Jay Berkenbilt > >>> Architecture: amd64 > >>> Source: tiff > >>> Version: 3.8.2-11 > >>> Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) > >>> Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb > >>> Size: 169372 > >>> MD5sum: 8c0019eef3a752760dca8f14c80c3820 > >>> SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f > >>> SHA256: > >>> e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 > >>> Description: Tag Image File Format (TIFF) library > >>> libtiff is a library providing support for the Tag Image File Format > >>> (TIFF), a widely used format for storing image data. This package > >>> includes the shared library. > >>> Homepage: http://libtiff.maptools.org > >>> Tag: role::shared-lib, works-with::image:raster > >>> > >>> A typical gdalinfo on one of the files is: > >>> > >>> $ gdalinfo -checksum n-41-25_0-0.tif > >>> Files: n-41-25_0-0.tif > >>> Size is 27192, 18091 > >>> Coordinate System is: > >>> GEOGCS["WGS 84", > >>> DATUM["WGS_1984", > >>> SPHEROID["WGS 84",6378137,298.2572235630016, > >>> AUTHORITY["EPSG","7030"]], > >>> AUTHORITY["EPSG","6326"]], > >>> PRIMEM["Greenwich",0], > >>> UNIT["degree",0.0174532925199433], > >>> AUTHORITY["EPSG","4326"]] > >>> Origin = (59.228401534356898,27.479955940770701) > >>> Pixel Size = (0.000138699063483,-0.000138699063483) > >>> Metadata: > >>> AREA_OR_POINT=Area > >>> Image Structure Metadata: > >>> INTERLEAVE=PIXEL > >>> Corner Coordinates: > >>> Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) > >>> Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) > >>> Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) > >>> Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) > >>> Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) > >>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red > >>> Checksum=29566 > >>> NoData Value=0 > >>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green > >>> Checksum=34905 > >>> NoData Value=0 > >>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue > >>> Checksum=24337 > >>> NoData Value=0 > >>> > >>> > >>> woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo > >>> linux-vdso.so.1 => (0x00007fff937fe000) > >>> libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 > >>> (0x00002ac017605000) > >>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) > >>> libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) > >>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) > >>> libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) > >>> libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) > >>> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 > >>> (0x00002ac018adf000) libodbc.so.1 => /usr/lib/libodbc.so.1 > >>> (0x00002ac018d55000) libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 > >>> (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 > >>> (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 > >>> (0x00002ac0193e7000) > >>> libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) > >>> libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 > >>> (0x00002ac019c3a000) > >>> libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) > >>> libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) > >>> libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) > >>> libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) > >>> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) > >>> libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) > >>> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) > >>> libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) > >>> libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) > >>> libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) > >>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) > >>> librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) > >>> libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) > >>> libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 > >>> (0x00002ac01bba1000) > >>> libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 > >>> (0x00002ac01bde0000) > >>> /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) > >>> libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so > >>> (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 > >>> (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 > >>> (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 > >>> (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 > >>> (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 > >>> (0x00002ac01d99a000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 > >>> (0x00002ac01dbec000) > >>> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) > >>> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) > >>> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 > >>> (0x00002ac01e42c000) > >>> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) > >>> libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 > >>> (0x00002ac01e890000) > >>> libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) > >>> liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 > >>> (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 > >>> (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 > >>> (0x00002ac01f1ce000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 > >>> (0x00002ac01f3e6000) libkrb5support.so.0 => > >>> /usr/lib/libkrb5support.so.0 (0x00002ac01f60d000) > >>> libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) > >>> libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) > >>> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) > >>> libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) > >>> libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 > >>> (0x00002ac020056000) > >>> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 > >>> (0x00002ac02015a000) > >>> > >>> Even Rouault wrote: > >>>> Hi, > >>>> > >>>> no those warnings don't sound good at all ! The number of overviews > >>>> should be fine too. > >>>> > >>>> Could you precise the version of GDAL you're using and if you have > >>>> built with internal libtiff or external libtiff ? > >>>> (Such warnings could happen with older libtiff, especially with TIFF > >>>> compression) > >>>> Could you just check gdalinfo -checksum file.tif on your original file > >>>> before running gdaladdo and check that it doesn't throw similar errors > >>>> ? > >>>> > >>>> Best regards, > >>>> Even > >>>> > >>>> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez ?crit : > >>>>> Hi, > >>>>> > >>>>> I just created a bunch of tif files from a mrsid file and when I use > >>>>> gdaladdo file.tif 2 4 8 16 32 64 128 256 > >>>>> > >>>>> I get over a 1000 errors like: > >>>>> > >>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline > >>>>> 1536 > >>>>> ERROR 1: TIFFReadEncodedTile() failed. > >>>>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 > >>>>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 > >>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline > >>>>> 1664 > >>>>> ERROR 1: TIFFReadEncodedTile() failed. > >>>>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 > >>>>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 > >>>>> > >>>>> > >>>>> > >>>>> Is this because of the number of overviews I requested? ot something > >>>>> else? Is it safe to ignore these? > >>>>> > >>>>> -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 From markusin at yahoo.de Sat Mar 21 07:22:29 2009 From: markusin at yahoo.de (Markus) Date: Sat Mar 21 07:29:12 2009 Subject: [gdal-dev] EPSG code question Message-ID: <225502.84623.qm@web27004.mail.ukl.yahoo.com> Hi all, I have an own wkt format similar to EPSG:25832. Now I want to use ogr2ogr to import the shape file into oracle spatial. I already added a new entry (EPSG:258320) in the crs table. When I am trying now to import I get the following error message: ERROR 6: EPSG PCS/GCS code 258320 not found in EPSG support files. Is this a valid EPSG coordinate system? my import command is: ogr2ogr -f OCI OCI:username/passwd@orcl11:mytable ./myshapefile.shp -s_srs EPSG:258320 Is there now a way to import the files anyway or do I need to add the epsg code into the file pcs.csv? If yes is there a procedure/guidelines how to add such a code? thanks for your help Markus From even.rouault at mines-paris.org Sat Mar 21 07:59:15 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sat Mar 21 07:59:24 2009 Subject: [gdal-dev] EPSG code question In-Reply-To: <225502.84623.qm@web27004.mail.ukl.yahoo.com> References: <225502.84623.qm@web27004.mail.ukl.yahoo.com> Message-ID: <200903211259.15718.even.rouault@mines-paris.org> Markus, Yes, you probably need to insert a new definition ito pcs.csv / gcs.csv. I believe the CSV files in $(GDAL_ROOT)/data come from libgeotiff and are derived from the EPSG database. See the README in http://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv But if you don't want to hack those CSV files, maybe the simpler solution would be to specify your projection as a WKT string instead of an EPSG code. That way, GDAL wouldn't have to query the CSV files in order to build the WKT string (GDAL/OGR internal model for storing SRS is a tree based on WKT representation). Best regards, Even From woodbri at swoodbridge.com Sat Mar 21 12:28:53 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Sat Mar 21 11:27:26 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <200903211021.14562.even.rouault@mines-paris.org> References: <49C2BC21.8030901@swoodbridge.com> <200903202224.13322.even.rouault@mines-paris.org> <49C45A9A.5090208@swoodbridge.com> <200903211021.14562.even.rouault@mines-paris.org> Message-ID: <49C515C5.6040807@swoodbridge.com> Even, It belatedly dawned on me that just rebuilding the gdal package to use the internal libtiff would be MUCH easier the messing around with the libtiff packages. In case anyone else needs to do this on debian: cd /usr/src apt-src install libgdal1-1.5.0 cd gdal-1.5.2 vi debian/rules # added to configure: # --with-libtiff=internal # --with-ecw=no # --with-mrsid=no # --with-jp2mrsid=no dpkg-buildpackage -rfakeroot cd .. sudo dpkg -i gdal-bin_1.5.2-3_amd64.deb libgdal-doc_1.5.2-3_all.deb libgdal-perl_1.5.2-3_amd64.deb libgdal1-1.5.0_1.5.2-3_amd64.deb libgdal1-dev_1.5.2-3_amd64.deb I had to disable ecw and mrsid packages because I have them built as loadable modules using Alan Boudreault packages from mapgears.com otherwise the dpkg-buildpackage errored out because it found the libNCSUtil... which is not part of a package. Anyway this builds and installs great and ldd /usr/bin/gdalinfo does not pull in the system libtiff. I'll test this as soon as I can delete anc copy, and run gdaladdo on about 51 GB of files. Hopefully I will not have issues to report :) Thank you, -Steve Even Rouault wrote: > Steve, > > yes you're looking at the correct site. None of those versions have been > released yet. But they are both in a state close to being released. > > For the test, I didn't use the .tar.gz but the CVS version. > To get libtiff 3.9 CVS head (Extract from > http://www.remotesensing.org/libtiff/) : > > export CVSROOT=:pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot > cvs login > (use empty password) > cvs checkout -r branch-3-9 libtiff > > Note that you cannot use directly libtiff 4.0 as a replacement of the libtiff > 3.X series as there have been changes to the API/ABI that make it > incompatible with a GDAL compiled against libtiff 3.X. If you want to use > libtiff 4.0 (mainly to get BigTIFF support), you'd need to compile GDAL from > the source against it (or just build GDAL with internal libtiff support, > which has been sync'ed with libtiff 4.0 development since GDAL 1.5). > > Even > > Le Saturday 21 March 2009 04:10:18 Stephen Woodbridge, vous avez ?crit : >> Even, >> >> Thank you for all the extra work you did, I very much appreciate it. >> Looks like I get to spend my weekend trying to rebuild the Lenny Source >> package for libtiff based on 3.9.0. >> >> This is probably not the right list, but looking at: >> >> ftp://ftp.remotesensing.org/pub/libtiff/ >> >> 3.9.0 looks to be beta since 7/13/2007 >> 4.0.0 looks to be beta since 1/21/2009 >> >> Did these ever get released? Am I looking at the correct site? >> >> Thanks again for you assistance. >> >> -Steve >> >> Even Rouault wrote: >>> Stephen, >>> >>> I've managed to reproduce your issue with GDAL 1.5 compiled with libtiff >>> 3.8.2 (and I'm not so surprised, as I remember that it was a known >>> issue). But when built with internal libtiff or against external libtiff >>> 3.9.0 (CVS head version), it works fine. So it is due to some bug in >>> libtiff 3.8.2. So you could either compile GDAL with internal libtiff >>> support, or just build libtiff 3.9.0 and trick GDAL to link against it by >>> using LD_LIBRARY_PATH. You'll need to create a symlink from the generated >>> libtiff.so to libtiff.so.4 which is expected by the Debian libgdal.so. >>> I've tried that and it works fine. >>> >>> Best regards, >>> >>> Even >>> >>> Le Friday 20 March 2009 04:43:39 Stephen Woodbridge, vous avez ?crit : >>>> Even, >>>> >>>> So I just happened to have made a backup copy of the tif files before >>>> adding the overviews. And as a said, all the files without overviews did >>>> not report errors with gdalinfo -checksum file.tif. I also check all >>>> the files with the overviews and some of them, not all, do report >>>> errors. I'm seeing reported: >>>> >>>> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >>>> field, ignoring and calculating from imagelength >>>> >>>> on some of the files that have overviews added. I went back and checked >>>> output from the gdaladdo and it shows up in places there also. >>>> >>>> This is the file without overviews added: >>>> >>>> woodbri@mappy:/u/leaddog-200903013/af-bck$ gdalinfo -checksum >>>> n-41-35_0-0.tif >>>> Driver: GTiff/GeoTIFF >>>> Files: n-41-35_0-0.tif >>>> Size is 26688, 16853 >>>> Coordinate System is: >>>> GEOGCS["WGS 84", >>>> DATUM["WGS_1984", >>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>> AUTHORITY["EPSG","7030"]], >>>> AUTHORITY["EPSG","6326"]], >>>> PRIMEM["Greenwich",0], >>>> UNIT["degree",0.0174532925199433], >>>> AUTHORITY["EPSG","4326"]] >>>> Origin = (59.025339626823701,37.469898080618897) >>>> Pixel Size = (0.000148923698721,-0.000148923698721) >>>> Metadata: >>>> AREA_OR_POINT=Area >>>> Image Structure Metadata: >>>> INTERLEAVE=PIXEL >>>> Corner Coordinates: >>>> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) >>>> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) >>>> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) >>>> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) >>>> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) >>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>> Checksum=4400 >>>> NoData Value=0 >>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>> Checksum=18333 >>>> NoData Value=0 >>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>> Checksum=64262 >>>> NoData Value=0 >>>> >>>> And here is the samefile after adding the overviews: >>>> >>>> woodbri@mappy:/u/leaddog-200903013/af-bck$ cd ../af >>>> woodbri@mappy:/u/leaddog-200903013/af$ gdalinfo -checksum >>>> n-41-35_0-0.tif Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong >>>> "StripByteCounts" field, ignoring and calculating from imagelength >>>> Driver: GTiff/GeoTIFF >>>> Files: n-41-35_0-0.tif >>>> Size is 26688, 16853 >>>> Coordinate System is: >>>> GEOGCS["WGS 84", >>>> DATUM["WGS_1984", >>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>> AUTHORITY["EPSG","7030"]], >>>> AUTHORITY["EPSG","6326"]], >>>> PRIMEM["Greenwich",0], >>>> UNIT["degree",0.0174532925199433], >>>> AUTHORITY["EPSG","4326"]] >>>> Origin = (59.025339626823701,37.469898080618897) >>>> Pixel Size = (0.000148923698721,-0.000148923698721) >>>> Metadata: >>>> AREA_OR_POINT=Area >>>> Image Structure Metadata: >>>> INTERLEAVE=PIXEL >>>> Corner Coordinates: >>>> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, 37d28'11.63"N) >>>> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, 34d57'36.31"N) >>>> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, 37d28'11.63"N) >>>> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, 34d57'36.31"N) >>>> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, 36d12'53.97"N) >>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>> Checksum=4400 >>>> NoData Value=0 >>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>> 417x264, 209x132, 105x66 >>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>> Checksum=18333 >>>> NoData Value=0 >>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>> 417x264, 209x132, 105x66 >>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>> Checksum=64262 >>>> NoData Value=0 >>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>> 417x264, 209x132, 105x66 >>>> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >>>> field, ignoring and calculating from imagelength >>>> >>>> Stephen Woodbridge wrote: >>>>> Even, >>>>> >>>>> I ran gdalinfo -checksum on all 51GB of images and none of them >>>>> reported any errors. And none of the images are compressed. >>>>> >>>>> I'm using Debian Lenny packages. There is an ldd output below. >>>>> >>>>> $ uname -a >>>>> Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 >>>>> GNU/Linux >>>>> >>>>> $ gdalinfo --version >>>>> GDAL 1.5.2, released 2008/05/29 >>>>> >>>>> $ apt-cache show libtiff4 >>>>> Package: libtiff4 >>>>> Priority: optional >>>>> Section: libs >>>>> Installed-Size: 484 >>>>> Maintainer: Jay Berkenbilt >>>>> Architecture: amd64 >>>>> Source: tiff >>>>> Version: 3.8.2-11 >>>>> Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) >>>>> Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb >>>>> Size: 169372 >>>>> MD5sum: 8c0019eef3a752760dca8f14c80c3820 >>>>> SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f >>>>> SHA256: >>>>> e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 >>>>> Description: Tag Image File Format (TIFF) library >>>>> libtiff is a library providing support for the Tag Image File Format >>>>> (TIFF), a widely used format for storing image data. This package >>>>> includes the shared library. >>>>> Homepage: http://libtiff.maptools.org >>>>> Tag: role::shared-lib, works-with::image:raster >>>>> >>>>> A typical gdalinfo on one of the files is: >>>>> >>>>> $ gdalinfo -checksum n-41-25_0-0.tif >>>>> Files: n-41-25_0-0.tif >>>>> Size is 27192, 18091 >>>>> Coordinate System is: >>>>> GEOGCS["WGS 84", >>>>> DATUM["WGS_1984", >>>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>>> AUTHORITY["EPSG","7030"]], >>>>> AUTHORITY["EPSG","6326"]], >>>>> PRIMEM["Greenwich",0], >>>>> UNIT["degree",0.0174532925199433], >>>>> AUTHORITY["EPSG","4326"]] >>>>> Origin = (59.228401534356898,27.479955940770701) >>>>> Pixel Size = (0.000138699063483,-0.000138699063483) >>>>> Metadata: >>>>> AREA_OR_POINT=Area >>>>> Image Structure Metadata: >>>>> INTERLEAVE=PIXEL >>>>> Corner Coordinates: >>>>> Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, 27d28'47.84"N) >>>>> Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, 24d58'14.70"N) >>>>> Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, 27d28'47.84"N) >>>>> Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, 24d58'14.70"N) >>>>> Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, 26d13'31.27"N) >>>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>>> Checksum=29566 >>>>> NoData Value=0 >>>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>>> Checksum=34905 >>>>> NoData Value=0 >>>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>>> Checksum=24337 >>>>> NoData Value=0 >>>>> >>>>> >>>>> woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo >>>>> linux-vdso.so.1 => (0x00007fff937fe000) >>>>> libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 >>>>> (0x00002ac017605000) >>>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac017dd4000) >>>>> libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) >>>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) >>>>> libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) >>>>> libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 (0x00002ac0188ce000) >>>>> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 >>>>> (0x00002ac018adf000) libodbc.so.1 => /usr/lib/libodbc.so.1 >>>>> (0x00002ac018d55000) libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 >>>>> (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 >>>>> (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 >>>>> (0x00002ac0193e7000) >>>>> libjasper.so.1 => /usr/lib/libjasper.so.1 (0x00002ac0199e0000) >>>>> libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 >>>>> (0x00002ac019c3a000) >>>>> libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) >>>>> libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) >>>>> libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 (0x00002ac01a43a000) >>>>> libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) >>>>> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) >>>>> libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) >>>>> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) >>>>> libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 (0x00002ac01af06000) >>>>> libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) >>>>> libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) >>>>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) >>>>> librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) >>>>> libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) >>>>> libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 >>>>> (0x00002ac01bba1000) >>>>> libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 >>>>> (0x00002ac01bde0000) >>>>> /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) >>>>> libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so >>>>> (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 >>>>> (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 >>>>> (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 >>>>> (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 >>>>> (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 >>>>> (0x00002ac01d99a000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 >>>>> (0x00002ac01dbec000) >>>>> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) >>>>> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) >>>>> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 >>>>> (0x00002ac01e42c000) >>>>> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) >>>>> libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 >>>>> (0x00002ac01e890000) >>>>> libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) >>>>> liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 >>>>> (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 >>>>> (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 >>>>> (0x00002ac01f1ce000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 >>>>> (0x00002ac01f3e6000) libkrb5support.so.0 => >>>>> /usr/lib/libkrb5support.so.0 (0x00002ac01f60d000) >>>>> libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002ac01f815000) >>>>> libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) >>>>> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) >>>>> libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) >>>>> libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 >>>>> (0x00002ac020056000) >>>>> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 >>>>> (0x00002ac02015a000) >>>>> >>>>> Even Rouault wrote: >>>>>> Hi, >>>>>> >>>>>> no those warnings don't sound good at all ! The number of overviews >>>>>> should be fine too. >>>>>> >>>>>> Could you precise the version of GDAL you're using and if you have >>>>>> built with internal libtiff or external libtiff ? >>>>>> (Such warnings could happen with older libtiff, especially with TIFF >>>>>> compression) >>>>>> Could you just check gdalinfo -checksum file.tif on your original file >>>>>> before running gdaladdo and check that it doesn't throw similar errors >>>>>> ? >>>>>> >>>>>> Best regards, >>>>>> Even >>>>>> >>>>>> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez > ?crit : >>>>>>> Hi, >>>>>>> >>>>>>> I just created a bunch of tif files from a mrsid file and when I use >>>>>>> gdaladdo file.tif 2 4 8 16 32 64 128 256 >>>>>>> >>>>>>> I get over a 1000 errors like: >>>>>>> >>>>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>>>>>> 1536 >>>>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>>>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 >>>>>>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 >>>>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for scanline >>>>>>> 1664 >>>>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>>>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 >>>>>>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this because of the number of overviews I requested? ot something >>>>>>> else? Is it safe to ignore these? >>>>>>> >>>>>>> -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 > > From davidgshi at yahoo.co.uk Sat Mar 21 13:11:41 2009 From: davidgshi at yahoo.co.uk (David Shi) Date: Sat Mar 21 13:18:25 2009 Subject: [gdal-dev] Looking for a Python script to turn GML into ESRI's .shp file package Message-ID: <71651.59081.qm@web26303.mail.ukl.yahoo.com> Hello. I am looking for a Python script to turn WFS server's GML into ESRI's .shp file package. Can?anyone help? ? Regards. ? David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090321/c32dfd86/attachment.html From woodbri at swoodbridge.com Sat Mar 21 20:33:55 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Sat Mar 21 19:32:27 2009 Subject: [gdal-dev] gdal create tif, errors with gdaladdo In-Reply-To: <49C515C5.6040807@swoodbridge.com> References: <49C2BC21.8030901@swoodbridge.com> <200903202224.13322.even.rouault@mines-paris.org> <49C45A9A.5090208@swoodbridge.com> <200903211021.14562.even.rouault@mines-paris.org> <49C515C5.6040807@swoodbridge.com> Message-ID: <49C58773.2040407@swoodbridge.com> Just to report back the fix below solved my problem. Reprocessed all the imagery and no errors reported, and no nasty artifacts on the images. Many thank to Even for his copious help and to the whole GDAL team. -Steve Stephen Woodbridge wrote: > Even, > > It belatedly dawned on me that just rebuilding the gdal package to use > the internal libtiff would be MUCH easier the messing around with the > libtiff packages. > > In case anyone else needs to do this on debian: > > cd /usr/src > apt-src install libgdal1-1.5.0 > cd gdal-1.5.2 > vi debian/rules > # added to configure: > # --with-libtiff=internal > # --with-ecw=no > # --with-mrsid=no > # --with-jp2mrsid=no > dpkg-buildpackage -rfakeroot > cd .. > sudo dpkg -i gdal-bin_1.5.2-3_amd64.deb libgdal-doc_1.5.2-3_all.deb > libgdal-perl_1.5.2-3_amd64.deb libgdal1-1.5.0_1.5.2-3_amd64.deb > libgdal1-dev_1.5.2-3_amd64.deb > > I had to disable ecw and mrsid packages because I have them built as > loadable modules using Alan Boudreault packages from mapgears.com > otherwise the dpkg-buildpackage errored out because it found the > libNCSUtil... which is not part of a package. > > Anyway this builds and installs great and ldd /usr/bin/gdalinfo does not > pull in the system libtiff. I'll test this as soon as I can delete anc > copy, and run gdaladdo on about 51 GB of files. Hopefully I will not > have issues to report :) > > Thank you, > -Steve > > Even Rouault wrote: >> Steve, >> >> yes you're looking at the correct site. None of those versions have >> been released yet. But they are both in a state close to being released. >> >> For the test, I didn't use the .tar.gz but the CVS version. To get >> libtiff 3.9 CVS head (Extract from >> http://www.remotesensing.org/libtiff/) : >> >> export CVSROOT=:pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot >> cvs login >> (use empty password) >> cvs checkout -r branch-3-9 libtiff >> >> Note that you cannot use directly libtiff 4.0 as a replacement of the >> libtiff 3.X series as there have been changes to the API/ABI that make >> it incompatible with a GDAL compiled against libtiff 3.X. If you want >> to use libtiff 4.0 (mainly to get BigTIFF support), you'd need to >> compile GDAL from the source against it (or just build GDAL with >> internal libtiff support, which has been sync'ed with libtiff 4.0 >> development since GDAL 1.5). >> >> Even >> >> Le Saturday 21 March 2009 04:10:18 Stephen Woodbridge, vous avez ?crit : >>> Even, >>> >>> Thank you for all the extra work you did, I very much appreciate it. >>> Looks like I get to spend my weekend trying to rebuild the Lenny Source >>> package for libtiff based on 3.9.0. >>> >>> This is probably not the right list, but looking at: >>> >>> ftp://ftp.remotesensing.org/pub/libtiff/ >>> >>> 3.9.0 looks to be beta since 7/13/2007 >>> 4.0.0 looks to be beta since 1/21/2009 >>> >>> Did these ever get released? Am I looking at the correct site? >>> >>> Thanks again for you assistance. >>> >>> -Steve >>> >>> Even Rouault wrote: >>>> Stephen, >>>> >>>> I've managed to reproduce your issue with GDAL 1.5 compiled with >>>> libtiff >>>> 3.8.2 (and I'm not so surprised, as I remember that it was a known >>>> issue). But when built with internal libtiff or against external >>>> libtiff >>>> 3.9.0 (CVS head version), it works fine. So it is due to some bug in >>>> libtiff 3.8.2. So you could either compile GDAL with internal libtiff >>>> support, or just build libtiff 3.9.0 and trick GDAL to link against >>>> it by >>>> using LD_LIBRARY_PATH. You'll need to create a symlink from the >>>> generated >>>> libtiff.so to libtiff.so.4 which is expected by the Debian libgdal.so. >>>> I've tried that and it works fine. >>>> >>>> Best regards, >>>> >>>> Even >>>> >>>> Le Friday 20 March 2009 04:43:39 Stephen Woodbridge, vous avez ?crit : >>>>> Even, >>>>> >>>>> So I just happened to have made a backup copy of the tif files before >>>>> adding the overviews. And as a said, all the files without >>>>> overviews did >>>>> not report errors with gdalinfo -checksum file.tif. I also check all >>>>> the files with the overviews and some of them, not all, do report >>>>> errors. I'm seeing reported: >>>>> >>>>> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >>>>> field, ignoring and calculating from imagelength >>>>> >>>>> on some of the files that have overviews added. I went back and >>>>> checked >>>>> output from the gdaladdo and it shows up in places there also. >>>>> >>>>> This is the file without overviews added: >>>>> >>>>> woodbri@mappy:/u/leaddog-200903013/af-bck$ gdalinfo -checksum >>>>> n-41-35_0-0.tif >>>>> Driver: GTiff/GeoTIFF >>>>> Files: n-41-35_0-0.tif >>>>> Size is 26688, 16853 >>>>> Coordinate System is: >>>>> GEOGCS["WGS 84", >>>>> DATUM["WGS_1984", >>>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>>> AUTHORITY["EPSG","7030"]], >>>>> AUTHORITY["EPSG","6326"]], >>>>> PRIMEM["Greenwich",0], >>>>> UNIT["degree",0.0174532925199433], >>>>> AUTHORITY["EPSG","4326"]] >>>>> Origin = (59.025339626823701,37.469898080618897) >>>>> Pixel Size = (0.000148923698721,-0.000148923698721) >>>>> Metadata: >>>>> AREA_OR_POINT=Area >>>>> Image Structure Metadata: >>>>> INTERLEAVE=PIXEL >>>>> Corner Coordinates: >>>>> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, >>>>> 37d28'11.63"N) >>>>> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, >>>>> 34d57'36.31"N) >>>>> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, >>>>> 37d28'11.63"N) >>>>> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, >>>>> 34d57'36.31"N) >>>>> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, >>>>> 36d12'53.97"N) >>>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>>> Checksum=4400 >>>>> NoData Value=0 >>>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>>> Checksum=18333 >>>>> NoData Value=0 >>>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>>> Checksum=64262 >>>>> NoData Value=0 >>>>> >>>>> And here is the samefile after adding the overviews: >>>>> >>>>> woodbri@mappy:/u/leaddog-200903013/af-bck$ cd ../af >>>>> woodbri@mappy:/u/leaddog-200903013/af$ gdalinfo -checksum >>>>> n-41-35_0-0.tif Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong >>>>> "StripByteCounts" field, ignoring and calculating from imagelength >>>>> Driver: GTiff/GeoTIFF >>>>> Files: n-41-35_0-0.tif >>>>> Size is 26688, 16853 >>>>> Coordinate System is: >>>>> GEOGCS["WGS 84", >>>>> DATUM["WGS_1984", >>>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>>> AUTHORITY["EPSG","7030"]], >>>>> AUTHORITY["EPSG","6326"]], >>>>> PRIMEM["Greenwich",0], >>>>> UNIT["degree",0.0174532925199433], >>>>> AUTHORITY["EPSG","4326"]] >>>>> Origin = (59.025339626823701,37.469898080618897) >>>>> Pixel Size = (0.000148923698721,-0.000148923698721) >>>>> Metadata: >>>>> AREA_OR_POINT=Area >>>>> Image Structure Metadata: >>>>> INTERLEAVE=PIXEL >>>>> Corner Coordinates: >>>>> Upper Left ( 59.0253396, 37.4698981) ( 59d 1'31.22"E, >>>>> 37d28'11.63"N) >>>>> Lower Left ( 59.0253396, 34.9600870) ( 59d 1'31.22"E, >>>>> 34d57'36.31"N) >>>>> Upper Right ( 62.9998153, 37.4698981) ( 62d59'59.34"E, >>>>> 37d28'11.63"N) >>>>> Lower Right ( 62.9998153, 34.9600870) ( 62d59'59.34"E, >>>>> 34d57'36.31"N) >>>>> Center ( 61.0125775, 36.2149925) ( 61d 0'45.28"E, >>>>> 36d12'53.97"N) >>>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>>> Checksum=4400 >>>>> NoData Value=0 >>>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>>> 417x264, 209x132, 105x66 >>>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>>> Checksum=18333 >>>>> NoData Value=0 >>>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>>> 417x264, 209x132, 105x66 >>>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>>> Checksum=64262 >>>>> NoData Value=0 >>>>> Overviews: 13344x8427, 6672x4214, 3336x2107, 1668x1054, 834x527, >>>>> 417x264, 209x132, 105x66 >>>>> Warning 1: TIFFReadDirectory:n-41-35_0-0.tif: Wrong "StripByteCounts" >>>>> field, ignoring and calculating from imagelength >>>>> >>>>> Stephen Woodbridge wrote: >>>>>> Even, >>>>>> >>>>>> I ran gdalinfo -checksum on all 51GB of images and none of them >>>>>> reported any errors. And none of the images are compressed. >>>>>> >>>>>> I'm using Debian Lenny packages. There is an ldd output below. >>>>>> >>>>>> $ uname -a >>>>>> Linux mappy 2.6.23-1-amd64 #1 SMP Fri Oct 12 23:45:48 UTC 2007 x86_64 >>>>>> GNU/Linux >>>>>> >>>>>> $ gdalinfo --version >>>>>> GDAL 1.5.2, released 2008/05/29 >>>>>> >>>>>> $ apt-cache show libtiff4 >>>>>> Package: libtiff4 >>>>>> Priority: optional >>>>>> Section: libs >>>>>> Installed-Size: 484 >>>>>> Maintainer: Jay Berkenbilt >>>>>> Architecture: amd64 >>>>>> Source: tiff >>>>>> Version: 3.8.2-11 >>>>>> Depends: libc6 (>= 2.7-1), libjpeg62, zlib1g (>= 1:1.1.4) >>>>>> Filename: pool/main/t/tiff/libtiff4_3.8.2-11_amd64.deb >>>>>> Size: 169372 >>>>>> MD5sum: 8c0019eef3a752760dca8f14c80c3820 >>>>>> SHA1: 3af8b1abde23f8b55eb840ff874cd0839d340e0f >>>>>> SHA256: >>>>>> e6d69f5e619e97bea1513f080750dc847eab04ef7f3eb9dc26985b2e2f3bcb56 >>>>>> Description: Tag Image File Format (TIFF) library >>>>>> libtiff is a library providing support for the Tag Image File Format >>>>>> (TIFF), a widely used format for storing image data. This package >>>>>> includes the shared library. >>>>>> Homepage: http://libtiff.maptools.org >>>>>> Tag: role::shared-lib, works-with::image:raster >>>>>> >>>>>> A typical gdalinfo on one of the files is: >>>>>> >>>>>> $ gdalinfo -checksum n-41-25_0-0.tif >>>>>> Files: n-41-25_0-0.tif >>>>>> Size is 27192, 18091 >>>>>> Coordinate System is: >>>>>> GEOGCS["WGS 84", >>>>>> DATUM["WGS_1984", >>>>>> SPHEROID["WGS 84",6378137,298.2572235630016, >>>>>> AUTHORITY["EPSG","7030"]], >>>>>> AUTHORITY["EPSG","6326"]], >>>>>> PRIMEM["Greenwich",0], >>>>>> UNIT["degree",0.0174532925199433], >>>>>> AUTHORITY["EPSG","4326"]] >>>>>> Origin = (59.228401534356898,27.479955940770701) >>>>>> Pixel Size = (0.000138699063483,-0.000138699063483) >>>>>> Metadata: >>>>>> AREA_OR_POINT=Area >>>>>> Image Structure Metadata: >>>>>> INTERLEAVE=PIXEL >>>>>> Corner Coordinates: >>>>>> Upper Left ( 59.2284015, 27.4799559) ( 59d13'42.25"E, >>>>>> 27d28'47.84"N) >>>>>> Lower Left ( 59.2284015, 24.9707512) ( 59d13'42.25"E, >>>>>> 24d58'14.70"N) >>>>>> Upper Right ( 62.9999065, 27.4799559) ( 62d59'59.66"E, >>>>>> 27d28'47.84"N) >>>>>> Lower Right ( 62.9999065, 24.9707512) ( 62d59'59.66"E, >>>>>> 24d58'14.70"N) >>>>>> Center ( 61.1141540, 26.2253536) ( 61d 6'50.95"E, >>>>>> 26d13'31.27"N) >>>>>> Band 1 Block=256x256 Type=Byte, ColorInterp=Red >>>>>> Checksum=29566 >>>>>> NoData Value=0 >>>>>> Band 2 Block=256x256 Type=Byte, ColorInterp=Green >>>>>> Checksum=34905 >>>>>> NoData Value=0 >>>>>> Band 3 Block=256x256 Type=Byte, ColorInterp=Blue >>>>>> Checksum=24337 >>>>>> NoData Value=0 >>>>>> >>>>>> >>>>>> woodbri@mappy:/u/leaddog-200903013$ ldd /usr/bin/gdalinfo >>>>>> linux-vdso.so.1 => (0x00007fff937fe000) >>>>>> libgdal1.5.0.so.1 => /usr/lib/libgdal1.5.0.so.1 >>>>>> (0x00002ac017605000) >>>>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 >>>>>> (0x00002ac017dd4000) >>>>>> libm.so.6 => /lib/libm.so.6 (0x00002ac0180e0000) >>>>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac018364000) >>>>>> libc.so.6 => /lib/libc.so.6 (0x00002ac01857b000) >>>>>> libgeos_c.so.1 => /usr/lib/libgeos_c.so.1 >>>>>> (0x00002ac0188ce000) >>>>>> libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 >>>>>> (0x00002ac018adf000) libodbc.so.1 => /usr/lib/libodbc.so.1 >>>>>> (0x00002ac018d55000) libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 >>>>>> (0x00002ac018fb1000) libexpat.so.1 => /usr/lib/libexpat.so.1 >>>>>> (0x00002ac0191be000) libxerces-c.so.28 => /usr/lib/libxerces-c.so.28 >>>>>> (0x00002ac0193e7000) >>>>>> libjasper.so.1 => /usr/lib/libjasper.so.1 >>>>>> (0x00002ac0199e0000) >>>>>> libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 >>>>>> (0x00002ac019c3a000) >>>>>> libmfhdf.so.4 => /usr/lib/libmfhdf.so.4 (0x00002ac019f61000) >>>>>> libdf.so.4 => /usr/lib/libdf.so.4 (0x00002ac01a188000) >>>>>> libogdi.so.3.2 => /usr/lib/libogdi.so.3.2 >>>>>> (0x00002ac01a43a000) >>>>>> libgif.so.4 => /usr/lib/libgif.so.4 (0x00002ac01a65a000) >>>>>> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ac01a862000) >>>>>> libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ac01aa85000) >>>>>> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ac01ace1000) >>>>>> libnetcdf.so.4 => /usr/lib/libnetcdf.so.4 >>>>>> (0x00002ac01af06000) >>>>>> libpq.so.5 => /usr/lib/libpq.so.5 (0x00002ac01b13c000) >>>>>> libz.so.1 => /usr/lib/libz.so.1 (0x00002ac01b360000) >>>>>> libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac01b577000) >>>>>> librt.so.1 => /lib/librt.so.1 (0x00002ac01b794000) >>>>>> libdl.so.2 => /lib/libdl.so.2 (0x00002ac01b99d000) >>>>>> libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 >>>>>> (0x00002ac01bba1000) >>>>>> libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 >>>>>> (0x00002ac01bde0000) >>>>>> /lib64/ld-linux-x86-64.so.2 (0x00002ac0173e8000) >>>>>> libgeos-3.0.0.so => /usr/lib/libgeos-3.0.0.so >>>>>> (0x00002ac01c1eb000) libltdl.so.3 => /usr/lib/libltdl.so.3 >>>>>> (0x00002ac01c53a000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 >>>>>> (0x00002ac01c741000) libicudata.so.38 => /usr/lib/libicudata.so.38 >>>>>> (0x00002ac01ca82000) libproj.so.0 => /usr/lib/libproj.so.0 >>>>>> (0x00002ac01d759000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 >>>>>> (0x00002ac01d99a000) libcrypto.so.0.9.8 => >>>>>> /usr/lib/libcrypto.so.0.9.8 >>>>>> (0x00002ac01dbec000) >>>>>> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002ac01df87000) >>>>>> libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002ac01e228000) >>>>>> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 >>>>>> (0x00002ac01e42c000) >>>>>> libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002ac01e658000) >>>>>> libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 >>>>>> (0x00002ac01e890000) >>>>>> libidn.so.11 => /usr/lib/libidn.so.11 (0x00002ac01eada000) >>>>>> liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 >>>>>> (0x00002ac01ed0c000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 >>>>>> (0x00002ac01ef1b000) libnsl.so.1 => /lib/libnsl.so.1 >>>>>> (0x00002ac01f1ce000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 >>>>>> (0x00002ac01f3e6000) libkrb5support.so.0 => >>>>>> /usr/lib/libkrb5support.so.0 (0x00002ac01f60d000) >>>>>> libkeyutils.so.1 => /lib/libkeyutils.so.1 >>>>>> (0x00002ac01f815000) >>>>>> libresolv.so.2 => /lib/libresolv.so.2 (0x00002ac01fa17000) >>>>>> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00002ac01fc2c000) >>>>>> libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00002ac01fe46000) >>>>>> libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 >>>>>> (0x00002ac020056000) >>>>>> libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 >>>>>> (0x00002ac02015a000) >>>>>> >>>>>> Even Rouault wrote: >>>>>>> Hi, >>>>>>> >>>>>>> no those warnings don't sound good at all ! The number of overviews >>>>>>> should be fine too. >>>>>>> >>>>>>> Could you precise the version of GDAL you're using and if you have >>>>>>> built with internal libtiff or external libtiff ? >>>>>>> (Such warnings could happen with older libtiff, especially with TIFF >>>>>>> compression) >>>>>>> Could you just check gdalinfo -checksum file.tif on your original >>>>>>> file >>>>>>> before running gdaladdo and check that it doesn't throw similar >>>>>>> errors >>>>>>> ? >>>>>>> >>>>>>> Best regards, >>>>>>> Even >>>>>>> >>>>>>> Le Thursday 19 March 2009 22:41:53 Stephen Woodbridge, vous avez >> ?crit : >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just created a bunch of tif files from a mrsid file and when I >>>>>>>> use >>>>>>>> gdaladdo file.tif 2 4 8 16 32 64 128 256 >>>>>>>> >>>>>>>> I get over a 1000 errors like: >>>>>>>> >>>>>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for >>>>>>>> scanline >>>>>>>> 1536 >>>>>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>>>>> ERROR 1: IReadBlock failed at X offset 12, Y offset 7 >>>>>>>> ERROR 1: GetBlockRef failed at X block offset 12, Y block offset 7 >>>>>>>> ERROR 1: n-41-25_0-0.tif:DumpModeDecode: Not enough data for >>>>>>>> scanline >>>>>>>> 1664 >>>>>>>> ERROR 1: TIFFReadEncodedTile() failed. >>>>>>>> ERROR 1: IReadBlock failed at X offset 13, Y offset 7 >>>>>>>> ERROR 1: GetBlockRef failed at X block offset 13, Y block offset 7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is this because of the number of overviews I requested? ot >>>>>>>> something >>>>>>>> else? Is it safe to ignore these? >>>>>>>> >>>>>>>> -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 mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From woodbri at swoodbridge.com Sun Mar 22 00:49:54 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Sat Mar 21 23:48:24 2009 Subject: [gdal-dev] Question on image formats vs performance and quality Message-ID: <49C5C372.2050403@swoodbridge.com> Hi all, I would be interest in you thoughts on comparing MrSID, ECW, and Tiff images from the perspective of image quality and performance. The scenario is I have imagery in MrSID. I typically decompress that into Tiled Tiff uncompressed imagery with overviews. I server it via mapserver and it has reasonable performance. I have not considered serving it from the MrSID files because I don't have a license to compress the files and I would need to reproject them. Also I'm guessing it in not a good idea to uncompress and compress them again as it is lossy and the image degrades. I have never worked with ECW, but I'm concerned about: 1) ECW is 8-bit data only and the source data is 24 bit RGB data 2) how does it compare performance wise to say the tiff images when rendering? Are there other formats that would be good to consider? What are their characteristics? Thanks, -Steve From mohwawang at yahoo.com Sun Mar 22 00:12:39 2009 From: mohwawang at yahoo.com (mohwawang) Date: Sun Mar 22 00:12:42 2009 Subject: [gdal-dev] where can I get ECW SDK Message-ID: <268111.8086.qm@web32604.mail.mud.yahoo.com> Hi all, I tried to get a copy of ECW SDK but failed. Following the instruction from http://www.gdal.org/frmt_ecw.html "ECW SDK available at www.ermapper.com" I ended up with the Erdas website and could not figure out where to get ECW SDK from Erdas website. Anyone knows what's going on? And how to get a copy of ECW SDK? Thanks. Best Regards, Mo Wang From woodbri at swoodbridge.com Sun Mar 22 11:24:39 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Sun Mar 22 10:53:12 2009 Subject: [gdal-dev] where can I get ECW SDK In-Reply-To: <268111.8086.qm@web32604.mail.mud.yahoo.com> References: <268111.8086.qm@web32604.mail.mud.yahoo.com> Message-ID: <49C65837.4090903@swoodbridge.com> mohwawang wrote: > Hi all, > > I tried to get a copy of ECW SDK but failed. Following the > instruction from http://www.gdal.org/frmt_ecw.html "ECW SDK available > at www.ermapper.com" I ended up with the Erdas website and could not > figure out where to get ECW SDK from Erdas website. Anyone knows > what's going on? And how to get a copy of ECW SDK? Thanks. Mo, You have to create an account and login, then go to the Support -> Downloads page and look for the SDK. -Steve W From armin.burger at gmx.net Sun Mar 22 11:25:49 2009 From: armin.burger at gmx.net (Armin Burger) Date: Sun Mar 22 11:25:54 2009 Subject: [gdal-dev] Question on image formats vs performance and quality In-Reply-To: <49C5C372.2050403@swoodbridge.com> References: <49C5C372.2050403@swoodbridge.com> Message-ID: <49C6587D.40307@gmx.net> Steve ECW needs Byte data *per band*, so you could convert 3 Band RGB (every band in byte) data without problems into ECW. Performance is another issue. As long as you do not have problems with disk space I would recommend continuing to use uncompressed Tiff with overviews. In combination with Mapserver/Gdal the best solution regarding performance. In our tests most of the time ~ 1.5 to 2 times faster than ECW, and becoming worse for ECW for more concurrent users. And I think the current ECW license conditions also have issues for serving this format. Other formats like Erdas Imagine are not faster than Tiff and with the BigTiff library also Tiff files can become > 4GB. Reagrds, Armin On 22/03/2009 05:49, Stephen Woodbridge wrote: > Hi all, > > I would be interest in you thoughts on comparing MrSID, ECW, and Tiff > images from the perspective of image quality and performance. > > The scenario is I have imagery in MrSID. I typically decompress that > into Tiled Tiff uncompressed imagery with overviews. I server it via > mapserver and it has reasonable performance. > > I have not considered serving it from the MrSID files because I don't > have a license to compress the files and I would need to reproject them. > Also I'm guessing it in not a good idea to uncompress and compress them > again as it is lossy and the image degrades. > > I have never worked with ECW, but I'm concerned about: > 1) ECW is 8-bit data only and the source data is 24 bit RGB data > 2) how does it compare performance wise to say the tiff images when > rendering? > > Are there other formats that would be good to consider? What are their > characteristics? > > Thanks, > -Steve > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From mohwawang at yahoo.com Sun Mar 22 21:31:32 2009 From: mohwawang at yahoo.com (mohwawang) Date: Sun Mar 22 21:31:33 2009 Subject: [gdal-dev] where can I get ECW SDK Message-ID: <252979.72903.qm@web32601.mail.mud.yahoo.com> Steve, Thank you for your quick answer to my question. After I filled in and submitted the online register form on the www.ermapper.com website I immediately got an ok on the User Account Settings saying "An e-mail with your verification code has been sent to your e-mail address: mohwawang@yahoo.com Please access your in-box and get the verification code, which is required to log-in first time." But I have been waiting for more than 12 hours and I have not received the email. Usually how long will it take to receive the email with the verification code from that site? I guess the e-mail with the verification code is sent by a computer and should take just few seconds. Unless the computer is done? Unlikely the form is checked by people and they don't work on Sundays? Any idea? Thanks. Best Regards, Mo Wang --- On Sun, 3/22/09, Stephen Woodbridge wrote: > From: Stephen Woodbridge > Subject: Re: [gdal-dev] where can I get ECW SDK > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Sunday, March 22, 2009, 11:24 AM > mohwawang wrote: > > Hi all, > > > > I tried to get a copy of ECW SDK but failed. Following > the > > instruction from http://www.gdal.org/frmt_ecw.html "ECW SDK available > > at www.ermapper.com" I ended up with the Erdas website > and could not > > figure out where to get ECW SDK from Erdas website. > Anyone knows > > what's going on? And how to get a copy of ECW SDK? > Thanks. > > Mo, > > You have to create an account and login, then go to the > Support -> Downloads page and look for the SDK. > > -Steve W > From woodbri at swoodbridge.com Sun Mar 22 23:52:29 2009 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Sun Mar 22 22:51:00 2009 Subject: [gdal-dev] where can I get ECW SDK In-Reply-To: <252979.72903.qm@web32601.mail.mud.yahoo.com> References: <252979.72903.qm@web32601.mail.mud.yahoo.com> Message-ID: <49C7077D.6060804@swoodbridge.com> Mine came quickly. Did you check if it got sent to your spam folder? You might try it again. I don't know what else to suggest. -Steve mohwawang wrote: > Steve, > > Thank you for your quick answer to my question. After I filled in and > submitted the online register form on the www.ermapper.com website I > immediately got an ok on the User Account Settings saying "An e-mail > with your verification code has been sent to your e-mail address: > mohwawang@yahoo.com Please access your in-box and get the > verification code, which is required to log-in first time." > > But I have been waiting for more than 12 hours and I have not > received the email. Usually how long will it take to receive the > email with the verification code from that site? I guess the e-mail > with the verification code is sent by a computer and should take just > few seconds. Unless the computer is done? Unlikely the form is > checked by people and they don't work on Sundays? Any idea? Thanks. > > Best Regards, > > Mo Wang > > --- On Sun, 3/22/09, Stephen Woodbridge > wrote: > >> From: Stephen Woodbridge Subject: Re: >> [gdal-dev] where can I get ECW SDK To: "mohwawang" >> Cc: gdal-dev@lists.osgeo.org Date: Sunday, >> March 22, 2009, 11:24 AM mohwawang wrote: >>> Hi all, >>> >>> I tried to get a copy of ECW SDK but failed. Following >> the >>> instruction from http://www.gdal.org/frmt_ecw.html "ECW SDK >>> available at www.ermapper.com" I ended up with the Erdas website >> and could not >>> figure out where to get ECW SDK from Erdas website. >> Anyone knows >>> what's going on? And how to get a copy of ECW SDK? >> Thanks. >> >> Mo, >> >> You have to create an account and login, then go to the Support -> >> Downloads page and look for the SDK. >> >> -Steve W >> > > > From mohwawang at yahoo.com Mon Mar 23 00:40:33 2009 From: mohwawang at yahoo.com (mohwawang) Date: Mon Mar 23 00:40:36 2009 Subject: [gdal-dev] where can I get ECW SDK Message-ID: <939719.18796.qm@web32603.mail.mud.yahoo.com> Steve, Thank you for your help. I've found it in my spam folder and can login the website. I followed your instruction - first went to the Support -> Downloads and looked for the SDK. I saw total 11 items: ERDAS IMAGINE, ERDAS ER Mapper, ERDAS Image Web Server, LPS, ERDAS ImageEqualizer, ORIMA, PR0600, ERDAS TITAN, ArcGIS Extensions, ERDAS Virtual Explorer, TopoMouse. Which one is for the SDK? Or I went to the wrong place? Thanks. Best Regards, Mo --- On Sun, 3/22/09, Stephen Woodbridge wrote: > From: Stephen Woodbridge > Subject: Re: [gdal-dev] where can I get ECW SDK > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Sunday, March 22, 2009, 11:52 PM > Mine came quickly. Did you check if > it got sent to your spam folder? You might try it again. I > don't know what else to suggest. > > -Steve > > mohwawang wrote: > > Steve, > > > > Thank you for your quick answer to my question. After > I filled in and > > submitted the online register form on the > www.ermapper.com website I > > immediately got an ok on the User Account Settings > saying "An e-mail > > with your verification code has been sent to your > e-mail address: > > mohwawang@yahoo.com > Please access your in-box and get the > > verification code, which is required to log-in first > time." > > > > But I have been waiting for more than 12 hours and I > have not > > received the email. Usually how long will it take to > receive the > > email with the verification code from that site? I > guess the e-mail > > with the verification code is sent by a computer and > should take just > > few seconds. Unless the computer is done? Unlikely the > form is > > checked by people and they don't work on Sundays? Any > idea? Thanks. > > > > Best Regards, > > > > Mo Wang > > > > --- On Sun, 3/22/09, Stephen Woodbridge > > wrote: > > > >> From: Stephen Woodbridge > Subject: Re: > >> [gdal-dev] where can I get ECW SDK To: > "mohwawang" > >> > Cc: gdal-dev@lists.osgeo.org > Date: Sunday, > >> March 22, 2009, 11:24 AM mohwawang wrote: > >>> Hi all, > >>> > >>> I tried to get a copy of ECW SDK but failed. > Following > >> the > >>> instruction from http://www.gdal.org/frmt_ecw.html "ECW SDK > >>> available at www.ermapper.com" I ended up with > the Erdas website > >> and could not > >>> figure out where to get ECW SDK from Erdas > website. > >> Anyone knows > >>> what's going on? And how to get a copy of ECW > SDK? > >> Thanks. > >> > >> Mo, > >> > >> You have to create an account and login, then go > to the Support -> > >> Downloads page and look for the SDK. > >> > >> -Steve W > >> > > > > > > > > From jorsion at gmail.com Mon Mar 23 04:08:07 2009 From: jorsion at gmail.com (jor sion) Date: Mon Mar 23 04:08:10 2009 Subject: [gdal-dev] how to get group information from HDF file by using GDAL in CSharp Message-ID: <8c2bdf730903230108h77443cebx41a58e63ed3b9040@mail.gmail.com> Hi, I try using GDAl to read/write HDF files. Is it possible to access the names of groups in HDF files using GDAL in CSharp? How can I show groups like in HDF Explorer? I can get subdatasets's name and description information using GetMetadata("SUBDATASETS"), but I want to know is there any other domains like SubDatasets domain that I can access? I can not use gdalinfo in c#. Thanks very much! Best regards? ?? Josn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090323/e7f5b94e/attachment.html From horning at amnh.org Mon Mar 23 05:04:10 2009 From: horning at amnh.org (Ned Horning) Date: Mon Mar 23 05:10:19 2009 Subject: [gdal-dev] gdal_merge error with large 16 bit images Message-ID: <49C7508A.2000808@amnh.org> Greetings, I am having trouble running gdal_merge on large unsigned 16 bit imagery. I am using the OSGeo4W installation of gdal_merge.py. When I run it on 8-bit unsigned GeoTiff imagery (Landsat TM) the program works as expected. When I run it on two small 16-bit unsigned int GeoTiff subsets (500 samples x 1000 lines) from an IKONOS image that also works as expected. However, when I try to mosaic two large (~1.4GB/image) unsigned integer GeoTiff images (IKONOS) the program ends with a Windows error message: ?python.exe has encounters a problem and needs to close.?Here is some additional information: When I run gdal_merge using the large IKONOS imagery on my Ubuntu box I get a segmentation fault error. I'm running this on a laptop with Windows XP and 1GB RAM. The command I am using is pasted below. I am able to mosaic the images using gdalwarp but it takes over 4 hours to complete and when I run these under Ubuntu a question mark ("?") is tacked to the end of the output file name. Unfortunately the images are too large for me to upload since I'm currently in Tanzania. I'm not sure if this information is useful to troubleshoot but any help that someone can provide would be appreciated. All the best, Ned -- C:\>gdal_merge -o e:\IKONOS\mosaic2.tif -ot Int16 E:\IKONOS\Imagery\20060724_6190010000.tif E:\IKONOS\Imagery\20060724_6190010001.tif From giohappy at gmail.com Mon Mar 23 05:50:55 2009 From: giohappy at gmail.com (G. Allegri) Date: Mon Mar 23 05:50:57 2009 Subject: [gdal-dev] Re: gdb debug for grass g.proj crash in Windows Vista In-Reply-To: References: Message-ID: 0x774a7dff in ntdll!DbgUiConvertStateChangeStructure () from C:\Windows\system32\ntdll.dll (gdb) warning: HEAP[g.proj.exe]: warning: Invalid address specified to RtlFreeHeap( 01400000, 017F4700 ) this is what causes the crash. -------------------------------------- Debug session output -------------------------------------- print_wkt (esristyle=2, dontprettify=20986248) at output.c:138 138 G_free(outwkt); (gdb) n 0x004035e0 in G_free () (gdb) n Single stepping until exit from function G_free, which has no line number information. G_free (buf=0x17f4700) at alloc.c:128 128 { (gdb) n 129 free(buf); (gdb) n 0x6f574d20 in free () from c:\OSGeo4W\apps\grass\grass-6.5.svn\lib\libgrass_gis.6.5.svn.dll (gdb) n Single stepping until exit from function free, which has no line number information. 0x76689d32 in msvcrt!free () from C:\Windows\system32\msvcrt.dll (gdb) n Single stepping until exit from function msvcrt!free, which has no line number information. 0x76689cd4 in msvcrt!memcpy () from C:\Windows\system32\msvcrt.dll (gdb) n Single stepping until exit from function msvcrt!memcpy, which has no line number information. 0x76689d3e in msvcrt!free () from C:\Windows\system32\msvcrt.dll (gdb) n Single stepping until exit from function msvcrt!free, which has no line number information. 0x765ec55b in KERNEL32!HeapLock () from C:\Windows\system32\kernel32.dll (gdb) n Single stepping until exit from function KERNEL32!HeapLock, which has no line number information. Program received signal SIGTRAP, Trace/breakpoint trap. 0x774a7dff in ntdll!DbgUiConvertStateChangeStructure () from C:\Windows\system32\ntdll.dll (gdb) warning: HEAP[g.proj.exe]: warning: Invalid address specified to RtlFreeHeap( 01400000, 017F4700 ) s Single stepping until exit from function ntdll!DbgUiConvertStateChangeStructure, which has no line number information. 0x77511c93 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlpNtMakeTemporaryKey, which has no line number information. 0x774e2b26 in ntdll!RtlTimeToTimeFields () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlTimeToTimeFields, which has no line number information. 0x77472140 in ntdll!RtlOwnerAcesPresent () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlOwnerAcesPresent, which has no line number information. 0x77512cf3 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlpNtMakeTemporaryKey, which has no line number information. 0x774ba1bd in ntdll!A_SHAInit () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!A_SHAInit, which has no line number information. 0x77512ec1 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlpNtMakeTemporaryKey, which has no line number information. 0x774dbfe8 in ntdll!RtlTimeToTimeFields () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlTimeToTimeFields, which has no line number information. 0x774c861a in ntdll!RtlUnhandledExceptionFilter () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlUnhandledExceptionFilter, which has no line number information. 0x774ba1bd in ntdll!A_SHAInit () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!A_SHAInit, which has no line number information. 0x774c861f in ntdll!RtlUnhandledExceptionFilter () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlUnhandledExceptionFilter, which has no line number information. 0x774c589a in ntdll!RtlFreeThreadActivationContextStack () from C:\Windows\system32\ntdll.dll (gdb) s Single stepping until exit from function ntdll!RtlFreeThreadActivationContextStack, which has no line number information. 0x765ec56f in KERNEL32!HeapLock () from C:\Windows\system32\kernel32.dll (gdb) s Single stepping until exit from function KERNEL32!HeapLock, which has no line number information. 0x76689d6b in msvcrt!free () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!free, which has no line number information. 0x766c1bd2 in msvcrt!_ftol2_sse_excpt () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!_ftol2_sse_excpt, which has no line number information. 0x76694ffd in strpbrk () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function strpbrk, which has no line number information. 0x766c1be5 in msvcrt!_ftol2_sse_excpt () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!_ftol2_sse_excpt, which has no line number information. 0x76689d73 in msvcrt!free () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!free, which has no line number information. 0x76689d19 in msvcrt!memcpy () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!memcpy, which has no line number information. 0x76689d78 in msvcrt!free () from C:\Windows\system32\msvcrt.dll (gdb) s Single stepping until exit from function msvcrt!free, which has no line number information. main (argc=2, argv=0x1403988) at main.c:233 233 if (create->answer) (gdb) s 239 if (projinfo != NULL) (gdb) n 240 G_free_key_value(projinfo); (gdb) n 241 if (projunits != NULL) (gdb) n 242 G_free_key_value(projunits); (gdb) n 244 exit(EXIT_SUCCESS); (gdb) n PROJCS["Transverse Mercator", GEOGCS["international", DATUM["Monte_Mario", SPHEROID["International_1924",6378388,297], TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",1500000], PARAMETER["false_northing",0], UNIT["metre",1]] Program exited normally From warmerdam at pobox.com Mon Mar 23 10:07:29 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 23 10:07:32 2009 Subject: [gdal-dev] gdal_merge error with large 16 bit images In-Reply-To: <49C7508A.2000808@amnh.org> References: <49C7508A.2000808@amnh.org> Message-ID: <931f8ea90903230707g89a4188xca5e8c62ff7e1dcc@mail.gmail.com> On Mon, Mar 23, 2009 at 5:04 AM, Ned Horning wrote: > Greetings, > > I am having trouble running gdal_merge on large unsigned 16 bit imagery. I > am using the OSGeo4W installation of gdal_merge.py. When I run it on 8-bit > unsigned GeoTiff imagery (Landsat TM) the program works as expected. When I > run it on two small 16-bit unsigned int GeoTiff subsets (500 samples x 1000 > lines) from an IKONOS image that also works as expected. However, when I try > to mosaic two large (~1.4GB/image) unsigned integer GeoTiff images (IKONOS) > the program ends with a Windows error message: ?python.exe has encounters a > problem and needs to close.?Here is some additional information: > > When I run gdal_merge using the large IKONOS imagery on my Ubuntu box I get > a segmentation fault error. > > I'm running this on a laptop with Windows XP and 1GB RAM. The command I am > using is pasted below. > > I am able to mosaic the images using gdalwarp but it takes over 4 hours to > complete and when I run these under Ubuntu a question mark ("?") is tacked > to the end of the output file name. > > Unfortunately the images are too large for me to upload since I'm currently > in Tanzania. Ned, gdal_merge.py attempts to load the whole source image into memory before plopping it into the output mosaic. So it is possible to make very large mosaics out of modest sized input files, but it is not practical to make mosaics out of very large input files. This is a deficiency of gdal_merge.py which was originally only intended to be a simple example script. You might try using gdalwarp to merge large images. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Mon Mar 23 10:56:57 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 23 10:56:59 2009 Subject: [gdal-dev] how to get group information from HDF file by using GDAL in CSharp In-Reply-To: <8c2bdf730903230108h77443cebx41a58e63ed3b9040@mail.gmail.com> References: <8c2bdf730903230108h77443cebx41a58e63ed3b9040@mail.gmail.com> Message-ID: <931f8ea90903230756n2d7c8d7ei53a99a07cbec57@mail.gmail.com> 2009/3/23 jor sion : > Hi, > > I try?using GDAl to read/write HDF files. > Is it possible to access the names of groups in HDF files using GDAL in > CSharp? How can I show groups like in HDF Explorer? > > I can get subdatasets's name and description information using > GetMetadata("SUBDATASETS"), but I want to know is there any other domains > like SubDatasets domain that I can access? I can not use gdalinfo in c#. Jor, I have reviewed the HDF4 driver code for GDAL and it only uses three domains. SUBDATASETS, GEOLOCATION and the default domain. So any information that might be available that you want will be in the default domain. The GEOLOCATION domain is used for swath data to identify which are the lat and long bands per an RFC on this topic. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From randre at gmail.com Mon Mar 23 16:18:16 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Mon Mar 23 16:18:19 2009 Subject: [gdal-dev] MapServer using GDAL_WMS to access TileCache layer Message-ID: <9c2015090903231318s2b770064rb4bdf5411baa33a5@mail.gmail.com> Hi All, I've created a TileCache layer that's being used to overlay tiles in a Google Maps page. That's working just fine, but I would also like to access this layer via a MapServer WMS call as well. I have tried to setup a GDAL_WMS file that can read the TileCache layer, but am getting "IReadBlock failed" errors when I try to run gdal_translate on it, or try to view the layer in a MapServer map. Below are the pertinent details of my configuration. TileCache layer: ----------------------- [20m_global] type=MapServerLayer mapfile=/var/www/mapfiles/20m_global/20m_global.map #url=http://10.10.40.152/cgi-bin/mapserv?map=/var/www/mapfiles/20m_global/20m_global.map metaTile=true metaSize=2,2 metaBuffer=0,500 layers=imagery spherical_mercator=true srs=EPSG:900913 GDAL_WMS xml file: ------------------------------ http://10.10.10.143/cgi-bin/tilecache-2.04/tilecache.cgi/1.0.0/v2_80m_global/{Z}/{X}/{Y}.png -20037508.34 20037508.34 20037508.34 -20037508.34 11 1 1 top EPSG:900913 256 256 3 gdalinfo output: --------------------- $ gdalinfo tilecache.xml Driver: WMS/OGC Web Map Service Files: tilecache.xml Size is 524288, 524288 Coordinate System is: PROJCS["Google Maps Global Mercator", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], PROJECTION["Mercator_2SP"], PARAMETER["standard_parallel_1",0], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",0], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["Meter",1], EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"], AUTHORITY["EPSG","900913"]] Origin = (-20037508.339999999850988,20037508.339999999850988) Pixel Size = (76.437028274536132,-76.437028274536132) Corner Coordinates: Upper Left (-20037508.340,20037508.340) (180d 0'0.00"W, 85d 3'4.06"N) Lower Left (-20037508.340,-20037508.340) (180d 0'0.00"W, 85d 3'4.06"S) Upper Right (20037508.340,20037508.340) (180d 0'0.00"E, 85d 3'4.06"N) Lower Right (20037508.340,-20037508.340) (180d 0'0.00"E, 85d 3'4.06"S) Center ( 0.0000000, 0.0000000) ( 0d 0'0.01"E, 0d 0'0.00"S) Band 1 Block=256x256 Type=Byte, ColorInterp=Undefined Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, 256x256 Band 2 Block=256x256 Type=Byte, ColorInterp=Undefined Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, 256x256 Band 3 Block=256x256 Type=Byte, ColorInterp=Undefined Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, 256x256 gdal_translate error: ---------------------------- $ gdal_translate -outsize 1% 1% tilecache.xml test.tif Input file size is 524288, 524288 0ERROR 4: `/vsimem/wms/0x8503470/wmsresult.dat' not recognised as a supported file format. ERROR 1: GDALWMS: Unable to open downloaded block. ERROR 1: GDALWMS: ReadBlockFromFile failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 4: `/vsimem/wms/0x809dc08/wmsresult.dat' not recognised as a supported file format. ERROR 1: GDALWMS: Unable to open downloaded block. ERROR 1: GDALWMS: ReadBlockFromFile failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 MapServer error: ----------------------- msDrawMap(): Image handling error. Failed to draw layer named 'imagery'. IReadBlock failed at X offset 1442, Y offset 607: Unable to access file. GDALRasterIO() failed: drawGDAL() If you see anything that jumps out at you as being incorrect, I'd love to hear from you. Thanks, Roger From even.rouault at mines-paris.org Mon Mar 23 16:35:19 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 23 16:35:32 2009 Subject: [gdal-dev] MapServer using GDAL_WMS to access TileCache layer In-Reply-To: <9c2015090903231318s2b770064rb4bdf5411baa33a5@mail.gmail.com> References: <9c2015090903231318s2b770064rb4bdf5411baa33a5@mail.gmail.com> Message-ID: <200903232135.20537.even.rouault@mines-paris.org> Roger, your GDAL_WMS xml file is not correct. The format of the URL you use is not consistant with the one expected by the "TileService" service. You've used the example of "TMS" service (which really new in GDAL 1.7.0dev SVN only) but the correct format would be exactly what you have commented out (${x} in lowercase, and not {X}). Best regards, Even Le Monday 23 March 2009 21:18:16 Roger Andr?, vous avez ?crit?: > Hi All, > > I've created a TileCache layer that's being used to overlay tiles in a > Google Maps page. That's working just fine, but I would also like to > access this layer via a MapServer WMS call as well. I have tried to > setup a GDAL_WMS file that can read the TileCache layer, but am > getting "IReadBlock failed" errors when I try to run gdal_translate on > it, or try to view the layer in a MapServer map. > > Below are the pertinent details of my configuration. > > TileCache layer: > ----------------------- > [20m_global] > type=MapServerLayer > mapfile=/var/www/mapfiles/20m_global/20m_global.map > #url=http://10.10.40.152/cgi-bin/mapserv?map=/var/www/mapfiles/20m_global/2 >0m_global.map metaTile=true > metaSize=2,2 > metaBuffer=0,500 > layers=imagery > spherical_mercator=true > srs=EPSG:900913 > > GDAL_WMS xml file: > ------------------------------ > > > > http://10.10.10.143/cgi-bin/tilecache-2.04/tilecache.cgi/1.0.0/v >2_80m_global/{Z}/{X}/{Y}.png > > -20037508.34 > 20037508.34 > 20037508.34 > -20037508.34 > 11 > 1 > 1 > top > > EPSG:900913 > 256 > 256 > 3 > > > > gdalinfo output: > --------------------- > $ gdalinfo tilecache.xml > Driver: WMS/OGC Web Map Service > Files: tilecache.xml > Size is 524288, 524288 > Coordinate System is: > PROJCS["Google Maps Global Mercator", > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.01745329251994328, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4326"]], > PROJECTION["Mercator_2SP"], > PARAMETER["standard_parallel_1",0], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",0], > PARAMETER["false_easting",0], > PARAMETER["false_northing",0], > UNIT["Meter",1], > EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 > +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext > +no_defs"], > AUTHORITY["EPSG","900913"]] > Origin = (-20037508.339999999850988,20037508.339999999850988) > Pixel Size = (76.437028274536132,-76.437028274536132) > Corner Coordinates: > Upper Left (-20037508.340,20037508.340) (180d 0'0.00"W, 85d 3'4.06"N) > Lower Left (-20037508.340,-20037508.340) (180d 0'0.00"W, 85d 3'4.06"S) > Upper Right (20037508.340,20037508.340) (180d 0'0.00"E, 85d 3'4.06"N) > Lower Right (20037508.340,-20037508.340) (180d 0'0.00"E, 85d 3'4.06"S) > Center ( 0.0000000, 0.0000000) ( 0d 0'0.01"E, 0d 0'0.00"S) > Band 1 Block=256x256 Type=Byte, ColorInterp=Undefined > Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, > 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, > 256x256 > Band 2 Block=256x256 Type=Byte, ColorInterp=Undefined > Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, > 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, > 256x256 > Band 3 Block=256x256 Type=Byte, ColorInterp=Undefined > Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, > 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, > 256x256 > > gdal_translate error: > ---------------------------- > $ gdal_translate -outsize 1% 1% tilecache.xml test.tif > Input file size is 524288, 524288 > 0ERROR 4: `/vsimem/wms/0x8503470/wmsresult.dat' not recognised as a > supported file format. > > ERROR 1: GDALWMS: Unable to open downloaded block. > ERROR 1: GDALWMS: ReadBlockFromFile failed. > ERROR 1: IReadBlock failed at X offset 0, Y offset 0 > ERROR 4: `/vsimem/wms/0x809dc08/wmsresult.dat' not recognised as a > supported file format. > > ERROR 1: GDALWMS: Unable to open downloaded block. > ERROR 1: GDALWMS: ReadBlockFromFile failed. > ERROR 1: IReadBlock failed at X offset 0, Y offset 0 > > MapServer error: > ----------------------- > msDrawMap(): Image handling error. Failed to draw layer named > 'imagery'. IReadBlock failed at X offset 1442, Y offset 607: Unable to > access file. GDALRasterIO() failed: drawGDAL() > > If you see anything that jumps out at you as being incorrect, I'd love > to hear from you. > > Thanks, > > Roger > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From randre at gmail.com Mon Mar 23 16:48:08 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Mon Mar 23 16:48:13 2009 Subject: [gdal-dev] MapServer using GDAL_WMS to access TileCache layer In-Reply-To: <200903232135.20537.even.rouault@mines-paris.org> References: <9c2015090903231318s2b770064rb4bdf5411baa33a5@mail.gmail.com> <200903232135.20537.even.rouault@mines-paris.org> Message-ID: <9c2015090903231348s7ea7d469l139aaf4faed80e70@mail.gmail.com> Hi Even, Thanks for the info. I have updated my GDAL_WMS file to now show: http://10.10.10.143/cgi-bin/tilecache-2.04/tilecache.cgi/1.0.0/v2_80m_global/${z}/${x}/${y}.png Still doesn't work though. gdal_translate -outsize 1% 1% tilecache.xml test.tif Input file size is 524288, 524288 0ERROR 4: `/vsimem/wms/0x8503480/wmsresult.dat' not recognised as a supported file format. ERROR 1: GDALWMS: Unable to open downloaded block. ERROR 1: GDALWMS: ReadBlockFromFile failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 4: `/vsimem/wms/0x809dc28/wmsresult.dat' not recognised as a supported file format. ERROR 1: GDALWMS: Unable to open downloaded block. ERROR 1: GDALWMS: ReadBlockFromFile failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 On Mon, Mar 23, 2009 at 1:35 PM, Even Rouault wrote: > Roger, > > your GDAL_WMS xml file is not correct. The format of the URL you use is not > consistant with the one expected by the "TileService" service. You've used > the example of "TMS" service (which really new in GDAL 1.7.0dev SVN only) but > the correct format would be exactly what you have commented out (${x} in > lowercase, and not {X}). > > Best regards, > Even > > Le Monday 23 March 2009 21:18:16 Roger Andr?, vous avez ?crit?: >> Hi All, >> >> I've created a TileCache layer that's being used to overlay tiles in a >> Google Maps page. ?That's working just fine, but I would also like to >> access this layer via a MapServer WMS call as well. ?I have tried to >> setup a GDAL_WMS file that can read the TileCache layer, but am >> getting "IReadBlock failed" errors when I try to run gdal_translate on >> it, or try to view the layer in a MapServer map. >> >> Below are the pertinent details of my configuration. >> >> TileCache layer: >> ----------------------- >> [20m_global] >> type=MapServerLayer >> mapfile=/var/www/mapfiles/20m_global/20m_global.map >> #url=http://10.10.40.152/cgi-bin/mapserv?map=/var/www/mapfiles/20m_global/2 >>0m_global.map metaTile=true >> metaSize=2,2 >> metaBuffer=0,500 >> layers=imagery >> spherical_mercator=true >> srs=EPSG:900913 >> >> GDAL_WMS xml file: >> ------------------------------ >> >> >> >> http://10.10.10.143/cgi-bin/tilecache-2.04/tilecache.cgi/1.0.0/v >>2_80m_global/{Z}/{X}/{Y}.png >> >> -20037508.34 >> 20037508.34 >> 20037508.34 >> -20037508.34 >> 11 >> 1 >> 1 >> top >> >> EPSG:900913 >> 256 >> 256 >> 3 >> >> >> >> gdalinfo output: >> --------------------- >> $ gdalinfo tilecache.xml >> Driver: WMS/OGC Web Map Service >> Files: tilecache.xml >> Size is 524288, 524288 >> Coordinate System is: >> PROJCS["Google Maps Global Mercator", >> ? ? GEOGCS["WGS 84", >> ? ? ? ? DATUM["WGS_1984", >> ? ? ? ? ? ? SPHEROID["WGS 84",6378137,298.257223563, >> ? ? ? ? ? ? ? ? AUTHORITY["EPSG","7030"]], >> ? ? ? ? ? ? AUTHORITY["EPSG","6326"]], >> ? ? ? ? PRIMEM["Greenwich",0, >> ? ? ? ? ? ? AUTHORITY["EPSG","8901"]], >> ? ? ? ? UNIT["degree",0.01745329251994328, >> ? ? ? ? ? ? AUTHORITY["EPSG","9122"]], >> ? ? ? ? AUTHORITY["EPSG","4326"]], >> ? ? PROJECTION["Mercator_2SP"], >> ? ? PARAMETER["standard_parallel_1",0], >> ? ? PARAMETER["latitude_of_origin",0], >> ? ? PARAMETER["central_meridian",0], >> ? ? PARAMETER["false_easting",0], >> ? ? PARAMETER["false_northing",0], >> ? ? UNIT["Meter",1], >> ? ? EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 >> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext >> +no_defs"], >> ? ? AUTHORITY["EPSG","900913"]] >> Origin = (-20037508.339999999850988,20037508.339999999850988) >> Pixel Size = (76.437028274536132,-76.437028274536132) >> Corner Coordinates: >> Upper Left ?(-20037508.340,20037508.340) (180d 0'0.00"W, 85d 3'4.06"N) >> Lower Left ?(-20037508.340,-20037508.340) (180d 0'0.00"W, 85d 3'4.06"S) >> Upper Right (20037508.340,20037508.340) (180d 0'0.00"E, 85d 3'4.06"N) >> Lower Right (20037508.340,-20037508.340) (180d 0'0.00"E, 85d 3'4.06"S) >> Center ? ? ?( ? 0.0000000, ? 0.0000000) ( ?0d 0'0.01"E, ?0d 0'0.00"S) >> Band 1 Block=256x256 Type=Byte, ColorInterp=Undefined >> ? Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, >> 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, >> 256x256 >> Band 2 Block=256x256 Type=Byte, ColorInterp=Undefined >> ? Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, >> 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, >> 256x256 >> Band 3 Block=256x256 Type=Byte, ColorInterp=Undefined >> ? Overviews: 262144x262144, 131072x131072, 65536x65536, 32768x32768, >> 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024, 512x512, >> 256x256 >> >> gdal_translate error: >> ---------------------------- >> $ gdal_translate -outsize 1% 1% tilecache.xml test.tif >> Input file size is 524288, 524288 >> 0ERROR 4: `/vsimem/wms/0x8503470/wmsresult.dat' not recognised as a >> supported file format. >> >> ERROR 1: GDALWMS: Unable to open downloaded block. >> ERROR 1: GDALWMS: ReadBlockFromFile failed. >> ERROR 1: IReadBlock failed at X offset 0, Y offset 0 >> ERROR 4: `/vsimem/wms/0x809dc08/wmsresult.dat' not recognised as a >> supported file format. >> >> ERROR 1: GDALWMS: Unable to open downloaded block. >> ERROR 1: GDALWMS: ReadBlockFromFile failed. >> ERROR 1: IReadBlock failed at X offset 0, Y offset 0 >> >> MapServer error: >> ----------------------- >> msDrawMap(): Image handling error. Failed to draw layer named >> 'imagery'. IReadBlock failed at X offset 1442, Y offset 607: Unable to >> access file. GDALRasterIO() failed: drawGDAL() >> >> If you see anything that jumps out at you as being incorrect, I'd love >> to hear from you. >> >> Thanks, >> >> Roger >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > From warmerdam at pobox.com Mon Mar 23 23:00:36 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 23 23:00:38 2009 Subject: [gdal-dev] Motion: Authorize $500 Sponsorship of the Toronto Code Sprint In-Reply-To: <49BE96E4.7090903@pobox.com> References: <49BE96E4.7090903@pobox.com> Message-ID: <931f8ea90903232000q309ac08cg402264f13b0b069e@mail.gmail.com> On Mon, Mar 16, 2009 at 2:13 PM, Frank Warmerdam wrote: > Motion: Authorize $500 Sponsorship of the Toronto Code Sprint Folks, I somewhat belatedly declare this motion passed with support from FrankW, EvenR, TamasS, HowardB and DanielM. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From jorsion at gmail.com Tue Mar 24 04:53:15 2009 From: jorsion at gmail.com (jor sion) Date: Tue Mar 24 04:53:17 2009 Subject: [gdal-dev] How to extract information from datasets with three dimensionss Message-ID: <8c2bdf730903240153t7deffd01g53cd7dd00de07286@mail.gmail.com> Hi, I am using GDAL in CSharp to read the information from HDF files. To read the information from datasets with two dimensions is easy. but I don't know how to get the X_Axis and Y_Axis of the dataset. I can only get the information at the position (X_Axis, Y_Axis). And it is diffcult to read data from datasets with three dimensions. It can only read one layer. I don't know how to read all the layer's information. Any suggestions? Best regards! -- JoSn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090324/adc0046b/attachment.html From P.Koonings at crotec.nl Tue Mar 24 05:29:21 2009 From: P.Koonings at crotec.nl (P.Koonings@crotec.nl) Date: Tue Mar 24 06:10:28 2009 Subject: [gdal-dev] GML file v3 (with circular arcs) translate with ogr2ogr Message-ID: An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090324/c1b81588/attachment-0001.html From warmerdam at pobox.com Tue Mar 24 10:36:52 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 24 10:36:54 2009 Subject: [gdal-dev] How to extract information from datasets with three dimensionss In-Reply-To: <8c2bdf730903240153t7deffd01g53cd7dd00de07286@mail.gmail.com> References: <8c2bdf730903240153t7deffd01g53cd7dd00de07286@mail.gmail.com> Message-ID: <931f8ea90903240736r14a4edch822e6ec7a56b12c@mail.gmail.com> 2009/3/24 jor sion : > Hi, > > I?am using?GDAL in CSharp to read the information from HDF files. > > To read the information from datasets with two dimensions is easy. but?I > don't know how to get the?X_Axis and Y_Axis of the dataset. I can only get > the information at?the position (X_Axis, Y_Axis). Jor, I'm not sure what you mean by "get the X_Axis". Perhaps you are wanting to establish the geographic locations associated with different pixel and line indexes into the band? You would use the GetGeotransform() method to get the affine transformation parameters between pixel/line and georeferenced coordinates. Read in particular the "Affine Geotransform" portion of: http://www.gdal.org/gdal_datamodel.html > And it is diffcult to read data from datasets with three dimensions. It can > only read one layer. I don't know how to? read all the layer's information. Where datasets in HDF are 3D, each elevation (or time) layer is normally represented as a distinct band. In some cases there may be metadata on the bands indicating their time/elevation level but in other cases not. GDAL is not particularly well organized to support 3D datasets. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From fevans at harris.com Tue Mar 24 11:01:48 2009 From: fevans at harris.com (turtlewax) Date: Tue Mar 24 11:01:50 2009 Subject: [Gdal-dev] C# fix for supporting the libtool builds In-Reply-To: References: Message-ID: <1237906908747-2527093.post@n2.nabble.com> Tamas: I've been working on the Mono bindings for gdal for months now. All these steps look like they might solve my problem, but I'm having trouble translating them into actions. For example: 2. $(LD) should be used instead of $(LD_SHARED) when linking the shared libraries with libtool. Do I define this in the swig/csharp/GNUMakefile, or with a ./configure command, or with an environment variable? 3. Should use $(SO_EXT) as the shared object extension (in every case) Ditto for SO_EXT. Where do I define these? -- View this message in context: http://n2.nabble.com/C--fix-for-supporting-the-libtool-builds-tp2029188p2527093.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From szekerest at gmail.com Tue Mar 24 11:13:10 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Tue Mar 24 11:13:15 2009 Subject: [Gdal-dev] C# fix for supporting the libtool builds In-Reply-To: <1237906908747-2527093.post@n2.nabble.com> References: <1237906908747-2527093.post@n2.nabble.com> Message-ID: Hi, You shouldn't have to do it manually, just run: make interface make in the csharp directory right after compiling the gdal libraries. Best regards, Tamas 2009/3/24 turtlewax > > Tamas: > > I've been working on the Mono bindings for gdal for months now. All these > steps look like they might solve my problem, but I'm having trouble > translating them into actions. For example: > > > 2. $(LD) should be used instead of $(LD_SHARED) when linking the > shared libraries with libtool. > > > Do I define this in the swig/csharp/GNUMakefile, or with a ./configure > command, or with an environment variable? > > > 3. Should use $(SO_EXT) as the shared object extension (in every case) > > > Ditto for SO_EXT. Where do I define these? > > > -- > View this message in context: > http://n2.nabble.com/C--fix-for-supporting-the-libtool-builds-tp2029188p2527093.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090324/56ec1b2b/attachment.html From amanda.m.henneke at boeing.com Tue Mar 24 13:09:06 2009 From: amanda.m.henneke at boeing.com (AmandaH) Date: Tue Mar 24 13:09:08 2009 Subject: [Gdal-dev] Writing a polygon to a new shapefile Message-ID: <1237914546338-2527864.post@n2.nabble.com> Hello- I'm new to the GDAL/OGR libraries. I'm trying to use the C# wrapper to OGR in order to create a new shapefile, but I'm running into some issues. Here is the code I have...can anyone tell me what I'm doing wrong? Geometry temp_geom; OSGeo.OGR.Driver new_drv = Ogr.GetDriverByName("ESRI Shapefile"); OSGeo.OGR.SpatialReference new_sr = new OSGeo.OGR.SpatialReference(""); OSGeo.OGR.DataSource ds_out = new_drv.CreateDataSource("D:\\Vector\\Output\\new.shp", new string[] { }); new_sr.IsSameGeogCS(old_sr); OSGeo.OGR.Layer new_layer = ds_out.CreateLayer("new_polygons", new_sr, OSGeo.OGR.wkbGeometryType.wkbPolygon, new string[] { }); FeatureDefn new_def = new_layer.GetLayerDefn(); OSGeo.OGR.Feature new_feat = new OSGeo.OGR.Feature(new_def); temp_geom = new Geometry(wkbGeometryType.wkbPolygon); dX = geom.GetX(iPoint); dY = geom.GetY(iPoint); dZ = geom.GetZ(iPoint); temp_geom.AddPoint(dX, dY, dZ); new_feat.SetGeometryDirectly(temp_geom); new_layer.CreateFeature(new_feat); temp_geom.Dispose(); -- View this message in context: http://n2.nabble.com/Writing-a-polygon-to-a-new-shapefile-tp2527864p2527864.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From fevans at harris.com Tue Mar 24 14:24:15 2009 From: fevans at harris.com (turtlewax) Date: Tue Mar 24 14:24:17 2009 Subject: [Gdal-dev] C# fix for supporting the libtool builds In-Reply-To: References: Message-ID: <1237919055368-2528235.post@n2.nabble.com> 1. Should rely on $(CXX) $(CC) and including GDALmake.opt for building the .cpp .c .cxx files What does this mean, in terms of actually creating a build? In other words, what does "Should rely on" mean? Do I set a flag, an environment variable? -- View this message in context: http://n2.nabble.com/C--fix-for-supporting-the-libtool-builds-tp2029188p2528235.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From mitchelljj98 at gmail.com Tue Mar 24 14:25:57 2009 From: mitchelljj98 at gmail.com (John Mitchell) Date: Tue Mar 24 14:25:59 2009 Subject: [gdal-dev] Can you convert a ESRI Personal GeoDatabase to shapefiles within the gdal tools? Message-ID: Hi, Can you convert a ESRI Personal GeoDatabase to shapefiles within the gdal tools? Thanks, John -- John J. Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090324/ad436c58/attachment.html From jmckenna at gatewaygeomatics.com Tue Mar 24 14:53:06 2009 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Tue Mar 24 14:59:48 2009 Subject: [gdal-dev] Can you convert a ESRI Personal GeoDatabase to shapefiles within the gdal tools? In-Reply-To: References: Message-ID: <49C92C12.8010402@gatewaygeomatics.com> John Mitchell wrote: > Hi, > > Can you convert a ESRI Personal GeoDatabase to shapefiles within the > gdal tools? > > Thanks, > Hi, Yes you should be able to use the ogr2ogr utility for that (but not the other way, from shp to pgeo). source: http://www.gdal.org/ogr/ogr_formats.html -jeff -- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ From warmerdam at pobox.com Tue Mar 24 15:42:04 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 24 15:42:05 2009 Subject: [Gdal-dev] Writing a polygon to a new shapefile In-Reply-To: <1237914546338-2527864.post@n2.nabble.com> References: <1237914546338-2527864.post@n2.nabble.com> Message-ID: <931f8ea90903241242n28873cafh7a14d4b4a5172f81@mail.gmail.com> Amanda, I see a few issues. On Tue, Mar 24, 2009 at 1:09 PM, AmandaH wrote: > OSGeo.OGR.Driver new_drv = Ogr.GetDriverByName("ESRI Shapefile"); > OSGeo.OGR.SpatialReference new_sr = new OSGeo.OGR.SpatialReference(""); > OSGeo.OGR.DataSource ds_out = new_drv.CreateDataSource("D:\\Vector\\Output\\new.shp", new string[] { }); > > new_sr.IsSameGeogCS(old_sr); IsSameGeogCS() is a test, returning a boolean. Was this intended to do something? > OSGeo.OGR.Layer new_layer = ds_out.CreateLayer("new_polygons", new_sr, ? OSGeo.OGR.wkbGeometryType.wkbPolygon, new string[] { }); > > FeatureDefn new_def = new_layer.GetLayerDefn(); > OSGeo.OGR.Feature new_feat = new OSGeo.OGR.Feature(new_def); > > temp_geom = new Geometry(wkbGeometryType.wkbPolygon); > > dX = geom.GetX(iPoint); > dY = geom.GetY(iPoint); > dZ = geom.GetZ(iPoint); > > temp_geom.AddPoint(dX, dY, dZ); Polygons consists of rings, and the rings consist of points. So to add a point to the polygon you really need to add it to the first ring. I'm not positive what the method names are in C# but the gist of it is that you need to add a ring to the polygon. Then add the point to the ring. > new_feat.SetGeometryDirectly(temp_geom); > new_layer.CreateFeature(new_feat); > temp_geom.Dispose(); Note that SetGeometryDirectly() normally transfers ownership of the geometry to the feature, and you should not explicitly destroy the geometry that is owned by the feature. If you use SetGeometry() instead of SetGeometryDirectly() then the feature will make a copy of the passed geometry. Best regards, > -- > View this message in context: http://n2.nabble.com/Writing-a-polygon-to-a-new-shapefile-tp2527864p2527864.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From szekerest at gmail.com Tue Mar 24 16:36:17 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Tue Mar 24 16:36:20 2009 Subject: [Gdal-dev] C# fix for supporting the libtool builds In-Reply-To: <1237919055368-2528235.post@n2.nabble.com> References: <1237919055368-2528235.post@n2.nabble.com> Message-ID: 2009/3/24 turtlewax > > > 1. Should rely on $(CXX) $(CC) and including GDALmake.opt for building > the .cpp .c .cxx files > > > What does this mean, in terms of actually creating a build? In other words, > what does "Should rely on" mean? Do I set a flag, an environment variable? > These are just technical comments/guidelines to follow when adding support to the libtool builds in the gdal makefiles. The actual values of $(CXX) $(CC) may vary depending on whether libtool is configured or not. But the C# makefile have already been fixed in this regard, so you should not take much care of these comments. Tamas > > -- > View this message in context: > http://n2.nabble.com/C--fix-for-supporting-the-libtool-builds-tp2029188p2528235.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090324/dd1ba8b1/attachment.html From peifer at gmx.eu Wed Mar 25 04:06:22 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Wed Mar 25 04:06:52 2009 Subject: [gdal-dev] prj to proj.4 Message-ID: Hi, I am looking for a convenient way to convert the SRS parameters from a random shapefile.prj into proj.4 format. A command line interface would be most helpful for a non-programmer, like me. As far as I can see: Grass' g.proj is expected to do the job, but I did not get any further than to this g.proj error: "Segmentation fault" :-( I understand that the related functionality is in the OGR source code, somewhere in the neighbourhood of the OGRSpatialReference method, but how can a non-programmer make use of it? My current workaround is to write a temporary *.gmt file and read the parameters from its header, e.g.: # @Jp"+proj=utm +zone=33 +ellps=GRS80 +units=m +no_defs " I have a vague feeling that this is not the most elegant way to do it and hope that some smarter people have a better solution. Hermann From robert.coup at onetrackmind.co.nz Wed Mar 25 06:49:12 2009 From: robert.coup at onetrackmind.co.nz (Robert Coup) Date: Wed Mar 25 06:49:14 2009 Subject: [gdal-dev] prj to proj.4 In-Reply-To: References: Message-ID: Hi Hermann, On Wed, Mar 25, 2009 at 9:06 PM, Hermann Peifer wrote: > > I am looking for a convenient way to convert the SRS parameters from a > random shapefile.prj into proj.4 format. A command line interface would be > most helpful for a non-programmer, like me. > > If you have python on your system (likely), then you can create a python script (eg. prj2proj.py) with the following code in it, then run "python prj2proj.py my.prj" and it'll print the proj4 equivalent of the my.prj file. HTH, Rob :) #!/usr/bin/env python import osr import sys def main(prj_file): prj_text = open(prj_file, 'r').read() srs = osr.SpatialReference() if srs.ImportFromWkt(prj_text): raise ValueError("Error importing PRJ information from: %s" % prj_file) print srs.ExportToProj4() if __name__=="__main__": main(*sys.argv[1]) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090325/48f30913/attachment.html From giohappy at gmail.com Wed Mar 25 09:50:16 2009 From: giohappy at gmail.com (G. Allegri) Date: Wed Mar 25 09:50:19 2009 Subject: [gdal-dev] Python and GDAL 1.6: TypeError with geom.Transform() Message-ID: Hello list. I have problems with GDAL 1.6 and Python. I need to reproject some points, and I know I can use geom.Transform(my osgeo.osr.CoordinateTransformation object). The problem is that it raises the following error: TypeError: in method 'Geometry_Transform', argument 2 of type 'OSRCoordinateTransformationShadow *' I've never seen it before. What's wrong? giovanni From hobu.inc at gmail.com Wed Mar 25 11:00:17 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Wed Mar 25 11:00:24 2009 Subject: [gdal-dev] prj to proj.4 In-Reply-To: References: Message-ID: <28FDFC97-C299-40A6-BF30-3D8988D77A94@gmail.com> Looking at the .prj file and searching http://spatialreference.org might also be productive. Another option is to upload it to spatialreference.org, and you can then get it in a number of formats. This approach isn't recommended for a lot of SRS's, but for a quick one-off sort of thing, it's pretty handy. Howard On Mar 25, 2009, at 5:49 AM, Robert Coup wrote: > Hi Hermann, > > On Wed, Mar 25, 2009 at 9:06 PM, Hermann Peifer wrote: > > I am looking for a convenient way to convert the SRS parameters from > a random shapefile.prj into proj.4 format. A command line interface > would be most helpful for a non-programmer, like me. > > > If you have python on your system (likely), then you can create a > python script (eg. prj2proj.py) with the following code in it, then > run "python prj2proj.py my.prj" and it'll print the proj4 equivalent > of the my.prj file. > > HTH, > > Rob :) > > > #!/usr/bin/env python > > import osr > import sys > > def main(prj_file): > prj_text = open(prj_file, 'r').read() > srs = osr.SpatialReference() > if srs.ImportFromWkt(prj_text): > raise ValueError("Error importing PRJ information from: %s" > % prj_file) > print srs.ExportToProj4() > > if __name__=="__main__": > main(*sys.argv[1]) > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From peifer at gmx.eu Wed Mar 25 13:31:07 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Wed Mar 25 13:31:38 2009 Subject: [gdal-dev] Re: prj to proj.4 In-Reply-To: <28FDFC97-C299-40A6-BF30-3D8988D77A94@gmail.com> References: <28FDFC97-C299-40A6-BF30-3D8988D77A94@gmail.com> Message-ID: Howard Butler wrote: > Looking at the .prj file and searching http://spatialreference.org might > also be productive. > > Another option is to upload it to spatialreference.org, and you can then > get it in a number of formats. This approach isn't recommended for a > lot of SRS's, but for a quick one-off sort of thing, it's pretty handy. > > Howard > Thanks for the hint, but I have 1000's of shapefiles which have all kinds of SRS's. So spatialreference.org doesn't seem to be the best option in my case. Rob's python script below actually looks like what I was looking for. Python is available on my system. I am however not root there. I still have to convince the system admin to install the gdal site-package, so that I can: import osr Hermann > On Mar 25, 2009, at 5:49 AM, Robert Coup wrote: > >> Hi Hermann, >> >> On Wed, Mar 25, 2009 at 9:06 PM, Hermann Peifer wrote: >> >> I am looking for a convenient way to convert the SRS parameters from a >> random shapefile.prj into proj.4 format. A command line interface >> would be most helpful for a non-programmer, like me. >> >> >> If you have python on your system (likely), then you can create a >> python script (eg. prj2proj.py) with the following code in it, then >> run "python prj2proj.py my.prj" and it'll print the proj4 equivalent >> of the my.prj file. >> >> HTH, >> >> Rob :) >> >> >> #!/usr/bin/env python >> >> import osr >> import sys >> >> def main(prj_file): >> prj_text = open(prj_file, 'r').read() >> srs = osr.SpatialReference() >> if srs.ImportFromWkt(prj_text): >> raise ValueError("Error importing PRJ information from: %s" % >> prj_file) >> print srs.ExportToProj4() >> >> if __name__=="__main__": >> main(*sys.argv[1]) >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Wed Mar 25 14:00:19 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Wed Mar 25 14:00:29 2009 Subject: [gdal-dev] Re: prj to proj.4 In-Reply-To: References: <28FDFC97-C299-40A6-BF30-3D8988D77A94@gmail.com> Message-ID: <200903251900.20265.even.rouault@mines-paris.org> Hermann, Actually you don't even need to have root priviledge to use the GDAL bindings. Go to swig/python and do "make install". This will generate the shared libraries and at the end it will error out because it can't install them in /usr/local/lib/python2.5/site-packages (or something similar) Then you need to hand copy into the directory where you put your python script the following files/directories : swig/python/ogr.py swig/python/osr.py swig/python/gdal.py swig/python/gdalconst.py swig/python/gdalnumeric.py swig/python/build/lib.linux-i686-2.5/osgeo/_gdal.so swig/python/build/lib.linux-i686-2.5/osgeo/_gdalconst.so swig/python/build/lib.linux-i686-2.5/osgeo/_osr.so swig/python/build/lib.linux-i686-2.5/osgeo/_ogr.so swig/python/build/lib.linux-i686-2.5/osgeo/_gdal_array.so swig/python/osgeo (directory) (If you're running on Windows, this should be similar. Replace the .so by the .dll) Best regards, Even Le Wednesday 25 March 2009 18:31:07 Hermann Peifer, vous avez ?crit?: > Howard Butler wrote: > > Looking at the .prj file and searching http://spatialreference.org might > > also be productive. > > > > Another option is to upload it to spatialreference.org, and you can then > > get it in a number of formats. This approach isn't recommended for a > > lot of SRS's, but for a quick one-off sort of thing, it's pretty handy. > > > > Howard > > Thanks for the hint, but I have 1000's of shapefiles which have all > kinds of SRS's. So spatialreference.org doesn't seem to be the best > option in my case. Rob's python script below actually looks like what I > was looking for. Python is available on my system. I am however not root > there. I still have to convince the system admin to install the gdal > site-package, so that I can: import osr > > Hermann > > > On Mar 25, 2009, at 5:49 AM, Robert Coup wrote: > >> Hi Hermann, > >> > >> On Wed, Mar 25, 2009 at 9:06 PM, Hermann Peifer wrote: > >> > >> I am looking for a convenient way to convert the SRS parameters from a > >> random shapefile.prj into proj.4 format. A command line interface > >> would be most helpful for a non-programmer, like me. > >> > >> > >> If you have python on your system (likely), then you can create a > >> python script (eg. prj2proj.py) with the following code in it, then > >> run "python prj2proj.py my.prj" and it'll print the proj4 equivalent > >> of the my.prj file. > >> > >> HTH, > >> > >> Rob :) > >> > >> > >> #!/usr/bin/env python > >> > >> import osr > >> import sys > >> > >> def main(prj_file): > >> prj_text = open(prj_file, 'r').read() > >> srs = osr.SpatialReference() > >> if srs.ImportFromWkt(prj_text): > >> raise ValueError("Error importing PRJ information from: %s" % > >> prj_file) > >> print srs.ExportToProj4() > >> > >> if __name__=="__main__": > >> main(*sys.argv[1]) > >> > >> _______________________________________________ > >> 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 From hobu.inc at gmail.com Wed Mar 25 14:07:22 2009 From: hobu.inc at gmail.com (Howard Butler) Date: Wed Mar 25 14:14:45 2009 Subject: [gdal-dev] Re: prj to proj.4 In-Reply-To: <200903251900.20265.even.rouault@mines-paris.org> References: <28FDFC97-C299-40A6-BF30-3D8988D77A94@gmail.com> <200903251900.20265.even.rouault@mines-paris.org> Message-ID: On Mar 25, 2009, at 1:00 PM, Even Rouault wrote: > Hermann, > > Actually you don't even need to have root priviledge to use the GDAL > bindings. > Go to swig/python and do "make install". Actually, this is cleaner than hand copying: cd swig/python python setup.py bdist_egg (or python setup.py bdist) cd dist copy that (in the case of the .egg) or those (if you did just did regular bdist) to a place that you can set your PYTHONPATH to From Shawn.Gong at drdc-rddc.gc.ca Wed Mar 25 16:17:20 2009 From: Shawn.Gong at drdc-rddc.gc.ca (Gong, Shawn (Contractor)) Date: Wed Mar 25 16:17:28 2009 Subject: [gdal-dev] SWIG Python binding for OpenEV2 Message-ID: hi list, I built Gdal 1.6 using old-generation Python bindings (not SWIG) for OpenEV1.8. Now I am ready to move to Mario Beauchamp's OpenEV2, whose Python codes call "from osgeo import gdal" instead of "import gdal" I will rebuild Gdal 1.6 using "./configure --with-python" on Linux. On Windows XP, I need some help: What do I need to change in nmake.opt? Are the following lines? # Set the location of your SWIG installation !IFNDEF SWIG SWIG = swig.exe !ENDIF thanks, Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090325/5894df0c/attachment.html From silyko at gmail.com Wed Mar 25 17:22:26 2009 From: silyko at gmail.com (Simon Lyngby Kokkendorff) Date: Wed Mar 25 17:29:58 2009 Subject: [gdal-dev] gdal-python and py2exe Message-ID: Hello All, This may seem stupid :-) I am doing an application using the gdal bindings for python on windows. I am trying to bundle it all up to an executable using py2exe and the NSIS-installer. It all seems to go well, the dll's from my installation of gdal, C:\gdalwin32-1.6\bin, get copied into the distribution and the executable runs fine on my computer, also when I delete the gdal environment variables. However, when I try to run the executable on another computer, where python and gdal is not installed, I get an error when trying to import gdal in my script (hidden inside the executable): "dll load failed" and then a message saying that gdal was not configured correctly on the system. So what is being configured when running the gdal for python installer exe, which has not been run on the other computer? I have tried to glance trough the installation files, but have not been able to figure it out, yet. Hope that someone in here can help me! Best, Simon Kokkendorff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090325/7292f2bc/attachment.html From Chris.Barker at noaa.gov Wed Mar 25 18:01:57 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed Mar 25 18:02:00 2009 Subject: [gdal-dev] gdal-python and py2exe In-Reply-To: References: Message-ID: <49CAA9D5.80605@noaa.gov> Simon Lyngby Kokkendorff wrote: > a message saying that gdal was not configured correctly on the > system. So what is being configured when running the gdal for python > installer exe, which has not been run on the other computer? Just taking a stab at it -- I think GDAL requires data files that you'll need to include and point it to, but I can't tell you where these usually live in Windows, or how to re-direct GDAL to them. -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.Barker@noaa.gov From randre at gmail.com Thu Mar 26 02:21:56 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Thu Mar 26 02:22:10 2009 Subject: [gdal-dev] GDAL TMS minidriver Message-ID: <9c2015090903252321t7b8443ady6186961c87a7bf49@mail.gmail.com> Hi All, I'm trying to use the TMS minidriver to read a TileCache instance and am getting an error that says, "GDALWMS: No mini-driver registered for 'TMS'". I'm trying to follow the instructions on http://www.gdal.org/frmt_wms.html, but am a bit confused. At the top of the page it says there are 3 services which are currently supported; WMS, WorldWind, and TileService. However, lower in the doc it also mentions TMS, and one of the examples http://www.gdal.org/frmt_wms_openstreetmap_tms.xml uses that service type, and looks like it would work with TileCache. I'm using gdal 1.5.2, is this functionality supported in that version? Thanks, Roger -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090325/b5dfd754/attachment-0001.html From klokan at klokan.cz Thu Mar 26 04:06:18 2009 From: klokan at klokan.cz (=?ISO-8859-2?Q?Klokan_Petr_P=F8idal?=) Date: Thu Mar 26 04:06:21 2009 Subject: [gdal-dev] gdal-python and py2exe - MapTiler.org Message-ID: <6e41d95b0903260106t4b3eec6ep44ee1e480685fc04@mail.gmail.com> Hi Simon and others, I am successfully bundling GDAL 1.6 from OSGeo4W in my MapTiler application - with py2exe, GDAL 1.6, wxPython, InnoSetup combination under Windows. MapTiler is a multi-platform user-friendly graphical application based on my GDAL2Tiles utility and targeted to end-users and newbies in open-source GIS world - it has a step by step wizard GUI which looks like this: http://mac.softpedia.com/progScreenshots/MapTiler-Screenshot-52156.html (somebody already published screenshots ;-)). It runs on Windows, Mac and on Linux. More info at: http://www.maptiler.org/. I made a presentation about it: http://www.vimeo.com/1766572 You can get the source code from SVN at: http://code.google.com/p/maptiler/ The software is in Alpha version now, with known bugs and limitation, but already quite usable. I plan to commit changes I did in GDAL2Tiles back into GDAL SVN... Ad system variables: I am setting up GDAL_DATA and other variables in the beginning of the python program (maptiler.py file), before loading GDAL modules - with autodetection of the operating system and a bit of hacking for py2exe. Is GDAL community interested in supporting further development of GDAL2Tiles and MapTiler during this Google Summer of Code? Because I am still PhD candidate at Czech Technical University in Prague I can participate as a student again... I proposed the project (no.5.) related to GDAL2Tiles/MapTiler at: http://trac.osgeo.org/gdal/wiki/SummerOfCode Best, Klokan On Wed, Mar 25, 2009 at 11:01 PM, Christopher Barker wrote: > Simon Lyngby Kokkendorff wrote: >> >> a message saying that gdal was not configured correctly on the system. So >> what is being configured when running the gdal for python installer exe, >> which has not been run on the other computer? > > Just taking a stab at it -- I think GDAL requires data files that you'll > need to include and point it to, but I can't tell you where these usually > live in Windows, or how to re-direct GDAL to them. > > -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.Barker@noaa.gov > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ From klokan at klokan.cz Thu Mar 26 04:13:02 2009 From: klokan at klokan.cz (=?ISO-8859-2?Q?Klokan_Petr_P=F8idal?=) Date: Thu Mar 26 04:13:05 2009 Subject: [gdal-dev] GDAL TMS minidriver In-Reply-To: <9c2015090903252321t7b8443ady6186961c87a7bf49@mail.gmail.com> References: <9c2015090903252321t7b8443ady6186961c87a7bf49@mail.gmail.com> Message-ID: <6e41d95b0903260113n5edc46f6uc878d7765d3eaf7b@mail.gmail.com> Roger, this patch was done by Christopher Schmidt during Toronto Code Sprint 2009 in the beginning of this month. The functionality is available only in gdal-trunk (1.7dev) since r16585. Details: http://trac.osgeo.org/gdal/ticket/2878 http://crschmidt.net/blog/376/toronto-code-sprint-day-2/ If you find a bug in the online documentation feel free to patch it ;-). Best reagards, Klokan 2009/3/26 Roger Andr? : > Hi All, > > I'm trying to use the TMS minidriver to read a TileCache instance and am > getting an error that says, "GDALWMS: No mini-driver registered for 'TMS'". > I'm trying to follow the instructions on http://www.gdal.org/frmt_wms.html, > but am a bit confused. At the top of the page it says there are 3 services > which are currently supported; WMS, WorldWind, and TileService.? However, > lower in the doc it also mentions TMS, and one of the examples > http://www.gdal.org/frmt_wms_openstreetmap_tms.xml uses that service type, > and looks like it would work with TileCache. > > I'm using gdal 1.5.2, is this functionality supported in that version? > > Thanks, > > Roger > -- > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ From silyko at gmail.com Thu Mar 26 04:32:46 2009 From: silyko at gmail.com (Simon Lyngby Kokkendorff) Date: Thu Mar 26 04:32:48 2009 Subject: [gdal-dev] gdal-python and py2exe - MapTiler.org In-Reply-To: <6e41d95b0903260106t4b3eec6ep44ee1e480685fc04@mail.gmail.com> References: <6e41d95b0903260106t4b3eec6ep44ee1e480685fc04@mail.gmail.com> Message-ID: Hi Klokan and Chris, Thanks for your replys. I had a feeling, that it had to do with setting up the env. variables properly from within the script. I will have a closer look at MapTiler, which looks great, and try to figure things out! The application I am doing is designed for surveyors who want to locate benchmarks while doing field work. Best, Simon 2009/3/26 Klokan Petr P?idal > Hi Simon and others, > > I am successfully bundling GDAL 1.6 from OSGeo4W in my MapTiler > application - with py2exe, GDAL 1.6, wxPython, InnoSetup combination > under Windows. > > MapTiler is a multi-platform user-friendly graphical application based > on my GDAL2Tiles utility and targeted to end-users and newbies in > open-source GIS world - it has a step by step wizard GUI which looks > like this: > http://mac.softpedia.com/progScreenshots/MapTiler-Screenshot-52156.html > (somebody already published screenshots ;-)). > It runs on Windows, Mac and on Linux. > More info at: http://www.maptiler.org/. > > I made a presentation about it: http://www.vimeo.com/1766572 > > You can get the source code from SVN at: > http://code.google.com/p/maptiler/ > > The software is in Alpha version now, with known bugs and limitation, > but already quite usable. I plan to commit changes I did in GDAL2Tiles > back into GDAL SVN... > > Ad system variables: I am setting up GDAL_DATA and other variables in > the beginning of the python program (maptiler.py file), before loading > GDAL modules - with autodetection of the operating system and a bit of > hacking for py2exe. > > Is GDAL community interested in supporting further development of > GDAL2Tiles and MapTiler during this Google Summer of Code? > Because I am still PhD candidate at Czech Technical University in > Prague I can participate as a student again... > I proposed the project (no.5.) related to GDAL2Tiles/MapTiler at: > http://trac.osgeo.org/gdal/wiki/SummerOfCode > > Best, > > Klokan > > On Wed, Mar 25, 2009 at 11:01 PM, Christopher Barker > wrote: > > Simon Lyngby Kokkendorff wrote: > >> > >> a message saying that gdal was not configured correctly on the system. > So > >> what is being configured when running the gdal for python installer exe, > >> which has not been run on the other computer? > > > > Just taking a stab at it -- I think GDAL requires data files that you'll > > need to include and point it to, but I can't tell you where these usually > > live in Windows, or how to re-direct GDAL to them. > > > > -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.Barker@noaa.gov > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > http://blog.klokan.cz/ > http://www.maptiler.org/ > http://www.oldmapsonline.org/ > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090326/d5c18615/attachment.html From andrew.loughhead at gmail.com Thu Mar 26 09:22:04 2009 From: andrew.loughhead at gmail.com (Andrew Loughhead) Date: Thu Mar 26 09:22:09 2009 Subject: [gdal-dev] NITF header writing - not really? Message-ID: <49CB817C.3010506@gmail.com> Does gdal_translate actually write values specified via -mo into the output NITF files? It seems that metadata fields specified with -mo get put into the .aux.xml file, but not into the actual output NITF file. For example: gdal_translate -of NITF -mo "NITF_FTITLE="myspecialvalue" infile.ntf outfile.ntf That seems to run, so I do gdalinfo on outfile.ntf. Great, I get: NITF_FTITLE=myspecialvalue But - when I take my NITF into software able to show headers (say, Erdas Imagine), the FTITLE header appears to be blank. On investigation, it appears that the run of gdalinfo outfile.ntf is actually just reporting the contents of outfile.ntf.aux.xml. If I remove that file, and run gdalinfo outfile.ntf, I get a blank NITF_FTITLE! A few headers are getting written into the output NITF file, such as OSTAID, but even these appear to have hardcoded values, except for as put in the .aux.xml file. In the case of OSTAID my custom value gets put into outfile.ntf.aux.xml, and reported by gdalinfo. If I delete outfile.ntf.aux.xml, and rerun gdalinfo outfile.ntf, the value GDAL is reported. Any ideas or info? thanks Andrew. From amanda.m.henneke at boeing.com Thu Mar 26 10:06:06 2009 From: amanda.m.henneke at boeing.com (AmandaH) Date: Thu Mar 26 10:06:07 2009 Subject: [Gdal-dev] gdal_rasterize and C# Message-ID: <1238076366161-2538567.post@n2.nabble.com> Does anyone have any help or example code for using gdal_rasterize with the C# API? I need to burn some shapefiles into a geotiff. Any help would be appreciated. -- View this message in context: http://n2.nabble.com/gdal_rasterize-and-C--tp2538567p2538567.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From anja.roesel at zmaw.de Thu Mar 26 11:12:02 2009 From: anja.roesel at zmaw.de (Anja Roesel) Date: Thu Mar 26 11:12:04 2009 Subject: [gdal-dev] again .hdf to .tif Message-ID: <49CB9B42.6050904@zmaw.de> sorry i forgot to mention the error message: >Segmentation fault Hi list, I am trying to convert MODIS .hdf files to .tif files (it worked with ASTER files earlier, thats why I am now really curious). i typed >gdalinfo MOD021KM.A2008134.1935.005.2009071201911.hdf result: ...... SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB SUBDATASET_1_DESC=[15x2030x1354] EV_1KM_RefSB (16-bit unsigned integer) SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB_Uncert_Indexes SUBDATASET_2_DESC= ........ then: >gdalwarp HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB modis.tif Have you any ideas, what is the problem? Thanks, Anja From yann.chemin at gmail.com Thu Mar 26 11:15:25 2009 From: yann.chemin at gmail.com (Yann Chemin) Date: Thu Mar 26 11:15:29 2009 Subject: [gdal-dev] again .hdf to .tif In-Reply-To: <49CB9B42.6050904@zmaw.de> References: <49CB9B42.6050904@zmaw.de> Message-ID: <4f37eb890903260815q77e41678n3b2830b71b91f50f@mail.gmail.com> Hi there, I am using this one right now on Level 2 and 3 MODIS products ------------------------------------------- #!/bin/bash mkdir processed for file in *.hdf do SDS_list=$(gdalinfo $file | grep "SUBDATASET_.*_NAME.*") for subdataset in $SDS_list do echo ${subdataset#*=} > tempfile.txt out=$(sed 's/\(.*\):\(.*\):"\(.*\).A\(.*\)\.\h\(.*\)\.\(.*\)\.\(.*\).hdf":\(.*\):\(.*\)/\3\_\4\_h\5\_\8\_\9\.tif/' tempfile.txt) gdalwarp -of GTiff -t_srs EPSG:4326 ${subdataset#*=} processed/$out done done ------------------------------------- maybe of help, Yann 2009/3/26 Anja Roesel : > sorry i forgot to mention the error message: >>Segmentation fault > > > > > > Hi list, > > I am trying to convert MODIS .hdf files to .tif files (it worked with > ASTER files earlier, thats why I am now really curious). > > i typed > >>gdalinfo MOD021KM.A2008134.1935.005.2009071201911.hdf > > result: > ...... > SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB > SUBDATASET_1_DESC=[15x2030x1354] EV_1KM_RefSB (16-bit unsigned integer) > SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB_Uncert_Indexes > SUBDATASET_2_DESC= > ........ > > then: > >>gdalwarp > HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB > ?modis.tif > > Have you any ideas, what is the problem? > Thanks, > Anja > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Yann Chemin Mobile: +33 (06) 10 11 39 26 Home: +33 (02) 35 27 08 20, Address: Gite de Mortagne, 16 rue de la chenaie, 76110 Bec de Mortagne, France Perso: http://www.freewebs.com/ychemin YiKingDo: http://yikingdo.unblog.fr/ From Jim.Klassen at ci.stpaul.mn.us Thu Mar 26 11:24:20 2009 From: Jim.Klassen at ci.stpaul.mn.us (Jim Klassen) Date: Thu Mar 26 11:24:26 2009 Subject: [gdal-dev] GDAL Warp API Message-ID: <49CB57D40200004F0000FC81@jeckle> I'm trying to do some aerial photo processing specifically converting RAW imagery to DOQs. Right now I have working code that uses GDAL to read/write the rasters and uses my own code to do the actual image processing. I would like to use the Warp API so I can take advantage of the ChunkAndWarpImage method, in particular, it's ability to break the problem down into chunks that will fit into memory. The problem I am facing is I can't write the part of the transformer function that converts from destination to source coordinates because the destination coordinate could occur nearly anywhere in the source image and likely will occur more than once. (The source data is from a push broom sensor so each scan line in the image has a different transformation depending on where the plane was and how it was orientated when the scan line was recorded.) From what I can gather, the Warp API is doing this to determine which part(s) of the source image it needs to grab to fill the destination image. In my case, I know that I will want to use the entire source image and have already calculated from the source image the extents destination image, but I don't see a way to tell this to the Warp API. So my question: Is there a way to get the Warp API to skip trying to discover the required source image extents or is there a way to write the transformer function to trick the Warp API into just using the entire source image without the transformation having to be mathematically rigorous? Jim Klassen From schut at sarvision.nl Thu Mar 26 11:25:05 2009 From: schut at sarvision.nl (Vincent Schut) Date: Thu Mar 26 11:34:42 2009 Subject: [gdal-dev] again .hdf to .tif In-Reply-To: <4f37eb890903260815q77e41678n3b2830b71b91f50f@mail.gmail.com> References: <49CB9B42.6050904@zmaw.de> <4f37eb890903260815q77e41678n3b2830b71b91f50f@mail.gmail.com> Message-ID: <49CB9E51.2020308@sarvision.nl> Yann Chemin wrote: > Hi there, > > I am using this one right now on Level 2 and 3 MODIS products > > ------------------------------------------- > #!/bin/bash > mkdir processed > for file in *.hdf > do SDS_list=$(gdalinfo $file | grep "SUBDATASET_.*_NAME.*") > for subdataset in $SDS_list > do echo ${subdataset#*=} > tempfile.txt > out=$(sed 's/\(.*\):\(.*\):"\(.*\).A\(.*\)\.\h\(.*\)\.\(.*\)\.\(.*\).hdf":\(.*\):\(.*\)/\3\_\4\_h\5\_\8\_\9\.tif/' > tempfile.txt) > gdalwarp -of GTiff -t_srs EPSG:4326 ${subdataset#*=} processed/$out > done > done > ------------------------------------- > > maybe of help, > Yann > > Note that, when you are using modis sinusoidal projected hdf products, you might have to use something like this to prevent a shift in the y direction which becomes more pronounced when further from the equator: gdalwarp -s_srs '+proj=sinu +R=6371007.181 +nadgrids=@null +wktext' -t_srs EPSG:4326 to force gdalwarp to adjust for the custom ellipsoid that the modis sinusoidal projection uses. Or, at least, I had to some time ago. It might have been 'fixed' already. Regards, Vincent. > 2009/3/26 Anja Roesel : > >> sorry i forgot to mention the error message: >> >>> Segmentation fault >>> >> >> >> >> Hi list, >> >> I am trying to convert MODIS .hdf files to .tif files (it worked with >> ASTER files earlier, thats why I am now really curious). >> >> i typed >> >> >>> gdalinfo MOD021KM.A2008134.1935.005.2009071201911.hdf >>> >> result: >> ...... >> SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB >> SUBDATASET_1_DESC=[15x2030x1354] EV_1KM_RefSB (16-bit unsigned integer) >> SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB_Uncert_Indexes >> SUBDATASET_2_DESC= >> ........ >> >> then: >> >> >>> gdalwarp >>> >> HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB >> modis.tif >> >> Have you any ideas, what is the problem? >> Thanks, >> Anja >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> > > > > From peifer at gmx.eu Thu Mar 26 11:35:42 2009 From: peifer at gmx.eu (Hermann Peifer) Date: Thu Mar 26 11:35:45 2009 Subject: [gdal-dev] Re: prj to proj.4 In-Reply-To: <95186.22409.qm@web33208.mail.mud.yahoo.com> References: <95186.22409.qm@web33208.mail.mud.yahoo.com> Message-ID: <49CBA0CE.6090208@gmx.eu> Brent Wood wrote: > Hermann, > > This might work for you, although far from elegant :-) > > If you generate a GMT file (using ogr2ogr) of each of the shapefiles, & just grep out the relevant lines from each file (@Jp is the proj.4 text, @Jw is the WKT version), it should give you both the WKT & proj.4 versions of the projection, (or just grep "@Jp" for the proj one); eg, ... > This is actually what I am doing already as a workaround (I mentioned this in my first mail). I just do it inside a small bash/AWK script, which says somewhere in the middle: if ( /^# @Jp/ ) proj = substr($0, 6) Just to finish the story with the Rob's Python script: With the helpful hints from the list I got around the initial problems, which mainly originate from the fact that I am not root on the target system. I was able to import osr, but then libgdal.so.1 was claimed to be missing (it is there, in $HOME/lib, but this is probably not where it is expected to be). Then there was the need for changing the PYTHONPATH, which I can do for myself, but not for the account under which the script is expected to run later... To make a long story short: I will have to convince the system admin to provide a more sustainable fix of these issues and until I have his willingness to do so, I will simply continue with my tmp.gmt workaround. Thanks for the support. It will just take some time before I can benefit from it. Hermann From anja.roesel at zmaw.de Thu Mar 26 11:10:13 2009 From: anja.roesel at zmaw.de (Anja Roesel) Date: Thu Mar 26 11:38:24 2009 Subject: [gdal-dev] again .hdf to .tif Message-ID: <49CB9AD5.3020603@zmaw.de> Hi list, I am trying to convert MODIS .hdf files to .tif files (it worked with ASTER files earlier, thats why I am now really curious). i typed >gdalinfo MOD021KM.A2008134.1935.005.2009071201911.hdf result: ...... SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB SUBDATASET_1_DESC=[15x2030x1354] EV_1KM_RefSB (16-bit unsigned integer) SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB_Uncert_Indexes SUBDATASET_2_DESC= ........ then: >gdalwarp HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB modis.tif Have you any ideas, what is the problem? Thanks, Anja From yann.chemin at gmail.com Thu Mar 26 12:08:13 2009 From: yann.chemin at gmail.com (Yann Chemin) Date: Thu Mar 26 12:08:17 2009 Subject: [gdal-dev] again .hdf to .tif In-Reply-To: <49CB9E51.2020308@sarvision.nl> References: <49CB9B42.6050904@zmaw.de> <4f37eb890903260815q77e41678n3b2830b71b91f50f@mail.gmail.com> <49CB9E51.2020308@sarvision.nl> Message-ID: <4f37eb890903260908w5748fb5fseaf77e79725fd4d8@mail.gmail.com> Yes Vincent, that rings a bell indeed. Thanks, Yann 2009/3/26 Vincent Schut : > Yann Chemin wrote: >> >> Hi there, >> >> I am using this one right now on Level 2 and 3 MODIS products >> >> ------------------------------------------- >> #!/bin/bash >> mkdir processed >> for file in *.hdf >> do SDS_list=$(gdalinfo $file | grep "SUBDATASET_.*_NAME.*") >> ? ? ? ?for subdataset in $SDS_list >> ? ? ? ?do echo ${subdataset#*=} > tempfile.txt >> ? ? ? ?out=$(sed >> 's/\(.*\):\(.*\):"\(.*\).A\(.*\)\.\h\(.*\)\.\(.*\)\.\(.*\).hdf":\(.*\):\(.*\)/\3\_\4\_h\5\_\8\_\9\.tif/' >> tempfile.txt) >> ? ? ? ?gdalwarp -of GTiff -t_srs EPSG:4326 ${subdataset#*=} processed/$out >> ? ? ? ?done >> done >> ------------------------------------- >> >> maybe of help, >> Yann >> >> > > Note that, when you are using modis sinusoidal projected hdf products, you > might have to use something like this to prevent a shift in the y direction > which becomes more pronounced when further from the equator: > > gdalwarp -s_srs '+proj=sinu +R=6371007.181 +nadgrids=@null +wktext' -t_srs > EPSG:4326 > > to force gdalwarp to adjust for the custom ellipsoid that the modis > sinusoidal projection uses. Or, at least, I had to some time ago. It might > have been 'fixed' already. > > Regards, > Vincent. >> >> 2009/3/26 Anja Roesel : >> >>> >>> sorry i forgot to mention the error message: >>> >>>> >>>> Segmentation fault >>>> >>> >>> >>> >>> Hi list, >>> >>> I am trying to convert MODIS .hdf files to .tif files (it worked with >>> ASTER files earlier, thats why I am now really curious). >>> >>> i typed >>> >>> >>>> >>>> gdalinfo MOD021KM.A2008134.1935.005.2009071201911.hdf >>>> >>> >>> result: >>> ...... >>> >>> SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB >>> SUBDATASET_1_DESC=[15x2030x1354] EV_1KM_RefSB (16-bit unsigned integer) >>> >>> SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB_Uncert_Indexes >>> SUBDATASET_2_DESC= >>> ........ >>> >>> then: >>> >>> >>>> >>>> gdalwarp >>>> >>> >>> >>> HDF4_EOS:EOS_SWATH:"MOD021KM.A2008134.1935.005.2009071201911.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB >>> ?modis.tif >>> >>> Have you any ideas, what is the problem? >>> Thanks, >>> Anja >>> >>> _______________________________________________ >>> 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 > -- Yann Chemin Mobile: +33 (06) 10 11 39 26 Home: +33 (02) 35 27 08 20, Address: Gite de Mortagne, 16 rue de la chenaie, 76110 Bec de Mortagne, France Perso: http://www.freewebs.com/ychemin YiKingDo: http://yikingdo.unblog.fr/ From randre at gmail.com Thu Mar 26 12:46:49 2009 From: randre at gmail.com (=?ISO-8859-1?Q?Roger_Andr=E9?=) Date: Thu Mar 26 12:46:52 2009 Subject: [gdal-dev] GDAL TMS minidriver In-Reply-To: <6e41d95b0903260113n5edc46f6uc878d7765d3eaf7b@mail.gmail.com> References: <9c2015090903252321t7b8443ady6186961c87a7bf49@mail.gmail.com> <6e41d95b0903260113n5edc46f6uc878d7765d3eaf7b@mail.gmail.com> Message-ID: <9c2015090903260946k2562ab80xf120ac55b9db1a49@mail.gmail.com> Got it, V 1.7. Thanks. -- 2009/3/26 Klokan Petr P?idal > Roger, > > this patch was done by Christopher Schmidt during Toronto Code Sprint > 2009 in the beginning of this month. > The functionality is available only in gdal-trunk (1.7dev) since r16585. > > Details: > http://trac.osgeo.org/gdal/ticket/2878 > http://crschmidt.net/blog/376/toronto-code-sprint-day-2/ > > If you find a bug in the online documentation feel free to patch it ;-). > > Best reagards, > > Klokan > > 2009/3/26 Roger Andr? : > > Hi All, > > > > I'm trying to use the TMS minidriver to read a TileCache instance and am > > getting an error that says, "GDALWMS: No mini-driver registered for > 'TMS'". > > I'm trying to follow the instructions on > http://www.gdal.org/frmt_wms.html, > > but am a bit confused. At the top of the page it says there are 3 > services > > which are currently supported; WMS, WorldWind, and TileService. However, > > lower in the doc it also mentions TMS, and one of the examples > > http://www.gdal.org/frmt_wms_openstreetmap_tms.xml uses that service > type, > > and looks like it would work with TileCache. > > > > I'm using gdal 1.5.2, is this functionality supported in that version? > > > > Thanks, > > > > Roger > > -- > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > http://blog.klokan.cz/ > http://www.maptiler.org/ > http://www.oldmapsonline.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090326/6f097ecf/attachment.html From even.rouault at mines-paris.org Thu Mar 26 14:25:57 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 26 14:26:08 2009 Subject: [gdal-dev] NITF header writing - not really? In-Reply-To: <49CB817C.3010506@gmail.com> References: <49CB817C.3010506@gmail.com> Message-ID: <200903261925.58715.even.rouault@mines-paris.org> Andrew, The way how to set NITF fields is documented in http://gdal.org/frmt_nitf.html. But I acknowledge this may be a bit confusing, because even if they are reported as metadata items by GDAL, NITF header fields must be set as creation options, not metadata. So if you replace -mo by -co and remove the NITF_ prefix, it should work as you expect. gdal_translate -of NITF -co FTITLE=myspecialvalue infile.ntf outfile.ntf I've updated the doc to make it a bit clearer hopefully. To explain the behaviour you currently observe with the .aux.xml file : the NITF driver doesn't implement the SetMetadata() API, so it just passes it to the PAM layer that can read it / write it from the auxiliary XML file. Best regards. Even Le Thursday 26 March 2009 14:22:04 Andrew Loughhead, vous avez ?crit?: > Does gdal_translate actually write values specified via -mo into the > output NITF files? It seems that metadata fields specified with > -mo get put into the .aux.xml file, but not into the actual output NITF > file. For example: > > gdal_translate -of NITF -mo "NITF_FTITLE="myspecialvalue" infile.ntf > outfile.ntf > > That seems to run, so I do gdalinfo on outfile.ntf. Great, I get: > NITF_FTITLE=myspecialvalue > > But - when I take my NITF into software able to show headers (say, Erdas > Imagine), the FTITLE header appears to be blank. On investigation, it > appears that the run of gdalinfo outfile.ntf is actually just reporting > the contents of outfile.ntf.aux.xml. If I remove that file, and run > gdalinfo outfile.ntf, I get a blank NITF_FTITLE! > > A few headers are getting written into the output NITF file, such as > OSTAID, but even these appear to have hardcoded values, except for > as put in the .aux.xml file. In the case of OSTAID my custom value > gets put into outfile.ntf.aux.xml, and reported by gdalinfo. If > I delete outfile.ntf.aux.xml, and rerun gdalinfo outfile.ntf, the > value GDAL is reported. > > Any ideas or info? > > thanks > Andrew. > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Thu Mar 26 15:58:50 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Thu Mar 26 15:59:02 2009 Subject: [gdal-dev] Re: [mapserver-users] ogr connection to postgis problems In-Reply-To: <681116190903261112y13200f78l87a05f70e73f91f3@mail.gmail.com> References: <681116190903250657y2bcc3604qb1df71e0b83e81d8@mail.gmail.com> <200903252105.52589.even.rouault@mines-paris.org> <681116190903261112y13200f78l87a05f70e73f91f3@mail.gmail.com> Message-ID: <200903262058.51933.even.rouault@mines-paris.org> (Moving it to gdal-dev list as it is really OGR related) Travis, Actually there's one test you didn't make. Can you test this : ogrinfo -ro -al PG:'dbname=fbs user=webserver password=topsecret' canadian_municipalities and this : ogrinfo -al PG:'dbname=fbs user=webserver password=topsecret' canadian_municipalities I suspect the first one will fail with "Unable to open datasource...." and that the second one will succeed but report 0 layer (only : "INFO: Open of `PG:'. Using driver `PostgreSQL' successful.) There must be something wrong (or not correctly handled by OGR) in your table definition. You could check that the column is being properly registered in the Postgis geometry_columns table. But it might be another reason (unhandled Postgres data type for a column, ...). Perhaps you could try again with GDAL 1.6.0 as there were lots of substantial changes done for that release. If it still doesn't work, perhaps you could dump the structure of your canadian_municipalities tables. Accessing the database through the -sql option use different mechanisms from accessing through the layers reported by the OGR PG driver. But generally, "ogrinfo -ro -al PG:'dbname=fbs user=webserver password=topsecret' your_layer" and "ogrinfo -ro PG:'dbname=fbs user=webserver password=topsecret' -sql 'SELECT * FROM your_layer'" should yield to similar results. Best regards, Even Le Thursday 26 March 2009 19:12:22, vous avez ?crit?: > Even > I'm using GDAL 1.5.1, released 2008/03/14 > > This is strange, I can get the -sql to return result but as soon as I > attempt to convert the result to a shp I get a failure > > [root@server34 support]# ogrinfo PG:'dbname=fbs user=webserver > password=topsecre t' -sql "select * from > canadian_municipalities WHERE name = 'OTTAWA'" | more > INFO: Open of `PG:dbname=fbs user=webserver password=topsecret' > using driver `PostgreSQL' successful. > > Layer name: sql_statement > Geometry: Unknown (any) > Feature Count: 1 > Extent: (-75.818115, 45.319733) - (-75.590118, 45.468719) > Layer SRS WKT: > (unknown) > Geometry Column = the_geom > gid: Integer (0.0) > prov: String (0.0) > name: String (0.0) > name_1: String (0.0) > OGRFeature(sql_statement):0 > gid (Integer) = 390 > prov (String) = ON > name (String) = OTTAWA > name_1 (String) = OTTAWA-CARLETON REGIONAL MUNICIPALITY > MULTIPOLYGON (((-75.747100987514116 > 45.357929043660768,-75.747139025748226 45. > 357913967904082,-75.748404955984952 45.357349002525353,-75.749320978319517 > 45.35 6940963375777,-75.750800938009831 45.356312037549................... > > ##################### > > > ogr2ogr ottawa.shp PG:'dbname=fbs user=webserver password=topsecret' > -sql "select * from canadian_municipalities WHERE name = 'OTTAWA'" > FAILURE: > Unable to open datasource `PG:dbname=fbs user=webserver > password=topsecret' with the following drivers. > > 2009/3/25 Even Rouault : > > Travis, > > > > this is really weird. I've reviewed a bit the source of the PG driver and > > the influence of the read-only mode vs update mode is very thin. The only > > behavioural differences are : > > 1) the result of TestCapabilities() method depend on it, but ogrinfo > > doesn't request layer TestCapabilities(). > > 2) if the PG database has no valid tables (for OGR), its opening will > > fail in read-only mode, whereas it would succeed in update mode. > > > > So in your use case, provided that there's at least one table reported by > > ogrinfo in update mode, I don't understand why it fails. What's the > > version of GDAL/OGR you're using ? > > > > Le Wednesday 25 March 2009 19:51:39 Travis Kirstine, vous avez ?crit?: > >> 2009/3/25 Stephen Woodbridge : > >> > Jeff McKenna wrote: > >> >> Travis Kirstine wrote: > >> >>> I am trying to test a connection to a postgis db ?using ogrinfo and > >> >>> am having difficulties. ?I am running the command on the same server > >> >>> that hosts the postgis db. ?I checked the pg_hba.config file to see > >> >>> if it allows local connections and everything looks OK but I still > >> >>> get "Failure" when connecting with ogr. > >> >>> > >> >>> Am I missing something? > >> >>> > >> >>> > >> >>> command > >> >>> ogrinfo -ro PG:'host=server34 dbname=earth user=bob > >> >>> password=suruncle' > >> >> > >> >> My thoughts: > >> >> > >> >> - since you are on the same server, use host=127.0.0.1 > >> >> - include the port parameter (usually port=5432) > >> > > >> > Have you try from the command line: > >> > > >> > psql -h server34 -U bob earth > >> > psql -h localhost -U bob earth > >> > psql -U bob earth > >> > > >> > Should prompt you for the password. > >> > > >> > Only the last on will use the local socket or named pipe. If the last > >> > one works the try: > >> > > >> > ogrinfo -ro PG:'host= dbname=earth user=bob password=suruncle' > >> > ogrinfo -ro PG:'dbname=earth user=bob password=suruncle' > >> > > >> > and see if either of these work. > >> > >> I got the query / connection to work, it seems that the -ro flag was > >> causing the problem > >> which is strange. > >> > >> this works > >> ogrinfo -sql 'SELECT * FROM counties' PG:'host= dbname=earth user=bob > >> password=suruncle' > >> > >> this dosen't > >> ogrinfo -ro -sql 'SELECT * FROM counties' PG:'host= dbname=earth > >> user=bob password=suruncle' > >> > >> I'm not sure what the problem is as the user bob has su privileges > >> > >> > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?List of roles > >> ?Role name | Superuser | Create role | Create DB | Connections | Member > >> of > >> -----------+-----------+-------------+-----------+-------------+-------- > >>--- postgres ?| yes ? ? ? | yes ? ? ? ? | yes ? ? ? | no limit ? ?| bob ? > >> ? ? ? ?| yes ? ? ? | no ? ? ? ? ?| yes ? ? ? | no limit ? ?| From DCarreira at edia.pt Thu Mar 26 19:54:16 2009 From: DCarreira at edia.pt (Duarte Carreira) Date: Thu Mar 26 20:30:12 2009 Subject: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields Message-ID: Hello. As always trying to coerce these two to work together nicely... The situation: exporting ArcSDE feature class to , shapefile, gpx... server: Oracle xe (10), ArcSDE 9.3 sp1, Win2003 Std x32 client: Vista x32, GDAL/OGR 1.6 build 1500 from Tamas site, sde dll's from 9.3 sp1 As you can see below, Oracle describes several fields as being number and nvarchar2, and ogrinfo only identifies numeric fields. All text fields come out as unknown. Now, what could this be due to? Anyone facing the same issue? I tried to use SQL to cast a nvarchar to character without success... Thanks, Duarte Feature class description in Oracle: Column Name Data Type Nullable Default Primary Key OBJECTID NUMBER No - - IDPERC NVARCHAR2(6) Yes - - NOME NVARCHAR2(150) Yes - - DESCRICAO NVARCHAR2(255) Yes - - IDPONTO NVARCHAR2(10) Yes - - IDSIG NUMBER Yes - - XCOORD NUMBER(38,8) Yes - - YCOORD NUMBER(38,8) Yes - - MORADA_COMPLETA NVARCHAR2(255) Yes - - CONCELHO NVARCHAR2(50) Yes - - FREGUESIA NVARCHAR2(50) Yes - - CODPOSTAL NVARCHAR2(10) Yes - - TELEFONE NVARCHAR2(10) Yes - - DESCRICAOPT NVARCHAR2(255) Yes - - NOMEPT NVARCHAR2(150) Yes - - SHAPE ST_GEOMETRY Yes - - 1 - 16 ogrinfo output: Layer name: . Geometry: Unknown (any) ERROR 1: SE_layer_get_statistics: -51/Underlying DBMS error Feature Count: -1 Extent: (6177.862000, -123296.045000) - (63997.354000, -91245.397000) Layer SRS WKT: PROJCS["Datum_73_Hayford_Gauss_IPCC", GEOGCS["GCS_Datum_73", DATUM["Datum_73", SPHEROID["International_1924",6378388.0,297.0]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",180.598], PARAMETER["False_Northing",-86.99], PARAMETER["Central_Meridian",-8.131906111111112], PARAMETER["Scale_Factor",1.0], PARAMETER["Latitude_Of_Origin",39.66666666666666], UNIT["Meter",1.0]] OBJECTID: Integer (10.0) IDPERC: (unknown) (6.0) NOME: (unknown) (50.0) DESCRICAO: (unknown) (50.0) IDLINHA: (unknown) (5.0) SHAPE_LENG: Real (38.8) From apachemaven at yeah.net Thu Mar 26 22:44:54 2009 From: apachemaven at yeah.net (apachemaven) Date: Thu Mar 26 23:15:25 2009 Subject: [gdal-dev] get the info of the hdf4 tranlate hdf4 to tif Message-ID: <23523724.103951238121894901.JavaMail.coremail@yeahapp3.yeah.net> I want to translate the hdf4 to tif ,and use the grass to conert this tif to its own format, then I can contiune my next work, I use the FWTools2.2.8 (which is installed in the F disk.)to handle this,after config the environment ,I run the command "gdalinfo d:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf", it worked , the key inofrmation is : =============== ............... ............... Subdatasets: SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB SUBDATASET_1_DESC=[5x4060x2708] EV_500_RefSB MODIS_SWATH_Type_L1B (16-bit unsigned integer) SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB_Uncert_Indexes SUBDATASET_2_DESC=[5x4060x2708] EV_500_RefSB_Uncert_Indexes MODIS_SWATH_Type_L1B (8-bit unsigned integer) SUBDATASET_3_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB SUBDATASET_3_DESC=[2x4060x2708] EV_250_Aggr500_RefSB MODIS_SWATH_Type_L1B (16-bit unsigned integer) SUBDATASET_4_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes SUBDATASET_4_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Uncert_Indexes MODIS_SWATH_Type_L1B (8-bit unsigned integer) SUBDATASET_5_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Samples_Used SUBDATASET_5_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Samples_Used MODIS_SWATH_Type_L1B (8-bit integer) =============== and now (for example )I want to get the subdataset 4,and translate it to geotiff,before run the gdal_translate I run the gdalinfo again to get the information of it:" gdalinfo HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes" I got the error messages as follows: ======================== C:\Documents and Settings\Administrator>gdalinfo HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes ERROR 4: `HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes' does not exist in the file system,and is not recognised as a supported dataset name. gdalinfo failed - unable to open 'HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245.005.20082751 12555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes'. Open GDAL Datasets: 1 N DriverIsNULL -1 512x512x0 ======================== I want to know why?and if I put the hdf data under the F:\anzhuang\FWTools 2.2.8\bin, I can get the correct result...... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/37fb49d5/attachment-0001.html From warmerdam at pobox.com Thu Mar 26 23:51:59 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Thu Mar 26 23:52:01 2009 Subject: [gdal-dev] GDAL Warp API In-Reply-To: <49CB57D40200004F0000FC81@jeckle> References: <49CB57D40200004F0000FC81@jeckle> Message-ID: <931f8ea90903262051w3dc94e9k44917918bc9b8ff6@mail.gmail.com> On Thu, Mar 26, 2009 at 8:24 AM, Jim Klassen wrote: > I'm trying to do some aerial photo processing specifically converting RAW imagery to DOQs. Right now I have working code that uses GDAL to read/write the rasters and uses my own code to do the actual image processing. I would like to use the Warp API so I can take advantage of the ChunkAndWarpImage method, in particular, it's ability to break the problem down into chunks that will fit into memory. > > The problem I am facing is I can't write the part of the transformer function that converts from destination to source coordinates because the destination coordinate could occur nearly anywhere in the source image and likely will occur more than once. (The source data is from a push broom sensor so each scan line in the image has a different transformation depending on where the plane was and how it was orientated when the scan line was recorded.) From what I can gather, the Warp API is doing this to determine which part(s) of the source image it needs to grab to fill the destination image. In my case, I know that I will want to use the entire source image and have already calculated from the source image the extents destination image, but I don't see a way to tell this to the Warp API. > > So my question: Is there a way to get the Warp API to skip trying to discover the required source image extents or is there a way to write the transformer function to trick the Warp API into just using the entire source image without the transformation having to be mathematically rigorous? Jim, It doesn't help to tell the warp api that you want the whole input image if you are wanting to take advantage of the chunking logic. However, it would likely not be important that you reverse transform be rigerous if you set the SOURCE_EXTRA warp option large enough to account for any likely error. http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08 Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From martin at ceperley.com Thu Mar 26 23:57:36 2009 From: martin at ceperley.com (Martin Ceperley) Date: Thu Mar 26 23:57:43 2009 Subject: [gdal-dev] Coordinate bounds after gdalwarp Message-ID: <0E1EB63B-5575-4019-B4D9-E5263ED27478@ceperley.com> Hello, After running gdalwarp with a bunch of control points, the resulting bitmap's coordinate bounds are slightly cropping off two of the corners and extending far beyond on the right. I am referencing these images for the first time and don't have the necessary bounds before the transformation. Here is a low-res example: http://ceperley.com/temp/OUT.jpg Any flags to correct this within gdalwarp or gdal_transform? Or do any of other command line tools generate projected corner coordinates? Thanks -Martin From warmerdam at pobox.com Fri Mar 27 00:10:40 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 27 00:10:42 2009 Subject: [gdal-dev] NITF header writing - not really? In-Reply-To: <49CB817C.3010506@gmail.com> References: <49CB817C.3010506@gmail.com> Message-ID: <931f8ea90903262110x32e81025ke289d8bfdfe9f7c4@mail.gmail.com> Andrew, I think this is a defect. Could you file a ticket on the issue? Best regards, On Thu, Mar 26, 2009 at 6:22 AM, Andrew Loughhead wrote: > Does gdal_translate actually write values specified via -mo into the > output NITF files? ?It seems that metadata fields specified with > -mo get put into the .aux.xml file, but not into the actual output NITF > file. ?For example: > > gdal_translate -of NITF -mo "NITF_FTITLE="myspecialvalue" infile.ntf > outfile.ntf > > That seems to run, so I do gdalinfo on outfile.ntf. ?Great, I get: > ?NITF_FTITLE=myspecialvalue > > But - when I take my NITF into software able to show headers (say, Erdas > Imagine), the FTITLE header appears to be blank. On investigation, it > appears that the run of gdalinfo outfile.ntf is actually just reporting > the contents of outfile.ntf.aux.xml. ?If I remove that file, and run > gdalinfo outfile.ntf, I get a blank NITF_FTITLE! > > A few headers are getting written into the output NITF file, such as > OSTAID, but even these appear to have hardcoded values, except for > as put in the .aux.xml file. In the case of OSTAID my custom value > gets put into outfile.ntf.aux.xml, and reported by gdalinfo. If > I delete outfile.ntf.aux.xml, and rerun gdalinfo outfile.ntf, the > value GDAL is reported. > > Any ideas or info? > > thanks > Andrew. > > > > _______________________________________________ > 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, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Fri Mar 27 00:34:25 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Fri Mar 27 00:34:26 2009 Subject: [gdal-dev] Coordinate bounds after gdalwarp In-Reply-To: <0E1EB63B-5575-4019-B4D9-E5263ED27478@ceperley.com> References: <0E1EB63B-5575-4019-B4D9-E5263ED27478@ceperley.com> Message-ID: <931f8ea90903262134t444b51e2tf9606805aa820c93@mail.gmail.com> On Thu, Mar 26, 2009 at 8:57 PM, Martin Ceperley wrote: > Hello, > > After running gdalwarp with a bunch of control points, the resulting > bitmap's coordinate bounds are slightly cropping off two of the corners and > extending far beyond on the right. I am referencing these images for the > first time and don't have the necessary bounds before the transformation. > > Here is a low-res example: http://ceperley.com/temp/OUT.jpg > > Any flags to correct this within gdalwarp or gdal_transform? Or do any of > other command line tools generate projected corner coordinates? Martin, You haven't been specific about the type of transformation you are using. I suspect it is a polynomial transformation based on GCPs. These transformations are not exactly inverted by GDAL and so it will often produce moderately incorrect output coordinates. You might try specifying -tps to use thin plate splines instead of polynomials as I believe they are properly inverted. However, they have other behavior problems and may not work out for you. I've been thinking it would be nice if the polynomials were properly inverted in GDAL, but I don't have the math chops to do that without a lot of work. Currently I build an inverse polynomial just by reversing the GCPs and computing a new polynomial. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From wroberts at csir.co.za Fri Mar 27 03:24:35 2009 From: wroberts at csir.co.za (Wesley Roberts) Date: Fri Mar 27 03:25:31 2009 Subject: [gdal-dev] Re: gdal_fillnodata error Message-ID: <49CC9B55020000730001A39D@pta-emo.csir.co.za> Dear list, Sometime last week I posted a question regarding errors associated with gdal_fillnodata. Brent Fraser kindly shared with me some C++ code he had written to approximate the workings of the python gdal_fillnodata app. Through trial and error (and some extra help from Brent) I have finally gotten the code to work and compile using the following command wroberts@wroberts-desktop:/usr/local/gdal/include$ sudo g++ -I/usr/include/gdal gdal_FillNoData.cpp -L/usr/local/gdal/lib -lgdal -o FillNoData unfortunately once compiled I try to run it for usage info and I get the following error wroberts@wroberts-desktop:/usr/local/gdal/include$ ./FillNoData ./FillNoData: error while loading shared libraries: libgdal.so.1: cannot open shared object file: No such file or directory I am a little lost as the file libgdal.so.1 is located in wroberts@wroberts-desktop:/usr/local/gdal/lib$ ls -l total 64212 -rw-r--r-- 1 root root 40876082 2009-03-17 10:09 libgdal.a -rwxr-xr-x 1 root root 1393 2009-03-17 10:09 libgdal.la lrwxrwxrwx 1 root root 17 2009-03-17 10:09 libgdal.so -> libgdal.so.1.13.0 lrwxrwxrwx 1 root root 17 2009-03-17 10:09 libgdal.so.1 -> libgdal.so.1.13.0 -rwxr-xr-x 1 root root 24795259 2009-03-17 10:09 libgdal.so.1.13.0 I now see that libgdal.so.1 is infact a link to another file. Unfortunately I have done a 'find' for libgdal.so.1 and have tried many combinations of paths to gdal lib folders and this is the only one that actually compiles. I would like to use the app to fill the gaps in Landsat ETM+ data (SLC-off). Does anyone on the list have ideas with regards to finding a solution to my problem? Any help would be greatly appreciated. Kind regards, Wesley >>> Brent Fraser 03/26/09 4:38 PM >>> Hi Wesley, I'm not a Linux/gcc user so I likely can't help much. There's two steps to creating an executable: 1. The compile step. gcc needs to be able to find any "include" files referenced in the source code. You've somewhat solved this by compiling in the GDAL include directory. You may want to look into how specify additional include directories on the gcc command line (a -I option?). 2. The link step. gcc needs to be able to find compiled libraries of functions referenced in the c++ code. This is the problem you've shown below. You need to specify the GDAL library on the gcc command line; something like: g++ gdal_FillNoData.cpp -L../lib -lgdal -o fill_no_data I found http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html to be a good gcc intro. And Frank Warmerdam gave some insight in http://n2.nabble.com/gdal_priv.h-not-found-on-ubuntu-td2035784.html Best Regards, Brent Fraser Wesley Roberts wrote: > Hi Brent, > > Many thanks for your code and apologies for not replying sooner, things > have been a little busy here. As you mentioned in your mail the code may > need some tweaking, I received some > > warning: deprecated conversion from string constant to ?char > > errors but have managed to sort those out through trial and error. I > also had trouble with the include files so am now compiling from inside > the gdal directory on usr/local/gdal/include. This is something I will > remedy later on, for now I am receiving the following errors and given > my inexperience using c++ I am not able to correct the code. Could you > please help me? Error is below. > > Many thanks, > Wesley > > > wroberts@wroberts-desktop:/usr/local/gdal/include$ sudo g++ > gdal_FillNoData.cpp -o fill_no_data > /tmp/ccz4jVWn.o: In function `ga_CopyBand(void*, void*, int, int)': > gdal_FillNoData.cpp:(.text+0x14b): undefined reference to > `GDALGetBlockSize' > gdal_FillNoData.cpp:(.text+0x156): undefined reference to > `GDALGetRasterDataType' > gdal_FillNoData.cpp:(.text+0x164): undefined reference to > `GDALGetDataTypeSize' > gdal_FillNoData.cpp:(.text+0x241): undefined reference to `GDALRasterIO' > gdal_FillNoData.cpp:(.text+0x29c): undefined referen> gdal_FillNoData.cpp:(.text+0x2e0): undefined reference to > `GDALGetGeoTransform' > gdal_FillNoData.cpp:(.text+0x2fb): undefined reference to > `GDALSetGeoTransform' > gdal_FillNoData.cpp:(.text+0x306): undefined reference to > `GDALGetProjectionRef' > gdal_FillNoData.cpp:(.text+0x315): undefined reference to > `GDALSetProjection' > /tmp/ccz4jVWn.o: In function `ga_World2Image(double, double, double*, > long*, long*)': > gdal_FillNoData.cpp:(.text+0x38b): undefined reference to > `GDALInvGeoTransform' > gdal_FillNoData.cpp:(.text+0x3b2): undefined reference to > `GDALApplyGeoTransform' > /tmp/ccz4jVWn.o: In function `ga_Image2World(long, long, double*, > double*, double*)': > gdal_FillNoData.cpp:(.text+0x467): undefined reference to > `GDALApplyGeoTransform' > /tmp/ccz4jVWn.o: In function `app_version(_IO_FILE*)': > gdal_FillNoData.cpp:(.text+0x4c1): undefined reference to > `GDALVersionInfo' > /tmp/ccz4jVWn.o: In function `main': > gdal_FillNoData.cpp:(.text+0x66d): undefined reference to > `GDALTermProgress' > gdal_FillNoData.cpp:(.text+0x6c8): undefined reference to > `GDALAllRegister' > gdal_FillNoData.cpp:(.text+0x6e7): undefined reference to > `GDALGeneralCmdLineProcessor' > gdal_FillNoData.cpp:(.text+0x7bc): undefined reference to `CSLAddString' > gdal_FillNoData.cpp:(.text+0x7f2): undefined reference to > `GDALDummyProgress' > gdal_FillNoData.cpp:(.text+0x99d): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xa0e): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xa47): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xa6c): undefined reference to > `GDALOpenShared' > gdal_FillNoData.cpp:(.text+0xa84): undefined reference to > `GDALOpenShared' > gdal_FillNoData.cpp:(.text+0xa92): undefined reference to > `CPLGetLastErrorMsg' > gdal_FillNoData.cpp:(.text+0xa99): undefined reference to > `CPLGetLastErrorNo' > gdal_FillNoData.cpp:(.text+0xabc): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xad3): undefined reference to > `GDALGetRasterXSize' > gdal_FillNoData.cpp:(.text+0xae1): undefined reference to > `GDALGetRasterYSize' > gdal_FillNoData.cpp:(.text+0xb0f): undefined reference to > `GDALGetRasterCount' > gdal_FillNoData.cpp:(.text+0xb74): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xb92): undefined reference to > `GDALGetRasterBand' > gdal_FillNoData.cpp:(.text+0xba0): undefined reference to > `GDALGetRasterDataType' > gdal_FillNoData.cpp:(.text+0xbcf): undefined reference to > `GDALGetMaskBand' > gdal_FillNoData.cpp:(.text+0xbe7): undefined reference to > `GDALOpenShared' > gdal_FillNoData.cpp:(.text+0xc03): undefined reference to > `GDALGetRasterBand' > gdal_FillNoData.cpp:(.text+0xc0d): undefined reference to > `CPLGetLasgdal_FillNoData.cpp:(.text+0xc37): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xc66): undefined reference to > `GDALGetDriverByName' > gdal_FillNoData.cpp:(.text+0xc74): undefined reference to > `CPLGetLastErrorMsg' > gdal_FillNoData.cpp:(.text+0xc7b): undefined reference to > `CPLGetLastErrorNo' > gdal_FillNoData.cpp:(.text+0xc9e): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xce0): undefined reference to `GDALCreate' > gdal_FillNoData.cpp:(.text+0xcee): undefined reference to > `CPLGetLastErrorMsg' > gdal_FillNoData.cpp:(.text+0xcf5): undefined reference to > `CPLGetLastErrorNo' > gdal_FillNoData.cpp:(.text+0xd18): undefined reference to > `GDALDestroyDriverManager' > gdal_FillNoData.cpp:(.text+0xd49): undefined reference to > `GDALGetRasterBand' > gdal_FillNoData.cpp:(.text+0xd85): undefined reference to > `GDALGetRasterNoDataValue' > gdal_FillNoData.cpp:(.text+0xd94): undefined reference to > `GDALSetRasterNoDataValue' > gdal_FillNoData.cpp:(.text+0xdd3): undefined reference to > `GDALFillNodata' > gdal_FillNoData.cpp:(.text+0xdde): undefined referenc> gdal_FillNoData.cpp:(.text+0xe00): undefined reference to `GDALClose' > gdal_FillNoData.cpp:(.text+0xe1a): undefined reference to > `GDALTermProgress' > collect2: ld returned 1 exit status > > >>>> Brent Fraser 03/18/09 11:40 PM >>> > Wesley, > > I had the same problem when dealing with DEMs over the last few days. > I don't know enough about python to make it work, so I coded > gdal_fillnodata in c++ (ish). See attached file. This is barely > debugged, so it may need some fixes to work for you. > > Brent Fraser > GeoAnalytic Inc. > > > Wesley Roberts wrote: >> Dear List, >> >> Yesterday I did an install of the latest svn gdal release (think it is > 1.7) to my local machine. I am interested in using the > gdal_fillnodata.py application to fill some lines in my Landsat 7 ETM > data. When I run the code >> python gdal_fillnodata.py -md 400 > /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.img > /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.fill.img >> I get the following error >> >> gdal.FillNodata() not available. You are likely using "old gen" >> bindings or an older version of the next gen bindings. >> >> I am not sure what this means, could somebody suggest a solution or > work around. I am currently trying r.fillnulls in Grass and that is > taking a really long time. >> Many thanks for your help and input, >> Wesley >> >> Wesley Roberts MSc. >> Researcher: Earth Observation (Ecosystems) >> Natural Resources and the Environment >> CSIR >> Tel: +27 (21) 888-2490 >> Fax: +27 (21) 888-2693 >> >> "To know the road ahead, ask those coming back." >> - Chinese proverb >> >> > > -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From apachemaven at yeah.net Fri Mar 27 03:33:09 2009 From: apachemaven at yeah.net (apachemaven) Date: Fri Mar 27 03:33:16 2009 Subject: [gdal-dev] creat a temp workplace Message-ID: <21686070.76661238139189556.JavaMail.coremail@yeahapp6.yeah.net> I am sorry to send again,because in the last email,I have not describe my problem exectly,and sent it .... ----------------------------------------------------------------------------------------------------- I want to handle some hdf data through a web service,and in the web service I handle the data by grass, so the problem comes out.The following is my setps: 1)translate the hdf4 to a tif by a FWTools2.2.8 which call the gdal command actually) for example I use the command "gdal_translate [the subset] d:\aa.tif" , 2)import the tif "r.in.gdal input=D:/aaa6.tif output=ggg" 3)process the ggg data of grass format for example "r.buffer map=ggg distance=30 output=temp" 4)convert the temp to tif "r.out.gdal input=temp format=GTiff output=d:/dd.tif" Then in the web service I return the url of the dd.tif to client. I want to know the above setps right or not? and in the step of 2 and 4 problems always come out..,a common problem is the data is blank even I reset the region use "g.region rast=..." And in the step 2, I want to creat a temp location and mapset,beacuse my current location is the spanish example data... My god,I am crazying@@! Ps: Thanks Nikos Alexandris very much,since I send my problem ,he always reply me quickly and never lose her(his) pacitient... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/d563c7a8/attachment-0001.html From sud at LIFA.DK Fri Mar 27 03:46:22 2009 From: sud at LIFA.DK (Sune Dogan, LIFA A/S) Date: Fri Mar 27 03:47:54 2009 Subject: [gdal-dev] ogr2ogr C# Message-ID: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> Hi Im developing a .NET C# project and need to convert from GML to ESRI Shape Simply i want to run this command: ogr2ogr -skipfailures -f "ESRI Shapefile" C:\shapefile.shp c:\gmlfile.gml which works fine from the FWTool Command tool. But i just want to do i in my application, can any one help me? Thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/aec0ff63/attachment.html From apachemaven at yeah.net Fri Mar 27 03:25:21 2009 From: apachemaven at yeah.net (apachemaven) Date: Fri Mar 27 03:56:20 2009 Subject: [gdal-dev] create a workplace (location mapset etc)_ Message-ID: <9818958.75091238138721787.JavaMail.coremail@yeahapp6.yeah.net> I want to handle some hdf data through a web service,and in the web service I handle the data by grass, so the problem comes out.The following is my setps: 1)translate the hdf4 to a tif by a FWTools2.2.8 which call the gdal command actually) for example I use the command "gdal_translate [the subset] d:\aa.tif" , 2)import the tif "r.in.gdal input=D:/aaa6.tif output=ggg" 3)process the ggg data of grass format for example "r.buffer map=ggg distance=30 output=temp" 4)convert the temp to tif "r.out.gdal input=temp format=GTiff output=d:/dd.tif" Then in the web service I return the url of the dd.tif to client. I want to know the above setps right or not? and in the step of 2 and 4 problems always come out..,a common problem is the data is blank even I reset the region use "g.region rast=..." My god,I am crazying@@! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/00e50c36/attachment.html From wroberts at csir.co.za Fri Mar 27 04:52:24 2009 From: wroberts at csir.co.za (Wesley Roberts) Date: Fri Mar 27 04:53:34 2009 Subject: [gdal-dev] Re: gdal_fillnodata error Message-ID: <49CCAFEB020000730001A3AA@pta-emo.csir.co.za> Hi Vincent and List, You are correct, the library was not in my path and the command you suggested worked perfectly. I think the problem lies in the number of versions of gdal I have installed on my machine. I have a recently downloaded svn version of gdal, gdal 1.5.2 and gdal 1.4.4. Version 1.4.4 was installed using synaptic (Ubuntu Hardy Heron), the svn version and 1.5.2 are both local installs compiled from source. gdal_translate etc all find their libraries from the synaptic version (I tried to find these but could not??) while FillNoData now gets its libraries from a local install. Managing the different versions is perhaps the source of my problem. I am in the process of learning to use OTB which requires gdal 1.5.2 and I downloaded the svn version of gdal for the original gdal_fillnodata which I could not get going, hence my previous mail regarding that. So yes, perhaps I need to manage my installs a bit better. Having said all this I now get a segmentation fault when I run the prog... will investigate to see what the problem is Many thanks to Brent and Vincent for your help, much appreciated Wesley Wesley Roberts MSc. Researcher: Earth Observation (Ecosystems) Natural Resources and the Environment CSIR Tel: +27 (21) 888-2490 Fax: +27 (21) 888-2693 "To know the road ahead, ask those coming back." - Chinese proverb >>> Vincent Schut 03/27/09 9:46 AM >>> Wesley Roberts wrote: > Dear list, > > Sometime last week I posted a question regarding errors associated with > gdal_fillnodata. Brent Fraser kindly shared with me some C++ code he had > written to approximate the workings of the python gdal_fillnodata app. > Through trial and error (and some extra help from Brent) I have finally > gotten the code to work and compile using the following command > > wroberts@wroberts-desktop:/usr/local/gdal/include$ sudo g++ > -I/usr/include/gdal gdal_FillNoData.cpp -L/usr/local/gdal/lib -lgdal -o > FillNoData > > unfortunately once compiled I try to run it for usage info and I get the > following error > > wroberts@wroberts-desktop:/usr/local/gdal/include$ ./FillNoData > ./FillNoData: error while loading shared libraries: libgdal.so.1: cannot > open shared object file: No such file or directory > > I am a little lost as the file libgdal.so.1 is located in > > wroberts@wroberts-desktop:/usr/local/gdal/lib$ ls -l > total 64212 > -rw-r--r-- 1 root root 40876082 2009-03-17 10:09 libgdal.a > -rwxr-xr-x 1 root root 1393 2009-03-17 10:09 libgdal.la > lrwxrwxrwx 1 root root 17 2009-03-17 10:09 libgdal.so -> > libgdal.so.1.13.0 > lrwxrwxrwx 1 root root 17 2009-03-17 10:09 libgdal.so.1 -> > libgdal.so.1.13.0 > -rwxr-xr-x 1 root root 24795259 2009-03-17 10:09 libgdal.so.1.13.0 > > I now see that libgdal.so.1 is infact a link to another file. > Unfortunately I have done a 'find' for libgdal.so.1 and have tried many > combinations of paths to gdal lib folders and this is the only one that > actually compiles. > Hi Wesley, it being a link is fine. First thing to check is if this directory '/usr/local/gdal/libs' is in your library search path. Check it by running your program as follows: LD_LIBRARY_PATH=/usr/local/gdal/lib ./FillNoData If this does not give you this error, the problem is your lib search path (I wonder however how your other gdal utilities, think gdal_translate etc. *do* find this lib then???). To add a directory to your system's lib search path permanently, you can (as root) add it to the file /etc/ld.so.conf. For a less permanent solution you could export it from your ~/.bashrc I think. If it still does not work, please report back to the list. Regards, Vincent. > I would like to use the app to fill the gaps in Landsat ETM+ data > (SLC-off). > > Does anyone on the list have ideas with regards to finding a solution to > my problem? Any help would be greatly appreciated. > > Kind regards, > Wesley > > > >>>> Brent Fraser 03/26/09 4:38 P> steps to creating an executable: > > 1. The compile step. gcc needs to be able to find any "include" files > referenced in the source code. You've somewhat solved this by compiling > in the GDAL include directory. You may want to look into how specify > additional include directories on the gcc command line (a -I option?). > > 2. The link step. gcc needs to be able to find compiled libraries of > functions referenced in the c++ code. This is the problem you've shown > below. You need to specify the GDAL library on the gcc command line; > something like: > > g++ gdal_FillNoData.cpp -L../lib -lgdal -o fill_no_data > > > I found http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html > to be a good gcc intro. And Frank Warmerdam gave some insight in > http://n2.nabble.com/gdal_priv.h-not-found-on-ubuntu-td2035784.html > > Best Regards, > Brent Fraser > > > Wesley Roberts wrote: > >> Hi Brent, >> >> Many thanks for your code and apologies for not replying sooner, >> > things > >> have been a little busy here. As you mentioned in your mail the code >> > may > >> need some tweaking, I received some >> >> warning: deprecated conversion from string constant to ?char >> >> errors but have managed to sort those out through trial and error. I >> also had trouble with the include files so am now compiling from >> > inside > >> the gdal directory on usr/local/gdal/include. This is something I will >> remedy later on, for now I am receiving the following errors and given >> my inexperience using c++ I am not able to correct the code. Could you >> please help me? Error is below. >> >> Many thanks, >> Wesley >> >> >> wroberts@wroberts-desktop:/usr/local/gdal/include$ sudo g++ >> gdal_FillNoData.cpp -o fill_no_data >> /tmp/ccz4jVWn.o: In function `ga_CopyBand(void*, void*, int, int)': >> gdal_FillNoData.cpp:(.text+0x14b): undefined reference to >> `GDALGetBlockSize' >> gdal_FillNoData.cpp:(.text+0x156): undefined reference to >> `GDALGetRasterDataType' >> gdal_FillNoData.cpp:(.text+0x164): undefined reference to >> `GDALGetDataTypeSize' >> gdal_FillNoData.cpp:(.text+0x241): undefined reference to >> > `GDALRasterIO' > >> gdal_FillNoData.cpp:(.text+0x29c): undefined referen> gdal_FillNoData.cpp:(.text+0x2e0): undefined reference to >> `GDALGetGeoTransform' >> gdal_FillNoData.cpp:(.text+0x2fb): undefined reference to >> `GDALSetGeoTransform' >> gdal_FillNoData.cpp:(.text+0x306): undefined reference to >> `GDALGetProjectionRef' >> gdal_FillNoData.cpp:(.text+0x315): undefined reference to >> `GDALSetProjection' >> /tmp/ccz4jVWn.o: In function `ga_World2Image(double, double, double*, >> long*, long*)': >> gdal_FillNoData.cpp:(.text+0x38b): undefined reference to >> `GDALInvGeoTransform' >> gdal_FillNoData.cpp:(.text+0x3b2): undefined reference to >> `GDALApplyGeoTransform' >> /tmp/ccz4jVWn.o: In function `ga_Image2World(long, long, double*, >> double*, double*)': >> gdal_FillNoData.cpp:(.text+0x467): undefined reference to >> `GDALApplyGeoTransform' >> /tmp/ccz4jVWn.o: In function `app_version(_IO_FILE*)': >> gdal_FillNoData.cpp:(.text+0x4c1): undefined reference to >> `GDALVersionInfo' >> /tmp/ccz4jVWn.o: In function `main': >> gdal_FillNoData.cpp:(.text+0x66d): undefined reference to >> `GDALTermProgress' >> gdal_FillNoData.cpp:(.text+0x6c8): undefined reference to >> `GDALAllRegister' >> gdal_FillNoData.cpp:(.text+0x6e7): undefined reference to >> `GDALGeneralCmdLineProcessor' >> gdal_FillNoData.cpp:(.text+0x7bc): undefined reference to >> > `CSLAddString' > >> gdal_FillNoData.cpp:(.text+0x7f2): undefined reference to >> `GDALDummyProgress' >> gdal_FillNoData.cpp:(.text+0x99d): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xa0e): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xa47): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xa6c): undefined ref>> gdal_FillNoData.cpp:(.text+0xa92): undefined reference to >> `CPLGetLastErrorMsg' >> gdal_FillNoData.cpp:(.text+0xa99): undefined reference to >> `CPLGetLastErrorNo' >> gdal_FillNoData.cpp:(.text+0xabc): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xad3): undefined reference to >> `GDALGetRasterXSize' >> gdal_FillNoData.cpp:(.text+0xae1): undefined reference to >> `GDALGetRasterYSize' >> gdal_FillNoData.cpp:(.text+0xb0f): undefined reference to >> `GDALGetRasterCount' >> gdal_FillNoData.cpp:(.text+0xb74): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xb92): undefined reference to >> `GDALGetRasterBand' >> gdal_FillNoData.cpp:(.text+0xba0): undefined reference to >> `GDALGetRasterDataType' >> gdal_FillNoData.cpp:(.text+0xbcf): undefined reference to >> `GDALGetMaskBand' >> gdal_FillNoData.cpp:(.text+0xbe7): undefined reference to >> `GDALOpenShared' >> gdal_FillNoData.cpp:(.text+0xc03): undefined reference to >> `GDALGetRasterBand' >> gdal_FillNoData.cpp:(.text+0xc0d): undefined reference to >> `CPLGetLasgdal_FillNoData.cpp:(.text+0xc37): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xc66): undefined reference to >> `GDALGetDriverByName' >> gdal_FillNoData.cpp:(.text+0xc74): undefined reference to >> `CPLGetLastErrorMsg' >> gdal_FillNoData.cpp:(.text+0xc7b): undefined reference to >> `CPLGetLastErrorNo' >> gdal_FillNoData.cpp:(.text+0xc9e): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xce0): undefined reference to `GDALCreate' >> gdal_FillNoData.cpp:(.text+0xcee): undefined reference to >> `CPLGetLastErrorMsg' >> gdal_FillNoData.cpp:(.text+0xcf5): undefined reference to >> `CPLGetLastErrorNo' >> gdal_FillNoData.cpp:(.text+0xd18): undefined reference to >> `GDALDestroyDriverManager' >> gdal_FillNoData.cpp:(.text+0xd49): undefined reference to >> `GDALGetRasterBand' >> gdal_FillNoData.cpp:(.text+0xd85): undefined reference to >> `GDALGetRasterNoDataValue' >> gdal_FillNoData.cpp:(.text+0xd94): undefined reference to >> `GDALSetRasterNoDataValue' >> gdal_FillNoData.cpp:(.text+0xdd3): undefined reference to >> `GDALFillNodata' >> gdal_FillNoData.cpp:(.text+0xdde): undefined referenc> gdal_FillNoData.cpp:(.text+0xe00): undefined reference to `GDALClose' >> gdal_FillNoData.cpp:(.text+0xe1a): undefined reference to >> `GDALTermProgress' >> collect2: ld returned 1 exit status >> >> >> >>>>> Brent Fraser 03/18/09 11:40 PM >>> >>>>> >> Wesley, >> >> I had the same problem when dealing with DEMs over the last few >> > days. > >> I don't know enough about python to make it work, so I coded >> gdal_fillnodata in c++ (ish). See attached file. This is barely >> debugged, so it may need some fixes to work for you. >> >> Brent Fraser >> GeoAnalytic Inc. >> >> >> Wesley Roberts wrote: >> >>> Dear List, >>> >>> Yesterday I did an install of the latest svn gdal release (think it >>> > is > >> 1.7) to my local machine. I am interested in using the >> gdal_fillnodata.py application to fill some lines in my Landsat 7 ETM >> data. When I run the code >> >>> python gdal_fillnodata.py -md 400 >>> > /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.img > > /home/wroberts/wes2006/Projects/Evapotranspiration/Data/Landsat_NDVI/test.fill.img > >>> I get the following error >>> >>> gdal.FillNodata() not available. You are likely using "old gen" >>> bindings or an older version of the next gen bindings. >>> >>> I am not sure what this means, could somebody suggest a solution or >>> >> work around. I am currently trying r.fillnulls in Grass and that is >> taking a really long time. >> >>> Many thanks for your help and input, >>> Wesley >>> >>> Wesley Roberts MSc. >>> Researcher: Earth Observation (Ecosystems) >>> Natural Resources and the Environment >>> CSIR >>> Tel>>> - Chinese proverb >>> >>> >>> >> > > > -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From schut at sarvision.nl Fri Mar 27 05:31:53 2009 From: schut at sarvision.nl (Vincent Schut) Date: Fri Mar 27 05:31:58 2009 Subject: [gdal-dev] Re: gdal_fillnodata error In-Reply-To: <49CCAFEB020000730001A3AA@pta-emo.csir.co.za> References: <49CCAFEB020000730001A3AA@pta-emo.csir.co.za> Message-ID: <49CC9D09.80706@sarvision.nl> Wesley Roberts wrote: > Hi Vincent and List, > > You are correct, the library was not in my path and the command you > suggested worked perfectly. I think the problem lies in the number of > versions of gdal I have installed on my machine. I have a recently > downloaded svn version of gdal, gdal 1.5.2 and gdal 1.4.4. Version 1.4.4 > was installed using synaptic (Ubuntu Hardy Heron), the svn version and > 1.5.2 are both local installs compiled from source. gdal_translate etc > all find their libraries from the synaptic version (I tried to find > these but could not??) while FillNoData now gets its libraries from a > local install. Managing the different versions is perhaps the source of > my problem. I am in the process of learning to use OTB which requires > gdal 1.5.2 Note that current versions of OTB from their hg repostitory *do* work for me with svn gdal (need to do a clean ccmake and build for OTB though, ccmake will pick up your gdal alright and for me the previous errors are gone). That might save you one extra gdal version on your system... Vincent. From szekerest at gmail.com Fri Mar 27 05:39:07 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Fri Mar 27 05:39:10 2009 Subject: [gdal-dev] ogr2ogr C# In-Reply-To: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> References: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> Message-ID: Hi, You'll have to re-implement the logic in ogr2ogr.cpp by using the ogr_csharp.dll. Refer to the following thread for more information: http://thread.gmane.org/gmane.comp.gis.gdal.devel/11789 Best regards, Tamas 2009/3/27 Sune Dogan, LIFA A/S > Hi > > Im developing a .NET C# project and need to convert from GML to ESRI Shape > > > Simply i want to run this command: > > ogr2ogr -skipfailures -f "ESRI Shapefile" C:\shapefile.shp c:\gmlfile.gml > > which works fine from the FWTool Command tool. > > But i just want to do i in my application, can any one help me? > > Thanks :) > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/53610eda/attachment-0001.html From DCarreira at edia.pt Fri Mar 27 05:44:13 2009 From: DCarreira at edia.pt (Duarte Carreira) Date: Fri Mar 27 06:13:25 2009 Subject: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields In-Reply-To: References: Message-ID: I'm correcting the subject of the message - the problem is with NVARCHAR fields (not varchar2). It seems this relates to utf issues/limitations in ogr. If I could use SQL functions this could be solved by the database itself. Like using TO_CHAR(field_name) or TRANSLATE(field_name USING CS_CHAR). But it seems ogr does not support these sql functions/operators... Any additional suggestions? Thanks, Duarte -----Mensagem original----- De: Duarte Carreira [mailto:DCarreira@edia.pt] Enviada: quinta-feira, 26 de Mar?o de 2009 23:54 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields Hello. As always trying to coerce these two to work together nicely... The situation: exporting ArcSDE feature class to , shapefile, gpx... server: Oracle xe (10), ArcSDE 9.3 sp1, Win2003 Std x32 client: Vista x32, GDAL/OGR 1.6 build 1500 from Tamas site, sde dll's from 9.3 sp1 As you can see below, Oracle describes several fields as being number and nvarchar2, and ogrinfo only identifies numeric fields. All text fields come out as unknown. Now, what could this be due to? Anyone facing the same issue? I tried to use SQL to cast a nvarchar to character without success... Thanks, Duarte Feature class description in Oracle: Column Name Data Type Nullable Default Primary Key OBJECTID NUMBER No - - IDPERC NVARCHAR2(6) Yes - - NOME NVARCHAR2(150) Yes - - DESCRICAO NVARCHAR2(255) Yes - - IDPONTO NVARCHAR2(10) Yes - - IDSIG NUMBER Yes - - XCOORD NUMBER(38,8) Yes - - YCOORD NUMBER(38,8) Yes - - MORADA_COMPLETA NVARCHAR2(255) Yes - - CONCELHO NVARCHAR2(50) Yes - - FREGUESIA NVARCHAR2(50) Yes - - CODPOSTAL NVARCHAR2(10) Yes - - TELEFONE NVARCHAR2(10) Yes - - DESCRICAOPT NVARCHAR2(255) Yes - - NOMEPT NVARCHAR2(150) Yes - - SHAPE ST_GEOMETRY Yes - - 1 - 16 ogrinfo output: Layer name: .
Geometry: Unknown (any) ERROR 1: SE_layer_get_statistics: -51/Underlying DBMS error Feature Count: -1 Extent: (6177.862000, -123296.045000) - (63997.354000, -91245.397000) Layer SRS WKT: PROJCS["Datum_73_Hayford_Gauss_IPCC", GEOGCS["GCS_Datum_73", DATUM["Datum_73", SPHEROID["International_1924",6378388.0,297.0]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",180.598], PARAMETER["False_Northing",-86.99], PARAMETER["Central_Meridian",-8.131906111111112], PARAMETER["Scale_Factor",1.0], PARAMETER["Latitude_Of_Origin",39.66666666666666], UNIT["Meter",1.0]] OBJECTID: Integer (10.0) IDPERC: (unknown) (6.0) NOME: (unknown) (50.0) DESCRICAO: (unknown) (50.0) IDLINHA: (unknown) (5.0) SHAPE_LENG: Real (38.8) From isajmeri at rediffmail.com Fri Mar 27 06:06:46 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Fri Mar 27 06:14:10 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <20090327100646.33749.qmail@f4mail-234-238.rediffmail.com> Dear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/e789e7aa/attachment.html From michael.smith at usace.army.mil Fri Mar 27 06:22:00 2009 From: michael.smith at usace.army.mil (Michael Smith) Date: Fri Mar 27 06:23:04 2009 Subject: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields In-Reply-To: Message-ID: Duarte, Why not create a view that has the TRANSLATE and TO_CHAR and then use that in OGR. Mike -- Michael Smith RSGIS Center ERDC - CRREL US Army Corps of Engineers On 3/27/09 5:44 AM, "Duarte Carreira" wrote: > I'm correcting the subject of the message - the problem is with NVARCHAR > fields (not varchar2). > It seems this relates to utf issues/limitations in ogr. > > If I could use SQL functions this could be solved by the database itself. Like > using TO_CHAR(field_name) or TRANSLATE(field_name USING CS_CHAR). But it seems > ogr does not support these sql functions/operators... > > Any additional suggestions? > > Thanks, > Duarte > > -----Mensagem original----- > De: Duarte Carreira [mailto:DCarreira@edia.pt] > Enviada: quinta-feira, 26 de Mar?o de 2009 23:54 > Para: gdal-dev@lists.osgeo.org > Assunto: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields > > Hello. > > As always trying to coerce these two to work together nicely... > > The situation: exporting ArcSDE feature class to , shapefile, gpx... > server: Oracle xe (10), ArcSDE 9.3 sp1, Win2003 Std x32 > client: Vista x32, GDAL/OGR 1.6 build 1500 from Tamas site, sde dll's from 9.3 > sp1 > > As you can see below, Oracle describes several fields as being number and > nvarchar2, and ogrinfo only identifies numeric fields. All text fields come > out as unknown. > > Now, what could this be due to? Anyone facing the same issue? I tried to use > SQL to cast a nvarchar to character without success... > > Thanks, > Duarte > > Feature class description in Oracle: > Column Name Data Type Nullable Default Primary Key > OBJECTID NUMBER No - - > IDPERC NVARCHAR2(6) Yes - - > NOME NVARCHAR2(150) Yes - - > DESCRICAO NVARCHAR2(255) Yes - - > IDPONTO NVARCHAR2(10) Yes - - > IDSIG NUMBER Yes - - > XCOORD NUMBER(38,8) Yes - - > YCOORD NUMBER(38,8) Yes - - > MORADA_COMPLETA NVARCHAR2(255) Yes - - > CONCELHO NVARCHAR2(50) Yes - - > FREGUESIA NVARCHAR2(50) Yes - - > CODPOSTAL NVARCHAR2(10) Yes - - > TELEFONE NVARCHAR2(10) Yes - - > DESCRICAOPT NVARCHAR2(255) Yes - - > NOMEPT NVARCHAR2(150) Yes - - > SHAPE ST_GEOMETRY Yes - - > 1 - 16 > > ogrinfo output: > Layer name: .
> Geometry: Unknown (any) > ERROR 1: SE_layer_get_statistics: -51/Underlying DBMS error > Feature Count: -1 > Extent: (6177.862000, -123296.045000) - (63997.354000, -91245.397000) > Layer SRS WKT: > PROJCS["Datum_73_Hayford_Gauss_IPCC", > GEOGCS["GCS_Datum_73", > DATUM["Datum_73", > SPHEROID["International_1924",6378388.0,297.0]], > PRIMEM["Greenwich",0.0], > UNIT["Degree",0.0174532925199433]], > PROJECTION["Transverse_Mercator"], > PARAMETER["False_Easting",180.598], > PARAMETER["False_Northing",-86.99], > PARAMETER["Central_Meridian",-8.131906111111112], > PARAMETER["Scale_Factor",1.0], > PARAMETER["Latitude_Of_Origin",39.66666666666666], > UNIT["Meter",1.0]] > OBJECTID: Integer (10.0) > IDPERC: (unknown) (6.0) > NOME: (unknown) (50.0) > DESCRICAO: (unknown) (50.0) > IDLINHA: (unknown) (5.0) > SHAPE_LENG: Real (38.8) > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From bea at ixsea.com Fri Mar 27 06:33:42 2009 From: bea at ixsea.com (=?iso-8859-1?Q?Beno=EEt_Andrieu?=) Date: Fri Mar 27 06:59:22 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <20090327100646.33749.qmail@f4mail-234-238.rediffmail.com> References: <20090327100646.33749.qmail@f4mail-234-238.rediffmail.com> Message-ID: <6A1BF916A2C34F63A7D41203F333D5C9@ixsea.local> Hi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html. It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AM Subject: [gdal-dev] How to use GDAL Library Dear all, I want to use GDAL library in my project using QT. How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc) please help me. Thanks in advance ------------------------------------------------------------------------------ _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/e511977e/attachment.html From isajmeri at rediffmail.com Fri Mar 27 10:11:20 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Fri Mar 27 10:18:44 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <1238153162.S.8403.10312.f4mail-235-216.rediffmail.com.old.replied.1238163080.28007@webmail.rediffmail.com> Hi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/55360a21/attachment.html From rkgeorge at cadmaps.com Fri Mar 27 10:43:34 2009 From: rkgeorge at cadmaps.com (Randy George) Date: Fri Mar 27 10:51:02 2009 Subject: [gdal-dev] ogr2ogr C# In-Reply-To: References: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> Message-ID: <049f01c9aeea$69b17e70$3d147b50$@com> Or do something ugly like use a .asmx to call your ogr2ogr cmdline as a Process: using System; using System.Web.Services; using System.Text; using System.IO; using System.Diagnostics; using System.Threading; using System.Security.Permissions; [WebService(Namespace = "http://www.myserver.com/ShpView")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [System.Web.Script.Services.ScriptService] [SecurityPermissionAttribute(SecurityAction.LinkDemand, Unrestricted = true)] public class RunTranslate : System.Web.Services.WebService { private static string basepath = "E:/ShpView/"; private static string pass = "pass"; private static string db = "DBname"; public RunTranslate () { } private delegate string StringDelegate(); [WebMethod] public string PostGISLoadCommand(string shp, string epsg) { string fileName = "E:/ShpView/ogr/bin/ogr2ogr"; string arguments = "-f PostgreSQL PG:\"user=user dbname="+db+" host=localhost password="+pass+" port=5432\" " + basepath + "/shpview/data/shape/" + shp + ".shp -a_srs \"" + epsg + "\" -overwrite"; return Run(fileName, arguments); } private static string Run(string fileName, string arguments) { string results = ""; string error = ""; Process cmdLineProcess = new Process(); using (cmdLineProcess) { cmdLineProcess.StartInfo.FileName = fileName; cmdLineProcess.StartInfo.Arguments = arguments; cmdLineProcess.StartInfo.UseShellExecute = false; cmdLineProcess.StartInfo.CreateNoWindow = true; cmdLineProcess.StartInfo.RedirectStandardOutput = true; cmdLineProcess.StartInfo.RedirectStandardError = true; if (cmdLineProcess.Start()) { StringDelegate outputStreamAsyncReader = new StringDelegate(cmdLineProcess.StandardOutput.ReadToEnd); StringDelegate errorStreamAsyncReader = new StringDelegate(cmdLineProcess.StandardError.ReadToEnd); IAsyncResult outAR = outputStreamAsyncReader.BeginInvoke(null, null); IAsyncResult errAR = errorStreamAsyncReader.BeginInvoke(null, null); if (Thread.CurrentThread.GetApartmentState() == ApartmentState.STA) { while (!(outAR.IsCompleted && errAR.IsCompleted)) { Thread.Sleep(10); } } else { WaitHandle[] arWaitHandles = new WaitHandle[2]; arWaitHandles[0] = outAR.AsyncWaitHandle; arWaitHandles[1] = errAR.AsyncWaitHandle; if (!WaitHandle.WaitAll(arWaitHandles)) { error = String.Format("Command line aborted: {0}", fileName); } } results = outputStreamAsyncReader.EndInvoke(outAR); error = errorStreamAsyncReader.EndInvoke(errAR); if (!cmdLineProcess.HasExited) { cmdLineProcess.WaitForExit(); } } else { error = String.Format("Could not start command line process: {0}", fileName); } cmdLineProcess.Close(); } return "Done: " + error + " " + results; } } From: gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Tamas Szekeres Sent: Friday, March 27, 2009 3:39 AM To: Sune Dogan, LIFA A/S Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] ogr2ogr C# Hi, You'll have to re-implement the logic in ogr2ogr.cpp by using the ogr_csharp.dll. Refer to the following thread for more information: http://thread.gmane.org/gmane.comp.gis.gdal.devel/11789 Best regards, Tamas 2009/3/27 Sune Dogan, LIFA A/S Hi Im developing a .NET C# project and need to convert from GML to ESRI Shape Simply i want to run this command: ogr2ogr -skipfailures -f "ESRI Shapefile" C:\shapefile.shp c:\gmlfile.gml which works fine from the FWTool Command tool. But i just want to do i in my application, can any one help me? Thanks :) _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/ca05c143/attachment-0001.html From nbarker at ittvis.com Fri Mar 27 11:52:43 2009 From: nbarker at ittvis.com (Norman Barker) Date: Fri Mar 27 12:21:58 2009 Subject: [gdal-dev] suitable test viewer for new driver Message-ID: Hi, I have written a gdal driver and would like to hook this into an existing viewer (public domain) to demonstrate the code. The driver makes a fair few changes to the GDAL API so it isn't as simple as just adding to the format list. Would I be better to use openev or openev2, or perhaps a different viewer? Any ideas are appreciated, I would like to use a viewer that compiles against the current GDAL trunk. Thanks, Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/926a5041/attachment.html From ivan.lucena at pmldnet.com Fri Mar 27 14:02:14 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Fri Mar 27 14:02:19 2009 Subject: [gdal-dev] python-gdal ComputStatistics return just two values Message-ID: <20090327180214.22787.qmail@s466.sureserver.com> Hi there, I believe that ComputeBandStats() should return 4 values min, max, mean and stddev) [1] but the Python API is returning just mean and stddev. python: >>> bd.ComputeBandStats() (9.0071713001936118, 11.350094331448236) >>> bd.ComputeRasterMinMax() (-1.7899999618530273, 31.149999618530273) gdalinfo: Band 1 Block=360x1 Type=Float32, ColorInterp=Gray Min=-1.790 Max=31.150 Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 Unit Type: unspecified Metadata: STATISTICS_MINIMUM=-1.789999961853 STATISTICS_MAXIMUM=31.14999961853 STATISTICS_MEAN=9.0071713001936 STATISTICS_STDDEV=11.350094331448 Is that a bug? See what happens in that case: >>> bd1.SetStatistics(bd2.ComputeBandStats()) Traceback (most recent call last): File "", line 1, in File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in SetStatistics return _gdal.Band_SetStatistics(*args) TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) My best regards, Ivan [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 From even.rouault at mines-paris.org Fri Mar 27 14:45:05 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 27 14:45:15 2009 Subject: [gdal-dev] python-gdal ComputStatistics return just two values In-Reply-To: <20090327180214.22787.qmail@s466.sureserver.com> References: <20090327180214.22787.qmail@s466.sureserver.com> Message-ID: <200903271945.06134.even.rouault@mines-paris.org> Hi Ivan, I don't think there's a bug. The C API for ComputeBandStats is : CPLErr CPL_DLL CPL_STDCALL GDALComputeBandStats( GDALRasterBandH hBand, int nSampleStep, double *pdfMean, double *pdfStdDev, GDALProgressFunc pfnProgress, void *pProgressData ); So, the python API is consistant with it. So it is expected that "bd1.SetStatistics(bd2.ComputeBandStats())" will fail as it is provided with 2 values instead of the expected 4. Best regards, Even Le Friday 27 March 2009 19:02:14 Lucena, Ivan, vous avez ?crit?: > Hi there, > > I believe that ComputeBandStats() should return 4 values min, max, mean and > stddev) [1] but the Python API is returning just mean and stddev. > > python: > >>> bd.ComputeBandStats() > > (9.0071713001936118, 11.350094331448236) > > >>> bd.ComputeRasterMinMax() > > (-1.7899999618530273, 31.149999618530273) > > gdalinfo: > > Band 1 Block=360x1 Type=Float32, ColorInterp=Gray > Min=-1.790 Max=31.150 > Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 > Unit Type: unspecified > Metadata: > STATISTICS_MINIMUM=-1.789999961853 > STATISTICS_MAXIMUM=31.14999961853 > STATISTICS_MEAN=9.0071713001936 > STATISTICS_STDDEV=11.350094331448 > > Is that a bug? > > See what happens in that case: > >>> bd1.SetStatistics(bd2.ComputeBandStats()) > > Traceback (most recent call last): > File "", line 1, in > File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in > SetStatistics return _gdal.Band_SetStatistics(*args) > TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) > > My best regards, > > Ivan > > [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at mines-paris.org Fri Mar 27 15:01:04 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 27 15:01:13 2009 Subject: [gdal-dev] ogr2ogr C# In-Reply-To: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> References: <25F335D588E9154B92DB21E4A1279FD701F6CFD3@aa-comm.LIFA.DK> Message-ID: <200903272001.04641.even.rouault@mines-paris.org> Note I've ported ogr2ogr to the Java bindings, so I guess it should be relatively easy to port it to C# as both languages are pretty close. Porting it from C++ to Java was rather straighforward (but very boring!). Replace NULL by null, TRUE by true, FALSE by false, -> by ., printf by System.out.println etc... See : http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogr2ogr.java Le Friday 27 March 2009 08:46:22 Sune Dogan, LIFA A/S, vous avez ?crit?: > Hi > > Im developing a .NET C# project and need to convert from GML to ESRI > Shape > > Simply i want to run this command: > > ogr2ogr -skipfailures -f "ESRI Shapefile" C:\shapefile.shp > c:\gmlfile.gml > > which works fine from the FWTool Command tool. > > But i just want to do i in my application, can any one help me? > > Thanks :) From ivan.lucena at pmldnet.com Fri Mar 27 15:05:11 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Fri Mar 27 15:05:14 2009 Subject: =?utf-8?B?UmU6IFtnZGFsLWRldl0gcHl0aG9uLWdkYWwgQ29tcHV0U3RhdGlzdGljcyByZXR1cm4ganVzdCB0d28gdmFsdWVz?= Message-ID: <20090327190511.29724.qmail@s466.sureserver.com> Even, I see. You are right. With the absence of ComputeRasterStatistics() I got confused and I made the wrong assumption. BTW, why there is no wrapper for ComputeRasterStatistics()? That would work then: >>> bd1.SetStatistics(bd2.ComputeRasterStatistics()) Not a big deal. The work around is easy. Thank you very much, Ivan > -------Original Message------- > From: Even Rouault > Subject: Re: [gdal-dev] python-gdal ComputStatistics return just two values > Sent: Mar 27 '09 18:45 > > Hi Ivan, > > I don't think there's a bug. > > The C API for ComputeBandStats is : > > CPLErr CPL_DLL CPL_STDCALL > GDALComputeBandStats( GDALRasterBandH hBand, int nSampleStep, > ???????????????????????????? double *pdfMean, double *pdfStdDev, > ???????????????????????????? GDALProgressFunc pfnProgress, > ???????????????????????????? void *pProgressData ); > > So, the python API is consistant with it. > > So it is expected that "bd1.SetStatistics(bd2.ComputeBandStats())" will fail > as it is provided with 2 values instead of the expected 4. > > Best regards, > Even > > Le Friday 27 March 2009 19:02:14 Lucena, Ivan, vous avez ?crit?: > > Hi there, > > > > I believe that ComputeBandStats() should return 4 values min, max, mean and > > stddev) [1] but the Python API is returning just mean and stddev. > > > > python: > > >>> bd.ComputeBandStats() > > > > (9.0071713001936118, 11.350094331448236) > > > > >>> bd.ComputeRasterMinMax() > > > > (-1.7899999618530273, 31.149999618530273) > > > > gdalinfo: > > > > Band 1 Block=360x1 Type=Float32, ColorInterp=Gray > >?? Min=-1.790 Max=31.150 > >?? Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 > >?? Unit Type: unspecified > >?? Metadata: > >???? STATISTICS_MINIMUM=-1.789999961853 > >???? STATISTICS_MAXIMUM=31.14999961853 > >???? STATISTICS_MEAN=9.0071713001936 > >???? STATISTICS_STDDEV=11.350094331448 > > > > Is that a bug? > > > > See what happens in that case: > > >>> bd1.SetStatistics(bd2.ComputeBandStats()) > > > > Traceback (most recent call last): > >?? File "", line 1, in > >?? File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in > > SetStatistics return _gdal.Band_SetStatistics(*args) > > TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) > > > > My best regards, > > > > Ivan > > > > [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > From mohwawang at yahoo.com Fri Mar 27 15:06:29 2009 From: mohwawang at yahoo.com (mohwawang) Date: Fri Mar 27 15:06:30 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <166774.87976.qm@web32606.mail.mud.yahoo.com> Hi all, When I used gdal_translate to convert a 16-bit QuickBird image to a ECW JPEG2000 compressed NITF image I got a Warning: ECW only supports Byte pixel data type, ignoring request for UInt16. Is it a big job (for example, change the algorithm of compression in ECW) or not so big a job to have ECW also support 16-bit imagery? Thanks. Best Regards, Mo From ivan.lucena at pmldnet.com Fri Mar 27 15:11:42 2009 From: ivan.lucena at pmldnet.com (=?utf-8?Q?Lucena,=20Ivan?=) Date: Fri Mar 27 15:11:43 2009 Subject: =?utf-8?B?UmU6IFtnZGFsLWRldl0gcHl0aG9uLWdkYWwgQ29tcHV0U3RhdGlzdGljcyByZXR1cm4ganVzdCB0d28gdmFsdWVz?= Message-ID: <20090327191142.12123.qmail@s466.sureserver.com> Actually... GetStatistics dows the same as ComputeRasterStatistcs() That is confusing... > -------Original Message------- > From: Lucena, Ivan > Subject: Re: [gdal-dev] python-gdal ComputStatistics return just two values > Sent: Mar 27 '09 19:05 > > Even, > > I see. You are right. With the absence of ComputeRasterStatistics() I got confused and I made the wrong > assumption. BTW, why there is no wrapper for ComputeRasterStatistics()? That would work then: > > >>> bd1.SetStatistics(bd2.ComputeRasterStatistics()) > > Not a big deal. The work around is easy. > > Thank you very much, > > Ivan > > > >??-------Original Message------- > >??From: Even Rouault > >??Subject: Re: [gdal-dev] python-gdal ComputStatistics return just two values > >??Sent: Mar 27 '09 18:45 > >?? > >??Hi Ivan, > >?? > >??I don't think there's a bug. > >?? > >??The C API for ComputeBandStats is : > >?? > >??CPLErr CPL_DLL CPL_STDCALL > >??GDALComputeBandStats( GDALRasterBandH hBand, int nSampleStep, > >?????????????????????????????? double *pdfMean, double *pdfStdDev, > >?????????????????????????????? GDALProgressFunc pfnProgress, > >?????????????????????????????? void *pProgressData ); > >?? > >??So, the python API is consistant with it. > >?? > >??So it is expected that "bd1.SetStatistics(bd2.ComputeBandStats())" will fail > >??as it is provided with 2 values instead of the expected 4. > >?? > >??Best regards, > >??Even > >?? > >??Le Friday 27 March 2009 19:02:14 Lucena, Ivan, vous avez ?crit?: > >??> Hi there, > >??> > >??> I believe that ComputeBandStats() should return 4 values min, max, mean and > >??> stddev) [1] but the Python API is returning just mean and stddev. > >??> > >??> python: > >??> >>> bd.ComputeBandStats() > >??> > >??> (9.0071713001936118, 11.350094331448236) > >??> > >??> >>> bd.ComputeRasterMinMax() > >??> > >??> (-1.7899999618530273, 31.149999618530273) > >??> > >??> gdalinfo: > >??> > >??> Band 1 Block=360x1 Type=Float32, ColorInterp=Gray > >??>?? Min=-1.790 Max=31.150 > >??>?? Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 > >??>?? Unit Type: unspecified > >??>?? Metadata: > >??>???? STATISTICS_MINIMUM=-1.789999961853 > >??>???? STATISTICS_MAXIMUM=31.14999961853 > >??>???? STATISTICS_MEAN=9.0071713001936 > >??>???? STATISTICS_STDDEV=11.350094331448 > >??> > >??> Is that a bug? > >??> > >??> See what happens in that case: > >??> >>> bd1.SetStatistics(bd2.ComputeBandStats()) > >??> > >??> Traceback (most recent call last): > >??>?? File "", line 1, in > >??>?? File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in > >??> SetStatistics return _gdal.Band_SetStatistics(*args) > >??> TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) > >??> > >??> My best regards, > >??> > >??> Ivan > >??> > >??> [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 > >??> > >??> _______________________________________________ > >??> 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 > From even.rouault at mines-paris.org Fri Mar 27 15:25:46 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Fri Mar 27 15:25:57 2009 Subject: [gdal-dev] python-gdal ComputStatistics return just two values In-Reply-To: <20090327190511.29724.qmail@s466.sureserver.com> References: <20090327190511.29724.qmail@s466.sureserver.com> Message-ID: <200903272025.47174.even.rouault@mines-paris.org> Le Friday 27 March 2009 20:05:11 Lucena, Ivan, vous avez ?crit?: > Even, > > I see. You are right. With the absence of ComputeRasterStatistics() I got > confused and I made the wrong > > assumption. BTW, why there is no wrapper for ComputeRasterStatistics()? That would work then: > >>> bd1.SetStatistics(bd2.ComputeRasterStatistics()) Because you don't use the latest and greatest GDAL ;-) Extract from swig/include/Band.i from SVN head: /* Interface method added for GDAL 1.7.0 */ %apply (double *OUTPUT){double *min, double *max, double *mean, double *stddev}; %apply (IF_ERROR_RETURN_NONE) { (CPLErr) }; CPLErr ComputeStatistics( bool approx_ok, double *min = NULL, double *max = NULL, double *mean = NULL, double *stddev = NULL, GDALProgressFunc callback = NULL, void* callback_data=NULL){ return GDALComputeRasterStatistics( self, approx_ok, min, max, mean, stddev, callback, callback_data ); } %clear (CPLErr); > > Not a big deal. The work around is easy. > > Thank you very much, > > Ivan > > > -------Original Message------- > > From: Even Rouault > > Subject: Re: [gdal-dev] python-gdal ComputStatistics return just two > > values Sent: Mar 27 '09 18:45 > > > > Hi Ivan, > > > > I don't think there's a bug. > > > > The C API for ComputeBandStats is : > > > > CPLErr CPL_DLL CPL_STDCALL > > GDALComputeBandStats( GDALRasterBandH hBand, int nSampleStep, > > ???????????????????????????? double *pdfMean, double *pdfStdDev, > > ???????????????????????????? GDALProgressFunc pfnProgress, > > ???????????????????????????? void *pProgressData ); > > > > So, the python API is consistant with it. > > > > So it is expected that "bd1.SetStatistics(bd2.ComputeBandStats())" will > > fail as it is provided with 2 values instead of the expected 4. > > > > Best regards, > > Even > > > > Le Friday 27 March 2009 19:02:14 Lucena, Ivan, vous avez ?crit?: > > > Hi there, > > > > > > I believe that ComputeBandStats() should return 4 values min, max, > > > mean and stddev) [1] but the Python API is returning just mean and > > > stddev. > > > > > > python: > > > >>> bd.ComputeBandStats() > > > > > > (9.0071713001936118, 11.350094331448236) > > > > > > >>> bd.ComputeRasterMinMax() > > > > > > (-1.7899999618530273, 31.149999618530273) > > > > > > gdalinfo: > > > > > > Band 1 Block=360x1 Type=Float32, ColorInterp=Gray > > >?? Min=-1.790 Max=31.150 > > >?? Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 > > >?? Unit Type: unspecified > > >?? Metadata: > > >???? STATISTICS_MINIMUM=-1.789999961853 > > >???? STATISTICS_MAXIMUM=31.14999961853 > > >???? STATISTICS_MEAN=9.0071713001936 > > >???? STATISTICS_STDDEV=11.350094331448 > > > > > > Is that a bug? > > > > > > See what happens in that case: > > > >>> bd1.SetStatistics(bd2.ComputeBandStats()) > > > > > > Traceback (most recent call last): > > >?? File "", line 1, in > > >?? File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in > > > SetStatistics return _gdal.Band_SetStatistics(*args) > > > TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) > > > > > > My best regards, > > > > > > Ivan > > > > > > [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 > > > > > > _______________________________________________ > > > gdal-dev mailing list > > > gdal-dev@lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev From fevans at harris.com Fri Mar 27 16:46:38 2009 From: fevans at harris.com (turtlewax) Date: Fri Mar 27 16:46:40 2009 Subject: [Gdal-dev] SWIG bindings in Linux Message-ID: <1238186798386-2546587.post@n2.nabble.com> In the past I've opened threads on GDAL/Mono. This may have been too specific, so I'd like to rephrase the topic to include GDAL SWIG bindings for any language in Linux. Just looking for feedback. Has anyone succeeded in getting the bindings to work in Linux? I realize the buildbots generate bindings, but has anyone else succeeded in compiling/using them? What configure command was used? What are the minimal dependencies? xerces, curl? What compiler/linker flags were used? I'm in a situation where I don't have root, so I'm forced to use a prefix for anything I compile/install. Thus far I've gotten a lot of SWIG projects to work in Linux, but have it a wall with gdal. Thanks in advance. -- View this message in context: http://n2.nabble.com/SWIG-bindings-in-Linux-tp2546587p2546587.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From ivan.lucena at pmldnet.com Fri Mar 27 18:19:48 2009 From: ivan.lucena at pmldnet.com (Ivan Lucena) Date: Fri Mar 27 18:19:28 2009 Subject: [gdal-dev] python-gdal ComputStatistics return just two values In-Reply-To: <200903272025.47174.even.rouault@mines-paris.org> References: <20090327190511.29724.qmail@s466.sureserver.com> <200903272025.47174.even.rouault@mines-paris.org> Message-ID: <49CD5104.4010001@pmldnet.com> D'accord. Even Rouault wrote: > Le Friday 27 March 2009 20:05:11 Lucena, Ivan, vous avez ?crit : >> Even, >> >> I see. You are right. With the absence of ComputeRasterStatistics() I got >> confused and I made the wrong >> >> assumption. BTW, why there is no wrapper for ComputeRasterStatistics()? That > would work then: >>>>> bd1.SetStatistics(bd2.ComputeRasterStatistics()) > > Because you don't use the latest and greatest GDAL ;-) > > Extract from swig/include/Band.i from SVN head: > > /* Interface method added for GDAL 1.7.0 */ > %apply (double *OUTPUT){double *min, double *max, double *mean, double > *stddev}; > %apply (IF_ERROR_RETURN_NONE) { (CPLErr) }; > CPLErr ComputeStatistics( bool approx_ok, double *min = NULL, double *max = > NULL, double *mean = NULL, double *stddev = NULL, > GDALProgressFunc callback = NULL, void* callback_data=NULL){ > return GDALComputeRasterStatistics( self, approx_ok, min, max, mean, > stddev, callback, callback_data ); > } > %clear (CPLErr); > > >> Not a big deal. The work around is easy. >> >> Thank you very much, >> >> Ivan >> >>> -------Original Message------- >>> From: Even Rouault >>> Subject: Re: [gdal-dev] python-gdal ComputStatistics return just two >>> values Sent: Mar 27 '09 18:45 >>> >>> Hi Ivan, >>> >>> I don't think there's a bug. >>> >>> The C API for ComputeBandStats is : >>> >>> CPLErr CPL_DLL CPL_STDCALL >>> GDALComputeBandStats( GDALRasterBandH hBand, int nSampleStep, >>> double *pdfMean, double *pdfStdDev, >>> GDALProgressFunc pfnProgress, >>> void *pProgressData ); >>> >>> So, the python API is consistant with it. >>> >>> So it is expected that "bd1.SetStatistics(bd2.ComputeBandStats())" will >>> fail as it is provided with 2 values instead of the expected 4. >>> >>> Best regards, >>> Even >>> >>> Le Friday 27 March 2009 19:02:14 Lucena, Ivan, vous avez ?crit : >>> > Hi there, >>> > >>> > I believe that ComputeBandStats() should return 4 values min, max, >>> > mean and stddev) [1] but the Python API is returning just mean and >>> > stddev. >>> > >>> > python: >>> > >>> bd.ComputeBandStats() >>> > >>> > (9.0071713001936118, 11.350094331448236) >>> > >>> > >>> bd.ComputeRasterMinMax() >>> > >>> > (-1.7899999618530273, 31.149999618530273) >>> > >>> > gdalinfo: >>> > >>> > Band 1 Block=360x1 Type=Float32, ColorInterp=Gray >>> > Min=-1.790 Max=31.150 >>> > Minimum=-1.790, Maximum=31.150, Mean=9.007, StdDev=11.350 >>> > Unit Type: unspecified >>> > Metadata: >>> > STATISTICS_MINIMUM=-1.789999961853 >>> > STATISTICS_MAXIMUM=31.14999961853 >>> > STATISTICS_MEAN=9.0071713001936 >>> > STATISTICS_STDDEV=11.350094331448 >>> > >>> > Is that a bug? >>> > >>> > See what happens in that case: >>> > >>> bd1.SetStatistics(bd2.ComputeBandStats()) >>> > >>> > Traceback (most recent call last): >>> > File "", line 1, in >>> > File "E:\Python25\Lib\site-packages\osgeo\gdal.py", line 729, in >>> > SetStatistics return _gdal.Band_SetStatistics(*args) >>> > TypeError: Band_SetStatistics() takes exactly 5 arguments (2 given) >>> > >>> > My best regards, >>> > >>> > Ivan >>> > >>> > [1] http://www.gdal.org/gdal_8h.html#a93b6b6ea6e71017ce25524e1a9ef1e3 >>> > >>> > _______________________________________________ >>> > gdal-dev mailing list >>> > gdal-dev@lists.osgeo.org >>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > From mateusz at loskot.net Fri Mar 27 18:26:16 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri Mar 27 18:26:22 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <166774.87976.qm@web32606.mail.mud.yahoo.com> References: <166774.87976.qm@web32606.mail.mud.yahoo.com> Message-ID: <49CD5288.3070102@loskot.net> mohwawang wrote: > Is it a big job (for example, change the algorithm of compression in > ECW) or not so big a job to have ECW also support 16-bit imagery? Wrong question. The correct one is: are you allowed to change anything in ECW to support anything what is not supported? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mateusz at loskot.net Fri Mar 27 18:29:32 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri Mar 27 18:29:39 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238153162.S.8403.10312.f4mail-235-216.rediffmail.com.old.replied.1238163080.28007@webmail.rediffmail.com> References: <1238153162.S.8403.10312.f4mail-235-216.rediffmail.com.old.replied.1238163080.28007@webmail.rediffmail.com> Message-ID: <49CD534C.9090106@loskot.net> Ajmeri Iqbal wrote: > Hi Beno?t Andrieu, > Thanks for reply. > i already saw that tutorial, > but the problame is how to and which library to be linked using QT(most > probably same way of C/C++). > coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib. Sometimes it's a good idea to read the manual [1] which says: "To use gdal link against the gdal_i.lib stub library." [1] http://trac.osgeo.org/gdal/wiki/BuildingOnWindows Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mohwawang at yahoo.com Fri Mar 27 19:20:52 2009 From: mohwawang at yahoo.com (mohwawang) Date: Fri Mar 27 19:20:55 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <435112.50711.qm@web32607.mail.mud.yahoo.com> Mateuse, So what's the answer to the "correct" question? Mo --- On Fri, 3/27/09, Mateusz Loskot wrote: > From: Mateusz Loskot > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Friday, March 27, 2009, 6:26 PM > mohwawang wrote: > > Is it a big job (for example, change the algorithm of > compression in > > ECW) or not so big a job to have ECW also support > 16-bit imagery? > > Wrong question. The correct one is: are you allowed to > change > anything in ECW to support anything what is not supported? > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > From mateusz at loskot.net Fri Mar 27 19:31:21 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri Mar 27 19:31:26 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <435112.50711.qm@web32607.mail.mud.yahoo.com> References: <435112.50711.qm@web32607.mail.mud.yahoo.com> Message-ID: <49CD61C9.50405@loskot.net> mohwawang wrote: > Mateuse, > > So what's the answer to the "correct" question? Read the license. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mohwawang at yahoo.com Fri Mar 27 22:51:10 2009 From: mohwawang at yahoo.com (mohwawang) Date: Fri Mar 27 22:51:12 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <417262.18179.qm@web32606.mail.mud.yahoo.com> Mateusz, License issue can be resolved through negotiation. Then back to the technique issue: Is it a big thing to change ECW to support 16-bit imagery? Mo --- On Fri, 3/27/09, Mateusz Loskot wrote: > From: Mateusz Loskot > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Friday, March 27, 2009, 7:31 PM > mohwawang wrote: > > Mateuse, > > > > So what's the answer to the "correct" question? > > Read the license. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > From ivan.lucena at pmldnet.com Sat Mar 28 00:10:08 2009 From: ivan.lucena at pmldnet.com (Ivan Lucena) Date: Sat Mar 28 00:09:47 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <417262.18179.qm@web32606.mail.mud.yahoo.com> References: <417262.18179.qm@web32606.mail.mud.yahoo.com> Message-ID: <49CDA320.5070604@pmldnet.com> Mo, See, GDAL does not implement the code that actually reads the ECW format. The GDAL ECW driver just make calls to a external library. That library is provided by the company that holds the copyright for that format [1]. So you would need to ask and negotiate with then first. But I believe that they probably have thought about that before and maybe that *is* a "big thing", as you said. It is not just a matter of storing pixels values but it is matter of running a algorithm to calculate the wavelets. Or maybe is just because that is how and why the format was designed. I mean, for byte image. But if they *do* decided to implement that change I believe it will be pretty simple for anyone of the GDAL driver's developers to make the necessary changes to adapt to it. But like I said before, don't hold you breath waiting for that. I don't think that there is a chance. [1] http://www.gdal.org/frmt_ecw.html My best regards, Ivan mohwawang wrote: > Mateusz, > > License issue can be resolved through negotiation. Then back to the technique issue: Is it a big thing to change ECW to support 16-bit imagery? > > Mo > > --- On Fri, 3/27/09, Mateusz Loskot wrote: > >> From: Mateusz Loskot >> Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? >> To: "mohwawang" >> Cc: gdal-dev@lists.osgeo.org >> Date: Friday, March 27, 2009, 7:31 PM >> mohwawang wrote: >>> Mateuse, >>> >>> So what's the answer to the "correct" question? >> Read the license. >> >> Best regards, >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> Charter Member of OSGeo, http://osgeo.org >> > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > From szekerest at gmail.com Sat Mar 28 06:28:20 2009 From: szekerest at gmail.com (Tamas Szekeres) Date: Sat Mar 28 06:28:23 2009 Subject: [Gdal-dev] SWIG bindings in Linux In-Reply-To: <1238186798386-2546587.post@n2.nabble.com> References: <1238186798386-2546587.post@n2.nabble.com> Message-ID: Hi Frank, I've got your build outputs but I still didn't have the chance to inspect the issue in more detail. I'll get back to you with further information shortly. I just wanted to mention thet the buildbot didn't require to have elevated privileges to build gdal and the SWIG bindings, however some prerequisites have already been pre-installed on the system. I've also found issues with some of the recent MONO libraries causing unexpected segfaults in the applications. Best regards, Tamas 2009/3/27 turtlewax > > In the past I've opened threads on GDAL/Mono. This may have been too > specific, so I'd like to rephrase the topic to include GDAL SWIG bindings > for any language in Linux. > > Just looking for feedback. Has anyone succeeded in getting the bindings to > work in Linux? I realize the buildbots generate bindings, but has anyone > else succeeded in compiling/using them? > > What configure command was used? > What are the minimal dependencies? xerces, curl? > What compiler/linker flags were used? > > I'm in a situation where I don't have root, so I'm forced to use a prefix > for anything I compile/install. Thus far I've gotten a lot of SWIG projects > to work in Linux, but have it a wall with gdal. > > Thanks in advance. > > -- > View this message in context: > http://n2.nabble.com/SWIG-bindings-in-Linux-tp2546587p2546587.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090328/65fc1a2c/attachment-0001.html From mohwawang at yahoo.com Sat Mar 28 09:19:42 2009 From: mohwawang at yahoo.com (mohwawang) Date: Sat Mar 28 09:19:49 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <722656.65137.qm@web32601.mail.mud.yahoo.com> Ivan, It seems that both you and me guess that it is a big thing to change the source code of ECW SDK to support 16bit imagery. So, forget about ECW. How about another jpeg2000 package, Jasper, which (1)supports 8bit and 16bit and (2)is an open source. GDAL has a driver for Jasper jpeg2000. But GDAL does not allow NITF with Jasper. GDAL only allows NITF with ECW jpeg2000, which we know (1)does not support 16bit and (2)has license issue. Why GDAL does not support Jasper jpeg2000 in NITF? Best Regards, Mo --- On Sat, 3/28/09, Ivan Lucena wrote: > From: Ivan Lucena > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Saturday, March 28, 2009, 12:10 AM > Mo, > > See, GDAL does not implement the code that actually reads > the ECW format. The GDAL ECW driver just make calls to a > external library. That library is provided by the company > that holds the copyright for that format [1]. So you would > need to ask and negotiate with then first. > > But I believe that they probably have thought about that > before and maybe that *is* a "big thing", as you said. It is > not just a matter of storing pixels values but it is matter > of running a algorithm to calculate the wavelets. Or maybe > is just because that is how and why the format was designed. > I mean, for byte image. > > But if they *do* decided to implement that change I believe > it will be pretty simple for anyone of the GDAL driver's > developers to make the necessary changes to adapt to it. > > But like I said before, don't hold you breath waiting for > that. I don't think that there is a chance. > > [1] http://www.gdal.org/frmt_ecw.html > > My best regards, > > Ivan > > mohwawang wrote: > > Mateusz, > > > > License issue can be resolved through negotiation. > Then back to the technique issue: Is it a big thing to > change ECW to support 16-bit imagery? > > > > Mo? > > --- On Fri, 3/27/09, Mateusz Loskot > wrote: > > > >> From: Mateusz Loskot > >> Subject: Re: [gdal-dev] Is it a big thing to > change ECW to support 16-bit imagery? > >> To: "mohwawang" > >> Cc: gdal-dev@lists.osgeo.org > >> Date: Friday, March 27, 2009, 7:31 PM > >> mohwawang wrote: > >>> Mateuse, > >>> > >>> So what's the answer to the "correct" > question? > >> Read the license. > >> > >> Best regards, > >> -- Mateusz Loskot, http://mateusz.loskot.net > >> Charter Member of OSGeo, http://osgeo.org > >> > > > > > >? ? > ???_______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > From even.rouault at mines-paris.org Sat Mar 28 09:36:07 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sat Mar 28 09:36:59 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <722656.65137.qm@web32601.mail.mud.yahoo.com> References: <722656.65137.qm@web32601.mail.mud.yahoo.com> Message-ID: <200903281436.14332.even.rouault@mines-paris.org> Mo, NITF driver cannot use Jasper for reading JPEG2000 compressed NITF images, because Jasper doesn't support decoding an image that is located at an arbitrary offset inside a file. (At least, that's the first reason why it can't work.). I imagine that if you badly want to use Japser, you could hack the NITF driver so that it writes a temporary image with just the JPEG200 content and pass it to the Jasper driver. Even Le Saturday 28 March 2009 14:19:42 mohwawang, vous avez ?crit?: > Ivan, > > It seems that both you and me guess that it is a big thing to change the > source code of ECW SDK to support 16bit imagery. > > So, forget about ECW. How about another jpeg2000 package, Jasper, which > (1)supports 8bit and 16bit and (2)is an open source. GDAL has a driver for > Jasper jpeg2000. But GDAL does not allow NITF with Jasper. GDAL only allows > NITF with ECW jpeg2000, which we know (1)does not support 16bit and (2)has > license issue. Why GDAL does not support Jasper jpeg2000 in NITF? > > Best Regards, > > Mo > > --- On Sat, 3/28/09, Ivan Lucena wrote: > > From: Ivan Lucena > > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit > > imagery? To: "mohwawang" > > Cc: gdal-dev@lists.osgeo.org > > Date: Saturday, March 28, 2009, 12:10 AM > > Mo, > > > > See, GDAL does not implement the code that actually reads > > the ECW format. The GDAL ECW driver just make calls to a > > external library. That library is provided by the company > > that holds the copyright for that format [1]. So you would > > need to ask and negotiate with then first. > > > > But I believe that they probably have thought about that > > before and maybe that *is* a "big thing", as you said. It is > > not just a matter of storing pixels values but it is matter > > of running a algorithm to calculate the wavelets. Or maybe > > is just because that is how and why the format was designed. > > I mean, for byte image. > > > > But if they *do* decided to implement that change I believe > > it will be pretty simple for anyone of the GDAL driver's > > developers to make the necessary changes to adapt to it. > > > > But like I said before, don't hold you breath waiting for > > that. I don't think that there is a chance. > > > > [1] http://www.gdal.org/frmt_ecw.html > > > > My best regards, > > > > Ivan > > > > mohwawang wrote: > > > Mateusz, > > > > > > License issue can be resolved through negotiation. > > > > Then back to the technique issue: Is it a big thing to > > change ECW to support 16-bit imagery? > > > > > Mo? > > > --- On Fri, 3/27/09, Mateusz Loskot > > > > wrote: > > >> From: Mateusz Loskot > > >> Subject: Re: [gdal-dev] Is it a big thing to > > > > change ECW to support 16-bit imagery? > > > > >> To: "mohwawang" > > >> Cc: gdal-dev@lists.osgeo.org > > >> Date: Friday, March 27, 2009, 7:31 PM > > >> > > >> mohwawang wrote: > > >>> Mateuse, > > >>> > > >>> So what's the answer to the "correct" > > > > question? > > > > >> Read the license. > > >> > > >> Best regards, > > >> -- Mateusz Loskot, http://mateusz.loskot.net > > >> Charter Member of OSGeo, http://osgeo.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 From mateusz at loskot.net Sat Mar 28 09:40:56 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Mar 28 09:41:10 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <417262.18179.qm@web32606.mail.mud.yahoo.com> References: <417262.18179.qm@web32606.mail.mud.yahoo.com> Message-ID: <49CE28E8.8090901@loskot.net> mohwawang wrote: > Mateusz, > > License issue can be resolved through negotiation. Then try to solve it first, before digging the source code. Otherwise, you will waste your time. > Then back to the > technique issue: Is it a big thing to change ECW to support 16-bit > imagery? IMHO, unless the license issue is solved, it's a far premature question. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mateusz at loskot.net Sat Mar 28 09:54:47 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Mar 28 09:55:00 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: References: Message-ID: <49CE2C27.1040604@loskot.net> legeochen wrote: > Hi All > I try to create some multipolygons with OGR. After creating them, but > when I want view them in arcscene, it just make arcscene crash! Then I > tried osgviewer with ESRI Shapefile, I was warned: > ESRIShape loader: .dbf file containe different record number that .shp > file. .dbf record skipped. Inspect your shapefile with ogrinfo as well as with Shapelib's shpdump and dbfdump. Check if .dbf contains exactly the same number of records as .shp file > Actually, only one feature in the dataset had been readed out. > Then, I tried osgviewer with ogr, got warnings like this: > Warning something wrong with a polygon in a multi polygon. No idea what's osgviewer and what its errors mean. > for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != > _roadwayArr.end();itrw++) ++itrw; if you care about performance. > { > OGRFeature *poFeature; > > OGRMultiPolygon multiPoly; > poFeature = OGRFeature::CreateFeature(poLayer->GetLayerDefn()); > Roadway::Triangle_list tris = (*itrw)->getTrianglelist(); No idea what Triangle and Roadway is, I assume it's your own geometry type. > for(Triangle_list::const_iterator ittri = tris.begin();ittri != > tris.end();ittri++) ++ittri; > { > OGRPolygon polygon; > OGRLinearRing poRing; > poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); > poRing.addPoint((*ittri).b().x(),(*ittri).b().y(),(*ittri).b().z()); > poRing.addPoint((*ittri).c().x(),(*ittri).c().y(),(*ittri).c().z()); > poRing.addPoint((*ittri).a().x(),(*ittri).a().y(),(*ittri).a().z()); Assure that TRUE == poRing.get_IsClosed(); > polygon.addRing(&poRing); > multiPoly.addGeometry(&polygon); > > } > poFeature->SetGeometry(&multiPoly); > if( poLayer->CreateFeature( poFeature ) != OGRERR_NONE ) > { > printf( "Failed to create feature in shapefile.\n" ); > return false; > } > OGRFeature::DestroyFeature( poFeature ); > } > OGRDataSource::DestroyDataSource( poDS ); > Any help is appreciated!! I'd suggest you to translate your Roadway/Triangle it to OGRPolygon and OGRMultiPolygon (what you actually have done) and then dump it to OGC Well-Known-Text (WKT). Then, try to validate these geometries with PostGIS using ST_GeometryFromText and ST_IsValid and friends. See chapter 4 and 6 of PostGIS manual. PostGIS (or GEOS) is good for geometries validation. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From fevans at harris.com Sat Mar 28 10:19:48 2009 From: fevans at harris.com (turtlewax) Date: Sat Mar 28 10:19:51 2009 Subject: [Gdal-dev] SWIG bindings in Linux In-Reply-To: References: <1238186798386-2546587.post@n2.nabble.com> Message-ID: <1238249988899-2549155.post@n2.nabble.com> Thanks Tamas, I have a ton of info, and logs, from the various combinations of things I've tried. I can provide the output .so libraries if you think it will help. I did one interesting experiment where I included gdal_wrap.cc in the compilation of "libgdal.so". This exposed the bindings directly in libgdal, instead of in a wrap library. It was not successful, but Mono did at least probe the library for the SWIGRegisterCallback methods. Even if it had worked, its not a valid solution. Just trying to expand my knowledge of how shared libraries link, and how symbols are exported, since I suspect this is the heart of the issue. On a sidenote, I'm incredibly impressed with Mono, its stability and the rate its evolving. But this weekend I'm going to experiment with the python bindings in linux, the goal of this is to isolate the problem. If the python bindings don't work (and I suspect they won't in my environment), I can shift my focus to the manner in which the symbols are exported from libgdal. If, on the other hand the python bindings work, I'll need to shift attention to libgdalcsharp.so. -- View this message in context: http://n2.nabble.com/SWIG-bindings-in-Linux-tp2546587p2549155.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From chaitanya.ch at gmail.com Sat Mar 28 10:35:16 2009 From: chaitanya.ch at gmail.com (Chaitanya kumar CH) Date: Sat Mar 28 10:35:20 2009 Subject: [gdal-dev] get the info of the hdf4 tranlate hdf4 to tif In-Reply-To: <23523724.103951238121894901.JavaMail.coremail@yeahapp3.yeah.net> References: <23523724.103951238121894901.JavaMail.coremail@yeahapp3.yeah.net> Message-ID: apachemaven, 2009/3/27 apachemaven : > I want to translate the hdf4 to tif ,and use the grass to conert this tif to > its own format, then I can contiune my next work, I use the FWTools2.2.8 > (which is installed in the F disk.)to handle this,after config the > environment ,I run the command "gdalinfo > d:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf", it worked , the > key inofrmation is : > =============== > ................ > ................ > Subdatasets: > > SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB > ? SUBDATASET_1_DESC=[5x4060x2708] EV_500_RefSB MODIS_SWATH_Type_L1B (16-bit > unsigned integer) > > SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB_Uncert_Indexes > ? SUBDATASET_2_DESC=[5x4060x2708] EV_500_RefSB_Uncert_Indexes > MODIS_SWATH_Type_L1B (8-bit unsigned integer) > > SUBDATASET_3_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB > ? SUBDATASET_3_DESC=[2x4060x2708] EV_250_Aggr500_RefSB MODIS_SWATH_Type_L1B > (16-bit unsigned integer) > > SUBDATASET_4_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes > ? SUBDATASET_4_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Uncert_Indexes > MODIS_SWATH_Type_L1B (8-bit unsigned integer) > > SUBDATASET_5_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Samples_Used > ? SUBDATASET_5_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Samples_Used > MODIS_SWATH_Type_L1B (8-bit integer) > =============== > and now (for example )I want to get the subdataset 4,and translate it to > geotiff,before run the gdal_translate I run the gdalinfo again to get the > information of it:" > gdalinfo > HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes" > I got the error messages as follows: > ======================== > C:\Documents and Settings\Administrator>gdalinfo > HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes > ERROR 4: > `HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245005.2008275112555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes' > does not exist in the file system,and is not recognised as a supported > dataset name. > gdalinfo failed - unable to open > 'HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245.005.20082751 > 12555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes'. Perhaps, the problem is with the colon (:) in the path. There may be some confusion with the path. Try to work around the colon by mounting the D drive on any other folder in the F drive and provide a relative path to the FWTools' bin folder. Let me know how it goes. > Open GDAL Datasets: > ? 1 N DriverIsNULL????? -1 512x512x0 > ======================== > I want to know why?and if I put the hdf data under the F:\anzhuang\FWTools > 2.2.8\bin, I can get the correct result...... > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > Regards, -- Chaitanya kumar CH. From jluis at ualg.pt Sat Mar 28 10:57:01 2009 From: jluis at ualg.pt (Joaquim Luis) Date: Sat Mar 28 10:57:07 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: <49CE2C27.1040604@loskot.net> References: <49CE2C27.1040604@loskot.net> Message-ID: <49CE3ABD.8060008@ualg.pt> Mateusz Loskot wrote: >> for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != >> _roadwayArr.end();itrw++) > > ++itrw; > > if you care about performance. Mateusz, Just curious. Why should that impact on performance? Joaquim Luis From mohwawang at yahoo.com Sat Mar 28 11:25:47 2009 From: mohwawang at yahoo.com (mohwawang) Date: Sat Mar 28 11:25:50 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <737198.52383.qm@web32608.mail.mud.yahoo.com> If you know that the technical problem can not be resolved easily (for example, if the deep part of the algorithm is based on 8bit and it needs a new algorithm for 16bit) then you have little incentive to negotiate the license. Mo --- On Sat, 3/28/09, Mateusz Loskot wrote: > From: Mateusz Loskot > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? > To: "mohwawang" > Cc: gdal-dev@lists.osgeo.org > Date: Saturday, March 28, 2009, 9:40 AM > mohwawang wrote: > > Mateusz, > > > > License issue can be resolved through negotiation. > > Then try to solve it first, before digging the source > code. > Otherwise, you will waste your time. > > > Then back to the > > technique issue: Is it a big thing to change ECW to > support 16-bit > > imagery? > > IMHO, unless the license issue is solved, it's a far > premature question. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > From mohwawang at yahoo.com Sat Mar 28 11:53:59 2009 From: mohwawang at yahoo.com (mohwawang) Date: Sat Mar 28 11:54:02 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? Message-ID: <667158.38603.qm@web32603.mail.mud.yahoo.com> Even, Thank you for telling me the reason why GDAL does not support Jasper for reading a NITF file and how to hack that. How about writing (instead of reading) a Jasper compressed image into NITF? I want to be able to write out not read in a JPG2000 compressed NITF file. (My input image is a 16bit raw image). Why GDAL does not support writing a Jasper compressed image into NITF? How to hack that? Thanks. Mo --- On Sat, 3/28/09, Even Rouault wrote: > From: Even Rouault > Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? > To: gdal-dev@lists.osgeo.org > Cc: "mohwawang" > Date: Saturday, March 28, 2009, 9:36 AM > > -----Inline Attachment Follows----- > > Mo, > > NITF driver cannot use Jasper for reading JPEG2000 > compressed NITF images, > because Jasper doesn't support decoding an image that is > located at an > arbitrary offset inside a file. (At least, that's the first > reason why it > can't work.). I imagine that if you badly want to use > Japser, you could hack > the NITF driver so that it writes a temporary image with > just the JPEG200 > content and pass it to the Jasper driver. > > Even > > Le Saturday 28 March 2009 14:19:42 mohwawang, vous avez > ?crit?: > > Ivan, > > > > It seems that both you and me guess that it is a big > thing to change the > > source code of ECW SDK to support 16bit imagery. > > > > So, forget about ECW. How about another jpeg2000 > package, Jasper, which > > (1)supports 8bit and 16bit and (2)is an open source. > GDAL has a driver for > > Jasper jpeg2000. But GDAL does not allow NITF with > Jasper. GDAL only allows > > NITF with ECW jpeg2000, which we know (1)does not > support 16bit and (2)has > > license issue. Why GDAL does not support Jasper > jpeg2000 in NITF? > > > > Best Regards, > > > > Mo > > > > --- On Sat, 3/28/09, Ivan Lucena > wrote: > > > From: Ivan Lucena > > > Subject: Re: [gdal-dev] Is it a big thing to > change ECW to support 16-bit > > > imagery? To: "mohwawang" > > > Cc: gdal-dev@lists.osgeo.org > > > Date: Saturday, March 28, 2009, 12:10 AM > > > Mo, > > > > > > See, GDAL does not implement the code that > actually reads > > > the ECW format. The GDAL ECW driver just make > calls to a > > > external library. That library is provided by the > company > > > that holds the copyright for that format [1]. So > you would > > > need to ask and negotiate with then first. > > > > > > But I believe that they probably have thought > about that > > > before and maybe that *is* a "big thing", as you > said. It is > > > not just a matter of storing pixels values but it > is matter > > > of running a algorithm to calculate the wavelets. > Or maybe > > > is just because that is how and why the format > was designed. > > > I mean, for byte image. > > > > > > But if they *do* decided to implement that change > I believe > > > it will be pretty simple for anyone of the GDAL > driver's > > > developers to make the necessary changes to adapt > to it. > > > > > > But like I said before, don't hold you breath > waiting for > > > that. I don't think that there is a chance. > > > > > > [1] http://www.gdal.org/frmt_ecw.html > > > > > > My best regards, > > > > > > Ivan > > > > > > mohwawang wrote: > > > > Mateusz, > > > > > > > > License issue can be resolved through > negotiation. > > > > > > Then back to the technique issue: Is it a big > thing to > > > change ECW to support 16-bit imagery? > > > > > > > Mo? > > > > --- On Fri, 3/27/09, Mateusz Loskot > > > > > > wrote: > > > >> From: Mateusz Loskot > > > >> Subject: Re: [gdal-dev] Is it a big > thing to > > > > > > change ECW to support 16-bit imagery? > > > > > > >> To: "mohwawang" > > > >> Cc: gdal-dev@lists.osgeo.org > > > >> Date: Friday, March 27, 2009, 7:31 PM > > > >> > > > >> mohwawang wrote: > > > >>> Mateuse, > > > >>> > > > >>> So what's the answer to the > "correct" > > > > > > question? > > > > > > >> Read the license. > > > >> > > > >> Best regards, > > > >> -- Mateusz Loskot, http://mateusz.loskot.net > > > >> Charter Member of OSGeo, http://osgeo.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 > > > From warmerdam at pobox.com Sat Mar 28 12:30:49 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Sat Mar 28 12:31:02 2009 Subject: [gdal-dev] suitable test viewer for new driver In-Reply-To: References: Message-ID: <49CE50B9.6090609@pobox.com> Norman Barker wrote: > Hi, > > > > I have written a gdal driver and would like to hook this into an > existing viewer (public domain) to demonstrate the code. The driver > makes a fair few changes to the GDAL API so it isn?t as simple as just > adding to the format list. > > Would I be better to use openev or openev2, or perhaps a different > viewer? Any ideas are appreciated, I would like to use a viewer that > compiles against the current GDAL trunk. Norman, In my opinion it is getting pretty hard to build OpenEV from source and it's OpenGL tile based approach may not be very ammendable to the progressive support you want to test. I'd suggest qgis (http://www.qgis.org). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From mateusz at loskot.net Sat Mar 28 13:48:09 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Mar 28 13:48:23 2009 Subject: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <737198.52383.qm@web32608.mail.mud.yahoo.com> References: <737198.52383.qm@web32608.mail.mud.yahoo.com> Message-ID: <49CE62D9.7010806@loskot.net> mohwawang wrote: > If you know that the technical problem can not be resolved easily > (for example, if the deep part of the algorithm is based on 8bit and > it needs a new algorithm for 16bit) then you have little incentive to > negotiate the license. In order to be sure if something is feasible or not, you have to investigate it, make some a research. Then you will know if you can implement things easy or not. My point is that it does *not* make sense to make an attempt on investigating it if you don't know you are allowed to do it or not. Otherwise you can spend hours on developing things and eventually you will lock it in a drawer and nobody will see you work. That would be quite pointless. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mateusz at loskot.net Sat Mar 28 14:09:52 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Mar 28 14:10:07 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: <49CE3ABD.8060008@ualg.pt> References: <49CE2C27.1040604@loskot.net> <49CE3ABD.8060008@ualg.pt> Message-ID: <49CE67F0.4090705@loskot.net> Joaquim Luis wrote: > Mateusz Loskot wrote: > >>> for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != >>> _roadwayArr.end();itrw++) >> >> ++itrw; >> >> if you care about performance. > > Mateusz, > > Just curious. Why should that impact on performance? The itrw here is most likely an iterator of type of user's class. The pointer arithmetic does work here only in terms of semantic, but not in terms of implementation. Meaning, both versions do the same - advance to next position: int* p = ...; // or any ordinary type p++; iterator it = ...; it++; However, the realization is completely different. Here is example of how pre- and post-increment operator is usually declared in a class: struct T { T& operator++(); // pre- T operator++(int); // post- }; The pre-increment operator returns reference to the object itself (return *this;) The post-increment returns a temporary copy of the object. There are important side-effects of returning copy: 1. it is constructed -> copy-construction -> constructor called 2. it is returned by value -> copy-construction -> constructor called Here is example of iterator and operator++ implementation: http://liblas.org/browser/trunk/include/liblas/iterator.hpp?rev813#L108 Object construction is considered in C++ as an expansive operation, next to dynamic storage allocation. If post-increment/decrement operator is used against pointers and integers, temporary object is also created, but as they are native types no constructor call is involved. People report different measurements on Usenet groups. Numbers vary but can easily hit 50 % of performance increase if you stick to use of pre-increment/decrement operator for class types. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From jluis at ualg.pt Sat Mar 28 15:25:53 2009 From: jluis at ualg.pt (Joaquim Luis) Date: Sat Mar 28 15:26:06 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: <49CE67F0.4090705@loskot.net> References: <49CE2C27.1040604@loskot.net> <49CE3ABD.8060008@ualg.pt> <49CE67F0.4090705@loskot.net> Message-ID: <49CE79C1.8000204@ualg.pt> Thankx I'll keep this in mind if I ever one day start practicing C++ For the time being, only good old C. Joaquim > Joaquim Luis wrote: >> Mateusz Loskot wrote: >> >>>> for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != >>>> _roadwayArr.end();itrw++) >>> ++itrw; >>> >>> if you care about performance. >> Mateusz, >> >> Just curious. Why should that impact on performance? > > The itrw here is most likely an iterator of type of user's class. > The pointer arithmetic does work here only in terms of > semantic, but not in terms of implementation. > Meaning, both versions do the same - advance to next position: > > int* p = ...; // or any ordinary type > p++; > > iterator it = ...; > it++; > > However, the realization is completely different. > Here is example of how pre- and post-increment operator is usually > declared in a class: > > struct T > { > T& operator++(); // pre- > T operator++(int); // post- > }; > > The pre-increment operator returns reference to the object > itself (return *this;) > > The post-increment returns a temporary copy of the object. > There are important side-effects of returning copy: > 1. it is constructed -> copy-construction -> constructor called > 2. it is returned by value -> copy-construction -> constructor called > > Here is example of iterator and operator++ implementation: > http://liblas.org/browser/trunk/include/liblas/iterator.hpp?rev813#L108 > > Object construction is considered in C++ as an expansive operation, > next to dynamic storage allocation. > If post-increment/decrement operator is used against pointers and > integers, temporary object is also created, but as they are native > types no constructor call is involved. > > People report different measurements on Usenet groups. Numbers > vary but can easily hit 50 % of performance increase if you > stick to use of pre-increment/decrement operator for class types. > > Best regards, From fabrice_martin2 at yahoo.fr Sat Mar 28 15:41:53 2009 From: fabrice_martin2 at yahoo.fr (fabrice martin) Date: Sat Mar 28 15:48:36 2009 Subject: [gdal-dev] suitable test viewer for new driver In-Reply-To: <49CE50B9.6090609@pobox.com> References: <49CE50B9.6090609@pobox.com> Message-ID: <348431.74509.qm@web26602.mail.ukl.yahoo.com> Hi, I'm a bit off-topic, but is this new driver the jpip driver described in RFC_24 (http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support)? If so, that's great news, does it use Kakadu for its implementation ? Best regards. Norman Barker wrote: > Hi, > > > I have written a gdal driver and would like to hook this into an existing viewer (public domain) to demonstrate the code. The driver makes a fair few changes to the GDAL API so it isn?t as simple as just adding to the format list. > > Would I be better to use openev or openev2, or perhaps a different viewer? Any ideas are appreciated, I would like to use a viewer that compiles against the current GDAL trunk. Norman, In my opinion it is getting pretty hard to build OpenEV from source and it's OpenGL tile based approach may not be very ammendable to the progressive support you want to test. I'd suggest qgis (http://www.qgis.org). From mateusz at loskot.net Sat Mar 28 15:52:02 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat Mar 28 15:52:11 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: <49CE79C1.8000204@ualg.pt> References: <49CE2C27.1040604@loskot.net> <49CE3ABD.8060008@ualg.pt> <49CE67F0.4090705@loskot.net> <49CE79C1.8000204@ualg.pt> Message-ID: <49CE7FE2.6080204@loskot.net> Joaquim Luis wrote: > Thankx > > I'll keep this in mind if I ever one day start practicing C++ For the > time being, only good old C. You are welcome. Simply, best thing is to always use pre-increment, regardless if working with pointers, integers or iterators. Then there is no need to remember about copy-construction issue when you switch to objects. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From DCarreira at edia.pt Sat Mar 28 17:00:36 2009 From: DCarreira at edia.pt (Duarte Carreira) Date: Sat Mar 28 17:07:35 2009 Subject: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields In-Reply-To: References: , Message-ID: Mike, That's a good idea, but not really well accepted in many cases... In my particular case I ended up changing my tables to varchar2... We'll have to wait for unicode support in ogr. Thanks, Duarte ________________________________________ De: Michael Smith [michael.smith@usace.army.mil] Enviado: sexta-feira, 27 de Mar?o de 2009 10:22 Para: Duarte Carreira; gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields Duarte, Why not create a view that has the TRANSLATE and TO_CHAR and then use that in OGR. Mike -- Michael Smith RSGIS Center ERDC - CRREL US Army Corps of Engineers On 3/27/09 5:44 AM, "Duarte Carreira" wrote: > I'm correcting the subject of the message - the problem is with NVARCHAR > fields (not varchar2). > It seems this relates to utf issues/limitations in ogr. > > If I could use SQL functions this could be solved by the database itself. Like > using TO_CHAR(field_name) or TRANSLATE(field_name USING CS_CHAR). But it seems > ogr does not support these sql functions/operators... > > Any additional suggestions? > > Thanks, > Duarte > > -----Mensagem original----- > De: Duarte Carreira [mailto:DCarreira@edia.pt] > Enviada: quinta-feira, 26 de Mar?o de 2009 23:54 > Para: gdal-dev@lists.osgeo.org > Assunto: [gdal-dev] ogr 1.6 and ArcSDE 9.3sp1: not reading varchar2 fields > > Hello. > > As always trying to coerce these two to work together nicely... > > The situation: exporting ArcSDE feature class to , shapefile, gpx... > server: Oracle xe (10), ArcSDE 9.3 sp1, Win2003 Std x32 > client: Vista x32, GDAL/OGR 1.6 build 1500 from Tamas site, sde dll's from 9.3 > sp1 > > As you can see below, Oracle describes several fields as being number and > nvarchar2, and ogrinfo only identifies numeric fields. All text fields come > out as unknown. > > Now, what could this be due to? Anyone facing the same issue? I tried to use > SQL to cast a nvarchar to character without success... > > Thanks, > Duarte > > Feature class description in Oracle: > Column Name Data Type Nullable Default Primary Key > OBJECTID NUMBER No - - > IDPERC NVARCHAR2(6) Yes - - > NOME NVARCHAR2(150) Yes - - > DESCRICAO NVARCHAR2(255) Yes - - > IDPONTO NVARCHAR2(10) Yes - - > IDSIG NUMBER Yes - - > XCOORD NUMBER(38,8) Yes - - > YCOORD NUMBER(38,8) Yes - - > MORADA_COMPLETA NVARCHAR2(255) Yes - - > CONCELHO NVARCHAR2(50) Yes - - > FREGUESIA NVARCHAR2(50) Yes - - > CODPOSTAL NVARCHAR2(10) Yes - - > TELEFONE NVARCHAR2(10) Yes - - > DESCRICAOPT NVARCHAR2(255) Yes - - > NOMEPT NVARCHAR2(150) Yes - - > SHAPE ST_GEOMETRY Yes - - > 1 - 16 > > ogrinfo output: > Layer name: .
> Geometry: Unknown (any) > ERROR 1: SE_layer_get_statistics: -51/Underlying DBMS error > Feature Count: -1 > Extent: (6177.862000, -123296.045000) - (63997.354000, -91245.397000) > Layer SRS WKT: > PROJCS["Datum_73_Hayford_Gauss_IPCC", > GEOGCS["GCS_Datum_73", > DATUM["Datum_73", > SPHEROID["International_1924",6378388.0,297.0]], > PRIMEM["Greenwich",0.0], > UNIT["Degree",0.0174532925199433]], > PROJECTION["Transverse_Mercator"], > PARAMETER["False_Easting",180.598], > PARAMETER["False_Northing",-86.99], > PARAMETER["Central_Meridian",-8.131906111111112], > PARAMETER["Scale_Factor",1.0], > PARAMETER["Latitude_Of_Origin",39.66666666666666], > UNIT["Meter",1.0]] > OBJECTID: Integer (10.0) > IDPERC: (unknown) (6.0) > NOME: (unknown) (50.0) > DESCRICAO: (unknown) (50.0) > IDLINHA: (unknown) (5.0) > SHAPE_LENG: Real (38.8) > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From ivan.lucena at pmldnet.com Sat Mar 28 20:12:16 2009 From: ivan.lucena at pmldnet.com (Ivan Lucena) Date: Sat Mar 28 20:11:59 2009 Subject: [gdal-dev] get the info of the hdf4 tranlate hdf4 to tif In-Reply-To: References: <23523724.103951238121894901.JavaMail.coremail@yeahapp3.yeah.net> Message-ID: <49CEBCE0.9040005@pmldnet.com> Hi, > Perhaps, the problem is with the colon (:) in the path. There may be If that is the case, I filed that ticket two months ago and Even has fixed it already http://trac.osgeo.org/gdal/ticket/2823 but maybe it is not on that build. Ivan Chaitanya kumar CH wrote: > apachemaven, > > 2009/3/27 apachemaven : >> I want to translate the hdf4 to tif ,and use the grass to conert this tif to >> its own format, then I can contiune my next work, I use the FWTools2.2.8 >> (which is installed in the F disk.)to handle this,after config the >> environment ,I run the command "gdalinfo >> d:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf", it worked , the >> key inofrmation is : >> =============== >> ................ >> ................ >> Subdatasets: >> >> SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB >> SUBDATASET_1_DESC=[5x4060x2708] EV_500_RefSB MODIS_SWATH_Type_L1B (16-bit >> unsigned integer) >> >> SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_500_RefSB_Uncert_Indexes >> SUBDATASET_2_DESC=[5x4060x2708] EV_500_RefSB_Uncert_Indexes >> MODIS_SWATH_Type_L1B (8-bit unsigned integer) >> >> SUBDATASET_3_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB >> SUBDATASET_3_DESC=[2x4060x2708] EV_250_Aggr500_RefSB MODIS_SWATH_Type_L1B >> (16-bit unsigned integer) >> >> SUBDATASET_4_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes >> SUBDATASET_4_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Uncert_Indexes >> MODIS_SWATH_Type_L1B (8-bit unsigned integer) >> >> SUBDATASET_5_NAME=HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Samples_Used >> SUBDATASET_5_DESC=[2x4060x2708] EV_250_Aggr500_RefSB_Samples_Used >> MODIS_SWATH_Type_L1B (8-bit integer) >> =============== >> and now (for example )I want to get the subdataset 4,and translate it to >> geotiff,before run the gdal_translate I run the gdalinfo again to get the >> information of it:" >> gdalinfo >> HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes" >> I got the error messages as follows: >> ======================== >> C:\Documents and Settings\Administrator>gdalinfo >> HDF4_EOS:EOS_SWATH:"D:\data\HDF\MOD02HKM.A2008275.0245.005.2008275112555.hdf":MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes >> ERROR 4: >> `HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245005.2008275112555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes' >> does not exist in the file system,and is not recognised as a supported >> dataset name. >> gdalinfo failed - unable to open >> 'HDF4_EOS:EOS_SWATH:D:\data\HDF\MOD02HKM.A2008275.0245.005.20082751 >> 12555.hdf:MODIS_SWATH_Type_L1B:EV_250_Aggr500_RefSB_Uncert_Indexes'. > > Perhaps, the problem is with the colon (:) in the path. There may be > some confusion with the path. Try to work around the colon by mounting > the D drive on any other folder in the F drive and provide a relative > path to the FWTools' bin folder. Let me know how it goes. > >> Open GDAL Datasets: >> 1 N DriverIsNULL -1 512x512x0 >> ======================== >> I want to know why?and if I put the hdf data under the F:\anzhuang\FWTools >> 2.2.8\bin, I can get the correct result...... >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > Regards, From legeochen at gmail.com Sat Mar 28 21:33:54 2009 From: legeochen at gmail.com (legeochen) Date: Sat Mar 28 21:33:56 2009 Subject: [gdal-dev] create 25D MultiPolygon how to In-Reply-To: <49CE79C1.8000204@ualg.pt> References: <49CE2C27.1040604@loskot.net> <49CE3ABD.8060008@ualg.pt> <49CE67F0.4090705@loskot.net> <49CE79C1.8000204@ualg.pt> Message-ID: Mateusz Loskot Thanks!! I'll keep this in mind. It's really important to good performance. 2009/3/29 Joaquim Luis > Thankx > > I'll keep this in mind if I ever one day start practicing C++ > For the time being, only good old C. > > Joaquim > > Joaquim Luis wrote: >> >>> Mateusz Loskot wrote: >>> >>> for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw != >>>>> _roadwayArr.end();itrw++) >>>>> >>>> ++itrw; >>>> >>>> if you care about performance. >>>> >>> Mateusz, >>> >>> Just curious. Why should that impact on performance? >>> >> >> The itrw here is most likely an iterator of type of user's class. >> The pointer arithmetic does work here only in terms of >> semantic, but not in terms of implementation. >> Meaning, both versions do the same - advance to next position: >> >> int* p = ...; // or any ordinary type >> p++; >> >> iterator it = ...; >> it++; >> >> However, the realization is completely different. >> Here is example of how pre- and post-increment operator is usually >> declared in a class: >> >> struct T >> { >> T& operator++(); // pre- >> T operator++(int); // post- >> }; >> >> The pre-increment operator returns reference to the object >> itself (return *this;) >> >> The post-increment returns a temporary copy of the object. >> There are important side-effects of returning copy: >> 1. it is constructed -> copy-construction -> constructor called >> 2. it is returned by value -> copy-construction -> constructor called >> >> Here is example of iterator and operator++ implementation: >> http://liblas.org/browser/trunk/include/liblas/iterator.hpp?rev813#L108 >> >> Object construction is considered in C++ as an expansive operation, >> next to dynamic storage allocation. >> If post-increment/decrement operator is used against pointers and >> integers, temporary object is also created, but as they are native >> types no constructor call is involved. >> >> People report different measurements on Usenet groups. Numbers >> vary but can easily hit 50 % of performance increase if you >> stick to use of pre-increment/decrement operator for class types. >> >> Best regards, >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090329/e6651c0e/attachment.html From mateusz at loskot.net Sun Mar 29 09:16:22 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun Mar 29 09:16:30 2009 Subject: [gdal-dev] WKT Raster driver in GSoC 2009 Message-ID: <49CF74A6.6070903@loskot.net> Dear Community, I've added proposal of GDAL Driver for PostGIS / WKT Raster to the GSoC 2009 list [1]. I hope you don't mind. [1] http://trac.osgeo.org/gdal/wiki/SummerOfCode If there is anyone interested in working on this project, I'm willing to mentor it. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From DCarreira at edia.pt Sun Mar 29 13:51:31 2009 From: DCarreira at edia.pt (Duarte Carreira) Date: Sun Mar 29 14:00:10 2009 Subject: [gdal-dev] convert 2 shapefiles to a single GPX? Message-ID: Even, I'm not having luck with the command to merge 2 gpx files. It always discards the points with many errors like this: ERROR 6: Cannot write a 'wpt' element after a 'trk' element. I am sure I'm using the correct order in the command, and the correct files. ogr2ogr -f GPX -dsco GPX_USE_EXTENSIONS=YES merged.gpx gpxdir waypoints tracks -skipfailures -lco FORCE_GPX_TRACK=TRUE I have added FORCE_GPX_TRACK=TRUE because the error before adding this referred to rte elements, and my lines are multilinestrings. Duarte ________________________________________ De:Duarte Carreira Mon, 19 Jan 2009 02:04:29 -0800 RE: [gdal-dev] convert 2 shapefiles to a single GPX? Now this I've got to try! The VRT file idea is intriguing. I didn't know it had this much flexibility... Thanks, Duarte -----Mensagem original----- De: Even Rouault [mailto:even.roua...@mines-paris.org] Enviada: s?bado, 17 de Janeiro de 2009 20:43 Para: gdal-dev@lists.osgeo.org Cc: Duarte Carreira; Stefan Keller; Jean-Claude Repetto Assunto: Re: [gdal-dev] convert 2 shapefiles to a single GPX? Here's one solution : 1) create a directory, for example "merge_shp" 2) copy in merge_shp the shapefile that is going to be put in the waypoints layer as "waypoints.shp" (rename the .dbf and .shx accordingly) 3) copy in merge_shp the shapefile that is going to be put in the tracks layer as "tracks.shp" (rename the .dbf and .shx accordingly) 4) run "ogr2ogr -f GPX merged.gpx merge_shp waypoints tracks" (the order of the layers is important) A solution based on an OGR VRT file defining the two layers from the 2 shapefiles would also probably work. Le Thursday 15 January 2009 12:03:27 Duarte Carreira, vous avez ?crit : > Maybe the same approach can be used with 2 gpx files? That would be very > good. I cannot merge 2 shapefiles with different geometry types. I could > convert line shape>gpx1 and point shape->gpx2 and then merge > gpx2+gpx2->gpx3... > > > Thanks, > Duarte > > De: Stefan Keller [mailto:sfkel...@gmail.com] > Enviada: quarta-feira, 14 de Janeiro de 2009 22:40 > Para: Jean-Claude Repetto > Cc: Duarte Carreira; gdal-dev@lists.osgeo.org > Assunto: Re: [gdal-dev] convert 2 shapefiles to a single GPX? > > > A merge of two shapefiles 'file1.shp' and 'file2.shp' into a new file > 'file_merged.shp' is performed like this (See > http://www.gdal.org/ogr/drv_shapefile.html): > > % ogr2ogr file_merged.shp file1.shp > % ogr2ogr -update -append file_merged.shp file2.shp -nln file_merged > > Then convert to GPX: > % ogr2ogr -f "GPX" out.gpx file_merged.shp > > Stefan > http://geoconverter.hsr.ch > 2009/1/14 Jean-Claude Repetto >> > Duarte Carreira a ?crit : > > Can OGR convert 2 shapefiles to a single GPX? > > The objective is to add tracks from a line shapefile and waypoints from a > point shapefile... > > Hello, > > I don't know the answer to your question, but since GPX files are text > files, it is very easy to merge two GPX files with a text editor. > > HTH ! > Jean-Claude > > > > _______________________________________________ > 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 From jorge.arevalo at gmail.com Sun Mar 29 14:11:40 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Sun Mar 29 14:11:57 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 Message-ID: Hello everybody, I'm interesed in these projects: - PNG Driver - WMTS implementation - WKT Raster Driver I would like to know a little more about them. Basically, their estimated difficulty. I'm very exciting about the possibility of being one of the selected OSGeo students for GSoC 2009, but I think that I need to be realistic and totally comitted with the project. I'm making a schedule, and I would like to know if all projects fit into it. For example, the last two projects seem to be longer that the first one, but maybe I'm wrong. Thanks in advance Best regards Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090329/f168cde0/attachment.html From jorge.arevalo at gmail.com Sun Mar 29 14:16:09 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Sun Mar 29 14:16:26 2009 Subject: [gdal-dev] WKT Raster driver in GSoC 2009 In-Reply-To: <49CF74A6.6070903@loskot.net> References: <49CF74A6.6070903@loskot.net> Message-ID: Hello, I've just send a mail about GSoC 09. This is one of the projects I'm interested in. What skills are required/strongly desired (apart from knowledge on C/C++)? What difficult level would you assign to the project? Oh, you may prefer to answer my other e-mail :-) Best regards Jorge On Sun, Mar 29, 2009 at 3:16 PM, Mateusz Loskot wrote: > Dear Community, > > I've added proposal of GDAL Driver for PostGIS / WKT Raster to the GSoC > 2009 list [1]. I hope you don't mind. > > [1] http://trac.osgeo.org/gdal/wiki/SummerOfCode > > If there is anyone interested in working on this project, > I'm willing to mentor it. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090329/df089913/attachment.html From even.rouault at mines-paris.org Sun Mar 29 14:26:22 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Sun Mar 29 14:26:33 2009 Subject: [gdal-dev] convert 2 shapefiles to a single GPX? In-Reply-To: References: Message-ID: <200903292026.23493.even.rouault@mines-paris.org> Duarte, yes I could reproduce your error too... In fact, depending on the source directory, you could observe that sometimes it works, sometimes it doesn't... The main reason is that ogr2ogr doesn't get the layers in the order you specify them on the command line. I've always made this wrong assumption, but the current state of ogr2ogr simply rely on the order in which they are exposed by the source dataset (and for a shapefile dataset, it is the order in which the filesystem lists the files of the directory, which is unspecified). Maybe we should correct ogr2ogr behaviour, so that is iterates on the source layers in the order in which they are specified... In the meantime, I've come with a workaround using OGR VRT. Save the following content as gpxdir.vrt for example, at the same level of your gpxdir directory. gpxdir waypoints wkbPoint WGS84 gpxdir tracks wkbLineString WGS84 Then run : ogr2ogr -f GPX -dsco GPX_USE_EXTENSIONS=YES merged.gpx gpxdir.vrt -skipfailures -lco FORCE_GPX_TRACK=TRUE Best regards, Even Le Sunday 29 March 2009 19:51:31 Duarte Carreira, vous avez ?crit?: > Even, > > I'm not having luck with the command to merge 2 gpx files. It always > discards the points with many errors like this: ERROR 6: Cannot write a > 'wpt' element after a 'trk' element. > > I am sure I'm using the correct order in the command, and the correct > files. ogr2ogr -f GPX -dsco GPX_USE_EXTENSIONS=YES merged.gpx gpxdir > waypoints tracks -skipfailures -lco FORCE_GPX_TRACK=TRUE > > I have added FORCE_GPX_TRACK=TRUE because the error before adding this > referred to rte elements, and my lines are multilinestrings. > > Duarte > > ________________________________________ > De:Duarte Carreira > Mon, 19 Jan 2009 02:04:29 -0800 > RE: [gdal-dev] convert 2 shapefiles to a single GPX? > > > Now this I've got to try! > > The VRT file idea is intriguing. I didn't know it had this much > flexibility... > > Thanks, > Duarte > > -----Mensagem original----- > De: Even Rouault > [mailto:even.roua...@mines-paris.org] > Enviada: s?bado, 17 de Janeiro de 2009 20:43 > Para: gdal-dev@lists.osgeo.org > Cc: Duarte Carreira; Stefan Keller; Jean-Claude Repetto > Assunto: Re: [gdal-dev] convert 2 shapefiles to a single GPX? > > Here's one solution : > > 1) create a directory, for example "merge_shp" > 2) copy in merge_shp the shapefile that is going to be put in the waypoints > layer as "waypoints.shp" (rename the .dbf and .shx accordingly) > 3) copy in merge_shp the shapefile that is going to be put in the tracks > layer as "tracks.shp" (rename the .dbf and .shx accordingly) > 4) run "ogr2ogr -f GPX merged.gpx merge_shp waypoints tracks" (the order of > the layers is important) > > A solution based on an OGR VRT file defining the two layers from the 2 > shapefiles would also probably work. > > Le Thursday 15 January 2009 12:03:27 Duarte Carreira, vous avez ?crit : > > Maybe the same approach can be used with 2 gpx files? That would be very > > good. I cannot merge 2 shapefiles with different geometry types. I could > > convert line shape>gpx1 and point shape->gpx2 and then merge > > gpx2+gpx2->gpx3... > > > > > > Thanks, > > Duarte > > > > De: Stefan Keller [mailto:sfkel...@gmail.com] > > Enviada: quarta-feira, 14 de Janeiro de 2009 22:40 > > Para: Jean-Claude Repetto > > Cc: Duarte Carreira; > > gdal-dev@lists.osgeo.org Assunto: Re: > > [gdal-dev] convert 2 shapefiles to a single GPX? > > > > > > A merge of two shapefiles 'file1.shp' and 'file2.shp' into a new file > > 'file_merged.shp' is performed like this (See > > http://www.gdal.org/ogr/drv_shapefile.html): > > > > % ogr2ogr file_merged.shp file1.shp > > % ogr2ogr -update -append file_merged.shp file2.shp -nln file_merged > > > > Then convert to GPX: > > % ogr2ogr -f "GPX" out.gpx file_merged.shp > > > > Stefan > > http://geoconverter.hsr.ch > > 2009/1/14 Jean-Claude Repetto > > >:jrepe...@free.fr>>> Duarte Carreira a ?crit : > > > > Can OGR convert 2 shapefiles to a single GPX? > > > > The objective is to add tracks from a line shapefile and waypoints from a > > point shapefile... > > > > Hello, > > > > I don't know the answer to your question, but since GPX files are text > > files, it is very easy to merge two GPX files with a text editor. > > > > HTH ! > > Jean-Claude > > > > > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org >@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 From mateusz at loskot.net Sun Mar 29 15:34:55 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun Mar 29 15:35:02 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: References: Message-ID: <49CFCD5F.4080904@loskot.net> Jorge Ar?valo wrote: > Hello everybody, > > I'm interesed in these projects: > - PNG Driver > - WMTS implementation > - WKT Raster Driver Great! > I would like to know a little more about them. Do you have any specific questions or concerns? > Basically, their estimated difficulty. Difficulty is a subjective thing. What is difficult to me, might be easy to you, so estimation may be lead misleading. > I'm very exciting about the possibility of being one of the selected > OSGeo students for GSoC 2009, but I think that I need to be realistic > and totally comitted with the project. I'm making a schedule, and I > would like to know if all projects fit into it. And, what's your schedule? > For example, the last > two projects seem to be longer that the first one, but maybe I'm > wrong. Exactly, "seem" is the right word. We don't know what's your experience and what you consider as easy/difficult. So, it's very hard to help you in making your decision unless you have specific / technical questions. Remember, that GSoC projects are not managed in the commercial way. It's you and mentor who agree that a project is completed or not. See Q9 and Q10: http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_use_code So, I'd not worry much about making a very detailed timeline plan. For instance WKT Raster driver, as I mentioned in the proposal, the idea is to develop a *prototype*, something that proofs (or not) the concept is feasible and implementation may perform well, something that will be helpful and usable for further development. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mateusz at loskot.net Sun Mar 29 15:47:08 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun Mar 29 15:47:16 2009 Subject: [gdal-dev] WKT Raster driver in GSoC 2009 In-Reply-To: References: <49CF74A6.6070903@loskot.net> Message-ID: <49CFD03C.1010509@loskot.net> Jorge Ar?valo wrote: > Hello, > > I've just send a mail about GSoC 09. This is one of the projects I'm > interested in. What skills are required/strongly desired (apart from > knowledge on C/C++)? In the proposal, I specified more elements: raster graphics, basic understanding of Well-Known-Binary-like formats, libpq, C (strong), C++ (basic). In my opinion, it's recommended that a candidate understand/know: - raster - band - pixel and how pixel type influences raster structure - recognize BIP, BIL and BSQ layouts - reading and parsing binary data in C/C++ - encode/decode raw binary data to/from hex in C/C++ - understand idea behind Well-Known-Text and Well-Known-Binary - understand basics of architecture of GDAL - understand basics of PostGIS - how to write good unit test for GDAL driver - how to use GDAL, PostgreSQL and PostGIS manuals and websites > What difficult level would you assign to the project? As I've explained, I'm unable to judge this aspect. > Oh, you may prefer to answer my other e-mail :-) Actually, I'd strongly encourage to discuss everything on public forum. As this is about GDAL driver, then gdal-dev is probably best place for discussing it. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From DCarreira at edia.pt Sun Mar 29 15:52:03 2009 From: DCarreira at edia.pt (Duarte Carreira) Date: Sun Mar 29 15:59:11 2009 Subject: [gdal-dev] OGR + ArcSDE: support for non-spatial tables Message-ID: Does anyone know if there's support for non-spatial tables in ArcSDE through OGR? For instance to make a join with a spatial table? Thanks, Duarte From jorge.arevalo at gmail.com Sun Mar 29 20:00:10 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Sun Mar 29 20:00:28 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <49CFCD5F.4080904@loskot.net> References: <49CFCD5F.4080904@loskot.net> Message-ID: Hello, "Difficult" is a very subjective thing, totally agree. Sorry for the approach of the question. Maybe I can raise it in that way: What amount of theoretical/practical knowledge do I need to start working on the project? For example, the first project (PNG driver) suggests me the following initial knowledges (most of them are specified in the web http://trac.osgeo.org/gdal/wiki/SummerOfCode): - PNG format (of course) - C / C++ fluently - Raster, bands - Basic GDAL architecture - NeuQuant algorithm - Kohonen Neural Networks - pngnq - Several tools that optimize PNG The project about WKT raster (the list that you provided me on another mail): - raster - band - pixel and how pixel type influences raster structure - recognize BIP, BIL and BSQ layouts - reading and parsing binary data in C/C++ - encode/decode raw binary data to/from hex in C/C++ - understand idea behind Well-Known-Text and Well-Known-Binary - understand basics of architecture of GDAL - understand basics of PostGIS - how to write good unit test for GDAL driver - how to use GDAL, PostgreSQL and PostGIS manuals and websites All concepts sound familiar (because I've studied or worked with them), but I think that I need some previous time to go deeper. I have to include this in my schedule. I'll finish it tomorrow, and we'll be able to go further on this issue, if you want :-) Thanks for your response Best regards Jorge 2009/3/29 Mateusz Loskot > Jorge Ar?valo wrote: > > Hello everybody, > > > > I'm interesed in these projects: > > - PNG Driver > > - WMTS implementation > > - WKT Raster Driver > > Great! > > > I would like to know a little more about them. > > Do you have any specific questions or concerns? > > > Basically, their estimated difficulty. > > Difficulty is a subjective thing. > What is difficult to me, might be easy to you, so estimation > may be lead misleading. > > > I'm very exciting about the possibility of being one of the selected > > OSGeo students for GSoC 2009, but I think that I need to be realistic > > and totally comitted with the project. I'm making a schedule, and I > > would like to know if all projects fit into it. > > And, what's your schedule? > > > For example, the last > > two projects seem to be longer that the first one, but maybe I'm > > wrong. > > Exactly, "seem" is the right word. > > We don't know what's your experience and what you consider as > easy/difficult. So, it's very hard to help you in making your > decision unless you have specific / technical questions. > > Remember, that GSoC projects are not managed in the commercial way. > It's you and mentor who agree that a project is completed or not. > See Q9 and Q10: > > http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_use_code > > So, I'd not worry much about making a very detailed timeline plan. > > For instance WKT Raster driver, as I mentioned in the proposal, the idea > is to develop a *prototype*, something that proofs (or not) the concept > is feasible and implementation may perform well, something that will be > helpful and usable for further development. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/c8f6cf9e/attachment.html From mateusz at loskot.net Sun Mar 29 20:09:12 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun Mar 29 20:09:17 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: References: <49CFCD5F.4080904@loskot.net> Message-ID: <49D00DA8.3010505@loskot.net> Jorge Ar?valo wrote: > "Difficult" is a very subjective thing, totally agree. Sorry for the > approach of the question. > [...] > All concepts sound familiar (because > I've studied or worked with them), but I think that I need some > previous time to go deeper. I have to include this in my schedule. Here are some helpful notes: http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_student_time GSoc lasts for fixed time period and no more. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From emmanuel.sambale at gmail.com Sun Mar 29 22:05:02 2009 From: emmanuel.sambale at gmail.com (maning sambale) Date: Sun Mar 29 22:05:04 2009 Subject: [gdal-dev] convert qct format to geotiff Message-ID: Hi, Hope this is the right list. I have topo maps in qct raster file format. QCT file is proprietary format from Memory Map: http://www.memory-map.co.uk/ Searching for a free converter I found this link: http://mail.python.org/pipermail/python-list/2007-December/641555.html Conversion seems to work on limited size 2000 x 2000 pixels and doesn't preserve rectification. Is there a gdal workaround to convert them into geotiff? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------ From jachym.cepicky at gmail.com Mon Mar 30 02:13:29 2009 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Mar 30 02:13:50 2009 Subject: [gdal-dev] Re: [GRASS-user] create a workplace (location mapset etc)_ In-Reply-To: <9818958.75091238138721787.JavaMail.coremail@yeahapp6.yeah.net> References: <9818958.75091238138721787.JavaMail.coremail@yeahapp6.yeah.net> Message-ID: <20090330061329.GI5448@kocour> hi. you can make the raster (and vector) data accessable via UMN MapServer directly, without any export need. UMN MapServer can read the data (via gdal/ogr) and display the via WMS. There is also another project, called pywms, which provides automatic WMS Service based on GRASS Database. The Capabilities document for WMS is created from GRASS Database on-the-fly, as well as maps. So, only r.in.gdal would be need, r.out.gdal is actually no necessary. Jachym [1] http://mapserver.org/ [2] http://pywms.wald.intevation.org On Fri, Mar 27, 2009 at 03:25:21PM +0800, apachemaven wrote: > I want to handle some hdf data through a web service,and in the web service I handle the data by grass, so the problem comes out.The following is my setps: > 1)translate the hdf4 to a tif by a FWTools2.2.8 which call the gdal command actually) > for example I use the command "gdal_translate [the subset] d:\aa.tif" , > 2)import the tif > "r.in.gdal input=D:/aaa6.tif output=ggg" > 3)process the ggg data of grass format > for example "r.buffer map=ggg distance=30 output=temp" > 4)convert the temp to tif > "r.out.gdal input=temp format=GTiff output=d:/dd.tif" > Then in the web service I return the url of the dd.tif to client. > I want to know the above setps right or not? > and in the step of 2 and 4 problems always come out..,a common problem is the data is blank even I reset the region use "g.region rast=..." > > My god,I am crazying@@! > _______________________________________________ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp Key fingerprint: 0C6D 0EAE 76BD 506C F299 ED8A C8AB 74B8 08D4 E08F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/aef2d9e1/attachment.bin From jachym.cepicky at gmail.com Mon Mar 30 02:17:07 2009 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Mar 30 02:17:33 2009 Subject: [gdal-dev] Re: [GRASS-user] creat a temp workplace In-Reply-To: <21686070.76661238139189556.JavaMail.coremail@yeahapp6.yeah.net> References: <21686070.76661238139189556.JavaMail.coremail@yeahapp6.yeah.net> Message-ID: <20090330061707.GJ5448@kocour> hi, On Fri, Mar 27, 2009 at 03:33:09PM +0800, apachemaven wrote: > And in the step 2, I want to creat a temp location and mapset,beacuse my current location is the spanish example data... > My god,I am crazying@@! basically, any location can be considered as "temp", because of after deleting the whole directory, it is gone (uninstalled). if you want to create temp location in a batch script, just prepare some template location (with PERMANENT mapset and DEFULT_WIND and other files) than you can just copy this template under new name and so the temporary location is created. if you set the GRASS_BATCH_JOB env. variable, (shell script to be processed as batch job), the script will be performed automatically. jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp Key fingerprint: 0C6D 0EAE 76BD 506C F299 ED8A C8AB 74B8 08D4 E08F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/6eff5ff5/attachment.bin From bea at ixsea.com Fri Mar 27 13:54:01 2009 From: bea at ixsea.com (=?iso-8859-1?Q?Beno=EEt_Andrieu?=) Date: Mon Mar 30 04:59:17 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238153162.S.8403.10312.f4mail-235-216.rediffmail.com.old.replied.1238163080.28007@webmail.rediffmail.com> References: <1238153162.S.8403.10312.f4mail-235-216.rediffmail.com.old.replied.1238163080.28007@webmail.rediffmail.com> Message-ID: <75EB64C9AC60428281F13122D7F0C1C8@ixsea.local> Hi, I am using FWTools 2.2.9 So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with : gdal_i.lib geos_i.lib geotiff_i.lib libtiff_i.lib proj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PM Subject: Re :Re: [gdal-dev] How to use GDAL Library Hi Beno?t Andrieu, Thanks for reply. i already saw that tutorial, but the problame is how to and which library to be linked using QT(most probably same way of C/C++). coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib. On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wrote Hi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html. It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AM Subject: [gdal-dev] How to use GDAL Library Dear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance _______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090327/df01911e/attachment-0001.html From isajmeri at rediffmail.com Mon Mar 30 05:06:37 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Mon Mar 30 05:14:02 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <1238403530.S.10067.16506.f4mail-234-125.rediffmail.com.old.1238403997.5158@webmail.rediffmail.com> Hi,Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code.i have downloded gdal_i.lib, gdal.dll and its include .h files..h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files.can u please give me broad idea or step by step procedure about how do i link these library to c++ code.thanks in advanceRegards,IqbalOn Fri, 27 Mar 2009 18:54:01 +0100 Beno?t Andrieu wroteHi, I am using FWTools 2.2.9So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with :gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PMSubject: Re :Re: [gdal-dev] How to use GDAL LibraryHi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/f4d9c59b/attachment.html From lucafasano at interfree.it Mon Mar 30 05:15:05 2009 From: lucafasano at interfree.it (Luca Fasano) Date: Mon Mar 30 05:17:35 2009 Subject: [gdal-dev] utm projection in gdal_translate Message-ID: <49D08D99.1010105@interfree.it> Hi, I want to create a GTiff copy to a data with projection overridden to *utm* using gdal_translate and its "a_srs" parameter. If I try to do this I obtain a wrongly located data. Command I use is like following: $ gdal_translate -of GTiff -a_srs "+proj=utm +datum=WGS84 +zone= " src dst.tiff If I try to georeference the same data with gdal_warp and the same parameters I obtain a correctly located data, so I think the problem doesn't come from datas neither from parameters. What's wrong? Have I skipped some parameters? From bea at ixsea.com Mon Mar 30 08:42:07 2009 From: bea at ixsea.com (=?iso-8859-1?Q?Beno=EEt_Andrieu?=) Date: Mon Mar 30 08:42:13 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238403530.S.10067.16506.f4mail-234-125.rediffmail.com.old.1238403997.5158@webmail.rediffmail.com> References: <1238403530.S.10067.16506.f4mail-234-125.rediffmail.com.old.1238403997.5158@webmail.rediffmail.com> Message-ID: <0F175576B710419692C76C6F6B70EA2B@ixsea.local> Hi ! You won't need any cpp files. Personally, I am using the FWTools package which bundles dll, libs and headers files. You just have to compile using gdal_priv.h Then link to gdal_i.lib Then provide with your runtime all the dlls which gdal_fw.dll is depending to. You will find which dlls it is depending to by using Dependency Walker (http://www.dependencywalker.com/). Then your runtime will be able to use all of the image formats drivers that GDAL was compiled to support. I hope this will help. Regards, Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 11:06 AM Subject: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library Hi, Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code. i have downloded gdal_i.lib, gdal.dll and its include .h files. .h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files. can u please give me broad idea or step by step procedure about how do i link these library to c++ code. thanks in advance Regards, Iqbal On Fri, 27 Mar 2009 18:54:01 +0100 Beno?t Andrieu wrote Hi, I am using FWTools 2.2.9 So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with : gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PM Subject: Re :Re: [gdal-dev] How to use GDAL Library Hi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/190999c3/attachment.html From isajmeri at rediffmail.com Mon Mar 30 09:22:46 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Mon Mar 30 09:30:12 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <1238416899.S.13090.14599.f4mail-234-215.rediffmail.com.1238419366.63138@webmail.rediffmail.com> Hi,Thanks Beno?t Andrieubea for your reply.you are right, there is no need any cpp file. but when i build the same code given in GDAL tutorial with QT Creator popups the following error.g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o debug\ImageRW.exe debug/main.o -L"d:\Qt\2009.01\qt\lib" gdal_i.lib -lQtCored4mingw32-make[1]: Leaving directory `D:/QT_Projects/ImageRW'mingw32-make: Leaving directory `D:/QT_Projects/ImageRW'debug/main.o: In function `main':D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterCount()'D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterYSize()'D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterXSize()'collect2: ld returned 1 exit statusmingw32-make[1]: *** [debug\ImageRW.exe] Error 1mingw32-make: *** [debug] Error 2Exited with code 2.but the same code i builded with VC++ 2005, its working fine.unfortunatly i want to link GDAL library in QT.the bellow is my QT .pro file settingQT -= guiTARGET = ImageRWCONFIG += consoleCONFIG -= app_bundleTEMPLATE = appSOURCES += main.cppLIBS += gdal_i.libthanks in advance.On Mon, 30 Mar 2009 14:42:07 +0200 Beno?t Andrieu wroteHi ! You won't need any cpp files.Personally, I am using the FWTools package which bundles dll, libs and headers files. You just have to compile using gdal_priv.hThen link to gdal_i.libThen provide with your runtime all the dlls which gdal_fw.dll is depending to.You will find which dlls it is depending to by using Dependency Walker (http://www.dependencywalker.com/). Then your runtime will be able to use all of the image formats drivers that GDAL was compiled to support. I hope this will help. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 11:06 AMSubject: Re :Re: Re :Re: [gdal-dev] How to use GDAL LibraryHi,Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code.i have downloded gdal_i.lib, gdal.dll and its include .h files..h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files.can u please give me broad idea or step by step procedure about how do i link these library to c++ code.thanks in advanceRegards,IqbalOn Fri, 27 Mar 2009 18:54:01 +0100 Beno?t Andrieu wroteHi, I am using FWTools 2.2.9So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with :gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PMSubject: Re :Re: [gdal-dev] How to use GDAL LibraryHi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/3e6b319e/attachment-0001.html From bea at ixsea.com Mon Mar 30 09:34:18 2009 From: bea at ixsea.com (=?iso-8859-1?Q?Beno=EEt_Andrieu?=) Date: Mon Mar 30 09:34:24 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238416899.S.13090.14599.f4mail-234-215.rediffmail.com.1238419366.63138@webmail.rediffmail.com> References: <1238416899.S.13090.14599.f4mail-234-215.rediffmail.com.1238419366.63138@webmail.rediffmail.com> Message-ID: Well... Have you checked your path to your include files ? Could I see the part of the code where the errors occured ? Thx Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 3:22 PM Subject: Re :Re: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library Hi, Thanks Beno?t Andrieubea for your reply. you are right, there is no need any cpp file. but when i build the same code given in GDAL tutorial with QT Creator popups the following error. g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o debugImageRW.exe debug/main.o -L"d:Qt2009.01qtlib" gdal_i.lib -lQtCored4 mingw32-make[1]: Leaving directory `D:/QT_Projects/ImageRW' mingw32-make: Leaving directory `D:/QT_Projects/ImageRW' debug/main.o: In function `main': D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterCount()' D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterYSize()' D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to `GDALDataset::GetRasterXSize()' collect2: ld returned 1 exit status mingw32-make[1]: *** [debugImageRW.exe] Error 1 mingw32-make: *** [debug] Error 2 Exited with code 2. but the same code i builded with VC++ 2005, its working fine. unfortunatly i want to link GDAL library in QT. the bellow is my QT .pro file setting QT -= gui TARGET = ImageRW CONFIG += console CONFIG -= app_bundle TEMPLATE = app SOURCES += main.cpp LIBS += gdal_i.lib thanks in advance. On Mon, 30 Mar 2009 14:42:07 +0200 Beno?t Andrieu wrote Hi ! You won't need any cpp files. Personally, I am using the FWTools package which bundles dll, libs and headers files. You just have to compile using gdal_priv.h Then link to gdal_i.lib Then provide with your runtime all the dlls which gdal_fw.dll is depending to. You will find which dlls it is depending to by using Dependency Walker (http://www.dependencywalker.com/). Then your runtime will be able to use all of the image formats drivers that GDAL was compiled to support. I hope this will help. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com ----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 11:06 AM Subject: Re :Re: Re :Re: [gdal-dev] How to use GDAL Library Hi,Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code. i have downloded gdal_i.lib, gdal.dll and its include .h files..h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files. can u please give me broad idea or step by step procedure about how do i link these library to c++ code. thanks in advanceRegards,IqbalOn Fri, 27 Mar 2009 18:54:01 +0100 Beno?t Andrieu wroteHi, I am using FWTools 2.2.9So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with :gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PMSubject: Re :Re: [gdal-dev] How to use GDAL LibraryHi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/55c570aa/attachment.html From jef at norbit.de Mon Mar 30 09:55:18 2009 From: jef at norbit.de (=?iso-8859-1?B?SvxyZ2VuIEUu?= Fischer) Date: Mon Mar 30 09:55:27 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238416899.S.13090.14599.f4mail-234-215.rediffmail.com.1238419366.63138@webmail.rediffmail.com> References: <1238416899.S.13090.14599.f4mail-234-215.rediffmail.com.1238419366.63138@webmail.rediffmail.com> Message-ID: <20090330135518.GA15550@norbit.de> Hi, On Mon, 30. Mar 2009 at 13:22:46 -0000, Ajmeri Iqbal wrote: > D:/QT_Projects/ImageRW/main.cpp:34: undefined reference to > `GDALDataset::GetRasterCount()' Are you using the C++ API directly? That won't work from MinGW unless GDAL is also built with MinGW. The C-API will work. J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 From nahumoz at gmail.com Mon Mar 30 11:25:13 2009 From: nahumoz at gmail.com (Oz Nahum) Date: Mon Mar 30 11:25:16 2009 Subject: [gdal-dev] ERROR 4: `AOI.tif' not recognised as a supported file format. Message-ID: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> Hi, I have encountered a weired problem with gdal_rasterize. when I run the script from here http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedonavectorfilesextentsforusewithgdal_rasterize When I run: #!/usr/bin/env python from osgeo import gdal from osgeo import osr from osgeo import ogr import numpy #from numpy import ones import stat, sys, os, string, commands shp = 'AOI' tiff = 'AOI.tif' px = 1 tiff_width = 80 tiff_height = 80 # Import vector shapefile vector = ogr.GetDriverByName('ESRI Shapefile') src_ds = vector.Open(shp +'.shp') src_lyr = src_ds.GetLayerByIndex(index=0) src_extent = src_lyr.GetExtent() # Create new raster layer with 4 bands raster = gdal.GetDriverByName('GTiff') dst_ds = raster.Create( tiff, tiff_width, tiff_height, 1, gdal.GDT_Byte) # Create raster GeoTransform based on upper left corner and pixel resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3], 0.0, -px] dst_ds.SetGeoTransform( raster_transform ) # Get projection of shapefile and assigned to raster srs = osr.SpatialReference() srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__()) dst_ds.SetProjection( srs.ExportToWkt() ) # Create blank raster with fully opaque alpha band zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) dst_ds.GetRasterBand(1).WriteArray( zeros ) commandString = 'gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif' commandOutput = commands.getoutput(commandString) print commandOutput #end of code I get the error this error: augmented to the gdal_rasterize command I see this error. When I run it via a shell script, I don't see the error: ERROR 4: `AOI.tif' not recognised as a supported file format. #!/bin/sh python create_empty_raster.py gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif Runs ok. So I am confused, why I can't call gdal_rasterize from python ? Thanks, for any help Oz Nahum Universt?t Tuebingen Applied Environmental Sciences -- ---- Imagine there's no countries It isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/b14d5eaf/attachment.html From warmerdam at pobox.com Mon Mar 30 12:42:16 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 30 12:42:35 2009 Subject: [gdal-dev] utm projection in gdal_translate In-Reply-To: <49D08D99.1010105@interfree.it> References: <49D08D99.1010105@interfree.it> Message-ID: <49D0F668.3090600@pobox.com> Luca Fasano wrote: > Hi, > I want to create a GTiff copy to a data with projection overridden to > *utm* using gdal_translate and its "a_srs" parameter. > If I try to do this I obtain a wrongly located data. > Command I use is like following: > $ gdal_translate -of GTiff -a_srs "+proj=utm +datum=WGS84 > +zone= " src dst.tiff > > If I try to georeference the same data with gdal_warp and the same > parameters I obtain a correctly located data, so I think the problem > doesn't come from datas neither from parameters. > > What's wrong? Have I skipped some parameters? Luca, Are you aware that gdal_translate's -a_srs just overrides the coordinate system definition but does not in any way adjust the geotransform? It is only suitable for use to override an improperly described dataset, not to transform a dataset into a new coordinate system. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From even.rouault at mines-paris.org Mon Mar 30 13:02:25 2009 From: even.rouault at mines-paris.org (Even Rouault) Date: Mon Mar 30 13:02:34 2009 Subject: [gdal-dev] ERROR 4: `AOI.tif' not recognised as a supported file format. In-Reply-To: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> References: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> Message-ID: <200903301902.25879.even.rouault@mines-paris.org> Oz, See the hereafter a correction to insert in your code that will hopefully fix your issue. Le Monday 30 March 2009 17:25:13 Oz Nahum, vous avez ?crit?: > Hi, > I have encountered a weired problem with gdal_rasterize. > > when I run the script from here > http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedona >vectorfilesextentsforusewithgdal_rasterize > > When I run: > #!/usr/bin/env python > > from osgeo import gdal > from osgeo import osr > from osgeo import ogr > import numpy > #from numpy import ones > import stat, sys, os, string, commands > > shp = 'AOI' > tiff = 'AOI.tif' > px = 1 > tiff_width = 80 > tiff_height = 80 > > # Import vector shapefile > vector = ogr.GetDriverByName('ESRI Shapefile') > src_ds = vector.Open(shp +'.shp') > src_lyr = src_ds.GetLayerByIndex(index=0) > src_extent = src_lyr.GetExtent() > > # Create new raster layer with 4 bands > raster = gdal.GetDriverByName('GTiff') > dst_ds = raster.Create( tiff, tiff_width, tiff_height, 1, gdal.GDT_Byte) > > # Create raster GeoTransform based on upper left corner and pixel > resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3], 0.0, > -px] dst_ds.SetGeoTransform( raster_transform ) > > # Get projection of shapefile and assigned to raster > srs = osr.SpatialReference() > srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__()) > dst_ds.SetProjection( srs.ExportToWkt() ) > > # Create blank raster with fully opaque alpha band > zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) > dst_ds.GetRasterBand(1).WriteArray( zeros ) # Properly close the dataset before calling gdal_rasterize, so that the TIF # file is properly written. dst_ds = None > > commandString = 'gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif' > commandOutput = commands.getoutput(commandString) > print commandOutput > #end of code > > I get the error this error: > > augmented to the gdal_rasterize command I see this error. When I run it via > a shell script, I don't see the error: > ERROR 4: `AOI.tif' not recognised as a supported file format. > > > #!/bin/sh > python create_empty_raster.py > gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif > > Runs ok. --> This runs ok as at the end of the create_empty_raster.py script, the GDAL dataset is automatically closed. > > So I am confused, why I can't call gdal_rasterize from python ? > Thanks, for any help > > Oz Nahum > Universt?t Tuebingen > Applied Environmental Sciences From bea at ixsea.com Mon Mar 30 13:27:27 2009 From: bea at ixsea.com (=?UTF-8?Q?Beno=C3=AEt_Andrieu?=) Date: Mon Mar 30 13:27:30 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <200903301902.25879.even.rouault@mines-paris.org> References: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> <200903301902.25879.even.rouault@mines-paris.org> Message-ID: <060C30ADE9374F78B20BE741F2F82F1C@ixsea.local> Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com From warmerdam at pobox.com Mon Mar 30 14:56:32 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 30 14:56:49 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <060C30ADE9374F78B20BE741F2F82F1C@ixsea.local> References: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> <200903301902.25879.even.rouault@mines-paris.org> <060C30ADE9374F78B20BE741F2F82F1C@ixsea.local> Message-ID: <49D115E0.1030605@pobox.com> Beno?t Andrieu wrote: > Hi list ! > > I was wondering why the Lanczos and cubicspline are available in > gdal_warp and not gdaladdo ? Beno?t, The overview builder and warper use quite different mechanisms so there is no close relationship between the resampling options available in each case. > The quality after downsizing images with gdalwarp is so perfect that I > am now willing to include this in my overviews. > Is there any chances to have this include in future releases or is there > any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. In theory it should be possible to programatically connect warpers to overview levels in cases where overview band objects have "proper" dataset parents - which is the case with GeoTIFF hosted overviews. For instance, this C entry point could likely be used with hSrcDS being the base datset, and hDstDS being the dataset for the overviews. One problem with this plan is that it is likely that overview datasets do not have proper geotransforms or coordinate systems. So you might need to push a geotransform onto the overview dataset (with GDALSetGeoTransform()) before calling GDALReprojectImage(). CPLErr CPL_DLL CPL_STDCALL GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, GDALDatasetH hDstDS, const char *pszDstWKT, GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit, double dfMaxError, GDALProgressFunc pfnProgress, void *pProgressArg, GDALWarpOptions *psOptions ); Generally the warp api resamplers are not suitable for with a destination dataset with a radically lower resolution than the source. So I'd suggest doing it such that each overview is generated from the next higher resolution overview rather than always building from the base level. Note that the overview levels still need to be pre-created using normal mechanisms. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From seth at pricepages.org Mon Mar 30 14:38:34 2009 From: seth at pricepages.org (Seth Price) Date: Mon Mar 30 15:13:39 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <060C30ADE9374F78B20BE741F2F82F1C@ixsea.local> References: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> <200903301902.25879.even.rouault@mines-paris.org> <060C30ADE9374F78B20BE741F2F82F1C@ixsea.local> Message-ID: <3422.129.123.22.47.1238438314.squirrel@pricepages.org> The resampling code between gdal_warp and gdaladdo is completely separate, thus it is basically two different projects. For the Google Summer of Code application I'm about to submit I will be working on the resampling code in GDAL's warper and GRASS. If I have time (and my application is accepted!) I'll try to look into gdaladdo also. ~Seth On Mon, March 30, 2009 12:27 pm, Beno??t Andrieu wrote: > Hi list ! > > I was wondering why the Lanczos and cubicspline are available in gdal_warp > and not gdaladdo ? > > The quality after downsizing images with gdalwarp is so perfect that I am > now willing to include this in my overviews. > Is there any chances to have this include in future releases or is there > any difficulties I am not aware of ? > > Beno??t Andrieu > bea@ixsea.com > benoit.andrieu@gmail.com > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From nahumoz at gmail.com Mon Mar 30 15:21:58 2009 From: nahumoz at gmail.com (Oz Nahum) Date: Mon Mar 30 15:22:05 2009 Subject: [gdal-dev] ERROR 4: `AOI.tif' not recognised as a supported file format. In-Reply-To: <200903301902.25879.even.rouault@mines-paris.org> References: <6ec71d090903300825v2aaa6798t2433a547e276a29a@mail.gmail.com> <200903301902.25879.even.rouault@mines-paris.org> Message-ID: <6ec71d090903301221t438b9910jfbd5f54407098545@mail.gmail.com> thanks, That does the trick. Oz. On Mon, Mar 30, 2009 at 7:02 PM, Even Rouault wrote: > Oz, > > See the hereafter a correction to insert in your code that will hopefully > fix > your issue. > > Le Monday 30 March 2009 17:25:13 Oz Nahum, vous avez ?crit : > > Hi, > > I have encountered a weired problem with gdal_rasterize. > > > > when I run the script from here > > > http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedona > >vectorfilesextentsforusewithgdal_rasterize > > > > When I run: > > #!/usr/bin/env python > > > > from osgeo import gdal > > from osgeo import osr > > from osgeo import ogr > > import numpy > > #from numpy import ones > > import stat, sys, os, string, commands > > > > shp = 'AOI' > > tiff = 'AOI.tif' > > px = 1 > > tiff_width = 80 > > tiff_height = 80 > > > > # Import vector shapefile > > vector = ogr.GetDriverByName('ESRI Shapefile') > > src_ds = vector.Open(shp +'.shp') > > src_lyr = src_ds.GetLayerByIndex(index=0) > > src_extent = src_lyr.GetExtent() > > > > # Create new raster layer with 4 bands > > raster = gdal.GetDriverByName('GTiff') > > dst_ds = raster.Create( tiff, tiff_width, tiff_height, 1, gdal.GDT_Byte) > > > > # Create raster GeoTransform based on upper left corner and pixel > > resolution raster_transform = [src_extent[0], px, 0.0, src_extent[3], > 0.0, > > -px] dst_ds.SetGeoTransform( raster_transform ) > > > > # Get projection of shapefile and assigned to raster > > srs = osr.SpatialReference() > > srs.ImportFromWkt(src_lyr.GetSpatialRef().__str__()) > > dst_ds.SetProjection( srs.ExportToWkt() ) > > > > # Create blank raster with fully opaque alpha band > > zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) > > dst_ds.GetRasterBand(1).WriteArray( zeros ) > > # Properly close the dataset before calling gdal_rasterize, so that the TIF > # file is properly written. > dst_ds = None > > > > > commandString = 'gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif' > > commandOutput = commands.getoutput(commandString) > > print commandOutput > > #end of code > > > > I get the error this error: > > > > augmented to the gdal_rasterize command I see this error. When I run it > via > > a shell script, I don't see the error: > > ERROR 4: `AOI.tif' not recognised as a supported file format. > > > > > > #!/bin/sh > > python create_empty_raster.py > > gdal_rasterize -burn 255 -l AOI AOI.shp AOI.tif > > > > Runs ok. > > --> This runs ok as at the end of the create_empty_raster.py script, the > GDAL > dataset is automatically closed. > > > > > So I am confused, why I can't call gdal_rasterize from python ? > > Thanks, for any help > > > > Oz Nahum > > Universt?t Tuebingen > > Applied Environmental Sciences > > > -- ---- Imagine there's no countries It isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace ---- You all must read 'The God Delusion' http://en.wikipedia.org/wiki/The_God_Delusion --- when one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion." Robert Pirsig, Zen and the Art of Motorcycle Maintenance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/95da968c/attachment.html From jorge.arevalo at gmail.com Mon Mar 30 16:19:35 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Mon Mar 30 16:20:13 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <49D00DA8.3010505@loskot.net> References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> Message-ID: Hello, Thanks for the link Mateusz. OK, I need your opinion. I've been working during 1 year (still working) in a project that uses gdal library (developing some code), and Postgis, to transform vectorial data (MIF files) on PNG tiles to show over google maps. I use Postgis to perform a previous merge of some vectorial data. Then, I transform the vectorial data in raster files, and "burn" the polygons over them using given colors. Finally, I transform these raster files in PNG tiles with gdal2tiles. The entire process could be improved by several ways: - I would like to have an enhaced PNG driver, to reduce the size of the tiles. For this reason, I had a theoretical approach to NeuQuant algorithm and I used pngnq. I discovered the relation between this algorithm and Kohonen Neural Networks, that I studied during my degree, and I liked a lot. Basically, for these reasons I'm interested in the project about PNG Driver - On one hand, at first I was using raster data, instead of vector data. When the need of merging data arose, I had to change the point and use vector data + Postgis. On the other hand, I would like to integrate my layer to another ones in a bigger context, and I think that the raster support on Postgis will be a really useful thing. For these reasons, I'm interested in the project about WKT Raster. - Before using gdal2tiles, I made my own "map tiler", creating the tiles needed "on-the-fly". As thought, it didn't work. I tried to use my own "tile cache system". One problem was the low rate of cache hints. Then, I discovered the WMS standard, and recently, the coming WMTS standard, even better. For this reason, I'm interested in the project about WMTS implementation. Now, this is my "minimum schedule". This is, the minimum amount of time that I can use this summer. With high probability, I will be able to use more time, but I prefer to put myself in the worst situation: May 23 - June 30: 22h per week (total 118h) July 1 - July 31: 45h per week (total 207h) August 1 - August 10: 22h per week (total 26h) Finally, I have experience with C, C++, Java and Python languages. My favourite one is C. I made the most of my practice work during degree in C. Do you think, with this provisional schedule in mind, that I can apply for one of the projects? If not, would it be possible to find a mentor for one of them? Without paying and GSoC deadlines, of course. Many thanks in advance, anyway Best regards Jorge 2009/3/30 Mateusz Loskot > Jorge Ar?valo wrote: > > "Difficult" is a very subjective thing, totally agree. Sorry for the > > approach of the question. > > [...] > > All concepts sound familiar (because > > I've studied or worked with them), but I think that I need some > > previous time to go deeper. I have to include this in my schedule. > > Here are some helpful notes: > > http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_student_time > > GSoc lasts for fixed time period and no more. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/97bd58a3/attachment-0001.html From bea at ixsea.com Mon Mar 30 16:45:05 2009 From: bea at ixsea.com (Benoit Andrieu) Date: Mon Mar 30 16:45:44 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Message-ID: <8a5889dab86cfcf6020be530ed0e34ea@ixsea.com> Thanks for the answer, > > Hi list ! > > > > I was wondering why the Lanczos and cubicspline are available in > > gdal_warp and not gdaladdo ? > > Beno?t, > > The overview builder and warper use quite different mechanisms so there > is no close relationship between the resampling options available in each > case. > Ok, I think the best thing to do for me is to look at the source code... > > The quality after downsizing images with gdalwarp is so perfect that I > > am now willing to include this in my overviews. > > Is there any chances to have this include in future releases or is there > > any difficulties I am not aware of ? > > It is my intention to add a cubic resampling option to the overview > building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. > In theory it should be possible to programatically connect warpers to > overview levels in cases where overview band objects have "proper" > dataset parents - which is the case with GeoTIFF hosted overviews. > > For instance, this C entry point could likely be used with hSrcDS being > the base datset, and hDstDS being the dataset for the overviews. One > problem with this plan is that it is likely that overview datasets do > not have proper geotransforms or coordinate systems. So you might need > to push a geotransform onto the overview dataset (with GDALSetGeoTransform()) > before calling GDALReprojectImage(). > > CPLErr CPL_DLL CPL_STDCALL > GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, > GDALDatasetH hDstDS, const char *pszDstWKT, > GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit, > double dfMaxError, > GDALProgressFunc pfnProgress, void *pProgressArg, > GDALWarpOptions *psOptions ); > > Generally the warp api resamplers are not suitable for with a destination > dataset with a radically lower resolution than the source. So I'd suggest > doing it such that each overview is generated from the next higher resolution > overview rather than always building from the base level. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a "library" callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) > Note that the overview levels still need to be pre-created using normal > mechanisms. Ok. Have to look. I'll take a look in the next days and will come back for help !! :) Regards, Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com From whatevar89 at gmail.com Mon Mar 30 16:45:27 2009 From: whatevar89 at gmail.com (erik) Date: Mon Mar 30 16:45:48 2009 Subject: [gdal-dev] using gcp's without giving coordinates Message-ID: <5c218180903301345l7fc1f8dco46b8b9d2fe1c0926@mail.gmail.com> Hello, I'm trying to convert a map from OziExplorer Map file fromat to Geotiff. FOr this i'm using the calibration points in the Map file as Ground Control Points. I do the following: gdal_translate \ -gcp 203 52 529000 4191000 \ -gcp 5174 3096 544000 4182000 \ -gcp 5201 99 544000 4191000 \ -gcp 176 3051 529000 4182000 \ -gcp 1861 1067 534000 4188000 \ -gcp 3517 2081 539000 4185000 \ -gcp 3526 1083 539000 4188000 \ -gcp 1851 2066 534000 4185000 \ -gcp 2844 2742 537000 4183000 \ -a_srs "+proj=utm +ellps=intl +k=0.999600 +x_0=500000.0 +y_0=0.0 +zone=30 +units=m +towgs84=-125.098545,-76.000054,-156.198703,0.0,0.0,-1.129,8.30463103 +no_defs" \ map.bmp \ map.tif However doing this still gives the maps upper left corner start at 0-0. I was wondering if there was a way to make gdal infer the correct corners of the map from the gcp's without specifying them directly. Or is there another way to achieve this without specifying the coord corners? (The calibration points are not corner-based) One solution would be to calculate the corners myself programmatically (from the pixels), but this would be the least good solution. Many thanks, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/b0a441c2/attachment.html From seth at pricepages.org Mon Mar 30 16:55:27 2009 From: seth at pricepages.org (Seth Price) Date: Mon Mar 30 16:55:31 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <0f1a434769ff5999ea55b5e1495d795a@ixsea.com> References: <0f1a434769ff5999ea55b5e1495d795a@ixsea.com> Message-ID: <3779.129.123.22.47.1238446527.squirrel@pricepages.org> I actually hope to be addressing performance in my GSoC project. I'm interested in rewriting the GDAL resampling code to CUDA, so the graphics card does the hard work. For example, instead of processing one pixel at a time, the latest GeForce GTX 260 would be able to process 216. I'm hoping for CUDA to be 50 to 100 times faster. Make sure you're using GDAL 1.6 or later, I recently rewrote the regular Lanczos/cubicspline warping code to be much faster. ~Seth On Mon, March 30, 2009 3:16 pm, Benoit Andrieu wrote: > Sounds interesting ! > I am curious to know what you will try to do in your project ! > > I am very interested in producing high quality images resulting for > mapserving and image merging. > We are using GDAL / Mapserver in our software suite. I made a try with > GeoServer and I found the results were very nice comparing to Mapserver. > We did not try to use GeoServer after that because there were others > artifacts. > > But now that I have seen Lanczos and cubicspline results on our images > using GDAL, I am convinced that there is something to do about Mapserver > to challenge GeoServer !! ;) > Of course, performance is a really big problem with Lanczos/cubicspline... > > I'll take a look at the code. > > Regards, > > Beno??t Andrieu > bea@ixsea.com > benoit.andrieu@gmail.com > >> -----Message re??u----- >> De: "Seth Price" >> ??: Beno????t Andrieu >> Cc: gdal-dev@lists.osgeo.org >> Date: 30/03/2009 20:38 >> Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in >> gdaladdo >> >> The resampling code between gdal_warp and gdaladdo is completely >> separate, >> thus it is basically two different projects. For the Google Summer of >> Code >> application I'm about to submit I will be working on the resampling code >> in GDAL's warper and GRASS. If I have time (and my application is >> accepted!) I'll try to look into gdaladdo also. >> ~Seth >> >> >> On Mon, March 30, 2009 12:27 pm, Beno????t Andrieu wrote: >> > Hi list ! >> > >> > I was wondering why the Lanczos and cubicspline are available in >> gdal_warp >> > and not gdaladdo ? >> > >> > The quality after downsizing images with gdalwarp is so perfect that I >> am >> > now willing to include this in my overviews. >> > Is there any chances to have this include in future releases or is >> there >> > any difficulties I am not aware of ? >> > >> > Beno????t Andrieu >> > bea@ixsea.com >> > benoit.andrieu@gmail.com >> > >> > _______________________________________________ >> > gdal-dev mailing list >> > gdal-dev@lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > From seth at pricepages.org Mon Mar 30 17:08:01 2009 From: seth at pricepages.org (Seth Price) Date: Mon Mar 30 17:08:07 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <8a5889dab86cfcf6020be530ed0e34ea@ixsea.com> References: <8a5889dab86cfcf6020be530ed0e34ea@ixsea.com> Message-ID: <3795.129.123.22.47.1238447281.squirrel@pricepages.org> One reason that warping is different than overviews is that warping has much more versatile resampling. For the current overview code, an integer number of pixels are combined into one pixel, and there is no overlap between resampling areas. For warping code, each destination pixel draws from source pixels which may overlap with the neighboring destination pixel. This is also complicated because the weights need to be recalculated for each destination pixel. I believe that there are complications due to various image bounds and NODATA masks in warping. Due to these problems, the warping code is much slower and complicated than the overview code. Feel free to take a look, though. Be sure to post anything you notice, and copy me in case I'm not paying attention to the mailing list on that day. ~Seth On Mon, March 30, 2009 3:45 pm, Benoit Andrieu wrote: > Thanks for the answer, > >> > Hi list ! >> > >> > I was wondering why the Lanczos and cubicspline are available in >> > gdal_warp and not gdaladdo ? >> >> Beno??t, >> >> The overview builder and warper use quite different mechanisms so there >> is no close relationship between the resampling options available in >> each >> case. >> > > Ok, I think the best thing to do for me is to look at the source code... > >> > The quality after downsizing images with gdalwarp is so perfect that I >> > am now willing to include this in my overviews. >> > Is there any chances to have this include in future releases or is >> there >> > any difficulties I am not aware of ? >> >> It is my intention to add a cubic resampling option to the overview >> building for 1.7. I am not planning to add the other options. > > Are you not planning because there is nobody asking for (poor me) ? > The image quality on our datasets is really amazing between merging with > bilinear / cubicspline / Lanczos ! > I am surprised to be the first one to notice such a difference. > I will try to see if gdaladdo and gdalwarp give the same results. I have a > doubt right now. > >> In theory it should be possible to programatically connect warpers to >> overview levels in cases where overview band objects have "proper" >> dataset parents - which is the case with GeoTIFF hosted overviews. >> >> For instance, this C entry point could likely be used with hSrcDS being >> the base datset, and hDstDS being the dataset for the overviews. One >> problem with this plan is that it is likely that overview datasets do >> not have proper geotransforms or coordinate systems. So you might need >> to push a geotransform onto the overview dataset (with >> GDALSetGeoTransform()) >> before calling GDALReprojectImage(). >> >> CPLErr CPL_DLL CPL_STDCALL >> GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, >> GDALDatasetH hDstDS, const char *pszDstWKT, >> GDALResampleAlg eResampleAlg, double >> dfWarpMemoryLimit, >> double dfMaxError, >> GDALProgressFunc pfnProgress, void *pProgressArg, >> GDALWarpOptions *psOptions ); >> >> Generally the warp api resamplers are not suitable for with a >> destination >> dataset with a radically lower resolution than the source. So I'd >> suggest >> doing it such that each overview is generated from the next higher >> resolution >> overview rather than always building from the base level. > > Ok. > Do you mean that producing a 1m x 1m image with 20cm x 20cm images could > give bad results ? > > There is something I am not sure to understand. > You are saying to use the warp library directly from the overviewing > mechanism. > Why can't I take the lanczos/cubicspline codes, separate it from the > warping code to make a "library" callable from the overviewing and warping > codes ? > I think that the answer is a long one so if it is too much to ask, just > say to me to look at the code ! ;) > >> Note that the overview levels still need to be pre-created using normal >> mechanisms. > > Ok. Have to look. > > I'll take a look in the next days and will come back for help !! :) > > Regards, > > Beno??t Andrieu > bea@ixsea.com > benoit.andrieu@gmail.com > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > From mateusz at loskot.net Mon Mar 30 17:11:31 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon Mar 30 17:11:45 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> Message-ID: <49D13583.7070607@loskot.net> Jorge Ar?valo wrote: > The entire process could be improved by several ways: > > - I would like to have an enhaced PNG driver, to reduce the size of the > tiles. For this reason, I had a theoretical approach to NeuQuant > algorithm and I used pngnq. I discovered the relation between this > algorithm and Kohonen Neural Networks, that I studied during my degree, > and I liked a lot. Basically, for these reasons I'm interested in the > project about PNG Driver Nice idea. > - On one hand, at first I was using raster data, instead of vector data. > When the need of merging data arose, I had to change the point and use > vector data + Postgis. On the other hand, I would like to integrate my > layer to another ones in a bigger context, and I think that the raster > support on Postgis will be a really useful thing. For these reasons, I'm > interested in the project about WKT Raster. Good. > - Before using gdal2tiles, I made my own "map tiler", creating the tiles > needed "on-the-fly". As thought, it didn't work. I tried to use my own > "tile cache system". One problem was the low rate of cache hints. Then, > I discovered the WMS standard, and recently, the coming WMTS standard, > even better. For this reason, I'm interested in the project about WMTS > implementation. Good as well. > Now, this is my "minimum schedule". This is, the minimum amount of time > that I can use this summer. With high probability, I will be able to use > more time, but I prefer to put myself in the worst situation: > > May 23 - June 30: 22h per week (total 118h) > July 1 - July 31: 45h per week (total 207h) > August 1 - August 10: 22h per week (total 26h) It should be more than enough. > Finally, I have experience with C, C++, Java and Python languages. My > favourite one is C. I made the most of my practice work during degree in C. Good. > Do you think, with this provisional schedule in mind, that I can apply > for one of the projects? Yes, I'm sure you are able to do it. > If not, would it be possible to find a mentor for one of them? > Without paying and GSoC deadlines, of course. I'm sure you can try, it won't hurt :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From mateusz at loskot.net Mon Mar 30 17:14:00 2009 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon Mar 30 17:14:13 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <49D13583.7070607@loskot.net> References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> <49D13583.7070607@loskot.net> Message-ID: <49D13618.1020200@loskot.net> Mateusz Loskot wrote: > Jorge Ar?valo wrote: >> The entire process could be improved by several ways: >> >> - I would like to have an enhaced PNG driver, to reduce the size of >> the tiles. For this reason, I had a theoretical approach to >> NeuQuant algorithm and I used pngnq. I discovered the relation >> between this algorithm and Kohonen Neural Networks, that I studied >> during my degree, and I liked a lot. Basically, for these reasons >> I'm interested in the project about PNG Driver > > Nice idea. By the way, here is project developed by a friend of mine C++ Kohonen Neural Network Library http://knnl.sourceforge.net/ Perhaps you will find it useful in your work. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org From bea at ixsea.com Mon Mar 30 17:16:27 2009 From: bea at ixsea.com (Benoit Andrieu) Date: Mon Mar 30 17:16:24 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Message-ID: <4f05bdb2819a68179dd09b6b4da2171b@ixsea.com> Wow ! Great !! CUDA is ideal for this kind of processing and should be "easy" to get very high performances. But maybe you should want to wait for OpenCL to get out from the specs phase ? You could support NVidia/ATI/Larrabee in a single shot... but you'll have to wait for some times... On my side, I would like to see what could be done with Intel's IPP. We are using it on our softwares and it is really fast. Could be interesting to use it in GDAL / Mapserver. Regards, Beno?t Andrieu bea@ixsea.com benoit.andrieu@gmail.com > -----Message re?u----- > De: Seth Price > ?: Benoit Andrieu > Cc: gdal-dev@lists.osgeo.org > Date: 30/03/2009 22:55 > Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo > > I actually hope to be addressing performance in my GSoC project. I'm > interested in rewriting the GDAL resampling code to CUDA, so the graphics > card does the hard work. For example, instead of processing one pixel at a > time, the latest GeForce GTX 260 would be able to process 216. I'm hoping > for CUDA to be 50 to 100 times faster. > > Make sure you're using GDAL 1.6 or later, I recently rewrote the regular > Lanczos/cubicspline warping code to be much faster. > ~Seth > > > On Mon, March 30, 2009 3:16 pm, Benoit Andrieu wrote: > > Sounds interesting ! > > I am curious to know what you will try to do in your project ! > > > > I am very interested in producing high quality images resulting for > > mapserving and image merging. > > We are using GDAL / Mapserver in our software suite. I made a try with > > GeoServer and I found the results were very nice comparing to Mapserver. > > We did not try to use GeoServer after that because there were others > > artifacts. > > > > But now that I have seen Lanczos and cubicspline results on our images > > using GDAL, I am convinced that there is something to do about Mapserver > > to challenge GeoServer !! ;) > > Of course, performance is a really big problem with Lanczos/cubicspline... > > > > I'll take a look at the code. > > > > Regards, > > > > Beno??t Andrieu > > bea@ixsea.com > > benoit.andrieu@gmail.com > > > >> -----Message re??u----- > >> De: "Seth Price" > >> ??: Beno????t Andrieu > >> Cc: gdal-dev@lists.osgeo.org > >> Date: 30/03/2009 20:38 > >> Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in > >> gdaladdo > >> > >> The resampling code between gdal_warp and gdaladdo is completely > >> separate, > >> thus it is basically two different projects. For the Google Summer of > >> Code > >> application I'm about to submit I will be working on the resampling code > >> in GDAL's warper and GRASS. If I have time (and my application is > >> accepted!) I'll try to look into gdaladdo also. > >> ~Seth > >> > >> > >> On Mon, March 30, 2009 12:27 pm, Beno????t Andrieu wrote: > >> > Hi list ! > >> > > >> > I was wondering why the Lanczos and cubicspline are available in > >> gdal_warp > >> > and not gdaladdo ? > >> > > >> > The quality after downsizing images with gdalwarp is so perfect that I > >> am > >> > now willing to include this in my overviews. > >> > Is there any chances to have this include in future releases or is > >> there > >> > any difficulties I am not aware of ? > >> > > >> > Beno????t Andrieu > >> > bea@ixsea.com > >> > benoit.andrieu@gmail.com > >> > > >> > _______________________________________________ > >> > gdal-dev mailing list > >> > gdal-dev@lists.osgeo.org > >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > >> > > > > > From jorge.arevalo at gmail.com Mon Mar 30 17:19:47 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Mon Mar 30 17:20:05 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <49D13618.1020200@loskot.net> References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> <49D13583.7070607@loskot.net> <49D13618.1020200@loskot.net> Message-ID: Hello, Thanks for the link, and for your opinion! I'll apply for the three projects. Best regards Jorge 2009/3/30 Mateusz Loskot > Mateusz Loskot wrote: > > Jorge Ar?valo wrote: > >> The entire process could be improved by several ways: > >> > >> - I would like to have an enhaced PNG driver, to reduce the size of > >> the tiles. For this reason, I had a theoretical approach to > >> NeuQuant algorithm and I used pngnq. I discovered the relation > >> between this algorithm and Kohonen Neural Networks, that I studied > >> during my degree, and I liked a lot. Basically, for these reasons > >> I'm interested in the project about PNG Driver > > > > Nice idea. > > By the way, here is project developed by a friend of mine > > C++ Kohonen Neural Network Library > > http://knnl.sourceforge.net/ > > Perhaps you will find it useful in your work. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090330/7b3f4f18/attachment.html From jluis at ualg.pt Mon Mar 30 17:35:54 2009 From: jluis at ualg.pt (Joaquim Luis) Date: Mon Mar 30 17:35:59 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> Message-ID: <49D13B3A.2080801@ualg.pt> Jorge Ar?valo wrote: > Hello, > > Thanks for the link Mateusz. > > OK, I need your opinion. I've been working during 1 year (still working) > in a project that uses gdal library (developing some code), and Postgis, > to transform vectorial data (MIF files) on PNG tiles to show over google > maps. > > I use Postgis to perform a previous merge of some vectorial data. Then, > I transform the vectorial data in raster files, and "burn" the polygons > over them using given colors. Finally, I transform these raster files in > PNG tiles with gdal2tiles. Guys, Maybe this interests you. The GMT tool "ps2raster" (CVS version) is now able to create KML code from any -- GMT-complicate-as-much-as-you-want -- images. Joaquim Luis From warmerdam at pobox.com Mon Mar 30 17:48:14 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 30 17:48:30 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <8a5889dab86cfcf6020be530ed0e34ea@ixsea.com> References: <8a5889dab86cfcf6020be530ed0e34ea@ixsea.com> Message-ID: <49D13E1E.3010201@pobox.com> Benoit Andrieu wrote: >>> The quality after downsizing images with gdalwarp is so perfect that I >>> am now willing to include this in my overviews. >>> Is there any chances to have this include in future releases or is there >>> any difficulties I am not aware of ? >> It is my intention to add a cubic resampling option to the overview >> building for 1.7. I am not planning to add the other options. > > Are you not planning because there is nobody asking for (poor me) ? > The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! > I am surprised to be the first one to notice such a difference. > I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. Benoit, I personally would prefer not to further complicate the overview code with additional resampling types. However, I have an insistent client who will pay, and who might become grumpy if I did not oblige. > Ok. > Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? In this case things might not be too bad, but these resampling kernels basically have at most 4x4 kernels, so if you are doing 20:1 downsampling only a small fraction of the pixels are having any influence. On the other hand in them more typical 1:1 resampling case you get nice results as a small window of pixels in the area gets considered in the resampling. For "1 step" radical downsampling something like average may give better results than 4x4 kernel resamplers. However, if downsampling is done stepwise (by powers of 2 for instance) then the 4x4 kernel resamplers may give good results all the way. > There is something I am not sure to understand. > You are saying to use the warp library directly from the overviewing mechanism. I am suggesting writing a small C application that would first generate normal overviews, and the use the warper to overwrite them with nicely downsampled imagery. > Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a "library" callable from the overviewing and warping codes ? > I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) This would be messy. I am trying to avoid overcomplicating the overview code which is already very complicated. In fact it is already so complicated that I'm mortified about extending it with cubic resampling. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From nowak at xpam.de Mon Mar 30 18:05:17 2009 From: nowak at xpam.de (Adam Nowacki) Date: Mon Mar 30 18:05:44 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <3779.129.123.22.47.1238446527.squirrel@pricepages.org> References: <0f1a434769ff5999ea55b5e1495d795a@ixsea.com> <3779.129.123.22.47.1238446527.squirrel@pricepages.org> Message-ID: <49D1421D.9000802@xpam.de> Seth Price wrote: > I actually hope to be addressing performance in my GSoC project. I'm > interested in rewriting the GDAL resampling code to CUDA, so the graphics > card does the hard work. For example, instead of processing one pixel at a > time, the latest GeForce GTX 260 would be able to process 216. I'm hoping > for CUDA to be 50 to 100 times faster. > > Make sure you're using GDAL 1.6 or later, I recently rewrote the regular > Lanczos/cubicspline warping code to be much faster. > ~Seth You can achieve pretty amazing speeds on the CPU alone. I have a SSE3 (would be trivial to rewrite as plain old SSE, probably a bit slower) Lanczos sampler with 4x4 kernel that runs at ~70 000 000 samples per second with float data type on a 2.33GHz Intel Xeon E5410 (one thread). I was considering porting the sampler to GDAL but found that I would have to rewrite the whole warping code to get any useful speed boost, including heavily optimizing coordinate transformations. From bea at ixsea.com Tue Mar 31 01:49:13 2009 From: bea at ixsea.com (Benoit Andrieu) Date: Tue Mar 31 01:49:10 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Message-ID: <8e325dd372039a0bb395fb1b29c5aa01@ixsea.com> Thanks for the answer Frank ! So in a first time I'll be looking at making a gdaladdo bis. By the way, do you know why Mapserver does "only" support nearest, average, bilinear, bicubic ? I thought it was using GDAL to do warping, but then it would natively support cubicspline and lanczos. I know that speed is a concern... ^^ By the way bis, I forgot to mention that we had some artifacts with gdalwarp yesterday. We are using FWTools 2.3.1. We wanted to merge several pictures at 20cm x 20cm resolution and make a 1m x 1m and a 4m x 4m. The pictures could be quite big : 30000 x 30000 pixels. First, we used gdalwarp to do all operations in a single one : merging and downsizing. But the resulting picture contained artifacts. In some areas, it is as if a nearest method was used instead of lanczos. Because of this, we then asked gdalwarp to make the downsizing. In a second call, we made the merging. There we did not find artifacts and it is ok for us to do like this. But I fear to have the same problems with bigger pictures. I will not be able to provide the pictures (sources or results) because of confidentiality agreements. But I could provide screenshots. Or try to reproduce on differents datasets. Regards, Beno?t Andrieu > -----Message re?u----- > De: Frank Warmerdam > ?: Benoit Andrieu > Cc: "gdal-dev@lists.osgeo.org" > Date: 30/03/2009 23:48 > Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo > > Benoit Andrieu wrote: > >>> The quality after downsizing images with gdalwarp is so perfect that I > >>> am now willing to include this in my overviews. > >>> Is there any chances to have this include in future releases or is there > >>> any difficulties I am not aware of ? > >> It is my intention to add a cubic resampling option to the overview > >> building for 1.7. I am not planning to add the other options. > > > > Are you not planning because there is nobody asking for (poor me) ? > > The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! > > I am surprised to be the first one to notice such a difference. > > I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. > > Benoit, > > I personally would prefer not to further complicate the overview > code with additional resampling types. However, I have an insistent > client who will pay, and who might become grumpy if I did not oblige. > > > Ok. > > Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? > > In this case things might not be too bad, but these resampling > kernels basically have at most 4x4 kernels, so if you are > doing 20:1 downsampling only a small fraction of the pixels are > having any influence. On the other hand in them more typical > 1:1 resampling case you get nice results as a small window of > pixels in the area gets considered in the resampling. > > For "1 step" radical downsampling something like average > may give better results than 4x4 kernel resamplers. > > However, if downsampling is done stepwise (by powers of > 2 for instance) then the 4x4 kernel resamplers may give > good results all the way. > > > There is something I am not sure to understand. > > You are saying to use the warp library directly from the overviewing mechanism. > > I am suggesting writing a small C application that would first > generate normal overviews, and the use the warper to overwrite > them with nicely downsampled imagery. > > > Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a "library" callable from the overviewing and warping codes ? > > I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) > > This would be messy. I am trying to avoid overcomplicating the overview > code which is already very complicated. In fact it is already so > complicated that I'm mortified about extending it with cubic resampling. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent From bea at ixsea.com Tue Mar 31 01:52:36 2009 From: bea at ixsea.com (Benoit Andrieu) Date: Tue Mar 31 01:52:33 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Message-ID: That sounds like bad news for my dreams ! :( I was planning to make a try with IPP on some parts of GDAL (warping, geometry rasterization). Did you make some profiling ? I would be interested to know the results ! Regards, Beno?t Andrieu > -----Message re?u----- > De: Adam Nowacki > ?: "gdal-dev@lists.osgeo.org >> Gdal-Dev" > Date: 31/03/2009 00:06 > Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo > > Seth Price wrote: > > I actually hope to be addressing performance in my GSoC project. I'm > > interested in rewriting the GDAL resampling code to CUDA, so the graphics > > card does the hard work. For example, instead of processing one pixel at a > > time, the latest GeForce GTX 260 would be able to process 216. I'm hoping > > for CUDA to be 50 to 100 times faster. > > > > Make sure you're using GDAL 1.6 or later, I recently rewrote the regular > > Lanczos/cubicspline warping code to be much faster. > > ~Seth > > You can achieve pretty amazing speeds on the CPU alone. I have a SSE3 > (would be trivial to rewrite as plain old SSE, probably a bit slower) > Lanczos sampler with 4x4 kernel that runs at ~70 000 000 samples per > second with float data type on a 2.33GHz Intel Xeon E5410 (one thread). > I was considering porting the sampler to GDAL but found that I would > have to rewrite the whole warping code to get any useful speed boost, > including heavily optimizing coordinate transformations. > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev From isajmeri at rediffmail.com Tue Mar 31 02:00:51 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Tue Mar 31 02:08:24 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <1238420030.S.18163.59213.f4mail-234-222.rediffmail.com.old.1238479251.1321@webmail.rediffmail.com> hi,following is my code.;;;;GDALDataset *poDataset;GDALAllRegister();poDataset = (GDALDataset *) GDALOpen( pszFilename, GA_ReadOnly );if( poDataset != NULL ){double adfGeoTransform[6];qDebug()<<"Driver: "<<poDataset->GetDriver()->GetDescription()<<poDataset->GetDriver()->GetMetadataItem   ( GDAL_DMD_LONGNAME );// at this point error popupqDebug()<<"Size is "<<poDataset->GetRasterXSize()<<poDataset->GetRasterYSize()<<poDataset->GetRasterCount();if( poDataset->GetProjectionRef() != NULL )qDebug()<<"Projection is `"<<poDataset->GetProjectionRef();if( poDataset->GetGeoTransform( adfGeoTransform ) == CE_None ){qDebug()<<"Origin = "<<adfGeoTransform[0]<<adfGeoTransform[3];qDebug()<< "Pixel Size = "<<adfGeoTransform[1]<<adfGeoTransform[5];}};;;;but the problame is resolve.i builded this code with MinGW so as per J?rgen's conversation C++ api won't work from MinGW unlessGDAL is also built with MinGW.now i recoded with C-api and working fine.but now i have confusion about functionality of C-api and C++-api.shell i continue with C-api or build GDAL library with MinGW and use C++-api?On Mon, 30 Mar 2009 15:34:18 +0200 Beno?t Andrieu wroteWell... Have you checked your path to your include files ?Could I see the part of the code where the errors occured ? Thx Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 3:22 PMSubject: Re :Re: Re :Re: Re :Re: [gdal-dev] How to use GDAL LibraryHi,Thanks Beno?t Andrieubea for your reply.you are right, there is no need any cpp file. but when i build the same code given in GDAL tutorial with QT Creator popups the following error.g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o debugImageRW.exe debug/main.o -L"d:Qt2009.01qtlib" gdal_i.lib -lQtCored4mingw32-make[1]: Leaving directory `D:/QT_Projects/ImageRW'mingw32-make: Leaving directory `D:/QT_Projects/ImageRW'debug/main.o: In function `main':D:/QT_Projects/ImageRW/main.cpp:34:   reference to `GDALDataset::GetRasterCount()'D:/QT_Projects/ImageRW/main.cpp:34:   reference to `GDALDataset::GetRasterYSize()'D:/QT_Projects/ImageRW/main.cpp:34:   reference to `GDALDataset::GetRasterXSize()'collect2: ld returned 1 exit statusmingw32-make[1]: *** [debugImageRW.exe] Error 1mingw32-make: *** [debug] Error 2Exited with code 2.but the same code i builded with VC++ 2005, its working fine.unfortunatly i want to link GDAL library in QT.the bellow is my QT .pro file settingQT -= guiTARGET = ImageRWCONFIG += consoleCONFIG -= app_bundleTEMPLATE = appSOURCES += main.cppLIBS += gdal_i.libthanks in advance.On Mon, 30 Mar 2009 14:42:07 +0200 Beno?t Andrieu wroteHi ! You won't need any cpp files.Personally, I am using the FWTools package which bundles dll, libs and headers files. You just have to compile using gdal_priv.hThen link to gdal_i.libThen provide with your runtime all the dlls which gdal_fw.dll is depending to.You will find which dlls it is depending to by using Dependency Walker (http://www.dependencywalker.com/). Then your runtime will be able to use all of the image formats drivers that GDAL was compiled to support. I hope this will help. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Monday, March 30, 2009 11:06 AMSubject: Re :Re: Re :Re: [gdal-dev] How to use GDAL LibraryHi,Actually i m working on Generic image reading/writing and display on viewer with all of its information, so i think i need all listed library. but dont know how to use them in my code.i have downloded gdal_i.lib, gdal.dll and its include .h files..h files contains only the prototype function to link with library but i could not find its .cpp file which may containt implementation function of that linking function of .h files.can u please give me broad idea or step by step procedure about how do i link these library to c++ code.thanks in advanceRegards,IqbalOn Fri, 27 Mar 2009 18:54:01 +0100 Beno?t Andrieu wroteHi, I am using FWTools 2.2.9So I am releasing my softwares with most of the dlls (you can use depends to find which). The linking is done with :gdal_i.libgeos_i.libgeotiff_i.liblibtiff_i.libproj_i.lib But yo may want to use more or less libraries... Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: bea@ixsea.com Cc: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 3:11 PMSubject: Re :Re: [gdal-dev] How to use GDAL LibraryHi Beno?t Andrieu,Thanks for reply.i already saw that tutorial,but the problame is how to and which library to be linked using QT(most probably same way of C/C++).coz there is a three library named gdal16.dll, gdal_i.lib and gdal.lib.On Fri, 27 Mar 2009 11:33:42 +0100 Beno?t Andrieu wroteHi, If you want to use GDAL in C / C++, take a look at the tutorial at http://www.gdal.org/gdal_tutorial.html.It is really straightforward, I used this for the integration of GDAL in our modules and it worked fine. Regards, Beno?t Andrieubea@ixsea.combenoit.andrieu@gmail.com----- Original Message ----- From: Ajmeri Iqbal To: gdal-dev@lists.osgeo.org Sent: Friday, March 27, 2009 11:06 AMSubject: [gdal-dev] How to use GDAL LibraryDear all,I want to use GDAL library in my project using QT.How could i use this library for Reading and writing the Raster images (i.e. JPEG,JPEG200,TIFF,GeoTiff,BMP,PNG,GIF, etc)please help me.Thanks in advance_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090331/3cca973f/attachment-0001.html From isajmeri at rediffmail.com Tue Mar 31 02:01:51 2009 From: isajmeri at rediffmail.com (Ajmeri Iqbal) Date: Tue Mar 31 02:09:18 2009 Subject: [gdal-dev] How to use GDAL Library Message-ID: <1238421329.S.4348.16145.f4mail-234-205.rediffmail.com.old.1238479311.11594@webmail.rediffmail.com> Thanks J?rgen.i recoded with C-api and working fine.but now i have confusion about functionality of C-api and C++-api.shell i continue with C-api or build GDAL library with MinGW and use C++-api?On Mon, 30 Mar 2009 15:55:18 +0200 J?rgen E. Fischer wroteHi,On Mon, 30. Mar 2009 at 13:22:46 -0000, Ajmeri Iqbal wrote:> D:/QT_Projects/ImageRW/main.cpp:34:   reference to> `GDALDataset::GetRasterCount()'Are you using the C++ API directly? That won't work from MinGW unlessGDAL is also built with MinGW. The C-API will work.J?rgen-- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50Software Engineer D-26506 Norden http://www.norbit.de-- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbHRheinstrasse 13, 26506 NordenGF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502_______________________________________________gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090331/4408d64c/attachment.html From warmerdam at pobox.com Tue Mar 31 02:12:21 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 02:14:43 2009 Subject: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo In-Reply-To: <8e325dd372039a0bb395fb1b29c5aa01@ixsea.com> References: <8e325dd372039a0bb395fb1b29c5aa01@ixsea.com> Message-ID: <49D1B445.80600@pobox.com> Benoit Andrieu wrote: > Thanks for the answer Frank ! > > So in a first time I'll be looking at making a gdaladdo bis. > > By the way, do you know why Mapserver does "only" support nearest, average, bilinear, bicubic ? > I thought it was using GDAL to do warping, but then it would natively support cubicspline and lanczos. > I know that speed is a concern... ^^ Benoit, MapServer has it's own resampling code focused more on speed than precision (or featurefulness). It does not actually have any cubic support as far as I know. I had intended to implement this but never got to it. > By the way bis, I forgot to mention that we had some artifacts with gdalwarp yesterday. > We are using FWTools 2.3.1. > We wanted to merge several pictures at 20cm x 20cm resolution and make a 1m x 1m and a 4m x 4m. > The pictures could be quite big : 30000 x 30000 pixels. > > First, we used gdalwarp to do all operations in a single one : merging and downsizing. > But the resulting picture contained artifacts. In some areas, it is as if a nearest method was used instead of lanczos. > > Because of this, we then asked gdalwarp to make the downsizing. In a second call, we made the merging. > There we did not find artifacts and it is ok for us to do like this. > But I fear to have the same problems with bigger pictures. > > I will not be able to provide the pictures (sources or results) because of confidentiality agreements. > But I could provide screenshots. > Or try to reproduce on differents datasets. I would encourage you to produce test images that demonstrate the artifacts clearly and that are submitable. Before submitting a bug report it would be good to confirm the problem with the latest "trunk" code. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From jef at norbit.de Tue Mar 31 04:19:08 2009 From: jef at norbit.de (=?iso-8859-1?B?SvxyZ2VuIEUu?= Fischer) Date: Tue Mar 31 04:19:19 2009 Subject: [gdal-dev] How to use GDAL Library In-Reply-To: <1238421329.S.4348.16145.f4mail-234-205.rediffmail.com.old.1238479311.11594@webmail.rediffmail.com> References: <1238421329.S.4348.16145.f4mail-234-205.rediffmail.com.old.1238479311.11594@webmail.rediffmail.com> Message-ID: <20090331081908.GA20981@norbit.de> Hi, [what's your firstname btw?] On Tue, 31. Mar 2009 at 06:01:51 -0000, Ajmeri Iqbal wrote: > shell i continue with C-api or build GDAL library with MinGW and use C++-api? http://trac.osgeo.org/gdal/wiki/FAQMiscellaneous#CAPIvsCAPI: > If you intend writing code using GDAL/OGR that will not require > recompilation when run against different GDAL/OGR versions, you should > try to stick to the C API when possible. Although the changes in the > C++ API are generally made in a upward compatible way, the C++ ABI > might change from a minor release to another one (for example from > GDAL 1.5.0 to GDAL 1.6.0) due to additions of new virtual methods, new > member variables to core classes, etc. J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 From mjollnir.ray at gmail.com Tue Mar 31 11:27:22 2009 From: mjollnir.ray at gmail.com (mjollnir) Date: Tue Mar 31 11:27:23 2009 Subject: [Gdal-dev] no file Message-ID: <1238513242031-2563633.post@n2.nabble.com> hi, i read the image from a JPG file, and translate it to a PNG dataset, now, i want send the PNG image binary data to a socket directly, actually no intermediate PNG file needed. can i do this? -- View this message in context: http://n2.nabble.com/no-file-tp2563633p2563633.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Tue Mar 31 11:37:01 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 11:37:15 2009 Subject: [Gdal-dev] no file In-Reply-To: <1238513242031-2563633.post@n2.nabble.com> References: <1238513242031-2563633.post@n2.nabble.com> Message-ID: <49D2389D.1010206@pobox.com> mjollnir wrote: > hi, > > i read the image from a JPG file, and translate it to a PNG dataset, now, i > want send the PNG image binary data to a socket directly, actually no > intermediate PNG file needed. Ray, You can run the PNG encoder to a memory buffer "virtual file" using the mechanism described at: http://www.gdal.org/cpl__vsi_8h.html#66e2e6f093fd42f8a941b962d4c8a19e Then you would send the contents of the memory buffer off to the socket. In theory you could also write a special file handler allowing you to stream it directly to the socket without an intermediate memory buffer but that would be very involved. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From mjollnir.ray at gmail.com Tue Mar 31 11:58:25 2009 From: mjollnir.ray at gmail.com (mjollnir) Date: Tue Mar 31 11:58:26 2009 Subject: [Gdal-dev] no file In-Reply-To: <49D2389D.1010206@pobox.com> References: <1238513242031-2563633.post@n2.nabble.com> <49D2389D.1010206@pobox.com> Message-ID: <1238515105247-2563823.post@n2.nabble.com> You can run the PNG encoder to a memory buffer "virtual file" using the mechanism described at: http://www.gdal.org/cpl__vsi_8h.html#66e2e6f093fd42f8a941b962d4c8a19e Then you would send the contents of the memory buffer off to the socket. In theory you could also write a special file handler allowing you to stream it directly to the socket without an intermediate memory buffer but that would be very involved. I like the second idea, would you please give me a clue -- View this message in context: http://n2.nabble.com/no-file-tp2563633p2563823.html Sent from the GDAL - Dev mailing list archive at Nabble.com. From warmerdam at pobox.com Tue Mar 31 12:02:11 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 12:02:26 2009 Subject: [Gdal-dev] no file In-Reply-To: <1238515105247-2563823.post@n2.nabble.com> References: <1238513242031-2563633.post@n2.nabble.com> <49D2389D.1010206@pobox.com> <1238515105247-2563823.post@n2.nabble.com> Message-ID: <49D23E83.30900@pobox.com> mjollnir wrote: > > > You can run the PNG encoder to a memory buffer "virtual file" using the > mechanism described at: > > http://www.gdal.org/cpl__vsi_8h.html#66e2e6f093fd42f8a941b962d4c8a19e > > Then you would send the contents of the memory buffer off to the socket. > > In theory you could also write a special file handler allowing you to > stream it directly to the socket without an intermediate memory buffer but > that would be very involved. > > I like the second idea, would you please give me a clue /me sighs. Is there some reason you feel that would be a much better solution? Are your png encoded results going to be very large? I'm not willing to spend a lot of time trying to explain how to do the second approach, but I will point you to ~/gdal/port/cpl_vsi_mem.cpp as an example of a custom file handler implemention (the one for in-memory virtual files). You can try to work it out from that. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From mmarks at google.com Tue Mar 31 12:37:26 2009 From: mmarks at google.com (Mano Marks) Date: Tue Mar 31 12:47:58 2009 Subject: [gdal-dev] gdal2tiles strangeness Message-ID: <781bff30903310937t4a9b6347hef2b27cbe1ca18d6@mail.gmail.com> I'm getting started with gdal2tiles, and I'm getting strange results. I downloaded a blue marble jpg from NASA: http://www.nasa.gov/vision/earth/features/blue_marble.html And I ran the following command lines: gdal_translate -of VRT -a_srs EPSG:4326 -gcp 0 0 -180 90 -gcp 21600 0 180 90 -gcp 21600 10800 180 -90 world_200401.jpg bluemarble1.vrt gdalwarp -of VRT -t_srs EPSG:4326 bluemarble1.vrt bluemarble2.vrt gdal2tiles -k bluemarble2.vrt Of course, the last step took awhile. The Google Maps and OpenLayers output was fine. However, the KML had some odd results. When loaded directly, it looked fine, but when I zoomed out, it appeared that what was the equivalent of zoom 0 and 1 the images retain a Mercator projection. Is this a known issue, or did I do something wrong? -- Mano Marks Geo Developer Advocate Google, Inc. mmarks@google.com http://twitter.com/ManoMarks From bclay at ball.com Tue Mar 31 12:53:22 2009 From: bclay at ball.com (Clay, Bruce) Date: Tue Mar 31 12:53:24 2009 Subject: [gdal-dev] in memory KML Message-ID: I know that OGR supports in memory feature classes and it supports creating KML data. I could not find any examples of using the in-memory datasource. Is there a way to create KML in memory? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090331/f119a320/attachment.html From bclay at ball.com Tue Mar 31 13:23:33 2009 From: bclay at ball.com (Clay, Bruce) Date: Tue Mar 31 13:23:36 2009 Subject: [gdal-dev] in memory KML In-Reply-To: References: Message-ID: After a bit more digging I am not sure I asked the right question. What I want to do is read feature information from a shapefile or other data source and get a string that contains the feature information encoded in KML that I can pass directly into Google Earth. I know I can do this operation is I open the shapefile write the KML data to disk then open the kml file up with fopen then read it into memory and send it t Google Earth but I would like to save the disk write the read operation. Any thoughts? Bruce ________________________________ From: gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Clay, Bruce Sent: Tuesday, March 31, 2009 12:53 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] in memory KML I know that OGR supports in memory feature classes and it supports creating KML data. I could not find any examples of using the in-memory datasource. Is there a way to create KML in memory? 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090331/bc43de3d/attachment.html From warmerdam at pobox.com Tue Mar 31 13:32:31 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 13:32:44 2009 Subject: [gdal-dev] in memory KML In-Reply-To: References: Message-ID: <49D253AF.3060505@pobox.com> Clay, Bruce wrote: > After a bit more digging I am not sure I asked the right question. > > > > What I want to do is read feature information from a shapefile or other > data source and get a string that contains the feature information > encoded in KML that I can pass directly into Google Earth. I know I can > do this operation is I open the shapefile write the KML data to disk > then open the kml file up with fopen then read it into memory and send > it t Google Earth but I would like to save the disk write the read > operation. > > > > Any thoughts? Bruce, I've skimmed the KML driver and there is no sign that it uses the VSI*L API for file access, so I don't see any way you can write results to a memory buffer without substantial recoding in the kml driver. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From klokan at klokan.cz Tue Mar 31 13:33:14 2009 From: klokan at klokan.cz (=?ISO-8859-2?Q?Klokan_Petr_P=F8idal?=) Date: Tue Mar 31 13:33:16 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <49D13583.7070607@loskot.net> References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> <49D13583.7070607@loskot.net> Message-ID: <6e41d95b0903311033t38cf7233g53d7eedec384e4bd@mail.gmail.com> Jorge, I am glad you are interested in the PNG driver, which I suggested as a project for Summer of Code... It would be really great to have this in GDAL and I guess more projects will profit from this... I am going to assist as much as I can, whether in gsoc program timeframe or even otherwise. Feel free to contact me with any questions related to this project... I guess for position of mentor there are better candidates then me (like Frank, Even, Mateusz, ...) Because I am a PhD student I applied in this Summer of Code as well as a student so I technically I can not be your mentor. I can work this summer on the WMTS implementation and other GDAL2Tiles improvements... but I don't want to block position of new candidates... If you are interested in WMTS implementation and GDAL2Tiles then just go ahead, this I can mentor for sure ;-) Best regards, Klokan 2009/3/30 Mateusz Loskot : > Jorge Ar?valo wrote: >> The entire process could be improved by several ways: >> >> - I would like to have an enhaced PNG driver, to reduce the size of the >> tiles. For this reason, I had a theoretical approach to NeuQuant >> algorithm and I used pngnq. I discovered the relation between this >> algorithm and Kohonen Neural Networks, that I studied during my degree, >> and I liked a lot. Basically, for these reasons I'm interested in the >> project about PNG Driver > > Nice idea. > >> - On one hand, at first I was using raster data, instead of vector data. >> When the need of merging data arose, I had to change the point and use >> vector data + Postgis. On the other hand, I would like to integrate my >> layer to another ones in a bigger context, and I think that the raster >> support on Postgis will be a really useful thing. For these reasons, I'm >> interested in the project about WKT Raster. > > Good. > >> - Before using gdal2tiles, I made my own "map tiler", creating the tiles >> needed "on-the-fly". As thought, it didn't work. I tried to use my own >> "tile cache system". One problem was the low rate of cache hints. Then, >> I discovered the WMS standard, and recently, the coming WMTS standard, >> even better. For this reason, I'm interested in the project about WMTS >> implementation. > > Good as well. > >> Now, this is my "minimum schedule". This is, the minimum amount of time >> that I can use this summer. With high probability, I will be able to use >> more time, but I prefer to put myself in the worst situation: >> >> May 23 - June 30: 22h per week (total 118h) >> July 1 - July 31: 45h per week (total 207h) >> August 1 - August 10: 22h per week (total 26h) > > It should be more than enough. > >> Finally, I have experience with C, C++, Java and Python languages. My >> favourite one is C. I made the most of my practice work during degree in C. > > Good. > >> Do you think, with this provisional schedule in mind, that I can apply >> for one of the projects? > > Yes, I'm sure you are able to do it. > >> If not, would it be possible to find a mentor for one of them? >> Without paying and GSoC deadlines, of course. > > I'm sure you can try, it won't hurt :-) > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ From klokan at klokan.cz Tue Mar 31 16:35:35 2009 From: klokan at klokan.cz (=?ISO-8859-2?Q?Klokan_Petr_P=F8idal?=) Date: Tue Mar 31 16:35:37 2009 Subject: [gdal-dev] gdal2tiles strangeness In-Reply-To: <781bff30903310937t4a9b6347hef2b27cbe1ca18d6@mail.gmail.com> References: <781bff30903310937t4a9b6347hef2b27cbe1ca18d6@mail.gmail.com> Message-ID: <6e41d95b0903311335k7074f73v6e5314ddb7215065@mail.gmail.com> Mano, If you would like to have both Google Maps and Google Earth presentation for a global map then you must generate two tile sets, because Google Maps supports only Mercator tiles (EPSG:900913) and Google Earth only geodetic (EPSG:4326). GDAL2Tiles has as a default tile profile 'mercator', it means that it will warp your input into Spherical Mercator internally. To create tiles and KML for Google Earth for your EPSG:4326 input data you should use -p "raster". >From the "gdal2tiles --help": -k, --force-kml Generate KML for Google Earth - default for 'geodetic' profile and 'raster' in EPSG:4326. For a dataset with different projection use with caution! Detailed description of recommended step by step usage of gdal2tiles for global maps was posted by Jesse Varner from CIRES & NOAA/NGDC, who used gdal2tiles for official presentation of Global magnetic anomaly map EMAG2 (for Google Maps/Earth) at: http://ngdc.noaa.gov/geomag/data/Google_Maps/EMAG2/index.html His post is here: http://groups.google.com/group/maptiler/msg/fe105e27a62711e4 Best regards, Klokan On Tue, Mar 31, 2009 at 6:37 PM, Mano Marks wrote: > I'm getting started with gdal2tiles, and I'm getting strange results. > > I downloaded a blue marble jpg from NASA: > http://www.nasa.gov/vision/earth/features/blue_marble.html > > And I ran the following command lines: > > gdal_translate -of VRT -a_srs EPSG:4326 -gcp 0 0 -180 90 -gcp 21600 0 > 180 90 -gcp 21600 10800 180 -90 world_200401.jpg bluemarble1.vrt > > gdalwarp -of VRT -t_srs EPSG:4326 bluemarble1.vrt bluemarble2.vrt > > gdal2tiles -k bluemarble2.vrt > > Of course, the last step took awhile. > > The Google Maps and OpenLayers output was fine. However, the KML had > some odd results. When loaded directly, it looked fine, but when I > zoomed out, it appeared that what was the equivalent of zoom 0 and 1 > the images retain a Mercator projection. Is this a known issue, or did > I do something wrong? > > -- > Mano Marks > Geo Developer Advocate > Google, Inc. > mmarks@google.com > http://twitter.com/ManoMarks > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ From wollez at gmx.net Tue Mar 31 18:07:33 2009 From: wollez at gmx.net (WolfgangZ) Date: Tue Mar 31 18:07:42 2009 Subject: [gdal-dev] removing of transparency possible? Message-ID: Hi, how do I remove a transparency layer? I used one during the merging process, but conversion to jpg (e.g.) complains about. Many thanks Wolg From wollez at gmx.net Tue Mar 31 18:08:45 2009 From: wollez at gmx.net (WolfgangZ) Date: Tue Mar 31 18:10:10 2009 Subject: [gdal-dev] Re: Is it a big thing to change ECW to support 16-bit imagery? In-Reply-To: <435112.50711.qm@web32607.mail.mud.yahoo.com> References: <435112.50711.qm@web32607.mail.mud.yahoo.com> Message-ID: I think you have to ask this question the right people! mohwawang schrieb: > Mateuse, > > So what's the answer to the "correct" question? > > Mo > > --- On Fri, 3/27/09, Mateusz Loskot wrote: > >> From: Mateusz Loskot >> Subject: Re: [gdal-dev] Is it a big thing to change ECW to support 16-bit imagery? >> To: "mohwawang" >> Cc: gdal-dev@lists.osgeo.org >> Date: Friday, March 27, 2009, 6:26 PM >> mohwawang wrote: >>> Is it a big job (for example, change the algorithm of >> compression in >>> ECW) or not so big a job to have ECW also support >> 16-bit imagery? >> >> Wrong question. The correct one is: are you allowed to >> change >> anything in ECW to support anything what is not supported? >> >> Best regards, >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> Charter Member of OSGeo, http://osgeo.org >> From jorge.arevalo at gmail.com Tue Mar 31 18:32:58 2009 From: jorge.arevalo at gmail.com (=?UTF-8?Q?Jorge_Ar=C3=A9valo?=) Date: Tue Mar 31 18:33:15 2009 Subject: [gdal-dev] Questions about projects of GSoC 2009 In-Reply-To: <6e41d95b0903311033t38cf7233g53d7eedec384e4bd@mail.gmail.com> References: <49CFCD5F.4080904@loskot.net> <49D00DA8.3010505@loskot.net> <49D13583.7070607@loskot.net> <6e41d95b0903311033t38cf7233g53d7eedec384e4bd@mail.gmail.com> Message-ID: Hello Klokan, Thanks for encouraging me! And congratulations for your excellent job with gdal2tiles. It really saved me from a lot of unproductive hours... It would be great to help you with WMTS implementation, or work with PNG driver, or with WKT Raster driver. I'm going to apply for the three projects directly on the GSoC page. Frank Warmerdarm told me on the GSoC list that it was the correct way. Am I right? Best regards Jorge On Tue, Mar 31, 2009 at 7:33 PM, Klokan Petr P?idal wrote: > Jorge, > > I am glad you are interested in the PNG driver, which I suggested as a > project for Summer of Code... > It would be really great to have this in GDAL and I guess more > projects will profit from this... > > I am going to assist as much as I can, whether in gsoc program > timeframe or even otherwise. > Feel free to contact me with any questions related to this project... > > I guess for position of mentor there are better candidates then me > (like Frank, Even, Mateusz, ...) > > Because I am a PhD student I applied in this Summer of Code as well as > a student so I technically I can not be your mentor. I can work this > summer on the WMTS implementation and other GDAL2Tiles improvements... > but I don't want to block position of new candidates... > If you are interested in WMTS implementation and GDAL2Tiles then just > go ahead, this I can mentor for sure ;-) > > Best regards, > > Klokan > > 2009/3/30 Mateusz Loskot : > > Jorge Ar?valo wrote: > >> The entire process could be improved by several ways: > >> > >> - I would like to have an enhaced PNG driver, to reduce the size of the > >> tiles. For this reason, I had a theoretical approach to NeuQuant > >> algorithm and I used pngnq. I discovered the relation between this > >> algorithm and Kohonen Neural Networks, that I studied during my degree, > >> and I liked a lot. Basically, for these reasons I'm interested in the > >> project about PNG Driver > > > > Nice idea. > > > >> - On one hand, at first I was using raster data, instead of vector data. > >> When the need of merging data arose, I had to change the point and use > >> vector data + Postgis. On the other hand, I would like to integrate my > >> layer to another ones in a bigger context, and I think that the raster > >> support on Postgis will be a really useful thing. For these reasons, I'm > >> interested in the project about WKT Raster. > > > > Good. > > > >> - Before using gdal2tiles, I made my own "map tiler", creating the tiles > >> needed "on-the-fly". As thought, it didn't work. I tried to use my own > >> "tile cache system". One problem was the low rate of cache hints. Then, > >> I discovered the WMS standard, and recently, the coming WMTS standard, > >> even better. For this reason, I'm interested in the project about WMTS > >> implementation. > > > > Good as well. > > > >> Now, this is my "minimum schedule". This is, the minimum amount of time > >> that I can use this summer. With high probability, I will be able to use > >> more time, but I prefer to put myself in the worst situation: > >> > >> May 23 - June 30: 22h per week (total 118h) > >> July 1 - July 31: 45h per week (total 207h) > >> August 1 - August 10: 22h per week (total 26h) > > > > It should be more than enough. > > > >> Finally, I have experience with C, C++, Java and Python languages. My > >> favourite one is C. I made the most of my practice work during degree in > C. > > > > Good. > > > >> Do you think, with this provisional schedule in mind, that I can apply > >> for one of the projects? > > > > Yes, I'm sure you are able to do it. > > > >> If not, would it be possible to find a mentor for one of them? > >> Without paying and GSoC deadlines, of course. > > > > I'm sure you can try, it won't hurt :-) > > > > Best regards, > > -- > > Mateusz Loskot, http://mateusz.loskot.net > > Charter Member of OSGeo, http://osgeo.org > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > http://blog.klokan.cz/ > http://www.maptiler.org/ > http://www.oldmapsonline.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090401/da45f56d/attachment.html From csomerlot at gmail.com Tue Mar 31 19:47:50 2009 From: csomerlot at gmail.com (Chris Somerlot) Date: Tue Mar 31 19:47:52 2009 Subject: [gdal-dev] help with resampling via python Message-ID: <9a8f0670903311647m1adbe2a4v7e1a2092cab8d91@mail.gmail.com> Having trouble figuring out how to resample an image to a different cell size from python. I looked over the VRT driver page and have been trying to get this to work: from osgeo import gdal gdal.AllRegister() src = gdal.Open('DOQ_test.TIF') drv = gdal.GetDriverByName('VRT') dst = drv.CreateCopy("", src, 0) dst.RasterXSize = '125' But it seems the cell size in the datasets and the bands are read only? Is there any programmatic way to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090331/9e19d837/attachment.html From mmarks at google.com Tue Mar 31 19:57:17 2009 From: mmarks at google.com (Mano Marks) Date: Tue Mar 31 20:08:13 2009 Subject: [gdal-dev] gdal2tiles strangeness In-Reply-To: <6e41d95b0903311335k7074f73v6e5314ddb7215065@mail.gmail.com> References: <781bff30903310937t4a9b6347hef2b27cbe1ca18d6@mail.gmail.com> <6e41d95b0903311335k7074f73v6e5314ddb7215065@mail.gmail.com> Message-ID: <781bff30903311657n7f29d083xd7c54aa0abed3a54@mail.gmail.com> Hi Klokan, Thanks for the pointer. So it looks like, right now, there's a bug in gdal2tiles, according to Jesse? Any news on when that might be fixed? Mano 2009/3/31 Klokan Petr P?idal : > Mano, > > If you would like to have both Google Maps and Google Earth > presentation for a global map then you must generate two tile sets, > because Google Maps supports only Mercator tiles (EPSG:900913) and > Google Earth only geodetic (EPSG:4326). > > GDAL2Tiles has as a default tile profile 'mercator', it means that it > will warp your input into Spherical Mercator internally. > To create tiles and KML for Google Earth for your EPSG:4326 input data > you should use -p "raster". > > From the "gdal2tiles --help": > > -k, --force-kml ? ? Generate KML for Google Earth - default for 'geodetic' > ? ? ? ? ? ? ? ? ? ? ? ?profile and 'raster' in EPSG:4326. For a dataset with > ? ? ? ? ? ? ? ? ? ? ? ?different projection use with caution! > > Detailed description of recommended step by step usage of gdal2tiles > for global maps was posted by Jesse Varner > from CIRES & NOAA/NGDC, who used gdal2tiles for official presentation > of Global magnetic anomaly map EMAG2 (for Google Maps/Earth) at: > http://ngdc.noaa.gov/geomag/data/Google_Maps/EMAG2/index.html > > His post is here: > http://groups.google.com/group/maptiler/msg/fe105e27a62711e4 > > Best regards, > > Klokan > > On Tue, Mar 31, 2009 at 6:37 PM, Mano Marks wrote: >> I'm getting started with gdal2tiles, and I'm getting strange results. >> >> I downloaded a blue marble jpg from NASA: >> http://www.nasa.gov/vision/earth/features/blue_marble.html >> >> And I ran the following command lines: >> >> gdal_translate -of VRT -a_srs EPSG:4326 -gcp 0 0 -180 90 -gcp 21600 0 >> 180 90 -gcp 21600 10800 180 -90 world_200401.jpg bluemarble1.vrt >> >> gdalwarp -of VRT -t_srs EPSG:4326 bluemarble1.vrt bluemarble2.vrt >> >> gdal2tiles -k bluemarble2.vrt >> >> Of course, the last step took awhile. >> >> The Google Maps and OpenLayers output was fine. However, the KML had >> some odd results. When loaded directly, it looked fine, but when I >> zoomed out, it appeared that what was the equivalent of zoom 0 and 1 >> the images retain a Mercator projection. Is this a known issue, or did >> I do something wrong? >> >> -- >> Mano Marks >> Geo Developer Advocate >> Google, Inc. >> mmarks@google.com >> http://twitter.com/ManoMarks >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > http://blog.klokan.cz/ > http://www.maptiler.org/ > http://www.oldmapsonline.org/ > -- Mano Marks Geo Developer Advocate Google, Inc. mmarks@google.com http://twitter.com/ManoMarks From belasalwa at yahoo.fr Tue Mar 31 20:05:15 2009 From: belasalwa at yahoo.fr (belaqziz salwa) Date: Tue Mar 31 20:11:59 2009 Subject: [gdal-dev] xml file for accessing to a wcs server Message-ID: <388993.72243.qm@web26001.mail.ukl.yahoo.com> Hi, for Accessing to a WCS server i created a local service description xml file,but when i tested the gdal_translate command, i have the following error: C:\Inetpub\wps>gdal_translate -of GTIFF wcs.xml wcs.tif -srcwin 0 0 547 347 Input file size is 548, 348 0ERROR 1: Returned tile does not match expected band count. Open GDAL Datasets: ? 1 N GTiff?????? -1 547x347x3 /vsimem/wcs/00E2F5F0/wcsresult.dat I also tried to re-compile gdal, but i have error : ??????? cd apps ??????? nmake /nologo /f makefile.vc ??????? cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG -I..\port -I..\ogr -I..\gcore? -I..\alg -I..\ogr\ogrsf_frmts?? -I..\frmts -I..\alg -I..\ogr -I..\ogr\ogrsf_frmts gdalinfo.c? ..\gdal_i.lib /link gdalinfo.c gdalinfo.obj : error LNK2019: unresolved external symbol _GDALAllRegister@0 referenced in function _main gdalinfo.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.EXE"' : return code '0x2' thanks for your help Salwa. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090401/b2799dd7/attachment.html From warmerdam at pobox.com Tue Mar 31 21:01:36 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 21:01:50 2009 Subject: [gdal-dev] xml file for accessing to a wcs server In-Reply-To: <388993.72243.qm@web26001.mail.ukl.yahoo.com> References: <388993.72243.qm@web26001.mail.ukl.yahoo.com> Message-ID: <49D2BCF0.7050807@pobox.com> belaqziz salwa wrote: > Hi, > > for Accessing to a WCS server i created a local service description xml > file,but when i > tested the gdal_translate command, i have the following error: > > C:\Inetpub\wps>gdal_translate -of GTIFF wcs.xml wcs.tif -srcwin 0 0 547 347 > Input file size is 548, 348 > 0ERROR 1: Returned tile does not match expected band count. > Open GDAL Datasets: > 1 N GTiff -1 547x347x3 /vsimem/wcs/00E2F5F0/wcsresult.dat Salwa, It would be helpful if you could provide the WCS service description file, assuming the WCS service is public. > I also tried to re-compile gdal, but i have error : > > cd apps > nmake /nologo /f makefile.vc > cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE > /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG -I..\port -I..\ogr -I..\gcore > -I..\alg -I..\ogr\ogrsf_frmts -I..\frmts -I..\alg -I..\ogr > -I..\ogr\ogrsf_frmts gdalinfo.c ..\gdal_i.lib /link > gdalinfo.c > gdalinfo.obj : error LNK2019: unresolved external symbol > _GDALAllRegister@0 referenced in function _main > gdalinfo.exe : fatal error LNK1120: 1 unresolved externals > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio > 8\VC\BIN\cl.EXE"' : return code '0x2' That is odd. I have no opinion on why it is happening. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent From warmerdam at pobox.com Tue Mar 31 21:13:19 2009 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue Mar 31 21:13:23 2009 Subject: [gdal-dev] removing of transparency possible? In-Reply-To: References: Message-ID: <49D2BFAF.2060004@pobox.com> WolfgangZ wrote: > Hi, > > how do I remove a transparency layer? I used one during the merging > process, but conversion to jpg (e.g.) complains about. > > Many thanks > Wolg Wolg, Are you referring to an alpha band? If so, you could select a subset of bands with gdal_translate using the -b flag. eg. gdal_translate -b 1 -b 2 -b 3 rgba.tif rgb.jpg Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent