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
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
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
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
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
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
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
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
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
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
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 *
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.
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
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
> 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
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
16 matches
Mail list logo