Re: [gdal-dev] tileindex performance

[christian . mueller]

Hi guys, I am the developer of the gdal_retile. Using gdal_retile on  
very large images only makes sense if you plan to import your tiles  
into a jdbc database. Serving images from so many files is not  
recommended.


I tested on an AIX Box, tiling an 80 GB Erdas image. The performance  
decrease was due to the increasing number of files in the file system.  
I had about 1 million of individual files. Deleting or moving this  
file set was a reason for drinking a cup of coffee. (15 - 30 minutes).  
And we are talking here from an AIX Box having a JFS file system and  
fast server disks.


Please check this symptom in your environment, look for the number of  
files you have created and the performance.


I am interested if this symptom occurs on your platforms too.

Cheers
Christian


Quoting Elijah Robison :


Hi Nikos,

I also have difficulty tiling large, high res images with gdal_retile.
I would say our average process--a county-wide, 1-foot resolution
ECW--takes about a month to run to completion.

At first, tiles are generated with blazing speed.  But by the time the
routine has been running for about 24-hours, it slows to a crawl.  Is
this the symptoms you are experiencing or are you running into
something else?

I would very much love to get to the bottom of this and find a way to
maintain the original performance throughout a tiling routine.

Best, Elijah Robison


nickos85 wrote:

Hi,

I have a mapserver and a high resolution image about 4GB when i make the
image tiles with a size of 512x512 using gdal_retile I have better result
instead of a tile size of 256x256. I think the problem is on how the search
algorithm for the location of the tile can be improoved. Any suggestions?

--Nikos Hatzopoulos

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev





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

[gdal-dev] Java swig binding wont comile.

[Michael Pascoe]

Hello,

I am trying to get GDAL building and working for the purpose of converting 
various scanned historic maps to the JPEG2000 format and also to georeference 
these images.

I downloaded gdal-1.7.2 and it built fine on (Red Hat 3.4.5-2). I then 
attempted to build the java swig bindings for GDAL using the directions at this 
page:

http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix

I got the following errors when I ran make:


