Hi William,
converting a single linestring or polygon into a multi- geometry simply
wraps the single geom into a collection. Like in the U.K., when you see
a single person waiting at a bus stop, it's actually a queue made of a
single person :)
Splitting a multi geometry would result in multiple
I just remembered that what I've done in the past wasn't splitting multi
features, but dropping the z from 3D shapefiles. So I don't know if the multi
splitting is possible.
And yes, forcing features to multi into PostGIS is different from splitting
multi features into a shapefile.
I suppose
Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the current situation when reading TIFF files with gdal :
- this program :
Le mardi 26 avril 2011 15:27:05, William Kyngesburye a écrit :
I just remembered that what I've done in the past wasn't splitting multi
features, but dropping the z from 3D shapefiles. So I don't know if the
multi splitting is possible.
And yes, forcing features to multi into PostGIS is
On Apr 26, 2011, at 12:33 PM, Even Rouault wrote:
Le mardi 26 avril 2011 15:27:05, William Kyngesburye a écrit :
I just remembered that what I've done in the past wasn't splitting multi
features, but dropping the z from 3D shapefiles. So I don't know if the
multi splitting is possible.
Le mardi 26 avril 2011 13:10:15, georgec_...@yahoo.com a écrit :
hello,
I saw your message on osgeo-org with the subject line NGA High Resolution
Elevation (HRE) data problem?
did you ever get the HRE files parsed with GDAL? I'm working on the same
sort of thing and was just wondering?
Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the current situation when reading TIFF files with gdal :
-
On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:
What can we do to help find a solution (what kind of modification to the
gdal debian package would you agree to make to solve this issue) ?
I'm not sure the solution is really in the debian packaging...
There are indeed very
Hi Even,
Quoting Even Rouault even.roua...@mines-paris.org:
Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the
All this comes from the fact that Orfeo Toolbox has ossim as one of
its main dependency, and ossim handles TIFF via libgeotiff and not via
gdal.
For example :
http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossi
mGeoTiff.cpp which makes extensive use of the geotiff
Quoting Francesco P. Lovergine fran...@debian.org:
On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote:
What can we do to help find a solution (what kind of modification to the
gdal debian package would you agree to make to solve this issue) ?
I'm not sure the solution is really in
On Tue, Apr 26, 2011 at 09:39:21PM +0200, MALIK Julien wrote:
Here we go:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268
of course this is a possibile solution to avoid symbol collision among
different libraries. It is not a os-independent solution even,
12 matches
Mail list logo
