Re: [gdal-dev] Motion: Adopt RFC 29: OGR Set Ignored Fields
+ 0 I'm not sure which approach DesiredFields vs IgnoredFields is the best one. Both have their pros and cons. IgnoredFields will be a bit awkward to use, but the main argument for this approach (avoid dropping any special fields) makes sense. I also think that a layer capability can be useful to know which driver makes use of it. For Tamas : About the -select option of ogr2ogr, I'd note that, paradoxically ogr2ogr does not use currently the SQL engine to implement this. The list of fields is just used to create the layout of the target layer definition and build the map between source and target field indices to be used by OGRFeature::SetFrom(). At first thought, I have imagined it could generate a SELECT field1, field2, ... FROM layer_name SQL expression instead and fallback to the -sql case. But for server based drivers (postgresql or mysql for example), this wouldn't fetch the geometry field... Best regards, Even Le vendredi 06 août 2010 15:04:12, Martin Dobias a écrit : Hi, As there have been no further comments on RFC 29, I would like to call for vote on it: http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields Regards Martin ___ 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] wrong in LINESTRING
hello I was wondering what I did wrong in the following code ? Geometry line2=new Geometry(1,LINESTRING((33.0 41.0 0,33.5 42.5 0, 33.9 41.9 0,33.0 41.0 0)), null, null); Feature feature = new Feature(layerDefinition); feature.SetFID(0); feature.SetGeometry(line2); layer.CreateFeature(feature); regards ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] wrong in LINESTRING
2 errors : 1) The WKT is incorrect. You don't need 2 open closing parenthesis for a LINESTRING. Just one is enough : LINESTRING(33.0 41.0 0,33.5 42.5 0, 33.9 41.9 0,33.0 41.0 0) 2) Provided you use GDAL = 1.7.0, you shouldn't use the Geometry(int eGeometryType, String wkt, byte[] wkb, String gml) constructor, which is really awkward to use and was kept only for backward compatibility. If you want to construct a geometry from a WKT string, you should pass 0 as the first argument, otherwise the geometry type will be used to create in your case a POINT EMPTY geometry. Use Geometry.CreateFromWkt() instead. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Maintenance report for Jun 17, 2010 to Aug 07, 2010
Frank, Please find the attached maintenance report for the work done by me. Same can be found at http://trac.osgeo.org/gdal/wiki/MaintenanceReportsByChaitanya#Jun172010toAug072010 -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E GDAL Maintenance Reports by Chaitanya kumar CH. Duration: Jun 17, 2010 to Aug 07, 2010 #3630: Added some corrections, changes and a test for xlink support in GML driver. #2852: Added a test. #3364: Fixed a typo that was making the comparision of coordinate systems to fail sometimes. #2798: Prepared a test for index management in shapefile driver. #3045: Fixed a memory leak. #3694: Made the mif driver more lenient with the mif file formatting. -- Chaitanya kumar CH chaitany...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] vsizip vsigzip on Win
Hi, I'm trying to access ziped files on Windows using the /vsizip but it fails most of times According to docs, this should work no? gdalinfo c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but it doesn't. I get ERROR 4: `c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt' does not exist in the file system, and is not recognised as a supported dataset name. However, I'm able to make it work by using the unix pathname syntax gdalinfo /vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but even this only works when I run the command from the root dir, that is from C:\ If run it from any another location I get the same error message. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] vsizip vsigzip on Win
Sorry for the noise. I found that the correct syntax is gdalinfo /vsizip/c:\m_gmt_so\tmp\N37W008.hgt.zip\N37W008.hgt and like that it works fine. Joaquim Hi, I'm trying to access ziped files on Windows using the /vsizip but it fails most of times According to docs, this should work no? gdalinfo c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but it doesn't. I get ERROR 4: `c:/vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt' does not exist in the file system, and is not recognised as a supported dataset name. However, I'm able to make it work by using the unix pathname syntax gdalinfo /vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt but even this only works when I run the command from the root dir, that is from C:\ If run it from any another location I get the same error message. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: How to retain double precision in GDAL?
Thanks for fixing the precision loss so quickly. you now can set the configuration option AAIGRID_DATATYPE to Float64 to force Float64 being used to avoid the loss of precision. I am not exactly sure whether this option relates to the gdal_translate command line utility or the Python binding (ReadAsArray) - or both. Could you perhaps post the updated script that produced the double precision values correctly? Thanks Ole Nielsen - Ole Nielsen Australia - Indonesia Facility for Disaster Reduction -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-How-to-retain-double-precision-in-GDAL-tp5379507p5387617.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
Re: [gdal-dev] Re: How to retain double precision in GDAL?
Ole, This option is for the AAIGRID driver. So this option is valid any time the format is handled. In a python script you set the option you need to set this option during the call to gdal.Open() to set a specific datatype. Refer to http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/aaigrid.py#L245and http://trac.osgeo.org/gdal/browser/trunk/autotest/gdrivers/aaigrid.py#L247 . Remember to set it to 'None'. To set this option for gdal/ogr utilities use the option --config as described in http://www.gdal.org/gdal_utilities.html. Use the CPLSetConfigOption() function in C/C++ code. On Mon, Aug 9, 2010 at 8:10 AM, Ole Nielsen ole.niel...@aifdr.org wrote: Thanks for fixing the precision loss so quickly. you now can set the configuration option AAIGRID_DATATYPE to Float64 to force Float64 being used to avoid the loss of precision. I am not exactly sure whether this option relates to the gdal_translate command line utility or the Python binding (ReadAsArray) - or both. Could you perhaps post the updated script that produced the double precision values correctly? Thanks Ole Nielsen - Ole Nielsen Australia - Indonesia Facility for Disaster Reduction -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-How-to-retain-double-precision-in-GDAL-tp5379507p5387617.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 -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