mkdir -p org/gdal/gdal
mkdir -p org/gdal/gdalconst
mkdir -p org/gdal/ogr
mkdir -p org/gdal/osr
/bin/sh /users/developers/ilismaps/GDAL/gdal-1.7.2/libtool --mode=compile 
--tag=CXX g++ -fno-strict-aliasing -g -O2  -Wall -Wdeclaration-after-statement  
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/port 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/gcore 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/alg 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/ogr 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/ogr/ogrsf_frmts 
-I/usr/java/jdk1.5.0_10/include -I/usr/java/jdk1.5.0_10/include/linux -c 
gdal_wrap.cpp
libtool: compile:  g++ -fno-strict-aliasing -g -O2 -Wall 
-Wdeclaration-after-statement -I/users/developers/ilismaps/GDAL/gdal-1.7.2/port 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/gcore 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/alg 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/ogr 
-I/users/developers/ilismaps/GDAL/gdal-1.7.2/ogr/ogrsf_frmts 
-I/usr/java/jdk1.5.0_10/include -I/usr/java/jdk1.5.0_10/include/linux -c 
gdal_wrap.cpp  -fPIC -DPIC -o .libs/gdal_wrap.o
cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid 
for C/ObjC but not for C++
gdal_wrap.cpp: In function `_jstring* 
Java_org_gdal_gdal_gdalJNI_get_1Driver_1ShortName(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:4194: error: `GDALDriverShadow_get_ShortName' was not declared in 
this scope
gdal_wrap.cpp:4194: warning: unused variable 'GDALDriverShadow_get_ShortName'
gdal_wrap.cpp: In function `_jstring* 
Java_org_gdal_gdal_gdalJNI_get_1Driver_1LongName(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:4211: error: `GDALDriverShadow_get_LongName' was not declared in 
this scope
gdal_wrap.cpp:4211: warning: unused variable 'GDALDriverShadow_get_LongName'
gdal_wrap.cpp: In function `_jstring* 
Java_org_gdal_gdal_gdalJNI_get_1Driver_1HelpTopic(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:4228: error: `GDALDriverShadow_get_HelpTopic' was not declared in 
this scope
gdal_wrap.cpp:4228: warning: unused variable 'GDALDriverShadow_get_HelpTopic'
gdal_wrap.cpp: In function `jlong 
Java_org_gdal_gdal_gdalJNI_Driver_1CreateCopy(JNIEnv*, _jclass*, jlong, 
_jstring*, jlong, jint, _jobject*, _jobject*)':
gdal_wrap.cpp:4378: error: `sProgressInfo' was not declared in this scope
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_GCPsToGeoTransform(JNIEnv*, _jclass*, 
_jobjectArray*, _jdoubleArray*, jint)':
gdal_wrap.cpp:5397: warning: cast to pointer from integer of different size
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_get_1Dataset_1RasterXSize(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:6501: error: `GDALDatasetShadow_get_RasterXSize' was not declared 
in this scope
gdal_wrap.cpp:6501: warning: unused variable 'GDALDatasetShadow_get_RasterXSize'
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_get_1Dataset_1RasterYSize(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:6516: error: `GDALDatasetShadow_get_RasterYSize' was not declared 
in this scope
gdal_wrap.cpp:6516: warning: unused variable 'GDALDatasetShadow_get_RasterYSize'
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_get_1Dataset_1RasterCount(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:6531: error: `GDALDatasetShadow_get_RasterCount' was not declared 
in this scope
gdal_wrap.cpp:6531: warning: unused variable 'GDALDatasetShadow_get_RasterCount'
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_Dataset_1BuildOverviews(JNIEnv*, _jclass*, jlong, 
_jstring*, _jintArray*, _jobject*)':
gdal_wrap.cpp:6750: error: `sProgressInfo' was not declared in this scope
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_Dataset_1SetGCPs(JNIEnv*, _jclass*, jlong, 
_jobjectArray*, _jstring*)':
gdal_wrap.cpp:6891: warning: cast to pointer from integer of different size
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_Band_1GetHistogram_1_1SWIG_10(JNIEnv*, _jclass*, 
jlong, jdouble, jdouble, _jintArray*, jboolean, jboolean, _jobject*)':
gdal_wrap.cpp:7859: error: `sProgressInfo' was not declared in this scope
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_Band_1GetDefaultHistogram(JNIEnv*, _jclass*, jlong, 
_jdoubleArray*, _jdoubleArray*, _jobjectArray*, jboolean, _jobject*)':
gdal_wrap.cpp:8076: error: `sProgressInfo' was not declared in this scope
gdal_wrap.cpp: In function `jint 
Java_org_gdal_gdal_gdalJNI_get_1Band_1XSize(JNIEnv*, _jclass*, jlong)':
gdal_wrap.cpp:8123: error: `GDALRasterBandShadow_get_XSize' was not declared in 
this scope
gdal_wrap.cpp:8123: warning: unused va

[gdal-dev] Re: geoPDF file "not recognized as a supported format" by GDAL1.8dev ?

[Tim Osborn]

Is there a prebuilt Windows 32-bit executable for Gdal Development 1.8
available for download anywhere?  I would love to try the new geospatial pdf
capability but don't really have the necessary expertise to build Gdal from
code.

Thanks

Tim Osborn
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-geoPDF-file-not-recognized-as-a-supported-format-by-GDAL1-8dev-tp5636448p5637475.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdaldem color-relief color_text_files

[Mark Millman]

I am in need of some color_text files to use with the gdaldem color-relief
utility to create color relief versions of Slope, Aspect, Roughness, TRI, &
TPI maps.  I seems to me that these ought to be pretty standard and as my
skill set is on the developer side rather than the cartographer side of
things I am hoping that some generous cartographer out there has already
created some eye candy quality color_text_files for this purpose.

 

Thanks in advance.  Mark

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geoPDF file "not recognized as a supported format" by GDAL1.8dev ?

[Matt Wilkie]

yes, GDAL should be able to read geoPDF topo files from the USGS. (geospatial
PDF is more neutral term than geoPDF that happens to be a trademark


This is great news, thanks!

-matt
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building with PDF driver on Windows + ?

[Joaquim Luis]

Thanks, this is obsolete now. I've just removed that. This dates back to when
KMLSUPEROVERLAY needed external minizip. Now minizip has been imported in GDAL
source tree and this is no longer needed.
   


Nice. So I got two for the price of one.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building with PDF driver on Windows + ?

[Even Rouault]

Le jeudi 14 octobre 2010 23:23:51, Joaquim Luis a écrit :
> Did I mention before that the propeller (sorry, poppler) doesn't have
> any building instructions for Windows?
> 
> Well, the CMakeLists.txt is incomplete and does not add the contents of
> the "splash" directory to the project. After adding all *.cc from
> 'splash' to project, GDAL is happy with the poppler.lib and now gdalinfo
> says

Cool!

> 
> ...
>KMLSUPEROVERLAY (rw): Kml Super Overlay
>XYZ (rwv): ASCII Gridded XYZ
>HF2 (rwv): HF2/HFZ heightfield raster
>PDF (rov): Geospatial PDF
> 
> but I'm now confused with the presence of the KMLSUPEROVERLAY because my
> nmake.opt has
> 
> # Uncomment out the following to enable KML Super-Overlay support.
> #KMLSUPEROVERLAY_SUPPORTED = YES
> #MINIZIP_INCLUDE = -I$(OSSIM_HOME)\minizip\src
> #MINIZIP_LIBRARY = $(OSSIM_HOME)\minizip\release\minizip.lib
> 
> 
> Not complaining. Just reporting.

Thanks, this is obsolete now. I've just removed that. This dates back to when 
KMLSUPEROVERLAY needed external minizip. Now minizip has been imported in GDAL 
source tree and this is no longer needed.

> 
> Joaquim
> 
> > On 14-10-2010 18:32, Even Rouault wrote:
> >> Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit :
> >>> Hi,
> >>> 
> >>> I tried to build GDAL on Win with PDF support and CV2010
> >>> 
> >>> Well that's an adventure.
> >> 
> >> I trust you and didn't even try this way.
> >> 
> >> Instead I just downloaded the kde-win32 installer, used the "packager
> >> mode"
> >> (or whatever it is called. I'm just quoting from my memory of doing
> >> this a few
> >> weeks ago), and selected the poppler, freetype and lcms packages and
> >> their
> >> developement packages. The only requirement for GDAL is poppler,
> >> freetype and
> >> lcms appears to be poppler requirements on this KDE build. But those
> >> lib only
> >> work with MSVC 2008 if I remember.
> > 
> > Even,
> > 
> > Hmm, on a further check those symbols are from poppler so it's not a
> > lcms fault.
> > I get another error building poppler referring iconv.h that I ignore
> > either but selected as a no dependency in CMake, but this affect the
> > creation of a poppler-cpp.lib, not poppler.lib so I'm not sure it
> > relates to the GDAL error.
> > I would like to build these dependencies myself because:
> > 
> > 1. I don't want to use anything that dares to create manifests
> > dependencies
> > 2. I want to be able to build 64 bits versions too.
> > 
> > Anyway, I found these warnings too that are unrelated to this PDF
> > driver issue
> > 
> > json_util.c
> > json_util.c(62) : warning C4013: 'open' undefined; assuming extern
> > returning int
> > json_util.c(71) : warning C4013: 'read' undefined; assuming extern
> > returning int
> > json_util.c(74) : warning C4013: 'close' undefined; assuming extern
> > returning int
> > json_util.c(109) : warning C4013: 'write' undefined; assuming extern
> > returning int
> > 
> > ogrsf_frmts.lib(resolvexlinks.obj) : warning LNK4221: This object file
> > does not define any previously undefined public symbols, so it will
> > not be used by any link operation that consumes this library
> > 
> > and many "blabla ... possible loss of data" warnings.
> > 
> > 
> > ___
> > 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] building with PDF driver on Windows + ?

[Joaquim Luis]

Did I mention before that the propeller (sorry, poppler) doesn't have 
any building instructions for Windows?


Well, the CMakeLists.txt is incomplete and does not add the contents of 
the "splash" directory to the project. After adding all *.cc from 
'splash' to project, GDAL is happy with the poppler.lib and now gdalinfo 
says


...
  KMLSUPEROVERLAY (rw): Kml Super Overlay
  XYZ (rwv): ASCII Gridded XYZ
  HF2 (rwv): HF2/HFZ heightfield raster
  PDF (rov): Geospatial PDF

but I'm now confused with the presence of the KMLSUPEROVERLAY because my 
nmake.opt has


# Uncomment out the following to enable KML Super-Overlay support.
#KMLSUPEROVERLAY_SUPPORTED = YES
#MINIZIP_INCLUDE = -I$(OSSIM_HOME)\minizip\src
#MINIZIP_LIBRARY = $(OSSIM_HOME)\minizip\release\minizip.lib


Not complaining. Just reporting.

Joaquim





On 14-10-2010 18:32, Even Rouault wrote:

Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit :

Hi,

I tried to build GDAL on Win with PDF support and CV2010

Well that's an adventure.

I trust you and didn't even try this way.

Instead I just downloaded the kde-win32 installer, used the "packager 
mode"
(or whatever it is called. I'm just quoting from my memory of doing 
this a few
weeks ago), and selected the poppler, freetype and lcms packages and 
their
developement packages. The only requirement for GDAL is poppler, 
freetype and
lcms appears to be poppler requirements on this KDE build. But those 
lib only

work with MSVC 2008 if I remember.


Even,

Hmm, on a further check those symbols are from poppler so it's not a 
lcms fault.
I get another error building poppler referring iconv.h that I ignore 
either but selected as a no dependency in CMake, but this affect the 
creation of a poppler-cpp.lib, not poppler.lib so I'm not sure it 
relates to the GDAL error.

I would like to build these dependencies myself because:

1. I don't want to use anything that dares to create manifests 
dependencies

2. I want to be able to build 64 bits versions too.

Anyway, I found these warnings too that are unrelated to this PDF 
driver issue


json_util.c
json_util.c(62) : warning C4013: 'open' undefined; assuming extern 
returning int
json_util.c(71) : warning C4013: 'read' undefined; assuming extern 
returning int
json_util.c(74) : warning C4013: 'close' undefined; assuming extern 
returning int
json_util.c(109) : warning C4013: 'write' undefined; assuming extern 
returning int


ogrsf_frmts.lib(resolvexlinks.obj) : warning LNK4221: This object file 
does not define any previously undefined public symbols, so it will 
not be used by any link operation that consumes this library


and many "blabla ... possible loss of data" warnings.


___
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] geoPDF file "not recognized as a supported format" by GDAL1.8dev ?

[Even Rouault]

Boris

yes, GDAL should be able to read geoPDF topo files from the USGS. (geospatial 
PDF is more neutral term than geoPDF that happens to be a trademark... see 
"Important Note" in http://en.wikipedia.org/wiki/Geospatial_PDF. no further 
comment...)

First, did you check that PDF is listed when doing :

$ gdalinfo --formats

If not, then GDAL configure hasn't found poppler. You should check that you 
have a /usr/include/poppler directory and a /usr/lib/libpoppler.so file, or if 
you have installed them in another root (./configure --enable-xpdf-headers --
prefix=/some/path) , you should specify this directory as value of --with-
poppler=/some/path

If yes, then you should provide a link to the file that causes problem so I can 
see what's wrong with it

Le jeudi 14 octobre 2010 21:24:38, Boris Dev a écrit :
> A GDAL doc  says GDAL1.8 handles
> geospatial PDF file (which I assume are the same as geoPDF topo files of
> the USGS).
> 
> The problem is that after compiling GDAL1.8 from source GDAL doesn't
> recognize my geoPDF file.
> 
> When I try both of the following:
> 
> $gdalinfo my_geopdf.pdf
> 
> $gdal_translate my_geopdf.pdf
> 
> It returns:
> 
> ERROR 4: 'my_geopdf.pdf' not recognized as a supported format"
> 
> When compiling GDAL and POPPLER (which is also needed for this problem) I
> made sure to do the following:
> 
> gdal$./configure --with-poppler=yes --with-python
> 
> poppler$./configure --enable-xpdf-headers
> 
> ...any suggestions on where I am going wrong with this?
> 
> I am new to using GDAL.
> 
> My final objective to to extact the geoPDF images as jpegs and somehow
> extract the latitude/longitude bounding box information of the image so I
> can create KMLs.
> 
> THANKS!!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] geoPDF file "not recognized as a supported format" by GDAL1.8dev ?

