Re: [gdal-dev] Update of EPSG database to v8.4

Hi all, just want to pick up the status of this, anything new/started somewhere I could help with? Trent, anything happened on your side about planetary proj support? I am going to have a nother look about it, once answers/comments reach. Cheers, Yann On 16 May 2014 at 04:46, Etienne Tourigny

Re: [gdal-dev] OGR support for Google Latitude KML output

Though another thing I just noted is that the attributes aren’t kept. I think this is already mentioned in the ticket #5095 and you said it requires a lot more development. Is this still the same status? Uli > On Dec 4, 2014, at 19:37, Ulrich Strötz

Re: [gdal-dev] OGR support for Google Latitude KML output

I didn’t compile against libkml. I compiled again against libkml and now it works perfect. Thanks again for this great fix! Makes my work a lot easier :) Uli > On Dec 4, 2014, at 17:17, Even Rouault wrote: > > Le vendredi 05 décembre 2014 00:11:44, Ulrich Strötz a écrit : >> Thanks Even for

Re: [gdal-dev] OGR support for Google Latitude KML output

Le vendredi 05 décembre 2014 00:11:44, Ulrich Strötz a écrit : > Thanks Even for getting on this so quickly! > > I built GDAL from source after you committed your changes, though I still > only get the start and end point. Did you try it with my sample file? Yes, I did. Are you compiling against

Re: [gdal-dev] OGR support for Google Latitude KML output

Thanks Even for getting on this so quickly! I built GDAL from source after you committed your changes, though I still only get the start and end point. Did you try it with my sample file? Thanks, Uli > On Dec 4, 2014, at 10:07, Even Rouault wrote: > > Le mercredi 03 décembre 2014 19:53:44,

Re: [gdal-dev] VICAR format

Michael, For some PDS releases, you may find a PDS detached label (*.lbl) pointing at a Vicar file. The PDS label contains a calculate-able "skipbytes" amount to jump over the original vicar label so that it can get to the start of the pixel stream. For your case, indeed the *.lbl is a PDS label

Re: [gdal-dev] QGIS crashes in ogrsqlitevirtualogr.cpp::OGR2SQLITE_Register

On 04.12.2014 23:04, Kyle Shannon wrote: It looks like this may be the issue: http://trac.osgeo.org/gdal/ticket/5725, and a fix has been committed. I think this has to do with more recent versions of sqlite. What version are you using? (Ah right, forgot to mention: gdal-1.11.1 sqlite-3.8.7.2)

Re: [gdal-dev] QGIS crashes in ogrsqlitevirtualogr.cpp::OGR2SQLITE_Register

Sandro, On Thu, Dec 4, 2014 at 2:50 PM, Sandro Mani wrote: > Hi, > > QGIS is currently crashing in Fedora 21+ when listing the supported ogr > drivers. In QgsVectorFileWriter::ogrDriverList, there is a portion of code > > // Unfortunately it seems that there is no simple way to detect if > // OGR

Re: [gdal-dev] QGIS crashes in ogrsqlitevirtualogr.cpp::OGR2SQLITE_Register

Le jeudi 04 décembre 2014 22:50:05, Sandro Mani a écrit : > Hi, > > QGIS is currently crashing in Fedora 21+ when listing the supported ogr > drivers. In QgsVectorFileWriter::ogrDriverList, there is a portion of code Sandro, Does Fedora 21+ use sqlite 3.8.7 ? If so, see http://trac.osgeo.org/gd

[gdal-dev] QGIS crashes in ogrsqlitevirtualogr.cpp::OGR2SQLITE_Register

Hi, QGIS is currently crashing in Fedora 21+ when listing the supported ogr drivers. In QgsVectorFileWriter::ogrDriverList, there is a portion of code // Unfortunately it seems that there is no simple way to detect if // OGR SQLite driver is compiled with SpatiaLite support. // We have HAVE_SP

Re: [gdal-dev] VICAR format

Michael, Yes - Sebastian Walters created one. I'm not clear if the driver will be pushed into the public version of GDAL? I know it is being used by the HRSC Team to convert to their VICAR products to GeoTiff (DEMs) and Jpeg2000.(images). If it does get pushed into GDAL then I would recommend th

Re: [gdal-dev] OGR support for Google Latitude KML output

Le mercredi 03 décembre 2014 19:53:44, Ulrich Strötz a écrit : > Hi everyone, > > I am trying to use ogr2ogr with a KML file generated by Google My Tracks > racks&hl=en>. > > There was a ticket #5095

Re: [gdal-dev] Problem using gdalbuildvrt with a large number of source datasets

Hello Even, I've had a chance to test the fix in trunk and can report that it works very well: the `gdalbuildvrt` completed in just over an hour with the progress meter giving a much more accurate report on progress. I have submitted an enhancement request regarding the VRT indexing at

[gdal-dev] GDAL rasterize C# bindings

Dear *, I want to use the gdal function rasterizelayer in order to transform my shape into a ascii grid. I'm using the C# bindings and GDAL 1.11. Now I'm stuck with the SWIGType which I has to pass to rasterize. I can neither create nor cast it from int[] but it appears to be obligious. On ht

Re: [gdal-dev] Motion: Adopt RFC 51: RasterIO() improvements : resampling and progress callback

> Motion : I move to adopt RFC 51: RasterIO() improvements : resampling and > progress callback > > http://trac.osgeo.org/gdal/wiki/rfc51_rasterio_resampling_progress > > Starting with my +1 I declare this motion passed with support from FrankW, JukkaR, HowardB, DanielM, TamasS and myself. I w