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 so
Quoting "Francesco P. Lovergine" :
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 pac
> 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 geoti
Hi Even,
Quoting Even Rouault :
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
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
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 :
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 wonder
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 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
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 :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa5
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,
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? I'm just starting out.
my email is georgec_...@yahoo.com
Thanks,
Geor
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 r
13 matches
Mail list logo
