Re: [gdal-dev] Split apart MULTI* problem
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 records - one per element, probably with the same original attribute values, but with different fids, which could be a problem if the original shape already had valid primary key values. I'm not sure ogr2ogr can do that, but probably there's an appropriate tool around, or you can explode the multi geometries in PostGIS. Best regards Sig Da: William Kyngesburye [wokl...@kyngchaos.com], 26/04/2011 2.20 I can't get ogr2ogr to split MULTI* shapefiles to non-multi features. I'm sure I've done this in the past (it's been a while). _ PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). -- This email was Anti Virus checked by Astaro Security Gateway. http://www.amat-mi.it ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Split apart MULTI* problem
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 I'll have to write a python script... On Apr 26, 2011, at 3:50 AM, Luca Sigfrido Percich wrote: 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 records - one per element, probably with the same original attribute values, but with different fids, which could be a problem if the original shape already had valid primary key values. I'm not sure ogr2ogr can do that, but probably there's an appropriate tool around, or you can explode the multi geometries in PostGIS. Best regards Sig Da: William Kyngesburye [wokl...@kyngchaos.com], 26/04/2011 2.20 I can't get ogr2ogr to split MULTI* shapefiles to non-multi features. I'm sure I've done this in the past (it's been a while). _ PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). -- This email was Anti Virus checked by Astaro Security Gateway. http://www.amat-mi.it ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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/1e0e2f87aa59/CMake/TestGDALOpen.cxx segfaults on Debian when linked with -lgeotiff -lgdal but not when linked with -lgdal -lgeotiff. It runs fine on Ubuntu - this program : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx segfaults on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs fine when geotiff comes before gdal. For now, we managed to provide binary packages for the Orfeo Toolbox applications on Ubuntu by ensuring geotiff comes before gdal in the link list (see https://launchpad.net/~otb). This works because we manage the build from begining to end. But this is a showstopper for our efforts to provide QGis plugins based on Orfeo Toolbox : even with the (fragile) solution we ended up with (ensuring the order geotiff-gdal in all our link commands), our qgis plugins crash as soon as they read a TIFF file on Ubuntu. So we are stuck and cannot release binaries of those plugins. 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) ? Do you have pointers on those versioned symbols you were referring to ? Are you still against the redefinition of the internal tiff/geotiff symbols or is this an option for you (for libtiff, there is already a working solution in the InsightToolkit) ? It seems to be the safest solution to me. Are we still the only people on Earth linking programs with both gdal and geotiff ;) ? Regards, Julien Le 29/11/2010 17:08, Julien Malik a écrit : Hello Even, Thank you for your answer. Le 29/11/2010 15:51, Even Rouault a écrit : Julien, To be fair, I think that --with-hide-internal-symbols just does what it advertizes : it hides GDAL internal symbols (internal libtiff, internal libgeotiff) to applications that link with libgdal. I mean that they cannot use those symbols (if they only link to libgdal). The advantage is that it speed-ups the loading of the library and the resolving of its symbols. However, it doesn't do what we could expect : in the case the application links with several libraries that define the same symbol (exported or not), it has no influence on how the symbols are resolved by the dynamic linker. So depending on the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol resolver will choose either the one from GDAL or the one from libgeotiff. OK, I see your point. It works at link time, but not at load time... Too bad ! By the way, are you sure that --with-hide-internal-symbols actually worsens the situation ? I'd have bet you'd got the same/similar issues with a build that doesn't use --with-hide-internal-symbols. No I'm not sure, I didn't test. So in fact the problem does not come really from hide-internal-symbols, but from the simple fact that geotiff is included in gdal with a different . I tried recently to use some trickery based on #define for the internal libtiff. The internal libtiff would have lines (in tif_config.h or in a specific header file imported by it) which would redefine each symbol like #define TIFFGetField GDAL_TIFFGetField. This was easily done with a simple script that parsed the output of nm/objdump -T on libtiff. It mostly worked but I couldn't get to work it completely without modifying the libtiff files, due to their use of #define mechanisms inside libtiff in a few places (in tif_swab.c and tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the libtiff files as they are directly imported from upstream libtiff. So that effort is mostly stalled for now. This is the procedure I know as mangling. I know Insight Toolkit does that (http://www.itk.org) for the internal libtiff version, but there are probably some modifications in the libtiff code. If this is not an option for you, then I think we're stuck. As far as using ld versionned symbols as Francesco Lovergine suggested, I've no experience with that mechanism. Perhaps you could investigate on that side. I don't know about it neither, but I can imagine what versioned symbols can mean. But it does not solve my problem (I want to use the packaged version of gdal in Debian and Ubuntu...) Thanks, Julien Even Hello, I'm reviving an already known problem about the gdal packages for Ubuntu/Debian, related to the use of the hide-internal-symbols configure option. To sum it up, we get into troubles with the gdal packages since we also use the geotiff API. Until recently, we knew only about a problem with Debian. It had been reported for example : - http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733 A similar issue
Re: [gdal-dev] Split apart MULTI* problem
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 different from splitting multi features into a shapefile. I suppose I'll have to write a python script... Or use the -explodecollections flag of ogr2ogr ? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Split apart MULTI* problem
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. And yes, forcing features to multi into PostGIS is different from splitting multi features into a shapefile. I suppose I'll have to write a python script... Or use the -explodecollections flag of ogr2ogr ? Oh. I missed that, it's not described in the long help. That works. thanks - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL and HRE
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? I'm just starting out. Do you refer to the HRE files in NITF format ? They are successfully read by GDAL, but the samples available show a vertical flip. However GDAL interpretation of georeferencing contained in the file seems correct, so either the samples are incorrect, either there's a subtelty that GDAL doesn't understand... my email is georgec_...@yahoo.com Thanks, George ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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 : - this program : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx segfaults on Debian when linked with -lgeotiff -lgdal but not when linked with -lgdal -lgeotiff. It runs fine on Ubuntu - this program : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx segfaults on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs fine when geotiff comes before gdal. For now, we managed to provide binary packages for the Orfeo Toolbox applications on Ubuntu by ensuring geotiff comes before gdal in the link list (see https://launchpad.net/~otb). This works because we manage the build from begining to end. But this is a showstopper for our efforts to provide QGis plugins based on Orfeo Toolbox : even with the (fragile) solution we ended up with (ensuring the order geotiff-gdal in all our link commands), our qgis plugins crash as soon as they read a TIFF file on Ubuntu. So we are stuck and cannot release binaries of those plugins. Stupid question (that won't solve the root cause of the problem): why do you need direct access to libtiff and libgeotiff ? Can't you do what you need to do with the GDAL GTiff driver ? 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 few (safe and easy) options : - build the GDAL package to link with system/external libtiff and libgeotiff. But then you loose bigtiff support - or make libtiff 4.X the system libtiff version (as in debian experimental) Do you have pointers on those versioned symbols you were referring to ? Not better that what you can find with a search with your favorite search engine... Are you still against the redefinition of the internal tiff/geotiff symbols or is this an option for you (for libtiff, there is already a working solution in the InsightToolkit) ? It seems to be the safest solution to me. I haven't watched what InsightToolkit does. Do you have some info ? If you can come with a solution that doesn't involve modifying the source code of libtiff/libgeotiff after it is imported in GDAL source tree, that might be worth considering it. Otherwise if you have a minimum invasive patch that could be upstreamed to the libtiff and libgeotiff projects, and conditionnaly enabled with some #ifdef that could be turned on when included in GDAL, that could perhaps be a viable solution. Provided that libtiff/libgeotiff mainteners are OK with that. Are we still the only people on Earth linking programs with both gdal and geotiff ;) ? Eh eh, I'd say yes, just so that it becomes a motivation for you to come with patch(es) ;-) That's how FOSS evolves... Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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 few (safe and easy) options : - build the GDAL package to link with system/external libtiff and libgeotiff. But then you loose bigtiff support - or make libtiff 4.X the system libtiff version (as in debian experimental) Do you have pointers on those versioned symbols you were referring to ? 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, so I would consider it to solve problems in Debian, not a general (upstream) solution. This is exactly what I'm going to provide in 1.8/experimental for next library transition. -- Francesco P. Lovergine ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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 current situation when reading TIFF files with gdal : - this program : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx segfaults on Debian when linked with -lgeotiff -lgdal but not when linked with -lgdal -lgeotiff. It runs fine on Ubuntu - this program : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx segfaults on Ubuntu when linked with -lgdal -lgeotiff -ltiff but runs fine when geotiff comes before gdal. For now, we managed to provide binary packages for the Orfeo Toolbox applications on Ubuntu by ensuring geotiff comes before gdal in the link list (see https://launchpad.net/~otb). This works because we manage the build from begining to end. But this is a showstopper for our efforts to provide QGis plugins based on Orfeo Toolbox : even with the (fragile) solution we ended up with (ensuring the order geotiff-gdal in all our link commands), our qgis plugins crash as soon as they read a TIFF file on Ubuntu. So we are stuck and cannot release binaries of those plugins. Stupid question (that won't solve the root cause of the problem): why do you need direct access to libtiff and libgeotiff ? Can't you do what you need to do with the GDAL GTiff driver ? 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/ossimGeoTiff.cpp which makes extensive use of the geotiff API. Other TIFF/GeoTIFF related files are : imaging/ossimTiffOverviewBuilder.cpp imaging/ossimTiffWriter.cpp imaging/ossimTiffTileSource.cpp 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 few (safe and easy) options : - build the GDAL package to link with system/external libtiff and libgeotiff. But then you loose bigtiff support I'm not sure this is an option. Any GIS/remote sensing user dealing with TIFF files want bigtiff support I think. - or make libtiff 4.X the system libtiff version (as in debian experimental) OK. What prevents from it ? Is it API/ABI incompatible with previous versions ? For example, could libtiff 4.X be packaged in ubuntugis repository and not break other packages ? Do you have pointers on those versioned symbols you were referring to ? Not better that what you can find with a search with your favorite search engine... Are you still against the redefinition of the internal tiff/geotiff symbols or is this an option for you (for libtiff, there is already a working solution in the InsightToolkit) ? It seems to be the safest solution to me. I haven't watched what InsightToolkit does. Do you have some info ? If you can come with a solution that doesn't involve modifying the source code of libtiff/libgeotiff after it is imported in GDAL source tree, that might be worth considering it. Sadly, I think it involves modification of libtiff sources. Otherwise if you have a minimum invasive patch that could be upstreamed to the libtiff and libgeotiff projects, and conditionnaly enabled with some #ifdef that could be turned on when included in GDAL, that could perhaps be a viable solution. Provided that libtiff/libgeotiff mainteners are OK with that. This crazy idea came to my mind also : a configure option which would allow prefixing all symbols exported by libtiff and libgeotiff. But this means 2 projects to modify. Surely harder to achieve than other solution. Are we still the only people on Earth linking programs with both gdal and geotiff ;) ? Eh eh, I'd say yes, just so that it becomes a motivation for you to come with patch(es) ;-) That's how FOSS evolves... Best regards, Even Thanks a lot for your comments, Julien This message was sent using IMP, the Internet Messaging Program. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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 API. Other TIFF/GeoTIFF related files are : imaging/ossimTiffOverviewBuilder.cpp imaging/ossimTiffWriter.cpp imaging/ossimTiffTileSource.cpp ok, I guess it is their native tiff reader/writer. - or make libtiff 4.X the system libtiff version (as in debian experimental) OK. What prevents from it ? Is it API/ABI incompatible with previous versions ? For example, could libtiff 4.X be packaged in ubuntugis repository and not break other packages ? No, libtiff 3.X and 4.X are not ABI compatible, and have also a few API differences (but that are small enough so that the GDAL GTiff driver can be built against both) This crazy idea came to my mind also : a configure option which would allow prefixing all symbols exported by libtiff and libgeotiff. But this means 2 projects to modify. Surely harder to achieve than other solution. The whole question is how to implement such a configuration option. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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 the debian packaging... There are indeed very few (safe and easy) options : - build the GDAL package to link with system/external libtiff and libgeotiff. But then you loose bigtiff support - or make libtiff 4.X the system libtiff version (as in debian experimental) Do you have pointers on those versioned symbols you were referring to ? 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, so I would consider it to solve problems in Debian, not a general (upstream) solution. This is exactly what I'm going to provide in 1.8/experimental for next library transition. Oh GREAT ! So I guess the issue will be closed soon. Very, very good news for us OrfeoToolbox users. Thanks so much for considering this ! -- Francesco P. Lovergine This message was sent using IMP, the Internet Messaging Program. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff conflict
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, so I would consider it to solve problems in Debian, not a general (upstream) solution. This is exactly what I'm going to provide in 1.8/experimental for next library transition. Oh GREAT ! So I guess the issue will be closed soon. Very, very good news for us OrfeoToolbox users. Thanks so much for considering this ! Note that it will sacrify binary compatibility against casual builds. You will need to build against the Debian version of GDAL, not third parties builds. -- Francesco P. Lovergine ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