[Boris Dev]

A GDAL doc  says GDAL1.8 handles
geospatial PDF file (which I assume are the same as geoPDF topo files of the
USGS).

The problem is that after compiling GDAL1.8 from source GDAL doesn't
recognize my geoPDF file.

When I try both of the following:

$gdalinfo my_geopdf.pdf

$gdal_translate my_geopdf.pdf

It returns:

ERROR 4: 'my_geopdf.pdf' not recognized as a supported format"

When compiling GDAL and POPPLER (which is also needed for this problem) I
made sure to do the following:

gdal$./configure --with-poppler=yes --with-python

poppler$./configure --enable-xpdf-headers

...any suggestions on where I am going wrong with this?

I am new to using GDAL.

My final objective to to extact the geoPDF images as jpegs and somehow
extract the latitude/longitude bounding box information of the image so I
can create KMLs.

THANKS!!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building with PDF driver on Windows

[Joaquim Luis]

On 14-10-2010 18:32, Even Rouault wrote:

Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit :
   

Hi,

I tried to build GDAL on Win with PDF support and CV2010

Well that's an adventure.
 

I trust you and didn't even try this way.

Instead I just downloaded the kde-win32 installer, used the "packager mode"
(or whatever it is called. I'm just quoting from my memory of doing this a few
weeks ago), and selected the poppler, freetype and lcms packages and their
developement packages. The only requirement for GDAL is poppler, freetype and
lcms appears to be poppler requirements on this KDE build. But those lib only
work with MSVC 2008 if I remember.
   


