Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
- What are the official ogr steps required to store a vector layer (represented as e.g. a list of x, y values and associated feature attributes (name, value))? In particular, is CreateField perhaps obsoleted by something else? Nothing obsoleted here. CreateField() and CreateFeature() are the way to go - Is the truncation to 10 characters hard and fast or driver dependent - and how should one deal with this truncation? Your example (which does not use CreateField) would suggest names can be longer than 10 characters. Yes, it is specific to the shapefile driver. This is a in fact a limitation of the DBF format itself : http://www.gdal.org/ogr/drv_shapefile.html And the implementation of the truncation has indeed changed in recent versions. I somehow remember that in previous versions CreateField() only truncated in the field name in the DBF file but not in the feature definition just after calling it. Now its behaviour is more consistant, but can indeed be a bit strange where one is not aware of it. - Where can i find some documentation of the OGR Python bindings? You'll find a lot of ressources here : http://trac.osgeo.org/gdal/wiki/GdalOgrInPython Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] AW: ESRI products have problems reading gdal spatialreference entry
Hermann, On 05/09/2011 16:03, Schmitz, Uwe wrote: I wonder, if anyone else has experienced this or similar behaviour. And how can I achieve that ESRI- *and* gdal-Tools can identify the correct reference system. What I asked on this list some weeks ago: --- snip --- From experience, I know that ESRI users have trouble with some projection and parameter names generated by GDAL and vice versa. Is it possible to convince GDAL to store coordinate system information in a way that would be ESRI-friendly and GDAL-friendly at the same time? http://osgeo-org.1803224.n2.nabble.com/gdal-dev-gdal-translate -eats-projection-parameter-values-td6680528.html#d1313170021000-317 --- snip --- My understanding of Frank's answer is that this is basically not possible. thanks for the link. It clarifies the problem but is unsatisfactory. I must have missed this thread beforehand, maybe due to the subject ;-) So if I conclude: ESRI and GDAL have different WKT formats. It is not possible to write GeoTIFF files which are fully ESRI *and* GDAL compatible. A workaround may be to use ArcGIS's GDAL support for GeoTIFF. So I will give this hint to our ESRI users. Thanks for the aswers and your time Uwe ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Merging tiff4 files
Hi, thx to Jean-Claude and Even, I definitively resolve my troubles. :) gdalwarp is the right tool to merge.It don't break with no-one raster and after I use gdaltranslate to produce a tiff4 raster. To help any-one that has same need. I put the call I'm using. The call take all the raster tiff4 available in a folder and merge all in 1 only raster. The SRS is the same (for me EPSG:3003) for source and target. Also I put the level 0 (white to -srcnodata to avoid that the overlapping of borders covers the raster near. As show from the image sample here attach. gdalwarp.exe -s_srs EPSG:3003 -t_srs EPSG:3003 -r near -ot Byte -srcnodata 0 -of GTiff -co TFW=YES ../raster/list/*.tif ../raster/raster_result.tif gdal_translate -co NBITS=1 -co COMPRESS=CCITTFAX4 -co TFW=YES ../raster/raster_result.tif ../raster/raster_result_as_tiff4.tif Regards, Andrea Peri. attachment: gdalwarp_merge_sample.gif___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECW writing (was GTiff optimisation)
Selon Jean-Claude Repetto jrepe...@free.fr: Le 05/09/2011 19:24, Even Rouault a écrit : If I add the libNCSEcwC.so library, it works: I had updated configure.in and configure to include that new dependency. So try ./configure again. I had run ./configure, so your changes are not sufficient, or there is another problem. I have noticed that libgdal.la contains : dependency_libs=' -R/usr/local/lib -L/usr/lib64 -lgeos_c /usr/lib64/libsqlite3.la /usr/lib64/libexpat.la /usr/lib64/libNCSEcw.la /usr/lib64/libNCSCnet.la /usr/lib64/libNCSUtil.la -lgif /usr/lib64/libgeotiff.la -lproj /usr/lib64/libproj.la -ljpeg -ltiff -lpng -L/usr/lib64/postgresql-9.0/lib64 -lpq -lpthread -lcurl -lrt -lssl -lcrypto /usr/lib64/libgmp.la -ldl -lz' If I add /usr/lib64/libNCSEcwC.la to this list, it works. Sorry, but I don't know the autotools enough well to solve the problem myself. Jean-Claude, Thanks for reporting. I believe this should be fixed now by http://trac.osgeo.org/gdal/changeset/23067 . The case that was dealt with before was when using ./configure --with-ecw=/the/path/to/install/dir , but not ./configure --with-ecw[=yes] which, I presume, is your use case. Please confirm if it works for you. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECW writing (was GTiff optimisation)
Le 06/09/2011 14:12, Even Rouault a écrit : I believe this should be fixed now by http://trac.osgeo.org/gdal/changeset/23067 . The case that was dealt with before was when using ./configure --with-ecw=/the/path/to/install/dir , but not ./configure --with-ecw[=yes] which, I presume, is your use case. Please confirm if it works for you. It works now, thanks. For your information, I have used ./configure without any parameter, because the script is able to detect if the libecwj2 library is installed or not. Now I am going to test gdal_edit.py . Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Hi Even Thanks again for all your help - all tests now pass using either gdal 1.6 or 1.8. Just to summarise, there were three issues as I see them: 1. Bounding boxes for raster data are computed differently (but better) in newer versions 2. While v1.6 of ogre would allow an single number of type numpy.ndarray this is no longer allow. Casting it to a float solves the problem. 3. New versions of ogre will not allow attribute names of length longer than 10 (at least when using the ESRI driver). Formerly, I think it silently truncated, now it is up to the user. That's at least what I did. For those interested, the updated class dealing with vector data for our risk modelling application is available on github at https://github.com/AIFDR/riab/blob/develop/impact/storage/vector.py Thanks again for a great piece of software Ole Nielsen On Tue, Sep 6, 2011 at 1:05 PM, Even Rouault even.roua...@mines-paris.orgwrote: - What are the official ogr steps required to store a vector layer (represented as e.g. a list of x, y values and associated feature attributes (name, value))? In particular, is CreateField perhaps obsoleted by something else? Nothing obsoleted here. CreateField() and CreateFeature() are the way to go - Is the truncation to 10 characters hard and fast or driver dependent - and how should one deal with this truncation? Your example (which does not use CreateField) would suggest names can be longer than 10 characters. Yes, it is specific to the shapefile driver. This is a in fact a limitation of the DBF format itself : http://www.gdal.org/ogr/drv_shapefile.html And the implementation of the truncation has indeed changed in recent versions. I somehow remember that in previous versions CreateField() only truncated in the field name in the DBF file but not in the feature definition just after calling it. Now its behaviour is more consistant, but can indeed be a bit strange where one is not aware of it. - Where can i find some documentation of the OGR Python bindings? You'll find a lot of ressources here : http://trac.osgeo.org/gdal/wiki/GdalOgrInPython Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny
On 11-09-02 04:42 PM, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny --- +1 Daniel -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Selon Ole Nielsen ole.moller.niel...@gmail.com: Hi Even Thanks again for all your help - all tests now pass using either gdal 1.6 or 1.8. Just to summarise, there were three issues as I see them: 1. Bounding boxes for raster data are computed differently (but better) in newer versions Specific to PixelIsPoint in the GTiff driver. 2. While v1.6 of ogre would allow an single number of type numpy.ndarray this is no longer allow. Casting it to a float solves the problem. I wasn't aware it could work before. There's perhaps now an ambiguity on which method to use, due to the addition of new possibilities for SetField() (just a bling guess). 3. New versions of ogre will not allow attribute names of length longer than 10 (at least when using the ESRI driver). Formerly, I think it silently truncated, now it is up to the user. That's at least what I did. I've a looked quickly a bit at your code and I've the feeling that you truncate yourself, instead of relying on OGR. The Shapefile driver does more than truncating. It also ensures uniqueness of the truncated names. For example, if you try creating a_very_long_name and a_very_long_name_again, they will be respectively truncated to a_very_lon and a_very_l_1. A safer solution to get the field name that got to the file would be to : field_defn = ogr.FieldDefn(a_very_long_name, ogr.OFTString) lyr.CreateField(field_defn) layer_defn = lyr.GetLayerDefn() last_field_idx = layer_defn.GetFieldCount() - 1 real_field_name = layer_defn.GetFieldDefn(last_field_idx).GetNameRef() ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Thanks - I was hoping I could rely on the library to do the intelligent truncation, but couldn't work it out. Can I just clarify that the name to use with SetField would then be what is provided by your last line? layer_defn.GetFieldDefn(last_field_idx).GetNameRef() Cheers and thanks Ole On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault even.roua...@mines-paris.orgwrote: Selon Ole Nielsen ole.moller.niel...@gmail.com: Hi Even Thanks again for all your help - all tests now pass using either gdal 1.6 or 1.8. Just to summarise, there were three issues as I see them: 1. Bounding boxes for raster data are computed differently (but better) in newer versions Specific to PixelIsPoint in the GTiff driver. 2. While v1.6 of ogre would allow an single number of type numpy.ndarray this is no longer allow. Casting it to a float solves the problem. I wasn't aware it could work before. There's perhaps now an ambiguity on which method to use, due to the addition of new possibilities for SetField() (just a bling guess). 3. New versions of ogre will not allow attribute names of length longer than 10 (at least when using the ESRI driver). Formerly, I think it silently truncated, now it is up to the user. That's at least what I did. I've a looked quickly a bit at your code and I've the feeling that you truncate yourself, instead of relying on OGR. The Shapefile driver does more than truncating. It also ensures uniqueness of the truncated names. For example, if you try creating a_very_long_name and a_very_long_name_again, they will be respectively truncated to a_very_lon and a_very_l_1. A safer solution to get the field name that got to the file would be to : field_defn = ogr.FieldDefn(a_very_long_name, ogr.OFTString) lyr.CreateField(field_defn) layer_defn = lyr.GetLayerDefn() last_field_idx = layer_defn.GetFieldCount() - 1 real_field_name = layer_defn.GetFieldDefn(last_field_idx).GetNameRef() ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR_G_ExportToWkt make MEX crash
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many
cases.
However, I had a situation when trying to fetch the reference info. The
chunk of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than Matlab crashes at that line. However, using the OSRExportTo...
functions works fine.
I'm I doing something forbidden or ...
heers
Joaquim
hSRS = OGR_L_GetSpatialRef(hLayer);/* Do not free it later */
if (hSRS) {
char*pszWKT = NULL, *pszProj4 = NULL;
mxArray*mxPrjRef;
/*OGR_G_ExportToWkt (hSRS, pszWKT); */ == THIS
CALL MAKE THE MEX CRASH
if (OSRExportToProj4(hSRS, pszProj4) == OGRERR_NONE) {
mxPrjRef = mxCreateString (pszProj4);
mxSetField (out_struct, 0, SRSProj4, mxPrjRef);
}
if (OSRExportToPrettyWkt(hSRS, pszWKT, 1) == OGRERR_NONE) {
mxPrjRef = mxCreateString (pszWKT);
mxSetField (out_struct, 0, SRSWkt, mxPrjRef);
}
}
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Selon Ole Nielsen ole.moller.niel...@gmail.com: Thanks - I was hoping I could rely on the library to do the intelligent truncation, but couldn't work it out. Can I just clarify that the name to use with SetField would then be what is provided by your last line? layer_defn.GetFieldDefn(last_field_idx).GetNameRef() Yes Cheers and thanks Ole On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault even.roua...@mines-paris.orgwrote: Selon Ole Nielsen ole.moller.niel...@gmail.com: Hi Even Thanks again for all your help - all tests now pass using either gdal 1.6 or 1.8. Just to summarise, there were three issues as I see them: 1. Bounding boxes for raster data are computed differently (but better) in newer versions Specific to PixelIsPoint in the GTiff driver. 2. While v1.6 of ogre would allow an single number of type numpy.ndarray this is no longer allow. Casting it to a float solves the problem. I wasn't aware it could work before. There's perhaps now an ambiguity on which method to use, due to the addition of new possibilities for SetField() (just a bling guess). 3. New versions of ogre will not allow attribute names of length longer than 10 (at least when using the ESRI driver). Formerly, I think it silently truncated, now it is up to the user. That's at least what I did. I've a looked quickly a bit at your code and I've the feeling that you truncate yourself, instead of relying on OGR. The Shapefile driver does more than truncating. It also ensures uniqueness of the truncated names. For example, if you try creating a_very_long_name and a_very_long_name_again, they will be respectively truncated to a_very_lon and a_very_l_1. A safer solution to get the field name that got to the file would be to : field_defn = ogr.FieldDefn(a_very_long_name, ogr.OFTString) lyr.CreateField(field_defn) layer_defn = lyr.GetLayerDefn() last_field_idx = layer_defn.GetFieldCount() - 1 real_field_name = layer_defn.GetFieldDefn(last_field_idx).GetNameRef() ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR_G_ExportToWkt make MEX crash
On 11-09-06 08:10 AM, Joaquim Luis wrote:
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many cases.
However, I had a situation when trying to fetch the reference info. The chunk
of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than Matlab crashes at that line. However, using the OSRExportTo... functions
works fine.
I'm I doing something forbidden or ...
...
hSRS = OGR_L_GetSpatialRef(hLayer); /* Do not free it later */
if (hSRS) {
char *pszWKT = NULL, *pszProj4 = NULL;
mxArray *mxPrjRef;
/*OGR_G_ExportToWkt (hSRS, pszWKT); */ == THIS CALL MAKE THE MEX CRASH
if (OSRExportToProj4(hSRS, pszProj4) == OGRERR_NONE) {
Joaquim,
OGR_G_* functions are intended to operate on OGRGeometry objects while
OSR* functions operate on OGRSpatialReferences. Your hSRS object is an
OGRSpatialReference and not suitable to pass to OGR_G_ExportToWkt().
You should use OSRExportToWkt() to translate an OGRSpatialReference into it's
WKT representation.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/warmerda
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] AW: ESRI products have problems reading gdal spatialreference entry
On 11-09-06 12:54 AM, Schmitz, Uwe wrote: On 05/09/2011 16:03, Schmitz, Uwe wrote: My understanding of Frank's answer is that this is basically not possible. thanks for the link. It clarifies the problem but is unsatisfactory. I must have missed this thread beforehand, maybe due to the subject ;-) So if I conclude: ESRI and GDAL have different WKT formats. It is not possible to write GeoTIFF files which are fully ESRI *and* GDAL compatible. Uwe, I do not agree with this conclusion! However, it is difficult to produce a GeoTIFF file that will exactly preserve and ESRI Project Engine string (ie. ESRI WKT) while at the same time being fully compatible with all other software. The issues are primarily around limits of the GeoTIFF format, and to some extend somewhat incomplete code implementations in GDAL / ArcGIS. A workaround may be to use ArcGIS's GDAL support for GeoTIFF. I am not sure what this means exactly. ArcGIS now always uses GDAL for reading and writing GeoTIFF. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/warmerda and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR_G_ExportToWkt make MEX crash
OGR_G_* functions are intended to operate on OGRGeometry objects while OSR* functions operate on OGRSpatialReferences. Your hSRS object is an OGRSpatialReference and not suitable to pass to OGR_G_ExportToWkt(). You should use OSRExportToWkt() to translate an OGRSpatialReference into it's WKT representation. Best regards, Thanks Frank. This is also a result of my attempt to understand all the OGR model plus inventing a way of wrapping it all inside a single StructureArray (the C-MEX API). So let me ask one further question about the model. Is is possible to have the case Dataset -- SRS -- Feature1 -- Geom1 -- SRS1 -- Feature2 -- Geom2 -- SRS2 -- ... that is, different SpatialReferences inside the same Dataset? Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] using GDALGridCreate in python?
Hi Even, you mentioned in your previous email that the GDALGridCreate() fcn has only been mapped to Java bindings (I am assuming this is already the case for the the latest stable (1.8.1) release)? If so, can you point me to the interface file in which this is implemented? Doing a find/grep i could not find it. thanks matt On 9/1/2011 10:10 AM, Matt Funk wrote: Hi, i got a question on using the gdal_grid utility: My input file looks like: lat,lon,data 24.007521,-114.111420,-0.078077 24.003864,-114.064293,-0.017523 24.000221,-114.017540,-0.069692 23.996593,-113.971153,-0.014572 23.992981,-113.925117,-0.032931 23.989380,-113.879440,-0.068089 23.985794,-113.834114,-0.027493 23.982224,-113.789124,-0.046154 23.978666,-113.744476,-0.073945 23.975121,-113.700165,-0.072757 23.971590,-113.656174,-0.048775 ... 3.034852,-96.767853,0.459120 3.028167,-96.727135,0.649308 3.021430,-96.686111,0.994770 3.014640,-96.644768,1.085215 3.007797,-96.603119,1.350796 3.000899,-96.561142,1.879670 2.993942,-96.518822,1.470742 I use gdal_grid: C:\software\gdal\gdalwin32-1.6\bin\gdal_grid.exe -a invdist:power=2.0:smoothing=1.0 -txe 2 24 -tye -117 -92 -outsize 50 50 -of GTiff -ot Float64 -l dust_t1735 dust_t1735.vrt dust_t1735.tiff The tiff file is generated, but when i try to open it, but i cannot open it and the file is somehow corrupted. For the experts on this utility, am i doing something obviously wrong? thanks matt On 8/30/2011 3:04 PM, Even Rouault wrote: Le mardi 30 août 2011 22:57:34, Matt Funk a écrit : On 8/30/2011 1:39 PM, Even Rouault wrote: Le mardi 30 août 2011 21:28:11, Matt Funk a écrit : Hi, i have several satellite scenes which basically give me 3 vectors: lat/lon/data which is on an irregular. I would like to interpolate those onto a regular grid. I found that GDALGridCreate would meet my need except that i am developing in python, but it appears the bindings for it don't exist (unless i am mistaken). So my question is whether someone knows of an alternative route to accomplish this or whether i am possible wrong in that i cannot use GDALGridCreate in python? Yes, you cannot use GDALGridCreate() in python. It has only been mapped to Java bindings for now. You can as a workaround for a process with the gdal_grid utility. I have never used the gdal_grid utility. Outside of its manpage (http://www.gdal.org/gdal_grid.html) i haven't found any usage examples. That's already a beginning ;-) As far as inputs are concerned it talks about csv file. Are there other input formats. All OGR supported formats : http://gdal.org/ogr/ogr_formats.html Also, this might be a dumb question, but would it be of any value to call the compiled c-gdal library directly from my python code? Possibly, but someone has to code the missing python swig typemaps however. matt thanks matt ___ 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 -- Matt Funk Research Associate Plant and Environmental Scienc. Dept. New Mexico State University ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR_G_ExportToWkt make MEX crash
On Tue, Sep 6, 2011 at 8:48 AM, Joaquim Luis jl...@ualg.pt wrote: OGR_G_* functions are intended to operate on OGRGeometry objects while OSR* functions operate on OGRSpatialReferences. Your hSRS object is an OGRSpatialReference and not suitable to pass to OGR_G_ExportToWkt(). You should use OSRExportToWkt() to translate an OGRSpatialReference into it's WKT representation. Best regards, Thanks Frank. This is also a result of my attempt to understand all the OGR model plus inventing a way of wrapping it all inside a single StructureArray (the C-MEX API). So let me ask one further question about the model. Is is possible to have the case Dataset -- SRS -- Feature1 -- Geom1 -- SRS1 -- Feature2 -- Geom2 -- SRS2 -- ... that is, different SpatialReferences inside the same Dataset? Joaquim, While not nailed down strictly, it is expected that all geometries in a layer will share the same coordinate system. It is however common for the geometries to be lacking the spatial reference object even though it is set on the layer. 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] using GDALGridCreate in python?
Le mardi 06 septembre 2011 18:25:04, Matt Funk a écrit : Hi Even, you mentioned in your previous email that the GDALGridCreate() fcn has only been mapped to Java bindings (I am assuming this is already the case for the the latest stable (1.8.1) release)? If so, can you point me to the interface file in which this is implemented? Doing a find/grep i could not find it. Yes, it is included in 1.8.1. You'll find it in swig/include/Operations.i ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] adding georeferencing information
On 5 September 2011 15:46, Jan Hartmann j.l.h.hartm...@uva.nl wrote: Is there a quick way to add back georeferencing information to a geotif file that has been processed by Imagemagick? There should be an applygeo utility distributed with the geotiff library which can do this. Andrew ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny
On Fri, Sep 02, 2011 at 10:42:16PM +0200, Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny +1 -- Andrey V. Kiselev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] adding georeferencing information
Is there a quick way to add back georeferencing information to a geotif file that has been processed by Imagemagick? also see http://code.google.com/p/maphew/source/browse/gis/gdal_extras/bin/gdalcopyproj.py cheers, matt wilkie Geomatics Analyst 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/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unicode support in OGR Shape/DBF
Le mardi 06 septembre 2011 19:42:18, Hilda Villegas a écrit : Hi, I'm trying to use the preliminary encoding support for shapefile/dbf as you said in the Ticket #882, SHAPE_ENCODING configuration variable can be used to override the interpretation, but I cannot find the valid values for this SHAPE_ENCODING anywhere, What value should I use if I want to write Unicode characters (UTF-8) in the DBF? To overrite the encoding when *writing*, you should the ENCODING layer creation option : ogr2ogr out.shp indatasource -lco ENCODING=UTF-8 Note: in that case, the encoding of the input datasource must be already encoded in UTF-8, which is the pivot encoding for OGR. The effect of -lco ENCODING=UTF-8 will be essentially to write a .cpg file with UTF-8 as its content. Apart from using a value of the form LDID/a_numeric_value where a_numeric_value is a value in the first column of table 9 of http://www.autopark.ru/ASBProgrammerGuide/DBFSTRUC.HTM (from 1 to 204), it is not entirely clear which other values are valid for the ENCODING parameter to have interoperability with other systems. The SHAPE_ENCODING configuration option/environment variable is to be used when you want to override the encoding indicated in the .dbf/.cpg file when reading a shapefile. It can be set to any valid value recognized by the iconv library, whose list you can get with iconv -l on a system with iconv binaries installed. In that case, OGR will recode from SHAPE_ENCODING to UTF-8. If you want no recoding to happen, you can set SHAPE_ENCODING=. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] New PHP bindings - php5-gdal
Hi, I have update the license of php5-gdal to the same as GDAL (I copied the license block). The project website is: http://projects.geonef.fr/projects/php5-gdal/wiki If you want to add a link to http://trac.osgeo.org/gdal/#GDALOGRInOtherLanguages, the project is ready for it. Regards, Jean-François Gigand - Geonef Paris, France - http://geonef.fr/ 2011/8/9 Jean-François Gigand j...@geonef.fr: Hi Thomas, I actually noticed that initiative 2 days ago by searching the ML, posts dated from around March. If I had seen them on that time, I would have shared my code earlier. I never used SWIG. When I wondered in last December if I should leverage SWIG or write a C++ PHP extension, I chose the latter when I noticed that the PHP SWIG bindings in GDAL were very old. I was also encouraged when I noticed that for MapServer, the PHP MapScript extension is written in core C, although they use SWIG for some other languages like Python. Mike Leahy, have you got anything working with the SWIG bindings? Since you know SWIG, what do you think about this choice? Jean-François Gigand - Geonef Paris, France - http://geonef.fr/ 2011/8/9 Tamas Szekeres szeker...@gmail.com: 2011/8/9 Jean-François Gigand j...@geonef.fr I decided to write this library when I got limited at using OGR/PHP (segfault crash) and noticed the latter has not been maintained for years. After trying to compile the SWIG bindings with no success, I thought a good robust C++ code would be the best deal for providing OOP interfaces to PHP. Hi Jean, I just wanted to mention, there have been some efforts recently by Mike Leahy to resurrect the php bindings, the corresponding ticket can be found here: http://trac.osgeo.org/gdal/ticket/3984 However I'm not sure about the current status of this work and how the bindings work with the attached patches. Do you have experiences? Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] NetCDF and datum handling suggestion
On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny etiennesky@gmail.com wrote: Patrick, A) your suggestion does make sense, it is imperial that basic datum information be saved as to adhere to CF-x standard. Are those CF variables (radius, flattening etc) really sufficient for software such as THREDDS? Yes, tests I did showed it was able to project correctly after adding these (whereas beforehand the WMS layers were off - presumably TDS assumes a spherical earth by default). The datum attributes are highlighted in color at CF conventions website, in the table at the end of the page: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/apf.html B) The other aspect (to save projection_ref so that GDAL can import it) also makes sense, however I have the following concern: If another software changes the datum and or projection information of a netcdf file created by GDAL, but keeps the GDAL 'spatial_ref' tag intact, then GDAL would import the wrong projection. I don't think that this should happen, as a program would be expected to write a new grid_mapping variable, without the GDAL tags. Can you think of possible software which does this and make a test? I can only think of CDO, and I do know that it discards anything from a previous projection definition. I can't think of any software that does this off the top of my head either ... though we've been looking into a NetCDF driver for the Geotoolkit project, which may be able to reproject existing NetCDF datasets. In any case GDAL should probably print a warning if the 2 get 'out of sync' when it imports? C) With that concern in mind,I was wondering if we can do one of the following instead: 1) import the standard CF variables and guess the WKT from that 2) just be content with the basic DATUM values from the CF variables for example, here is what a wkt looks like when importing a CF netcdf file wich a WGS84 datum: GEOGCS[unknown, DATUM[unknown, SPHEROID[Spheroid,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] and here is the full WGS84 WKT generated by GDAL GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] As you can see, the important values are there, but there are no descriptive names and EPSG authority. This is not strictly identified as WGS84 EPSG datum, but the important stuff is there. I thought about this too ... it does seem a bit concerning though to try and recognise the named datums from the values - possibly you'd have issues of the accuracy they are stored at determining whether GDAL could recognise them correctly or not? I've heard there may be a 'dynamic datum' in development that has its values adjusted more frequently - in this case referencing a standard name would likely be necessary. Having checked the GDAL NetCDF format page though, it does check the CF encoded projection before it's own WKT, so it'd be good if we could consistently use CF as first reference for the datum too. D) I doubt that the CF conventions have plans to support PROJ.4/WKT in the near future. Have a look at the draft for CF-1.6, nothing new about PROJ.4 or WKT : http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#grid-mappings-and-projections However, I would suggest to discuss this on the CF mailing list. They might be receptive, as they already make references to PROJ.4 in their projection definitions. BUT it would be better in this case to use PROJ.4 strings instead of WKT, as (I think) that PROJ.4 strings are better supported than WKT (including Proj.4 itself). For example, the folks that work on CDO have plans to support PROJ.4 strings, but now WKT. Thanks, I'll need to read up a bit more on Proj.4 strings but sounds like it could be a good way to go. I just had a bit more of a look around the CF webpages and they did consider putting more CRS information in the specs, e.g. a crs_id attribute that could contain an EPSG code, but it didn't make it through as yet: https://cf-pcmdi.llnl.gov/trac/wiki/GridMappingAndCrs https://cf-pcmdi.llnl.gov/trac/ticket/18 So yes discussing this on their mailing list again sounds like a good idea. Am I correct in thinking that GDAL could output a PROJ.4 string and import it in the same manner that it currently does with WKT? Not sure - clearly you can specify Proj4 from the command line to commands, but not sure you can ask it to store this, will do some checking. BTW, there is a CF-NetCDF 1.0 Standards Working Group part of OGC, perhaps we can discuss with someone from that group? http://www.opengeospatial.org/projects/groups/cf-netcdf1.0swg Yes, sounds like a good idea. We actually read through the OGC standards on NetCDF recently, the basic standard already accepted really just
Re: [gdal-dev] NetCDF and datum handling suggestion
On Tue, Sep 6, 2011 at 8:31 PM, Patrick Sunter patdeve...@gmail.com wrote: On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny etiennesky@gmail.com wrote: Patrick, A) your suggestion does make sense, it is imperial that basic datum information be saved as to adhere to CF-x standard. Are those CF variables (radius, flattening etc) really sufficient for software such as THREDDS? Yes, tests I did showed it was able to project correctly after adding these (whereas beforehand the WMS layers were off - presumably TDS assumes a spherical earth by default). good The datum attributes are highlighted in color at CF conventions website, in the table at the end of the page: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/apf.html B) The other aspect (to save projection_ref so that GDAL can import it) also makes sense, however I have the following concern: If another software changes the datum and or projection information of a netcdf file created by GDAL, but keeps the GDAL 'spatial_ref' tag intact, then GDAL would import the wrong projection. I don't think that this should happen, as a program would be expected to write a new grid_mapping variable, without the GDAL tags. Can you think of possible software which does this and make a test? I can only think of CDO, and I do know that it discards anything from a previous projection definition. I can't think of any software that does this off the top of my head either ... though we've been looking into a NetCDF driver for the Geotoolkit project, which may be able to reproject existing NetCDF datasets. In any case GDAL should probably print a warning if the 2 get 'out of sync' when it imports? How could we know if it is 'out of sync'? My feeling is that it's ok to assume that any software that messes with the projection info will delete any custom tags, but still safer to use as much standard information as possible, and stay away from GDAL tags when possible. C) With that concern in mind,I was wondering if we can do one of the following instead: 1) import the standard CF variables and guess the WKT from that 2) just be content with the basic DATUM values from the CF variables for example, here is what a wkt looks like when importing a CF netcdf file wich a WGS84 datum: GEOGCS[unknown, DATUM[unknown, SPHEROID[Spheroid,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] and here is the full WGS84 WKT generated by GDAL GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] As you can see, the important values are there, but there are no descriptive names and EPSG authority. This is not strictly identified as WGS84 EPSG datum, but the important stuff is there. I thought about this too ... it does seem a bit concerning though to try and recognise the named datums from the values - possibly you'd have issues of the accuracy they are stored at determining whether GDAL could recognise them correctly or not? I've heard there may be a 'dynamic datum' in development that has its values adjusted more frequently - in this case referencing a standard name would likely be necessary. Having checked the GDAL NetCDF format page though, it does check the CF encoded projection before it's own WKT, so it'd be good if we could consistently use CF as first reference for the datum too. agreed, I propose we stay away from WKT/PROJ.4 when a suitable CF representation exists, and if not fall back to WKT / PROJ.4 - unless it becomes a standard in later CF conventions, which could take time IMHO. D) I doubt that the CF conventions have plans to support PROJ.4/WKT in the near future. Have a look at the draft for CF-1.6, nothing new about PROJ.4 or WKT : http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#grid-mappings-and-projections However, I would suggest to discuss this on the CF mailing list. They might be receptive, as they already make references to PROJ.4 in their projection definitions. BUT it would be better in this case to use PROJ.4 strings instead of WKT, as (I think) that PROJ.4 strings are better supported than WKT (including Proj.4 itself). For example, the folks that work on CDO have plans to support PROJ.4 strings, but now WKT. Thanks, I'll need to read up a bit more on Proj.4 strings but sounds like it could be a good way to go. I just had a bit more of a look around the CF webpages and they did consider putting more CRS information in the specs, e.g. a crs_id attribute that could contain an EPSG code, but it didn't make it through as yet: https://cf-pcmdi.llnl.gov/trac/wiki/GridMappingAndCrs https://cf-pcmdi.llnl.gov/trac/ticket/18 So yes
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Yes this seems to work. However, I get a huge amounts of warnings of the form lyr.CreateField(fd) Warning 6: Normalized/laundered field name: 'A slightly long name' to 'A slightly' 0 They obviously tell what name has been derived, but I don't want this output to clutter, and since that name is already available through your procedure they really should be suppressed. Can that be done? Many thanks Ole On Tue, Sep 6, 2011 at 10:10 PM, Even Rouault even.roua...@mines-paris.orgwrote: Selon Ole Nielsen ole.moller.niel...@gmail.com: Thanks - I was hoping I could rely on the library to do the intelligent truncation, but couldn't work it out. Can I just clarify that the name to use with SetField would then be what is provided by your last line? layer_defn.GetFieldDefn(last_field_idx).GetNameRef() Yes Cheers and thanks Ole On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault even.roua...@mines-paris.orgwrote: Selon Ole Nielsen ole.moller.niel...@gmail.com: Hi Even Thanks again for all your help - all tests now pass using either gdal 1.6 or 1.8. Just to summarise, there were three issues as I see them: 1. Bounding boxes for raster data are computed differently (but better) in newer versions Specific to PixelIsPoint in the GTiff driver. 2. While v1.6 of ogre would allow an single number of type numpy.ndarray this is no longer allow. Casting it to a float solves the problem. I wasn't aware it could work before. There's perhaps now an ambiguity on which method to use, due to the addition of new possibilities for SetField() (just a bling guess). 3. New versions of ogre will not allow attribute names of length longer than 10 (at least when using the ESRI driver). Formerly, I think it silently truncated, now it is up to the user. That's at least what I did. I've a looked quickly a bit at your code and I've the feeling that you truncate yourself, instead of relying on OGR. The Shapefile driver does more than truncating. It also ensures uniqueness of the truncated names. For example, if you try creating a_very_long_name and a_very_long_name_again, they will be respectively truncated to a_very_lon and a_very_l_1. A safer solution to get the field name that got to the file would be to : field_defn = ogr.FieldDefn(a_very_long_name, ogr.OFTString) lyr.CreateField(field_defn) layer_defn = lyr.GetLayerDefn() last_field_idx = layer_defn.GetFieldCount() - 1 real_field_name = layer_defn.GetFieldDefn(last_field_idx).GetNameRef() ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] merging of files with gdalwarp causses a slight shift
Hi All, Merging 2 files with a geographical CRS results in the output being shifted a quarter-pixel to the east and south. The datum is WGS84 (altough not explicitly named), I get the same result if I explicitly set it to WGS84. SImilar data in modis sinusoidal projection gets merged fine with the same command. I am using the following command: gdalwarp -srcnodata 0 -dstnodata 0 -co COMPRESS=LZW MCD45monthly.burndate.Win06.2010-byte.tif MCD45monthly.burndate.Win05.2010-byte.tif MCD45monthly.burndate.sam.2010-Byte.tif Files can be found at: http://www.openclimgeo.org/pub/ Any help would be appreciated! Here is the gdalinfo for the 3 files. Etienne tourigny@supernova: /data/research/work/modis/mcd45/gtiff/out/upload $ gdalinfo MCD45monthly.burndate.Win05.2010-byte.tif Driver: GTiff/GeoTIFF Files: MCD45monthly.burndate.Win05.2010-byte.tif Size is 10923, 5234 Coordinate System is: GEOGCS[, DATUM[unknown, SPHEROID[unnamed,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-81.997802734374957,12.997802734374995) Pixel Size = (0.00439453125,-0.00439453125) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -81.9978027, 12.9978027) ( 81d59'52.09W, 12d59'52.09N) Lower Left ( -81.9978027, -10.0031738) ( 81d59'52.09W, 10d 0'11.43S) Upper Right ( -33.9963379, 12.9978027) ( 33d59'46.82W, 12d59'52.09N) Lower Right ( -33.9963379, -10.0031738) ( 33d59'46.82W, 10d 0'11.43S) Center ( -57.9970703, 1.4973145) ( 57d59'49.45W, 1d29'50.33N) Band 1 Block=10923x1 Type=Byte, ColorInterp=Gray NoData Value=0 tourigny@supernova: /data/research/work/modis/mcd45/gtiff/out/upload $ gdalinfo MCD45monthly.burndate.Win06.2010-byte.tif Driver: GTiff/GeoTIFF Files: MCD45monthly.burndate.Win06.2010-byte.tif Size is 10240, 5689 Coordinate System is: GEOGCS[, DATUM[unknown, SPHEROID[unnamed,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-78.997802734374972,-10.002197265624996) Pixel Size = (0.00439453125,-0.00439453125) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -78.9978027, -10.0021973) ( 78d59'52.09W, 10d 0' 7.91S) Lower Left ( -78.9978027, -35.0026855) ( 78d59'52.09W, 35d 0' 9.67S) Upper Right ( -33.9978027, -10.0021973) ( 33d59'52.09W, 10d 0' 7.91S) Lower Right ( -33.9978027, -35.0026855) ( 33d59'52.09W, 35d 0' 9.67S) Center ( -56.4978027, -22.5024414) ( 56d29'52.09W, 22d30' 8.79S) Band 1 Block=10240x1 Type=Byte, ColorInterp=Gray NoData Value=0 tourigny@supernova: /data/research/work/modis/mcd45/gtiff/out/upload $ gdalinfo MCD45monthly.burndate.sam.2010-Byte.tif Driver: GTiff/GeoTIFF Files: MCD45monthly.burndate.sam.2010-Byte.tif Size is 10923, 10923 Coordinate System is: GEOGCS[, DATUM[unknown, SPHEROID[unnamed,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-81.997802734374957,12.997802734374995) Pixel Size = (0.00439453125,-0.00439453125) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -81.9978027, 12.9978027) ( 81d59'52.09W, 12d59'52.09N) Lower Left ( -81.9978027, -35.0036621) ( 81d59'52.09W, 35d 0'13.18S) Upper Right ( -33.9963379, 12.9978027) ( 33d59'46.82W, 12d59'52.09N) Lower Right ( -33.9963379, -35.0036621) ( 33d59'46.82W, 35d 0'13.18S) Center ( -57.9970703, -11.0029297) ( 57d59'49.45W, 11d 0'10.55S) Band 1 Block=10923x1 Type=Byte, ColorInterp=Gray NoData Value=0 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] merging of files with gdalwarp causses a slight shift
On 11-09-06 06:05 PM, Etienne Tourigny wrote: Hi All, Merging 2 files with a geographical CRS results in the output being shifted a quarter-pixel to the east and south. The datum is WGS84 (altough not explicitly named), I get the same result if I explicitly set it to WGS84. SImilar data in modis sinusoidal projection gets merged fine with the same command. I am using the following command: gdalwarp -srcnodata 0 -dstnodata 0 -co COMPRESS=LZW MCD45monthly.burndate.Win06.2010-byte.tif MCD45monthly.burndate.Win05.2010-byte.tif MCD45monthly.burndate.sam.2010-Byte.tif Files can be found at: http://www.openclimgeo.org/pub/ Any help would be appreciated! Here is the gdalinfo for the 3 files. Etienne, As far as I can see the two input files (Win05 and Win06) are not sampled on the same grid even though they have the same pixel size. For instance comparing the offsets of the top left X positions we see they are not an even number of pixels apart: (-81.997802734374957 - -78.997802734374972) / 0.00439453125 -682.666345 When gdalwarp creates the output file it picks an extent and pixel size to capture all the input files and preserve essentially the same pixel size. In this case the pixel size seems to be preserved but by definition the sampling grid can't match both files so one ends up being resampled. So, things are working as intended. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/warmerda and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny
Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny I declare this motion passed with support from PSC members AndreyK, DanielM, EvenR, FrankW and TamasS and with non-PSC member Kyle Shannon. Etienne, I'll let Frank deal with the practical details to enable you as a committer. Welcome aboard ! Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: NotImplementedError: Wrong number of arguments for overloaded function 'Feature_SetField'.
Le mercredi 07 septembre 2011 02:36:35, Ole Nielsen a écrit :
Yes this seems to work. However, I get a huge amounts of warnings of the
form
lyr.CreateField(fd)
Warning 6: Normalized/laundered field name: 'A slightly long name' to 'A
slightly'
0
They obviously tell what name has been derived, but I don't want this
output to clutter, and since that name is already available through your
procedure they really should be suppressed. Can that be done?
Yes, you can surround the CreateField() call with :
gdal.PushErrorHandler('CPLQuietErrorHandler')
...
gdal.PopErrorHandler()
Many thanks
Ole
On Tue, Sep 6, 2011 at 10:10 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Ole Nielsen ole.moller.niel...@gmail.com:
Thanks - I was hoping I could rely on the library to do the intelligent
truncation, but couldn't work it out.
Can I just clarify that the name to use with SetField would then be
what
is
provided by your last line?
layer_defn.GetFieldDefn(last_field_idx).GetNameRef()
Yes
Cheers and thanks
Ole
On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Ole Nielsen ole.moller.niel...@gmail.com:
Hi Even
Thanks again for all your help - all tests now pass using either
gdal
1.6
or
1.8. Just to summarise, there were three issues as I see them:
1. Bounding boxes for raster data are computed differently (but
better)
in newer versions
Specific to PixelIsPoint in the GTiff driver.
2. While v1.6 of ogre would allow an single number of type
numpy.ndarray
this is no longer allow. Casting it to a float solves the
problem.
I wasn't aware it could work before. There's perhaps now an ambiguity
on
which
method to use, due to the addition of new possibilities for
SetField() (just a
bling guess).
3. New versions of ogre will not allow attribute names of length
longer
than 10 (at least when using the ESRI driver). Formerly, I think
it
silently
truncated, now it is up to the user. That's at least what I did.
I've a looked quickly a bit at your code and I've the feeling that
you truncate
yourself, instead of relying on OGR. The Shapefile driver does more
than
truncating. It also ensures uniqueness of the truncated names. For
example,
if
you try creating a_very_long_name and a_very_long_name_again,
they
will
be
respectively truncated to a_very_lon and a_very_l_1. A safer
solution
to get
the field name that got to the file would be to :
field_defn = ogr.FieldDefn(a_very_long_name, ogr.OFTString)
lyr.CreateField(field_defn)
layer_defn = lyr.GetLayerDefn()
last_field_idx = layer_defn.GetFieldCount() - 1
real_field_name =
layer_defn.GetFieldDefn(last_field_idx).GetNameRef()
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Small issue at OGR_G_GetCoordinateDimension doc
Le mercredi 07 septembre 2011 01:48:09, Joaquim Luis a écrit : Hi The doc of OGR_G_GetCoordinateDimension states at http://www.gdal.org/ogr/ogr__api_8h.html#8a5e78b0753339d1cdd282b0e151d28f that ... Returns: in practice this always returns 2 indicating that coordinates are specified within a two dimensional space. but that's not true as I just confirmed with the autotest multipatch.shp example file, where it returns 3 as it should because vectors are 3D. Fixed. Thanks. Joaquim ___ 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] NetCDF and datum handling suggestion
In case you feel like testing it, the functions needed are OGRSpatialReference::importFromProj4() and exportToProj4(), the later which is not documented. Perhaps others can comment on the suitability of exporttoProj4() ??? It is documented but doxygen didn't like a macro that was inserted between the comment and the function. Should be fixed by r23070 I'd note that proj4 strings have not all the expressivity of WKT. In particular they cannot capture citation strings, or authority name and code. So the suitability of using them depends on what you want to do with them. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
