[gdal-dev] Exporting from GML to DXF
Hi, I like testing the capabilities of GDAL/OGR to export from a GML to a DXF. I create a very simple file header.dxf and ask to OGR to export a test file GML to dxf. The file header.dxf I create has simply this 4 rows: --- 0 SECTION 2 HEADER --- But when I start ogr2ogr it stop with an error reporting unable to more than one OGR layer in a dxf file. of course my GML has more then one layer :( But I don't understand if this a limit of the dxf driver or is a bug in my too simple header.dxf file. Many thx, Andrea. -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Handling CPG (encoding) file
Even, re use case 1) below. One instance where the raw data format might be required is where that encoding contains characters that are not present in an output encoding and specific action is to be taken to render such characters in a transmittable form in the output character set. Best wishes, Peter Even Rouault wrote: Alexander, I'm cc'ing Gaige Paulsen as he proposed in http://trac.osgeo.org/gdal/ticket/3403 a patch with a similar approach to yours, that is to say provide a method at the OGRLayer level to return the encoding. The more I think to this issue the more I recognize that the UTF-8 everywhere internally is probably not practical in all situations, or at least doesn't let enough control to the user. The UTF-8 as a pivot is - conceptually - OK for the read part, but it doesn't help for the write part when a driver doesn't support UTF-8 (or if for some compatibility reasons with other software, we must write data in a certain encoding) My main remark about your patch is I don't believe that the enum approach to list the encodings is the best one. I'd be rather in favor of using a string, and possibly sticking to the ones returned by 'iconv -l' so that we can easily use the return of GetEncoding() to feed it into the converter through CPLRecode(). I've experimented with it some time ago and have ready some changes in cpl_recode_stub.cpp configure to plug iconv support into it, in order to extend its scope beyond the current hardcoded support for UTF8 and ISO-8859-1. We could imagine a -s_encoding, -t_encoding and -a_encoding switches to ogr2ogr to let the user define the transcoding or encoding assignment. One of the difficulty raised by Gaige in #3403 is the meaning of the width attribute of an OGRFieldDefn object (number of bytes or number characters in a given encoding), and how/if it will be affected by an encoding change. The other issues raised by Gaige in his last comment are still worth considering. For the read part, what do we want ? : 1) that the driver returns the data in its raw encoding and mentions the encoding -- matches the approach of your proposal 2) that we ask it to return the data to UTF-8 when we don't care about the data in its source encoding 3) that we can override its encoding when the source encoding is believed to be incorrect so that 2) can work properly 1) and 2) approach are clearly following 2 differents tracks. One way to reconcile both would be to provide some configuration/opening option to choose which behaviour is prefered. RFC23 currently chooses 2) as it mandates that Any driver which knows it's encoding should convert to UTF-8. Well, probably not a big deal since that any change related to how we deal with encoding is likely to cause RFC23 to be amended anyway. Personnaly, I'm not sure about which one is the best. I'm wondering what the use cases for 1) are : when do we really want the data to be returned in its source encoding -- will not be it converted later to UTF-8 at the application level after the user has potentially selected/overriden the source encoding ? In which case 3) would solve the problem. Just thinking loud... For the write part, a OGRSFDriver::GetSupportedEncodings() and OGRLayer::SetEncoding() could make sense (for the later, if it must be exposed at the datasource or layer level is an open point and a slight difference between yours and Gaige's approach) Best regards Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 433806 Fax: 01904 433740 Snail mail: Computing Service, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] export SDO to SHP?
Hi list, is it possile to import and SDO table into a shape file using ogr2ogr? regards, Imran -- I.R ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
AW: [gdal-dev] Create gdaldataset from in-memory Image/Bitmap/byte[]/MemoryStream
Tamas, I just went through the gdal 1.7 release notes, and read that a function 'FileFromMemBuffer' was added to the csharp bindings. Since I'm getting image blobs from an sqlite database (png), is it a suitable way to use that function? Thanks Felix Obermaier -- Ingenieurgruppe IVV GmbH Co. KG Dipl.-Ing. Felix Obermaier Oppenhoffallee 171 52066 Aachen Telefon: +49 (241) 94691-39 Telefax: +49 (241) 531622 eMail: o...@ivv-aachen.demailto:o...@ivv-aachen.de Internet: http://www.ivv-aachen.de Sitz der Gesellschaft: Aachen Amtsgericht Aachen HRA 6212 GF: Bauassessor Dr.-Ing. Dieter Hölsken IVV-Management GmbH Amtsgericht Aachen HRB 12543 Von: Tamas Szekeres [mailto:szeker...@gmail.com] Gesendet: Donnerstag, 20. Mai 2010 23:03 An: Felix Obermaier Cc: gdal-dev@lists.osgeo.org Betreff: Re: [gdal-dev] Create gdaldataset from in-memory Image/Bitmap/byte[]/MemoryStream Felix, You can find examples in the gdal source tree about creating a dataset and write data by using the WriteRaster method: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALWrite.cs http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALDatasetWrite.cs For more information about the raster IO operations in C# see: http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpRaster Best regards, Tamas 2010/5/20 Felix Obermaier o...@ivv-aachen.demailto:o...@ivv-aachen.de Hello list, I'm using GDAL via swig C# bindings. Is there a way to create a gdal dataset object from an in-memory Image/Bitmap/byte[]/MemoryStream, and if so, how can I achive this. Thanks in advance Felix Obermaier -- Ingenieurgruppe IVV GmbH Co. KG Dipl.-Ing. Felix Obermaier Oppenhoffallee 171 52066 Aachen Telefon: +49 (241) 94691-39 Telefax: +49 (241) 531622 eMail: obe_at_ivv-aachen.dehttp://obe_at_ivv-aachen.de Internet: http://www.ivv-aachen.de Sitz der Gesellschaft: Aachen Amtsgericht Aachen HRA 6212 GF: Bauassessor Dr.-Ing. Dieter Hölsken IVV-Management GmbH Amtsgericht Aachen HRB 12543 ___ gdal-dev mailing list gdal-dev@lists.osgeo.orgmailto: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] export SDO to SHP?
Imran, If SDO means Oracle Spatial format, you can refer to ( http://www.gdal.org/ogr/ogr_formats.html) and ( http://www.gdal.org/ogr/drv_oci.html) for formats and ( http://www.gdal.org/ogr_utilities.html) for tools. On Wed, May 26, 2010 at 12:23 PM, Imran Rajjad raj...@gmail.com wrote: Hi list, is it possile to import and SDO table into a shape file using ogr2ogr? regards, Imran -- I.R ___ 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-9848167848 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] export SDO to SHP?
ogr2ogr -f ESRI Shapefile some_shapefile.shp OCI:user/p...@tns:schema.table_name Will do just that. Mike -- Michael Smith US Army Corps of Engineers Remote Sensing/GIS Center Hanover, NH On 5/26/10 1:53 AM, Imran Rajjad raj...@gmail.com wrote: Hi list, is it possile to import and SDO table into a shape file using ogr2ogr? regards, Imran ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] export SDO to SHP?
El día Wednesday 26 May 2010 08:53:54, Imran Rajjad dijo: is it possile to import and SDO table into a shape file using ogr2ogr? http://www.gdal.org/ogr/drv_oci.html -- Iván Sánchez Ortega i...@sanchezortega.es Un ordenador no es una televisión ni un microondas: es una herramienta compleja. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] All that code in apps is a bit of waste of effort
Folks, There are already quite many applications in the apps folder. Many of them contain methods, which could be of more general use than just that one command line app. I'm specifically thinking about gdaldem now. It would be cool to have its methods available more broadly and through the FFI (also sometimes called swig bindings). Then I could have those methods easily available in a GUI :) gdaldem is a bit complex example as it defines four new classes, but still. Best regards, Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OTB/Monteverdi tutorial at IGARSS 2010
Dear all, Those of you who will be attending IGARSS 2010 (July 25-30 in Honolulu) may be interested in the following tutorial: HD-2: Pragmatic Remote Sensing: A Hands-on Approach to Processing (http://www.igarss10.org). It will be given on Sunday, July 25, 08:30 - 12:30 and will present in detail the different steps of a general remote sensing image processing chain through a hands-on approach. The free and open source software Monteverdi (user friendly application based on the Orfeo Toolbox) will be used for the work. Orfeo Toolbox and Monteverdi (http://www.orfeo-toolbox.org) rely heavily on other open source projects, such as gdal, ossim and others, to provide processing capabilities for satellite images. Best regards, Emmanuel Christophe ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Handling CPG (encoding) file
Even, Thanks for bringing this to my attention. We're winding down a major release here (hence my relative absence from the mailing list except as a lurker with occasional comments), but this issue is one I wanted to revisit this summer. Snips and comments below On May 25, 2010, at 7:31 PM, Even Rouault wrote: Alexander, I'm cc'ing Gaige Paulsen as he proposed in http://trac.osgeo.org/gdal/ticket/3403 a patch with a similar approach to yours, that is to say provide a method at the OGRLayer level to return the encoding. The more I think to this issue the more I recognize that the UTF-8 everywhere internally is probably not practical in all situations, or at least doesn't let enough control to the user. The UTF-8 as a pivot is - conceptually - OK for the read part, but it doesn't help for the write part when a driver doesn't support UTF-8 (or if for some compatibility reasons with other software, we must write data in a certain encoding) My main remark about your patch is I don't believe that the enum approach to list the encodings is the best one. I'd be rather in favor of using a string, and possibly sticking to the ones returned by 'iconv -l' so that we can easily use the return of GetEncoding() to feed it into the converter through CPLRecode(). I've experimented with it some time ago and have ready some changes in cpl_recode_stub.cpp configure to plug iconv support into it, in order to extend its scope beyond the current hardcoded support for UTF8 and ISO-8859-1. I agree with using strings instead of enums for this. We could imagine a -s_encoding, -t_encoding and -a_encoding switches to ogr2ogr to let the user define the transcoding or encoding assignment. One of the difficulty raised by Gaige in #3403 is the meaning of the width attribute of an OGRFieldDefn object (number of bytes or number characters in a given encoding), and how/if it will be affected by an encoding change. The other issues raised by Gaige in his last comment are still worth considering. For the read part, what do we want ? : 1) that the driver returns the data in its raw encoding and mentions the encoding -- matches the approach of your proposal 2) that we ask it to return the data to UTF-8 when we don't care about the data in its source encoding 3) that we can override its encoding when the source encoding is believed to be incorrect so that 2) can work properly I still think that UTF-8 as a pivot makes sense and works well for most cases (we tend to use it internally as well). And, mostly I prefer the use of #3. I was specifically looking at these different problems: - Situations where a format handles multiple encodings, but the encoding in the file being read is either ambiguous or incorrect. - Situations where there is a need to determine which of multiple encodings to use (sometimes necessary for compatibility reasons) - Situations where storage space is very tight and field width must be intelligently degraded 1) and 2) approach are clearly following 2 differents tracks. One way to reconcile both would be to provide some configuration/opening option to choose which behaviour is prefered. RFC23 currently chooses 2) as it mandates that Any driver which knows it's encoding should convert to UTF-8. Well, probably not a big deal since that any change related to how we deal with encoding is likely to cause RFC23 to be amended anyway. Personnaly, I'm not sure about which one is the best. I'm wondering what the use cases for 1) are : when do we really want the data to be returned in its source encoding -- will not be it converted later to UTF-8 at the application level after the user has potentially selected/overriden the source encoding ? In which case 3) would solve the problem. Just thinking loud... I think 3 could well solve the problem here. The only downside that I see is that it might make implementation of auto-detection difficult if someone were to attempt to do that in a manner that not everyone agreed on.However, the cases that I see above would be resolved by #3. For the write part, a OGRSFDriver::GetSupportedEncodings() and OGRLayer::SetEncoding() could make sense (for the later, if it must be exposed at the datasource or layer level is an open point and a slight difference between yours and Gaige's approach) Is there a need for a per-layer approach to this? I've yet to see a format that allowed different encodings in different layers. Although, thinking about it, it might be a problem using some of the virtual data sets, since they hide some of this. -Gaige ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Getting private Metadata from Geotiff Images
Hey, I am a little bit new to GDAL and came across a problem. I am the C# wrapper of GDAL and I am needing to get specific metadata such as ModelTiepointTag, ModelPixelScaleTag and a few more. I have tried using the getmetadata( ) method as well as the getmetadataitem( ) method, but no luck. I was wondering If anyone else has gone through this problem and if so how did you resolve it? Any help would be greatly appreciated, Thanks. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Getting-private-Metadata-from-Geotiff-Images-tp5103966p5103966.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] Re: Modify virtual file attributes
I noticed that in current trunk version SetScale and SetOffset methods are present for the API of gdal.Band in Python bindings. As reported in ticket num. 3587: [...] With [19412] SetScale and SetOffset methods are added. When SetUnitType method will be added too, this ticket could be considered as solved. If also SetUnitType method will be added, a backport should be wonderful :) . Best regards -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Modify-virtual-file-attributes-tp5074120p5103992.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] Getting private Metadata from Geotiff Images
radioheadCDA wrote: Hey, I am a little bit new to GDAL and came across a problem. I am the C# wrapper of GDAL and I am needing to get specific metadata such as ModelTiepointTag, ModelPixelScaleTag and a few more. I have tried using the getmetadata( ) method as well as the getmetadataitem( ) method, but no luck. I was wondering If anyone else has gone through this problem and if so how did you resolve it? Any help would be greatly appreciated, Thanks. Chris, These geotiff tags are not directly accessable through GDAL. Instead they are transformed into the corresponding GDAL datastructures like geotransform or GCPs depending on the exact tags. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Getting private Metadata from Geotiff Images
Thanks! That is a lot of help. Does that mean I can call the geotransform method to access the private metadata information? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Getting-private-Metadata-from-Geotiff-Images-tp5103966p5104110.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: Getting private Metadata from Geotiff Images
radioheadCDA wrote: Thanks! That is a lot of help. Does that mean I can call the geotransform method to access the private metadata information? Chris, If you call GetGeotransform() you should get back six doubles which for a north up affine georeferenced image (ie one specified with a single tiepoint and a pixel scale) will contain the origin, and the pixel size. I would encourage you to read the docs to understand the geotransform fully. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Using GDAL with KOMPSAT-2 images
Greetings While I was importing to GRASS some KOMPSAT-2 images I got a few warnings. Then, I decided to do some GDALINFO over those Kompsat-2 images and I got the following warnings: Warning 1: TIFFFetchNormalTag:ASCII value for tag DocumentName does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag ImageDescription does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag Artist does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag HostComputer does not end in null byte And only after this I got the gdalinfo response: Driver: GTiff/GeoTIFF Files: MSC_090905125514_16582_25480940M3P07N_1G.tif Size is 4551, 4663 Coordinate System is: PROJCS[WGS 84 / UTM zone 24S, GEOGCS[WGS_1984, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235604902, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,-39], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,1000], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32724]] Origin = (602410.721905449754559,9118774.368212059140205) Pixel Size = (4.000,-4.000) Metadata: TIFFTAG_DOCUMENTNAME=MSC_090905125514_16582_25480940M3P07N_1G.tif TIFFTAG_IMAGEDESCRIPTION=GeoTIFF v1.0 : KOMPSAT2 MSC Image Level 1G Product Level 1G TIFFTAG_DATETIME=2009:09:05 12:56:16 TIFFTAG_ARTIST=Received IRPE NULL Location 0.00/0.00 Processing TLS Location 43.60/1.44 TIFFTAG_HOSTCOMPUTER=Producer background SW version CAP 1.0.091126.01 TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_MINSAMPLEVALUE=0 TIFFTAG_MAXSAMPLEVALUE=1100 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Point Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 602410.722, 9118774.368) ( 38d 4'14.81W, 7d58'16.21S) Lower Left ( 602410.722, 9100122.368) ( 38d 4'13.43W, 8d 8'23.51S) Upper Right ( 620614.722, 9118774.368) ( 37d54'20.26W, 7d58'14.75S) Lower Right ( 620614.722, 9100122.368) ( 37d54'18.62W, 8d 8'22.02S) Center ( 611512.722, 9109448.368) ( 37d59'16.78W, 8d 3'19.15S) Band 1 Block=4551x1 Type=UInt16, ColorInterp=Gray Metadata: LAYER_TYPE=athematic What this warnings refer to? is this a critical issue? Thanks Best regards, Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal.Allregister Error
Looks like one or more dlls are missing or not available to load at run time. Make sure gdal.dll or all of the dependencies are available to load by the application. You can place the dll-s in the directory of your executable or include the directory location in the PATH environment. Best regards, Tamas 2010/5/26 radioheadCDA chrisaustin2...@gmail.com Hey, I have been having a very large issue, well maybe not large but very frustrating. I have been using the C# wrapper for gdal in visual studio and have been getting an error when GDAL tries to register the drivers before doing anything else. The error I get is this: The type Intializer for 'OSGeo.GDAL.Gdal' threw an exception I have tried changing enviroment variables, deleting then re-adding refrences to gdal, both which have done nothing to solve the problem. If anyone knows anything that might help me solve the issue, I would greatly appreciate at it. Thanks. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Gdal-Allregister-Error-tp5104079p5104079.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
Re: [gdal-dev] Using GDAL with KOMPSAT-2 images
Luis Lisboa wrote: Greetings While I was importing to GRASS some KOMPSAT-2 images I got a few warnings. Then, I decided to do some GDALINFO over those Kompsat-2 images and I got the following warnings: Warning 1: TIFFFetchNormalTag:ASCII value for tag DocumentName does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag ImageDescription does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag Artist does not end in null byte Warning 1: TIFFFetchNormalTag:ASCII value for tag HostComputer does not end in null byte ... What this warnings refer to? is this a critical issue? Luis, This is not a critical error, only a warning. However, if you are in contact with the data producer you might encourage them to bring their TIFF production into agreement with the specification which requires that the last byte of these text items should be a zero byte. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Gdal.Allregister Error
Hey thanks for the advice, but It seems i'm still having trouble. I have copied all of the dlls to the running application folder, and also looked at the setfwenv.bat and tried to manually set all of the enviroment variables, and I set all of them except for the GDAL_DRIVER_PATH=%FWTOOLS_DIR%\gdal_plugins enviroment because I can't seem to find the file gdal_plugins folder. This is starting to get annoying lol -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Gdal-Allregister-Error-tp5104079p5104516.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] Re: Gdal.Allregister Error
So I found the inner exception for the All register problem and it says it can't load the dll gdal_wrap but I have put an environment variable pointing to the folder its but it still shows up the exception. Is there any other reason why it would load the gdal_wrap dll? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Gdal-Allregister-Error-tp5104079p5105015.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: Handling CPG (encoding) file
For the write part, a OGRSFDriver::GetSupportedEncodings() and OGRLayer::SetEncoding() could make sense (for the later, if it must be exposed at the datasource or layer level is an open point and a slight difference between yours and Gaige's approach) Is there a need for a per-layer approach to this? I've yet to see a format that allowed different encodings in different layers. Although, thinking about it, it might be a problem using some of the virtual data sets, since they hide some of this. Actually, I'm not confident that a standalone SetEncoding() method is appropriate. This should rather be an extra parameter (or a stantardized creation option) of CreateDataSource() , as drivers will often need that information at the very beginning to write the appropriate header (for example the encoding of a XML file) and you cannot sanely change encoding in the middle of writing a file... Also, when you create a non UTF-8 datasource, - is the data passed to the driver already encoded in the target encoding (a) - or is it in UTF-8 (b) and the driver is responsible to convert it to the target encoding. Approach (a) gives strong predictibility of which bytes go to the file and enable the user to control how he wants the data to be degraded. But the downside of it is is that it would lead to a weird behaviour for read/write datasources. When you read, you'd get data in UTF-8 (AFAIK all encodings can be losslessly transcoded to UTF-8. Correct me if I'm wrong), but when you write you pass it in encoding ... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Gdal.Allregister Error
I got it to recognize the file but its saying that it can't find an entry point in the dllthis is really aggravating ha -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Gdal-Allregister-Error-tp5104079p5105091.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] GDAL installation on Linux (CentOS 64bit)
I downloaded all packages ( http://download.opensuse.org/repositories/Application:/Geo/CentOS_5/x86_64/) for CentOS 5. When i try to install netcdf-4.0.1-7.1.x86_64.rpm, I get this error: r...@localhost gdal17_64bit]# rpm -i netcdf-4.0.1-7.1.x86_64.rpm warning: netcdf-4.0.1-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 9591c39b error: Failed dependencies: libnetcdf.so.4()(64bit) is needed by netcdf-4.0.1-7.1.x86_64 On the other hand, when i try to install libnetcdf4-4.0.1-7.1.x86_64.rpm, I get this error: [r...@localhost gdal17_64bit]# rpm -i libnetcdf4-4.0.1-7.1.x86_64.rpm warning: libnetcdf4-4.0.1-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 9591c39b error: Failed dependencies: netcdf = 4.0.1 is needed by libnetcdf4-4.0.1-7.1.x86_64 So how can i install netcdf properly? Is there anyone has this problem? Best Regards, MJM ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: AW: [gdal-dev] Create gdaldataset from in-memory Image/Bitmap/byte[]/MemoryStream
2010/5/26 Even Rouault even.roua...@mines-paris.org
Felix,
yes you should be able to use FileFromMemBuffer() to create a virtual file
and
open it with the PNG driver (since the PNG driver supports virtual IO --
as
confirmed by gdalinfo --format PNG)
Here's the C API for it :
http://gdal.org/cpl__vsi_8h.html#1ecb3a78729ecea4d2ce22065a605244
And here's an extract of a test in the Python autotest suite.
content = open('data/byte.tif', mode='rb').read()
# Create in-memory file and initialize it with the content
gdal.FileFromMemBuffer('/vsimem/tiffinmem', content)
# Open the in-memory file
ds = gdal.Open('/vsimem/tiffinmem')
# do something with the dataset
# Close the dataset
ds = None
# Release memory associated to the in-memory file
gdal.Unlink('/vsimem/tiffinmem')
Disclaimer: You should be able to adapt the above for C#, but I haven't
tested
with the C# bindings, so there's a risk that they aren't ready if there's
some missing required typemap.
Felix,
The current version of the C# signature of FileFromMemBuffer is rude and not
user friendly, though I could imagine the following transcript of the python
code above for the C# bindings (not tested):
byte[] bytes = File.ReadAllBytes(data\\byte.tif);
GCHandle handle = GCHandle.Alloc(bytes, GCHandleType.Pinned);
try
{
Gdal.FileFromMemBuffer(/vsimem/tiffinmem,
handle.AddrOfPinnedObject());
using (Dataset ds = gdal.Open(/vsimem/tiffinmem))
{
// do something
}
Gdal.Unlink(/vsimem/tiffinmem);
}
finally
{
handle.Free();
}
In the future I'm about to add a second signature to the bindings *public
static void FileFromMemBuffer(string pszFilename, int nBytes, byte[]
pabyData)* which could also avoid the extra memcopy implemented in the
current version.
Feel free to add a ticket http://trac.osgeo.org/gdal/newticket to require
this addition.
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Gdal.Allregister Error
Hi, While I'm not sure what kind of binaries you are testing with, I would somewhat suggest to use a package from http://vbkto.dyndns.org/sdk/ which should contain all the required dll-s. gdal_wrap.dll is the unmanaged part of the bindings and it should also be available to load by the application at run time. As a last resort you could also use a file monitoring tool like ProcMonhttp://technet.microsoft.com/en-us/sysinternals/bb896645.aspxto identify the dll-s which could not be loaded. Best regards, Tamas 2010/5/26 radioheadCDA chrisaustin2...@gmail.com I got it to recognize the file but its saying that it can't find an entry point in the dllthis is really aggravating ha -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Gdal-Allregister-Error-tp5104079p5105091.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] ESRI text format?
Hi folks, Im dealing with some text data files that were exported from ArcMap as text files. They have polygons in them, an look like this: Polygon 0 0 0 -86.9890993091 28.999375461 1.#QNAN 1.#QNAN 1 -87.0129414796 28.9832507557 1.#QNAN 1.#QNAN 2 -87.0312816107 28.9590589356 1.#QNAN 1.#QNAN 3 -87.0551237811 28.9179197345 1.#QNAN 1.#QNAN ... Does anyone know what to call this format, and can OGR read or write it? I tried ogrinfo on it, and it wasn't recognized, so probably not, but I thought someone might have a hint. The problem at hand is to convert shape files with polygons into this format, I was hoping it would be a simple call to org2ogr, but I guess I may have to write a python script. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