Even,

Hmm, on a further check those symbols are from poppler so it's not a 
lcms fault.
I get another error building poppler referring iconv.h that I ignore 
either but selected as a no dependency in CMake, but this affect the 
creation of a poppler-cpp.lib, not poppler.lib so I'm not sure it 
relates to the GDAL error.

I would like to build these dependencies myself because:

1. I don't want to use anything that dares to create manifests dependencies
2. I want to be able to build 64 bits versions too.

Anyway, I found these warnings too that are unrelated to this PDF driver 
issue


json_util.c
json_util.c(62) : warning C4013: 'open' undefined; assuming extern 
returning int
json_util.c(71) : warning C4013: 'read' undefined; assuming extern 
returning int
json_util.c(74) : warning C4013: 'close' undefined; assuming extern 
returning int
json_util.c(109) : warning C4013: 'write' undefined; assuming extern 
returning int


ogrsf_frmts.lib(resolvexlinks.obj) : warning LNK4221: This object file 
does not define any previously undefined public symbols, so it will not 
be used by any link operation that consumes this library


and many "blabla ... possible loss of data" warnings.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: Geomedia mdb files

[Rasmus Debitsch]

You may find a description of the Geomedia BLOB format at 
http://www.mygeomedia.com/articles/gdoblobs.asp. A more detailed description 
should be available via the Intergraph synergy program 
(http://synergy.intergraph.com/).


Rasmus 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building with PDF driver on Windows

[Even Rouault]

Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit :
> Hi,
> 
> I tried to build GDAL on Win with PDF support and CV2010
> 
> Well that's an adventure.

I trust you and didn't even try this way.

Instead I just downloaded the kde-win32 installer, used the "packager mode" 
(or whatever it is called. I'm just quoting from my memory of doing this a few 
weeks ago), and selected the poppler, freetype and lcms packages and their 
developement packages. The only requirement for GDAL is poppler, freetype and 
lcms appears to be poppler requirements on this KDE build. But those lib only 
work with MSVC 2008 if I remember.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] tileindex performance

