Re: [gdal-dev] Selecting OGR Driver Based on File Name
Joel Odom wrote: Is there a canonical way to pick an OGR driver based on a file name or on a generalized connect string? (For example, if the file name ends in .shp, it would select the Shapefile driver.) Thanks. Joel, No. I really wanted to send this out with just that one word answer, but I can't help myself but elaborate. First, I think file format identification based on filename extension is a terrible idea, and I curse those operating systems that try to build it into the graphical shell. Likewise a pox on applications that carry on this tradition. Second, there are a number of OGR file formats that have no dependency on extension. For example GML, DGN, DXF, PCIDSK. For these formats any extension is fine and only letting people pick a file if it has some particular is offensive to me. Third, there are lots of database connection formats that aren't extension based. Typically these can be identified based on a prefix string like MYSQL: though not always. Despite my feelings on this matter, on the GDAL side of the house we actually provide a metadata item on drivers allowing specification of a preferred extension which applications can use. We also have an identify mechanism that will try to efficiently identify what format a file or dataset name string is without necessarily actually opening it. Unfortunately, the OGR world is less sophisticated in this regard and lacks these two mechanisms. This is one reason I'd like to have a grand unification of GDAL and OGR one day. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Selecting OGR Driver Based on File Name
Thanks, Frank. I understand the purist argument against this, though I think that 90% of the time you can look at a connection string for a data source and determine what the output driver should be. I'd like to see this feature in the future, but I understand that it would need a caveat that it may not always work or return the expected result. Maybe a GuessOutputDriver(...) function would be the appropriate way to name it. On Wed, Oct 6, 2010 at 8:47 AM, Frank Warmerdam warmer...@pobox.com wrote: Joel Odom wrote: Is there a canonical way to pick an OGR driver based on a file name or on a generalized connect string? (For example, if the file name ends in .shp, it would select the Shapefile driver.) Thanks. Joel, No. I really wanted to send this out with just that one word answer, but I can't help myself but elaborate. First, I think file format identification based on filename extension is a terrible idea, and I curse those operating systems that try to build it into the graphical shell. Likewise a pox on applications that carry on this tradition. Second, there are a number of OGR file formats that have no dependency on extension. For example GML, DGN, DXF, PCIDSK. For these formats any extension is fine and only letting people pick a file if it has some particular is offensive to me. Third, there are lots of database connection formats that aren't extension based. Typically these can be identified based on a prefix string like MYSQL: though not always. Despite my feelings on this matter, on the GDAL side of the house we actually provide a metadata item on drivers allowing specification of a preferred extension which applications can use. We also have an identify mechanism that will try to efficiently identify what format a file or dataset name string is without necessarily actually opening it. Unfortunately, the OGR world is less sophisticated in this regard and lacks these two mechanisms. This is one reason I'd like to have a grand unification of GDAL and OGR one day. 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 -- http://www.operationliberate.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gdal_rasterize -tr and -te
On 05/10/2010 19:40, Even Rouault wrote: Le lundi 04 octobre 2010 17:23:47, Frank Warmerdam a écrit : gdal_translate, gdalwarp, ... Even, I would suggest -tap for target aligned pixels to go with -tr. I would think that gdalwarp, gdal_rasterize, and perhaps gdal_merge.py and gdalbuildvrt would be appropriate applications to support this switch. Foks, I've followed Frank's suggestion. Please test the patch attached to http://trac.osgeo.org/gdal/ticket/3772 (applies cleanly on latest trunk, r20770) and report if it works as you expect. Then I'll commit it. I don't see how it would be appropriate for gdal_translate. Best regards, I applied the patch and the corner coordinates seem to work fine for gdal_rasterize and gdalwarp. I haven't tried gdalbuildvrt. Perhaps someone else would like to test it? On the other hand... The new, target aligned tiffs do only have NODATA values, which seems to be related to ERROR 1: $ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte -a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn 1 -where CODE=111 lu001l_luxembourg.shp out.tif OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0) succeeded as ESRI Shapefile. GDAL: QuietDelete(out.tif) invoking Delete() GDAL: GDALOpen(out.tif, this=0x19cbe00) succeeds as GTiff. GDAL: GDALDefaultOverviews::OverviewScan() GDAL: GDALClose(out.tif, this=0x19cbe00) GDAL: GDALDriver::Create(GTiff,out.tif,224,321,1,Byte,0x1979ab0) ERROR 1: Type mismatch or improper type of arguments to = operator. GTiff: Adjusted bytes to write from 8064 to 7392. GDAL: GDALClose(out.tif, this=0x19caf40) GDAL: GDALDeregister_GTiff() called. I am not sure if this new ERROR is related to your patch or some other changes which came through checking out -r 20770. This error message is obvioulsy defined in from ogr/swq_op_general.cpp Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize -tr and -te
The results of -tap are what I expect, pixels aligned with 0,0. Although I have a separate question at the end. Prior to the patch I ran this: gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif and got this: gdalinfo townrasterb.tif ... Origin = (7267911.066051597706974,512434.991065477312077) Pixel Size = (100.000,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267911.066, 512434.991) (124d 6'49.77W, 45d 0'53.75N) Lower Left ( 7267911.066, 290634.991) (124d 4'33.15W, 44d24'25.68N) Upper Right ( 7392811.066, 512434.991) (123d37'52.26W, 45d 1'45.22N) Lower Right ( 7392811.066, 290634.991) (123d35'53.84W, 44d25'16.61N) Center ( 7330361.066, 401534.991) (123d51'17.02W, 44d43' 6.24N) Band 1 Block=1249x1 Type=Float64, ColorInterp=Gray After the patch I ran this: gdal_rasterize -tr 100 100 -tap -a Elevation -l town town.shp townrasterd.tif and got this: gdalinfo townrasterd.tif ... Origin = (7267900.000,512500.000) Pixel Size = (100.000,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267900.000, 512500.000) (124d 6'49.97W, 45d 0'54.39N) Lower Left ( 7267900.000, 290600.000) (124d 4'33.28W, 44d24'25.33N) Upper Right ( 7392900.000, 512500.000) (123d37'51.05W, 45d 1'45.90N) Lower Right ( 7392900.000, 290600.000) (123d35'52.60W, 44d25'16.29N) Center ( 7330400.000, 401550.000) (123d51'16.49W, 44d43' 6.41N) Band 1 Block=1250x1 Type=Float64, ColorInterp=Gray town.shp is a point layer with 12 points, 11 of those points have values in -a Elevation (1 is null), and in the output tif, 9 pixels have values. The far south and far east points do not have corresponding pixels with values. If this needs review, I can open a ticket and attach a very small example. I include this info in this thread since that is the case before -tap and after -tap I get the same thing, except the far east point has a corresponding pixel with -tap. This probably doesn't have anything (much) to do with -tap. Thanks, Eli Hermann Peifer pei...@gmx.eu 10/06/10 7:43 AM On 06/10/2010 16:34, Frank Warmerdam wrote: Hermann Peifer wrote: $ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte -a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn 1 -where CODE=111 lu001l_luxembourg.shp out.tif OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0) succeeded as ESRI Shapefile. GDAL: QuietDelete(out.tif) invoking Delete() GDAL: GDALOpen(out.tif, this=0x19cbe00) succeeds as GTiff. GDAL: GDALDefaultOverviews::OverviewScan() GDAL: GDALClose(out.tif, this=0x19cbe00) GDAL: GDALDriver::Create(GTiff,out.tif,224,321,1,Byte,0x1979ab0) ERROR 1: Type mismatch or improper type of arguments to = operator. ... I see: ERROR 1 can be avoided by using: -where CODE=\'5\' (CODE is a string field). In any case: I rasterize via a shell script and I did not get the same error when running the same script last week. Herman, Were you using GDAL 1.7 last week? No, but an earlier version of 1.8dev (a few months old, perhaps) Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize -tr and -te
Le mercredi 06 octobre 2010 18:42:14, Eli Adam a écrit : The results of -tap are what I expect, pixels aligned with 0,0. Although I have a separate question at the end. ok, I've applied the patch in trunk in r20778 Prior to the patch I ran this: gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif and got this: gdalinfo townrasterb.tif ... Origin = (7267911.066051597706974,512434.991065477312077) Pixel Size = (100.000,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267911.066, 512434.991) (124d 6'49.77W, 45d 0'53.75N) Lower Left ( 7267911.066, 290634.991) (124d 4'33.15W, 44d24'25.68N) Upper Right ( 7392811.066, 512434.991) (123d37'52.26W, 45d 1'45.22N) Lower Right ( 7392811.066, 290634.991) (123d35'53.84W, 44d25'16.61N) Center ( 7330361.066, 401534.991) (123d51'17.02W, 44d43' 6.24N) Band 1 Block=1249x1 Type=Float64, ColorInterp=Gray After the patch I ran this: gdal_rasterize -tr 100 100 -tap -a Elevation -l town town.shp townrasterd.tif and got this: gdalinfo townrasterd.tif ... Origin = (7267900.000,512500.000) Pixel Size = (100.000,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 7267900.000, 512500.000) (124d 6'49.97W, 45d 0'54.39N) Lower Left ( 7267900.000, 290600.000) (124d 4'33.28W, 44d24'25.33N) Upper Right ( 7392900.000, 512500.000) (123d37'51.05W, 45d 1'45.90N) Lower Right ( 7392900.000, 290600.000) (123d35'52.60W, 44d25'16.29N) Center ( 7330400.000, 401550.000) (123d51'16.49W, 44d43' 6.41N) Band 1 Block=1250x1 Type=Float64, ColorInterp=Gray town.shp is a point layer with 12 points, 11 of those points have values in -a Elevation (1 is null), and in the output tif, 9 pixels have values. The far south and far east points do not have corresponding pixels with values. If this needs review, I can open a ticket and attach a very small example. I include this info in this thread since that is the case before -tap and after -tap I get the same thing, except the far east point has a corresponding pixel with -tap. This probably doesn't have anything (much) to do with -tap. Yes, I'm pretty confident this has nothing to do with -tap. More likely an issue with the rasterize code itself. You can probably file a ticket with data and command on how to reproduce to keep track of the issue. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: GDAL JAVA problem
Le mercredi 06 octobre 2010 16:35:38, sagar_sahay a écrit : After tweaking the path variable I got this exception: Native library load failed. java.lang.UnsatisfiedLinkError: /home/gdal/gdal-1.7.2/swig/java/libgdaljni.so: /home/gdal/gdal-1.7.2/swig/java/libgdaljni.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) Exception in thread main java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.AllRegister()V at org.gdal.gdal.gdalJNI.AllRegister(Native Method) at org.gdal.gdal.gdal.AllRegister(gdal.java:447) at ogr.gdalinfo.main(gdalinfo.java:57) Java Result: 1 Please Help. Well, by looking at the error, it looks like you're on a 64bit Linux, so the binding library has been compiled as 64bit, which is fine. So my guess is that you're running a 32bit JVM or 64bit JVM in 32bit mode. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] corner coords in tif vs ecw
I used gdal_translate to convert a geotiff to an ecw file. C:\Program Files\FWTools2.4.7gdal_translate -of ECW f:\test\mytif.tif f:\test\myecw.ecw Input file size is 2353, 2353 0...10...20...30...40...50...60...70...80...90...100 - done. However, the corner coordinates are different between the two files. The tiff uses values from the coordinate system, while the ecw seems to just use the tile dimensions. I'm not sure if there is something different in how the two formats store that data, or if there was an option I didn't use. Any insight is appreciated. gdalinfo results for the tif and ecw are below. C:\Program Files\FWTools2.4.7gdalinfo f:\gisdata\test\mytif.tif Driver: GTiff/GeoTIFF Files: f:\gisdata\test\mytif.tif Size is 2353, 2353 Coordinate System is: PROJCS[Bermuda_2000_National_Grid, GEOGCS[GCS_Bermuda_2000, DATUM[Bermuda_2000, SPHEROID[WGS_1984,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,32], PARAMETER[central_meridian,-64.75], PARAMETER[scale_factor,1], PARAMETER[false_easting,55], PARAMETER[false_northing,10], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (535999.7874998,12.8624999) Pixel Size = (0.425,-0.425) Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 535999.787, 12.862) ( 64d53'54.96W, 32d16'13.63N) Lower Left ( 535999.787, 128999.837) ( 64d53'54.90W, 32d15'41.16N) Upper Right ( 536999.813, 12.862) ( 64d53'16.74W, 32d16'13.67N) Lower Right ( 536999.813, 128999.837) ( 64d53'16.70W, 32d15'41.20N) Center ( 536499.800, 129499.850) ( 64d53'35.82W, 32d15'57.42N) Band 1 Block=2353x8 Type=Byte, ColorInterp=Red Band 2 Block=2353x8 Type=Byte, ColorInterp=Green Band 3 Block=2353x8 Type=Byte, ColorInterp=Blue C:\Program Files\FWTools2.4.7gdalinfo f:\gisdata\test\myecw.ecw Driver: ECW/ERMapper Compressed Wavelets Files: f:\gisdata\test\myecw.ecw f:\gisdata\test\myecw.ecw.aux.xml Size is 2353, 2353 Coordinate System is: PROJCS[Bermuda_2000_National_Grid, GEOGCS[GCS_Bermuda_2000, DATUM[Bermuda_2000, SPHEROID[WGS_1984,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,32], PARAMETER[central_meridian,-64.75], PARAMETER[scale_factor,1], PARAMETER[false_easting,55], PARAMETER[false_northing,10], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 2353.0) Upper Right ( 2353.0,0.0) Lower Right ( 2353.0, 2353.0) Center ( 1176.5, 1176.5) Band 1 Block=2353x1 Type=Byte, ColorInterp=Red Overviews: arbitrary Band 2 Block=2353x1 Type=Byte, ColorInterp=Green Overviews: arbitrary Band 3 Block=2353x1 Type=Byte, ColorInterp=Blue Overviews: arbitrary -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-corner-coords-in-tif-vs-ecw-tp5608144p5608144.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
