Re: [gdal-dev] invalid byte sequence for encoding UTF8: 0xc309
Hi Even, 2015-02-23 11:29 GMT+01:00 Even Rouault even.roua...@spatialys.com: Fixed by http://trac.osgeo.org/gdal/changeset/28539 I'm not sure if people relied on the implicit truncation done by the COPY code path, but for now it is better do disable it as it was wrong for UTF-8 characters. thanks, I can confirm that solves this problem. Are you planning to backport to 1.11 branch? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] invalid byte sequence for encoding UTF8: 0xc309
Le lundi 23 février 2015 11:36:33, Martin Landa a écrit : Hi Even, 2015-02-23 11:29 GMT+01:00 Even Rouault even.roua...@spatialys.com: Fixed by http://trac.osgeo.org/gdal/changeset/28539 I'm not sure if people relied on the implicit truncation done by the COPY code path, but for now it is better do disable it as it was wrong for UTF-8 characters. thanks, I can confirm that solves this problem. Are you planning to backport to 1.11 branch? The direct backport wasn't possible since the code had been refactored and people could likely depend on truncation for non-UTF8 content. So I have finally fixed the truncation to work. There was embryonic code, but wrong/subobtimal, in the PGDump driver. Should now be completely fixed in 1.11 and trunk per http://trac.osgeo.org/gdal/ticket/5854 Martin -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] invalid byte sequence for encoding UTF8: 0xc309
Hi Even, 2015-02-23 12:58 GMT+01:00 Even Rouault even.roua...@spatialys.com: The direct backport wasn't possible since the code had been refactored and people could likely depend on truncation for non-UTF8 content. So I have finally fixed the truncation to work. There was embryonic code, but wrong/subobtimal, in the PGDump driver. Should now be completely fixed in 1.11 and trunk per http://trac.osgeo.org/gdal/ticket/5854 thanks! Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Extracting Features
Hey, I'm using the ogr2ogr vector utility, and i want to extract features from a data source which intersect the extent of another data source. How can i do it? Best regards, Tomer -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Extracting-Features-tp5189503.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] invalid byte sequence for encoding UTF8: 0xc309
Le lundi 23 février 2015 11:12:45, Martin Landa a écrit : Hi, I am having problem to convert VFR file [1] to PostGIS. The command ogr2ogr -f PostgreSQL PG:dbname=uvoh /vsicurl/http://vdp.cuzk.cz/vymenny_format/specialni/20150203_ST_UVOH.xml.g z -overwrite fails with: ERROR 1: COPY statement failed. ERROR: invalid byte sequence for encoding UTF8: 0xc309 CONTEXT: COPY volebniokrsek, line 7416 Any idea what could be wrong? Thanks in advance! Martin Martin, Fixed by http://trac.osgeo.org/gdal/changeset/28539 I'm not sure if people relied on the implicit truncation done by the COPY code path, but for now it is better do disable it as it was wrong for UTF-8 characters. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GetFeatures 1-indexed for spatialite?
Le lundi 23 février 2015 19:40:42, Matt Perry a écrit : I'm running into some strange behavior with the Spatialite driver, accessing features through the ogr python bindings. layer.GetFeature(0) == None layer.GetFeature(1) == ... # first feature for spatialite layers only; all other drivers appear to be 0-indexed. More details and code to reproduce: https://github.com/perrygeo/python-raster-stats/issues/55#issuecomment-7560 2253 I'm using GDAL 1.11.1 on OS X via homebrew and the latest python bindings from pypi. Is this a bug or undocumented behavior? Matt, I'd say driver specific behaviour. Drivers for DBMS should return a feature ID that is the value of the integer primary key of the table (generally starting at 1). For other drivers shch as shapefile etc, the convention may change according to the driver. Anyway in the general case there might be holes in numbering in case of deleted features. So the recommanded way of interating over features is to call GetNextFeature(), as GetFeature() might be slow in some drivers due to the lack of indexing or proper method to seek to an arbitrary feature. Even Matt Perry ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal.FileFromMemBuffer
Patrick,
After the FileFromMemBuffer() call, the content has been copied to an
internal buffer. I think the C++ API has a way of avoiding the copy (if
desired) but the python does not.
The good thing is, no need to worry about the lifetime of the request
result object.
Best regards,
Frank
On Mon, Feb 23, 2015 at 12:12 PM, Patrick Young
patrick.mckendree.yo...@gmail.com wrote:
Hi all,
I've been playing around a bit with the vsimem stuff in gdal using python,
works great! Basically, I'm getting a json response from an ArcServer
endpoint and I want to get out of the ESRI world as quick as I can.
My question is, when I do something like this,
r = requests.get(url, params=payload, timeout=timeout)
gdal.FileFromMemBuffer('/vsimem/temp', r.content)
does the buffer get copied to the created virtual file? I know I need to
clean up with a gdal.Unlink(('/vsimem/temp'), but does something bad happen
when Python frees the r request?
Thanks a ton!
-Patrick
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
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
[gdal-dev] gdal.FileFromMemBuffer
Hi all,
I've been playing around a bit with the vsimem stuff in gdal using python,
works great! Basically, I'm getting a json response from an ArcServer
endpoint and I want to get out of the ESRI world as quick as I can.
My question is, when I do something like this,
r = requests.get(url, params=payload, timeout=timeout)
gdal.FileFromMemBuffer('/vsimem/temp', r.content)
does the buffer get copied to the created virtual file? I know I need to
clean up with a gdal.Unlink(('/vsimem/temp'), but does something bad happen
when Python frees the r request?
Thanks a ton!
-Patrick
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GetFeatures 1-indexed for spatialite?
On Mon, Feb 23, 2015 at 12:46 PM, Even Rouault even.roua...@spatialys.com wrote: Le lundi 23 février 2015 19:40:42, Matt Perry a écrit : I'm running into some strange behavior with the Spatialite driver, accessing features through the ogr python bindings. layer.GetFeature(0) == None layer.GetFeature(1) == ... # first feature for spatialite layers only; all other drivers appear to be 0-indexed. More details and code to reproduce: https://github.com/perrygeo/python-raster-stats/issues/55#issuecomment-7560 2253 I'm using GDAL 1.11.1 on OS X via homebrew and the latest python bindings from pypi. Is this a bug or undocumented behavior? Matt, I'd say driver specific behaviour. Drivers for DBMS should return a feature ID that is the value of the integer primary key of the table (generally starting at 1). For other drivers shch as shapefile etc, the convention may change according to the driver. Anyway in the general case there might be holes in numbering in case of deleted features. So the recommanded way of interating over features is to call GetNextFeature(), as GetFeature() might be slow in some drivers due to the lack of indexing or proper method to seek to an arbitrary feature. Sounds like a good idea to rewrite with GetNextFeaure(). Thanks! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