[Elijah Robison]

Hi Nikos,

I also have difficulty tiling large, high res images with gdal_retile.  
I would say our average process--a county-wide, 1-foot resolution 
ECW--takes about a month to run to completion.


At first, tiles are generated with blazing speed.  But by the time the 
routine has been running for about 24-hours, it slows to a crawl.  Is 
this the symptoms you are experiencing or are you running into something 
else?


I would very much love to get to the bottom of this and find a way to 
maintain the original performance throughout a tiling routine.


Best, Elijah Robison


nickos85 wrote:

Hi,

I have a mapserver and a high resolution image about 4GB when i make the
image tiles with a size of 512x512 using gdal_retile I have better result
instead of a tile size of 256x256. I think the problem is on how the search
algorithm for the location of the tile can be improoved. Any suggestions?

--Nikos Hatzopoulos 
  

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] tileindex performance

[Frank Warmerdam]

nickos85 wrote:

Hi,

I have a mapserver and a high resolution image about 4GB when i make the
image tiles with a size of 512x512 using gdal_retile I have better result
instead of a tile size of 256x256. I think the problem is on how the search
algorithm for the location of the tile can be improoved. Any suggestions?


Nikos,

Did you spatially index your tile index?  The tileindex should be spatially
indexed with shptree.

What sorts of map requests are you making?  Are they made at near full
resolution or are they overviews?

