Re: [gdal-dev] problem with importing gml file to PostGIS with ogr2ogr

Thanks for your explanations but I still can't import polygons which contains many vertices. I do some test with polygons which contains different quantities of vertices and on my computer and configuration I can import polygon which has 2046 pairs (x,y) of coordinates but I can't import when i

Re: [gdal-dev] Reading error with dwg and dxf files

Selon Xian Chen/³ÂÏÛ : > Thanks Even. > > After checking the code under dwg and dxf, I believe the relevant error code > to my original error report should be in > ogr/ogrsf_frmts/dxf/ogrdxf_polyline_smooth.cpp. The code in EmitArc() must > consider the case when ogrArcStartAngle > ogrArcEndAngle

Re: [gdal-dev] problem with importing gml file to PostGIS with ogr2ogr

Selon Piotr Pachó : > Hello list, > I have problem with importing gml file (with polygons) to postgis using > standard ogr2ogr command which look like: > > ogr2ogr -a_srs EPSG:2180 -f "PostgreSQL" PG:"host=localhost > user=postgres dbname=test password=postgres port=5432" > d:\test\BDOT10k\OT_ADJA

[gdal-dev] problem with importing gml file to PostGIS with ogr2ogr

Hello list, I have problem with importing gml file (with polygons) to postgis using standard ogr2ogr command which look like: ogr2ogr -a_srs EPSG:2180 -f "PostgreSQL" PG:"host=localhost user=postgres dbname=test password=postgres port=5432" d:\test\BDOT10k\OT_ADJA_A.xml I tried to import two GML

[gdal-dev] Error Oracle -lco options

Hi list I have to upload data (same problem with shapefiles and gml) in Oracle with ogr2ogr and I got an error when I specify any -lco option. If I don't add -lco in command line, data is uploaded without error. Anyone have an idea? thank's ogr2ogr --version GDAL 1.10.0, released 2013/04

Re: [gdal-dev] Motion: Adopt RFC 41 : Support for multiple geometry fields in OGR

A belated +1 from here as well. I'll update the MSSQL driver, as soon as the core implementation is committed. Best regards, Tamas 2013/8/5 Even Rouault > > Hi, > > > > Motion: I move to adopt RFC 41 : Support for multiple geometry > fields in > > OGR > > > >

Re: [gdal-dev] Wrong metadata or gdalinfo weakness (on Landsat scene over Madagascar)?

Even is correct, all Landsat data from USGS (with very few exceptions) are projected to UTM North zones, including southern hemisphere scenes. The only difference between North and South UTM zones is a false northing added to ensure positive y coordinates of southern scenes, which is why the y

Re: [gdal-dev] Motion: Adopt RFC 41 : Support for multiple geometry fields in OGR

> Hi, > > Motion: I move to adopt RFC 41 : Support for multiple geometry fields in > OGR > > http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields > > I've made a few changes in the last few days. See the history : > Hi, I declare this mo

Re: [gdal-dev] Wrong metadata or gdalinfo weakness (on Landsat scene over Madagascar)?

Selon Nikos Alexandris : GDAL is doing its job great on this case. The data is just oddly georeferenced, but the end result is OK if you look at the corner coordinates in longitude, latitude. The projection is UTM north, but with with negative y values, which means it is on the southern hemisphere

Re: [gdal-dev] OGDI dead?

On 05/08/13 06:26, Frank Warmerdam wrote: William, Interesting point. It would appear I'll need to do a few small fixes to OGDI to keep it building, though I normally just work around the projects.h one. In fact, I'm only vaguely familiar with the existance and role of libdtusa.so so perhaps t

Re: [gdal-dev] OGDI dead?

I figured out why it stopped working, then started working again - I had disabled GDAL 1.9 (OS X framework), which has OGDI libraries bundled in it. My OGDI library was built when 1.9 was current, and I just changed the library loader (system) paths to bundle it with GDAL 1.10. I didn't realiz

[gdal-dev] Wrong metadata or gdalinfo weakness (on Landsat scene over Madagascar)?

For the Landsat scene over Madagascar LE71610762013070PFS00, gdalinfo reports UTM Zone 38N (EPSG:32638, ). This is wrong. It should be UTM Zone 38 _S_ (EPSG:32738, ). Is it the metadata's fault or is gdali