[gdal-dev] image quality with pyramids (with gdal_retile)
Hi, I am building a pyramid from a 650 MB geotiff file (rgb) , with the following command from fwtools 2.4.6 on a win32 box gdal_retile -levels 5 -pyramidOnly -targetDir pyramid bathymetry. I loaded these image files to geoserver and see that when I zoomed to the higheest available level, the images are degraded in quality in comparison to original one. Also , I expected that the resulting pyramid size to be bigger than the original file size, but it is NOT. What is the reason for this , any ideas, and solutions? Best regards, Devrim Baris Acar ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] image quality with pyramids (with gdal_retile)
I never use gdal_retile, but i use gdaladdo. It's perfect and there's no qualtity degradation. gdaladdo create one tiff (or other format if you want) overview, containing different level. Syntax : gdaladdo -ro filename 2 4 8 16 32 http://www.gdal.org/gdaladdo.html 2011/3/15 Devrim Baris Acar devrimba...@gmail.com Hi, I am building a pyramid from a 650 MB geotiff file (rgb) , with the following command from fwtools 2.4.6 on a win32 box gdal_retile -levels 5 -pyramidOnly -targetDir pyramid bathymetry. I loaded these image files to geoserver and see that when I zoomed to the higheest available level, the images are degraded in quality in comparison to original one. Also , I expected that the resulting pyramid size to be bigger than the original file size, but it is NOT. What is the reason for this , any ideas, and solutions? Best regards, Devrim Baris Acar ___ 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
[gdal-dev] Many files over the network
Thanks Even. Yes it is GeoTIFF. This is the first time I've ever looked at the GDAL source, so I am not sure what the faster version we have was actually doing regarding metadata files. I know that by commenting out the search for RPC files, I was able to get the image open time back down to what it was previously. It was taking a half second just to search for RPC files in the new version. I know the previous version I was using must NOT have been doing that, because the image open time previously was more like a tenth of a second. I've not been using SVN (I do have a small bit of experience with Hg). I built GDAL from source code downloaded from Tamas Szekeres since that is where I am getting my GDAL binaries now. Do you have any suggestions on the best way for me to proceed to test your patch? Thanks, Kyle ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Many files over the network
Selon Kyle Ellison kelli...@geocue.com: Thanks Even. Yes it is GeoTIFF. This is the first time I've ever looked at the GDAL source, so I am not sure what the faster version we have was actually doing regarding metadata files. I know that by commenting out the search for RPC files, I was able to get the image open time back down to what it was previously. It was taking a half second just to search for RPC files in the new version. I know the previous version I was using must NOT have been doing that, because the image open time previously was more like a tenth of a second. I've not been using SVN (I do have a small bit of experience with Hg). I built GDAL from source code downloaded from Tamas Szekeres since that is where I am getting my GDAL binaries now. Do you have any suggestions on the best way for me to proceed to test your patch? Use one of the source packages tagged -devel as they reflect SVN head. You should be able to apply the patch cleanly over it. Thanks, Kyle ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Where is this nmake.opt file located?
Hi All I am using FWTools.Can anyone tell me where is this nmake.opt file located on our system?if its not there then how to get it?(As i want to configure oracle spatial with GDAL) please reply soon. Thanks and regards Natasha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange issue on debian squeeze
Oliver, Can you confirm if you have xerces headers in /etc/include directory? On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger oliver@googlemail.comwrote: I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit server. I'm using the following configure: ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes Installed are: libxerces-c-dev 3.1.1-1+b1 libxerces-c3.1 3.1.1-1+b1 out of the debian repositories. And I'm getting the following output from configure: checking for Xerces C++ Parser headers in /usr/include and /usr/include/xercesc... not found checking for Xerces C++ Parser... no Xerces-C support: no The same happens e.g. with expat and openjpeg. It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. Do you have any idea, what is happening here? Thanks, Oliver ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange issue on debian squeeze
On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: Oliver, Can you confirm if you have xerces headers in /etc/include directory? That should probably say /usr/include directory, in case that was not obvious. -Steve On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger oliver@googlemail.com mailto:oliver@googlemail.com wrote: I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit server. I'm using the following configure: ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes Installed are: libxerces-c-dev 3.1.1-1+b1 libxerces-c3.1 3.1.1-1+b1 out of the debian repositories. And I'm getting the following output from configure: checking for Xerces C++ Parser headers in /usr/include and /usr/include/xercesc... not found checking for Xerces C++ Parser... no Xerces-C support: no The same happens e.g. with expat and openjpeg. It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. Do you have any idea, what is happening here? Thanks, Oliver ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ 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] Many files over the network
Even, I tried out the patch. I was unable to actually try it in the 1.9 source since my environment uses the C# bindings and gdal18.dll. So, I applied the patch manually to the 1.8 version I had. That was not terribly difficult... mainly just different line numbers in geotiff.cpp. Anyway, we got the performance of yesteryear back. I would very much like you to commit that change to the main trunk if that is possible. Thanks for your help on this. Best Regards, Kyle -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Monday, March 14, 2011 5:41 PM To: gdal-dev@lists.osgeo.org Cc: Kyle Ellison Subject: Re: [gdal-dev] Many files over the network Kyle, you didn't mention which driver was in question. I guess this is GeoTIFF ? I've looked at the code of the driver and it appears that it loads the .rpb and .imd files at least since GDAL 1.6.0. The new thing in GDAL 1.8.0 is that it also tries to load the _rpc.txt file. Is it that small difference which causes the slowdown you observe ? In fact, setting GDAL_DISABLE_READDIR_ON_OPEN = TRUE might make things actually worse (w.r.t to that aspect of loading rpb/rpc/imd) since the driver has to really test the filesystem to look for the existence of the files, whereas by default it would rely on the papszSiblingsFile list. Anyway, I've attached a patch (against SVN trunk) that differs the loading of RPC and IMD until necessary (that is to say when GetMetadata() or GetMetadataItem() is called with RPC or IMD metadata domain, or when GetFileList() is called). Could you try it and report if it makes things better for you ? Another idea to solve the performance problem would be to use an alternate GDALOpen() where you could provide the papszSiblingFile list. If you read several files in the same directory, you could build the list one and provide it multiple times afterwards. Best regards, Even Often, we need to open many raster files over a network connection with thousands of other files residing in the same directory. Previously, we were using version 1.7.0 of GDAL (from FW Tools), and we used SetConfigOption(GDAL_DISABLE_READDIR_ON_OPEN, TRUE) to suppress the automatic search for sibling files. This approach served us well. We upgraded to 1.8.0. It was quite a bit slower opening the raster files. I was able to get GDAL built in debug and stepped through the code and discovered the following: 1. It searches for several files containing RPC metadata. 2. It searches for files for PAM as well. I was able to use SetConfigOption(GDAL_PAM_ENABLED, NO) to suppress searching for PAM files. However, I do not see a way to suppress searching for RPC metadata. Does anyone know of a way to do this or other workarounds? If there is no way to currently do this, is the community open to adding this option? I apologize if this question has been posted previously, but I haven't yet found a convenient way to search the archives. Thanks, Kyle ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Many files over the network
Le mardi 15 mars 2011 22:48:16, Kyle Ellison a écrit : Even, I tried out the patch. I was unable to actually try it in the 1.9 source since my environment uses the C# bindings and gdal18.dll. So, I applied the patch manually to the 1.8 version I had. That was not terribly difficult... mainly just different line numbers in geotiff.cpp. Anyway, we got the performance of yesteryear back. I would very much like you to commit that change to the main trunk if that is possible. Thanks for your help on this. Would you mind opening a GDAL Trac ticket to record this ? Thanks Best Regards, Kyle -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Monday, March 14, 2011 5:41 PM To: gdal-dev@lists.osgeo.org Cc: Kyle Ellison Subject: Re: [gdal-dev] Many files over the network Kyle, you didn't mention which driver was in question. I guess this is GeoTIFF ? I've looked at the code of the driver and it appears that it loads the .rpb and .imd files at least since GDAL 1.6.0. The new thing in GDAL 1.8.0 is that it also tries to load the _rpc.txt file. Is it that small difference which causes the slowdown you observe ? In fact, setting GDAL_DISABLE_READDIR_ON_OPEN = TRUE might make things actually worse (w.r.t to that aspect of loading rpb/rpc/imd) since the driver has to really test the filesystem to look for the existence of the files, whereas by default it would rely on the papszSiblingsFile list. Anyway, I've attached a patch (against SVN trunk) that differs the loading of RPC and IMD until necessary (that is to say when GetMetadata() or GetMetadataItem() is called with RPC or IMD metadata domain, or when GetFileList() is called). Could you try it and report if it makes things better for you ? Another idea to solve the performance problem would be to use an alternate GDALOpen() where you could provide the papszSiblingFile list. If you read several files in the same directory, you could build the list one and provide it multiple times afterwards. Best regards, Even Often, we need to open many raster files over a network connection with thousands of other files residing in the same directory. Previously, we were using version 1.7.0 of GDAL (from FW Tools), and we used SetConfigOption(GDAL_DISABLE_READDIR_ON_OPEN, TRUE) to suppress the automatic search for sibling files. This approach served us well. We upgraded to 1.8.0. It was quite a bit slower opening the raster files. I was able to get GDAL built in debug and stepped through the code and discovered the following: 1. It searches for several files containing RPC metadata. 2. It searches for files for PAM as well. I was able to use SetConfigOption(GDAL_PAM_ENABLED, NO) to suppress searching for PAM files. However, I do not see a way to suppress searching for RPC metadata. Does anyone know of a way to do this or other workarounds? If there is no way to currently do this, is the community open to adding this option? I apologize if this question has been posted previously, but I haven't yet found a convenient way to search the archives. Thanks, Kyle ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange issue on debian squeeze
I can reproduce this feature/bug on a freshly installed minimal squeeze having nothing than downloaded gdal-source using # ./configure --with-xerces=yes --with-xerces-inc=/usr/include/ --with-xerces-lib=/usr/lib/ and having installed i libxerces-c-dev v libxerces-c3-dev v libxerces-c3-doc v libxerces-c3-samples i libxerces-c3.1 providing libxerces-c-3.1.so libxerces-c.a libxerces-c.la libxerces-c.so in /usr/lib and providing a bunch of *.hpp in subfolders of /usr/include/xercesc Marco Am 15.03.2011 20:15, schrieb Stephen Woodbridge: On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: Oliver, Can you confirm if you have xerces headers in /etc/include directory? That should probably say /usr/include directory, in case that was not obvious. -Steve On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger oliver@googlemail.com mailto:oliver@googlemail.com wrote: I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit server. I'm using the following configure: ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes Installed are: libxerces-c-dev 3.1.1-1+b1 libxerces-c3.1 3.1.1-1+b1 out of the debian repositories. And I'm getting the following output from configure: checking for Xerces C++ Parser headers in /usr/include and /usr/include/xercesc... not found checking for Xerces C++ Parser... no Xerces-C support: no The same happens e.g. with expat and openjpeg. It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. Do you have any idea, what is happening here? Thanks, Oliver ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange issue on debian squeeze
Le mardi 15 mars 2011 23:49:30, Marco Lechner - FOSSGIS e.V. a écrit : I can reproduce this feature/bug on a freshly installed minimal squeeze having nothing than downloaded gdal-source using Well, I've just installed a virtual machine with a Debian Squeeze 64 bit and installed libxerces-c-dev and ibxerces-c3.1 All : You don't need to provide any argument at all. ./configure will automagically find xerces (at least for Debian and most other popular distros) Marco : If you want to provide the arguments, you must be aware that the -- with-xerces-lib must be followed with the linker flags and not the library path. So it should be : ./configure --with-xerces=yes --with-xerces- inc=/usr/include/ --with-xerces-lib=-lxerces-c Oliver : stupid question, but did you check if g++ is installed. Not recognizing xerces (which has a C++ API) would be a typical symtom of an absence of g++. Admitedly, GDAL ./configure should error out loudly at the very moment where it can't find a c++ compiler... # ./configure --with-xerces=yes --with-xerces-inc=/usr/include/ --with-xerces-lib=/usr/lib/ and having installed i libxerces-c-dev v libxerces-c3-dev v libxerces-c3-doc v libxerces-c3-samples i libxerces-c3.1 providing libxerces-c-3.1.so libxerces-c.a libxerces-c.la libxerces-c.so in /usr/lib and providing a bunch of *.hpp in subfolders of /usr/include/xercesc Marco Am 15.03.2011 20:15, schrieb Stephen Woodbridge: On 3/15/2011 2:23 PM, Chaitanya kumar CH wrote: Oliver, Can you confirm if you have xerces headers in /etc/include directory? That should probably say /usr/include directory, in case that was not obvious. -Steve On Tue, Mar 15, 2011 at 11:13 PM, Oliver Burger oliver@googlemail.com mailto:oliver@googlemail.com wrote: I have a strange problem installing gdal-1.8.0 on a debian squeeze 64bit server. I'm using the following configure: ./configure --prefix=/usr/local/gdal-1.8.0 --with-xerces=yes Installed are: libxerces-c-dev 3.1.1-1+b1 libxerces-c3.1 3.1.1-1+b1 out of the debian repositories. And I'm getting the following output from configure: checking for Xerces C++ Parser headers in /usr/include and /usr/include/xercesc... not found checking for Xerces C++ Parser... no Xerces-C support: no The same happens e.g. with expat and openjpeg. It's working all right on a Ubuntu 32bit and a Mandriva 32bit machine. Do you have any idea, what is happening here? Thanks, Oliver ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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 ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Calculate footprints of shapefiles
Hi all I would like to catalogue shapefiles scattered over lots of directories of the file system and store retrievable information of the shapefiles in a PostGIS layer. Extracting parameters like extent, projection, fields, etc works very fine with GDAL's Python bindings. But I would also like to store a sort of footprint of the whole shapefile as a geometry object since the extent is a bit coarse geographic representation of the shapefile. So far I have no better idea than eg. for polygon shapefiles looping through all features, applying a Union function on them. And at the end trying to use the Simplify method on the resulting polygon that will be used as the footprint. This is for sure not very efficient for larger shapefiles with lots of records. And for line and point shapefiles I still don't have a clue how their records could be represented by an enclosing polygon (maybe the Boundary functions does something like this...). Any ideas how this footprint generation could be achieved in a feasible way using GDAL/OGR Python? Cheers, Armin ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Calculate footprints of shapefiles
Armin, Not sure if this would be straightforward in GDAL but you might want to consider a combination of GDAL + Shapely (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). What you're trying to do is spatial analysis not directly implemented in GDAL. Shapely requires that you're working with Cartesian coordinates. The upside is that it has WKT/WKB support for direct loading into PostGIS. -marius On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: Hi all I would like to catalogue shapefiles scattered over lots of directories of the file system and store retrievable information of the shapefiles in a PostGIS layer. Extracting parameters like extent, projection, fields, etc works very fine with GDAL's Python bindings. But I would also like to store a sort of footprint of the whole shapefile as a geometry object since the extent is a bit coarse geographic representation of the shapefile. So far I have no better idea than eg. for polygon shapefiles looping through all features, applying a Union function on them. And at the end trying to use the Simplify method on the resulting polygon that will be used as the footprint. This is for sure not very efficient for larger shapefiles with lots of records. And for line and point shapefiles I still don't have a clue how their records could be represented by an enclosing polygon (maybe the Boundary functions does something like this...). Any ideas how this footprint generation could be achieved in a feasible way using GDAL/OGR Python? Cheers, Armin ___ 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] Calculate footprints of shapefiles
Marius, thanks for the suggestion. I don't know if shapely supports re-projection of geometries or has a simplify algorithm, which I will both need. There could be some other functions of GDAL/OGR that I might need in the future as well. So in principal I'd prefer to stick to GDAL. armin On 16/03/2011 01:35, Marius Jigmond wrote: Armin, Not sure if this would be straightforward in GDAL but you might want to consider a combination of GDAL + Shapely (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). What you're trying to do is spatial analysis not directly implemented in GDAL. Shapely requires that you're working with Cartesian coordinates. The upside is that it has WKT/WKB support for direct loading into PostGIS. -marius On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: Hi all I would like to catalogue shapefiles scattered over lots of directories of the file system and store retrievable information of the shapefiles in a PostGIS layer. Extracting parameters like extent, projection, fields, etc works very fine with GDAL's Python bindings. But I would also like to store a sort of footprint of the whole shapefile as a geometry object since the extent is a bit coarse geographic representation of the shapefile. So far I have no better idea than eg. for polygon shapefiles looping through all features, applying a Union function on them. And at the end trying to use the Simplify method on the resulting polygon that will be used as the footprint. This is for sure not very efficient for larger shapefiles with lots of records. And for line and point shapefiles I still don't have a clue how their records could be represented by an enclosing polygon (maybe the Boundary functions does something like this...). Any ideas how this footprint generation could be achieved in a feasible way using GDAL/OGR Python? Cheers, Armin ___ 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
[gdal-dev] netCDF to Shapefile
Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7 GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] netCDF to Shapefile
Manuel, Shapefile is for vector formats alone. Try a raster format to convert the netCDF data. As for the performance, you don't need to cache anything. But it may help to tweak the GDAL_CACHEMAX setting. http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer manuelrai...@hotmail.comwrote: Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7 GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] netCDF to Shapefile
Thanks for your help, it has to be a Shapefile because we do some further processing (symbology, map creation...). The netCDF file contains hydrodynamics point data. Best regards Manuel Date: Wed, 16 Mar 2011 09:32:16 +0530 Subject: Re: [gdal-dev] netCDF to Shapefile From: chaitanya...@gmail.com To: manuelrai...@hotmail.com CC: gdal-dev@lists.osgeo.org Manuel, Shapefile is for vector formats alone. Try a raster format to convert the netCDF data. As for the performance, you don't need to cache anything. But it may help to tweak the GDAL_CACHEMAX setting. http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer manuelrai...@hotmail.com wrote: Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7 GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Calculate footprints of shapefiles
Armin, This can be done in either OGR or PostGIS. For OGR, refer to the OGRGeometry class reference, especially the ConvexHull(), Union() and UnionCascaded() functions. For PostGIS, ST_Boundary() and ST_Union(). On Wed, Mar 16, 2011 at 6:23 AM, Armin Burger armin.bur...@gmx.net wrote: Marius, thanks for the suggestion. I don't know if shapely supports re-projection of geometries or has a simplify algorithm, which I will both need. There could be some other functions of GDAL/OGR that I might need in the future as well. So in principal I'd prefer to stick to GDAL. armin On 16/03/2011 01:35, Marius Jigmond wrote: Armin, Not sure if this would be straightforward in GDAL but you might want to consider a combination of GDAL + Shapely (http://gispython.org/shapely/docs/1.2/manual.html#cascading-unions). What you're trying to do is spatial analysis not directly implemented in GDAL. Shapely requires that you're working with Cartesian coordinates. The upside is that it has WKT/WKB support for direct loading into PostGIS. -marius On Wed, 2011-03-16 at 01:08 +0100, Armin Burger wrote: Hi all I would like to catalogue shapefiles scattered over lots of directories of the file system and store retrievable information of the shapefiles in a PostGIS layer. Extracting parameters like extent, projection, fields, etc works very fine with GDAL's Python bindings. But I would also like to store a sort of footprint of the whole shapefile as a geometry object since the extent is a bit coarse geographic representation of the shapefile. So far I have no better idea than eg. for polygon shapefiles looping through all features, applying a Union function on them. And at the end trying to use the Simplify method on the resulting polygon that will be used as the footprint. This is for sure not very efficient for larger shapefiles with lots of records. And for line and point shapefiles I still don't have a clue how their records could be represented by an enclosing polygon (maybe the Boundary functions does something like this...). Any ideas how this footprint generation could be achieved in a feasible way using GDAL/OGR Python? Cheers, Armin ___ 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 -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] netCDF to Shapefile
Hi Manuel, I think you will still need to be more specific. You've indicated that the data is points, but not what the variables in the file are, which variables need to be interrogated for coordinates vs. values, what their dimensions are, whether you want several shapefiles, or just one with (say) multiple attributes, etc. There are a number of ways to convert such data to shapefile, but it might be best to choose a reasonably easy scripting language to do it, such as Python or R - and so there are probably better forums than this for your problem. Either way you'll need to provide a lot more detail - it's likely to be a two step process, with converting the NetCDF grids to tables (in memory or file), and then those to point shapefiles. Cheers, Mike. On Wed, Mar 16, 2011 at 3:17 PM, Manuel Rainer manuelrai...@hotmail.com wrote: Thanks for your help, it has to be a Shapefile because we do some further processing (symbology, map creation...). The netCDF file contains hydrodynamics point data. Best regards Manuel Date: Wed, 16 Mar 2011 09:32:16 +0530 Subject: Re: [gdal-dev] netCDF to Shapefile From: chaitanya...@gmail.com To: manuelrai...@hotmail.com CC: gdal-dev@lists.osgeo.org Manuel, Shapefile is for vector formats alone. Try a raster format to convert the netCDF data. As for the performance, you don't need to cache anything. But it may help to tweak the GDAL_CACHEMAX setting. http://trac.osgeo.org/gdal/wiki/FAQRaster#Howtoimprovegdalwarpperfomance On Wed, Mar 16, 2011 at 8:21 AM, Manuel Rainer manuelrai...@hotmail.com wrote: Hi, I would like to convert certain time slices (records) out of a netCDF file to a Shapefile. The netCDF file has 7 GB, so what is the best proceed to get an appropriate performance? I mean, should the data be cached (e.g. in an ASCII file, ...) before writing a Shapefile or can the shp directly be generated? Perhaps you have some experiences... Thanks for your help! Best regards Manuel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