I'm generally not a fan of tiling with gdal_retile, and prefer to make one,
or a few, large files internally tiled with overviews.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] tileindex performance

[nickos85]

Hi,

I have a mapserver and a high resolution image about 4GB when i make the
image tiles with a size of 512x512 using gdal_retile I have better result
instead of a tile size of 256x256. I think the problem is on how the search
algorithm for the location of the tile can be improoved. Any suggestions?

--Nikos Hatzopoulos 
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/tileindex-performance-tp5635751p5635751.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] building with PDF driver on Windows

[Joaquim Luis]

Hi,

I tried to build GDAL on Win with PDF support and CV2010

Well that's an adventure. Instructions on how to build poppler are 
completely absent (but there is on CMake list file that we may try to 
guess what's essential from the optional stuff).  Building free type 
raised an error somewhere (something about an already defined INT32)


Next, there was this error (easily fixed with a pair of '/')

C:/programs/compa_libs/poppler\goo/gtypes.h(31) : error C2371: 'GBool' : 
redefinition; different bas ic types

..\..\port\cpl_port.h(169) : see declaration of 'GBool'

But finally I stopped at the errors bellow. I see in the nmake.opt that 
it links also against liblcms-1.lib. I don't know this one but Google 
seams indicate that it is
"Little CMS (color management engine)". Is that so? And the errors below 
are they explained by the fact that I'm not linking against this lib?

Clearly, we need a bit more info on how build with PDF support.

Thanks

Joaquim



lib /nologo /out:gdal.lib port\*.obj gcore\*.obj alg\*.obj 
frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib
ogrsf_frmts.lib(resolvexlinks.obj) : warning LNK4221: This object file 
does not define any previously undefined public symbols, so it will not 
be used by any link operation that consumes this library
link /nologo /dll /INCLUDE:_OGRFeatureStylePuller  
/INCLUDE:_OSRValidate  /INCLUDE:_OPTGetPr
ojectionMethods  /INCLUDE:_OGR_G_GetPointCount  /INCLUDE:_OGRRegisterAll 
/INCLUDE:_gdalsimpleimagew...@36  /INCLUDE:_gdalreprojectim...@48  
/INCLUDE:_gdalcomputemediancut...@32  /INCLUDE:_gdalditherrgb2...@28  
/INCLUDE:_octnewcoordinatetransformat...@8  port\*.obj gcore\*.obj 
alg\*.obj frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib 
ogr\ogr.lib  
C:\programs\compa_libs\hdf-4.2.5\compileds\vc10_32\lib\hm425m.lib 
C:\programs\compa_libs\hdf-4.2.5\compileds\vc10_32\lib\hd425m.lib 
Ws2_32.lib  
c:\programs\Geo_DSDK-7.0.0.2167\lib\Release_md\lti_dsdk_dll.lib 
advapi32.lib user32.lib
C:\progs_cygw\netcdf-3.6.3\compileds\VC10_32\lib\libnetcdf.lib 
C:\programs\proj4\compileds\VC10_32\lib\proj_i.lib 
C:\programs\compa_libs\hdf5-1.8.4-patch1\compileds\vc10_32\dll\hdf5dll.lib 
C:\program
s\compa_libs\curl-7.20.0\compileds\vc10_32/lib/libcurl_imp.lib 
wsock32.lib wldap32.lib winmm.lib
 
C:\programs\compa_libs\poppler\buildVC2010_32\Release/poppler.lib 
C:\programs\compa_libs\freetype-2.4.3\objs\win32\vc2008\freetype243.lib 
advapi32.lib gdi32.lib gcore\Version.res  /out:gdal17.dll /implib:gdal_i.lib
   Creating library gdal_i.lib and object gdal_i.exppdfdataset.obj : 
error LNK2019: unresolved external symbol "public: void __thiscall 
PDFDoc::displayP
ageSlice(class OutputDev 
*,int,double,double,int,int,int,int,int,int,int,int,int (__cdecl*)(void *),
void *,int (__cdecl*)(class Annot *,void *),void *)" 
(?displaypagesl...@pdfdoc@@QAEXPAVOutputDev@@HN
np6ah...@z1p6ahpavannot@@1...@z1@Z) referenced in function "public: 
virtual enum CPLErr __thisc
all PDFRasterBand::IReadBlock(int,int,void *)" 
(?ireadbl...@pdfrasterband@@UAE?AW4CPLErr@@hh...@z)
pdfdataset.obj : error LNK2019: unresolved external symbol "public: 
__thiscall SplashOutputDev::SplashOutputDev(enum 
SplashColorMode,int,int,unsigned char *,int,int)" 
(??0SplashOutputDev@@q...@w4splashcolormode@@hhpa...@z) referenced in 
function "public: virtual enum CPLErr __thiscall PDFRasterBand::
IReadBlock(int,int,void *)" 
(?ireadbl...@pdfrasterband@@UAE?AW4CPLErr@@hh...@z)

gdal17.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\link.EXE"' :

 return code '0x460'
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Error in gml reader.

[Ralf Suhr]

Hello List,

I am working with gml v3 data. Sometimes coordiantes like 712345.082 
5432000.318 become 712345.082 5432 when using the postgres database driver. 
But everthing is correct when using the new pg_dump driver. The gml data is 
read by nas driver who used gml driver for converting geometrys.

I have created a ticket.

Gr
Ralf
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev