Re: [gdal-dev] OGR Field Types?

2015-06-04 Thread Stefan Keller
Hi Brad 2015-06-05 3:18 GMT+02:00 Brad Hards wrote: >> We've finished the GeoCSV spec. > Does that mean: http://giswiki.hsr.ch/GeoCSV ? Yes. Any comments are welcome. Cheers, S. 2015-06-05 3:18 GMT+02:00 Brad Hards : > On Fri, 5 Jun 2015 12:38:01 AM Stefan Keller wrote: >> We've finished the

Re: [gdal-dev] OGR Field Types?

2015-06-04 Thread Brad Hards
On Fri, 5 Jun 2015 12:38:01 AM Stefan Keller wrote: > We've finished the GeoCSV spec. Does that mean: http://giswiki.hsr.ch/GeoCSV ? Brad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem appending non-geometry tables in PostGis

2015-06-04 Thread Saulteau Don
If you add "-nlt NONE" to the ogr2ogr command, does that work? You might need to do that just for the non-spatial tables, because if you do that with the spatial tables, they will only upload the attributes. Donovan On Thu, Jun 4, 2015 at 5:19 PM, Roger André wrote: > Hi All, > > I'm having s

[gdal-dev] Problem appending non-geometry tables in PostGis

2015-06-04 Thread Roger André
Hi All, I'm having some trouble using ogr2ogr to do batch uploads to a Postgis DB. It appears that on tables which don't contain geometry, CreateLayer is failing and not allowing data to be appended to an existing table. Here is the command that is being used to load each feature class: ogr2ogr

Re: [gdal-dev] OGR Field Types?

2015-06-04 Thread Stefan Keller
Hi even We've finished the GeoCSV spec. and we're almost ready to publish the Editable GeoCSV plugin fpr QGIS. So, I have following enhancement requests for the OGR CSV reader, regarding CSVT: 1. Accept "WKT" (case insensitive) indicating WKT geometry field. 2. Accept "CoordX" and "CoordX" (in an

Re: [gdal-dev] Bindings

2015-06-04 Thread Tamas Szekeres
Hi Ari, Creating language specific main files would be fine for me. We could also add the "language specific extensions" at the bottom section (like gdal_csharp_extend.i) directly into the file. We should however make sure to update all relevant files if a common change is done in a language spec

[gdal-dev] ImportError: numpy.core.multiarray failed to import

2015-06-04 Thread Ronquillo, Edgar Nahum
Hello, So I am trying to run the example called "Clip a Geotiff with Shapefile" from this website https://pcjericks.github.io/py-gdalogr-cookbook/raster_layers.html. However, I get an error about numpy although I do have numpy installed. I believe is something with GDAL. Here is my output error

Re: [gdal-dev] Bytes still reachables in setFromUserInput function

2015-06-04 Thread Mathieu Coudert
Thanks Even for the prompt answer. I would have expected a method through the OGR API to handle it without having to call proj but if it appears like the standard or default way for you to do it, let's do it. Cheers, Mathieu On Thu, Jun 4, 2015 at 4:20 PM, Even Rouault wrote: > Le jeudi 04 ju

[gdal-dev] Bindings

2015-06-04 Thread Ari Jolma
Hi, I've been trying to find a way to make the common SWIG interface files less concerned about languages and the whole system more flexible and understandable (which I see a prerequisite for further developments). My conclusion seems to be now that it is probably better to make the main fil

Re: [gdal-dev] Read Ascii Grid and produce GeoTiff

2015-06-04 Thread Even Rouault
Le jeudi 04 juin 2015 15:58:49, Ronquillo, Edgar Nahum a écrit : > Hello everyone, > I have been looking around for a while now. I want to create a python > script that can read an AsciiGrid file and be able to produce a GeoTiff > out of it. I know it is possible with Gdal, I just don't seem to get

Re: [gdal-dev] Bytes still reachables in setFromUserInput function

2015-06-04 Thread Even Rouault
Le jeudi 04 juin 2015 16:04:32, Mathieu Coudert a écrit : > Hello, > > > > I am using GDAL 1.11.2 on linux Centos and here is one of my function : > > > > { > > OGRSpatialReference sr; > > if (sr.SetFromUserInput(proj.c_str()) != OGRERR_NONE) > > throw InvalidInput(); > > > > char *

[gdal-dev] Read Ascii Grid and produce GeoTiff

2015-06-04 Thread Ronquillo, Edgar Nahum
Hello everyone, I have been looking around for a while now. I want to create a python script that can read an AsciiGrid file and be able to produce a GeoTiff out of it. I know it is possible with Gdal, I just don't seem to get it. There are some references out there about this but nothing exact.

[gdal-dev] Bytes still reachables in setFromUserInput function

2015-06-04 Thread Mathieu Coudert
Hello, I am using GDAL 1.11.2 on linux Centos and here is one of my function : { OGRSpatialReference sr; if (sr.SetFromUserInput(proj.c_str()) != OGRERR_NONE) throw InvalidInput(); char *wkt; sr.exportToWkt(&wkt); string srs (wkt); OGRFree(wkt); return srs; } This code wor

[gdal-dev] Call for discussion on RFC 26: GDAL Block Cache Improvements

2015-06-04 Thread Even Rouault
Hi, I've updated an old RFC initiated by Tamas. The main idea, having a hashset based implementation as an alternative to the array based, remains. Changes consist mainly in code restructuration, perf improvements to reduce lock contention and porting to the state of the latest code base. This

Re: [gdal-dev] Filesize too large when writing compressed float's to a Geotiff from Python

2015-06-04 Thread Even Rouault
> It makes sense that the order in which the data is written/stored affects > the performance of the compression, but i don't get why it would be > different for integers as compared to floats? Floats are larger than Int8 and Int16, so for the same amount of GDAL_CACHEMAX, you can cache less blo

Re: [gdal-dev] Filesize too large when writing compressed float's to a Geotiff from Python

2015-06-04 Thread Rutger
Even, Thanks for the suggestions, the first two work well. I'll have a look at the ds.WriteRaster, that seems an interesting way, since it also prevents unnecessary looping over the bands. Writing per block is what i usually do, maybe that's why i never noticed it before. I now ran into it whil