Hi Ivan,<br><br><br><div class="gmail_quote">On Mon, Aug 16, 2010 at 6:02 AM, Lucena, Ivan <span dir="ltr"><<a href="mailto:ivan.lucena@pmldnet.com">ivan.lucena@pmldnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sebastian,<br>
<br>
I have this little piece of code in Python that shows how 18 levels of pyramids would look like:<br>
<br></blockquote><div>...<br>... <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">10 185 265 1 1 1049401<br>
11 92 132 1 1 1049402<br>
** What you don't have: **<br>
12 46 66 1 1 1049403<br>
13 23 33 1 1 1049404<br>
14 11 16 1 1 1049405<br>
15 5 8 1 1 1049406<br>
16 2 4 1 1 1049407<br>
17 1 2 1 1 1049408<br>
<br>
Where:<br>
<br>
<br></blockquote><div>...<br><br>...<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
You said that “it performs very well at zoom level under 12” and performs poorly with zoom level between 13 and 17.<br>
<br></blockquote><div><br>are MapServer/GoogleMaps zoom level exactly the same as Oracle PyramidLevels ?<br>
<br>
For example... in Oracle , Pyramid level 0 means maximum zoom... that in MapServer/GoogleMaps it would something like 20 ???<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The problem is that you don't have those levels built into your GeoRaster object.<br>
<br>
So, before doing any change to the system settings, could you please try to increase the number of pyramids to 17?<br>
<br>
Building the pyramids is a internal process on the server. Even if you use gdaladdo, that will just call a function from the GeoRaster PL/SQL extension.<br>
<br>
It wouldn't take as long as before because it will add up to the existing levels.<br>
<br>
The PL/SQL call should looks like that:<br>
<br>
declare<br>
gr sdo_georaster;<br>
begin<br>
select georaster into gr from fluvd04q200pj where id = 1 for update;<br>
sdo_geor.generatePyramid(gr, 'rlevel=17 resampling=NN');<br>
update fluvd04q200pj set georaster = gr where id = 1;<br>
commit;<br>
end;<br>
/<br>
<br></blockquote><div><br>
from Oracle documentation <br>
<br>
rLevel (for example, rLevel=2): Specifies the maximum reduction level: the<br>
number of pyramid levels to create at a smaller (reduced) size than the original<br>
object. If you do not specify this keyword, pyramid levels are generated until the<br>
smaller of the number of rows or columns is between 64 and 128. The dimension<br>
sizes at each lower resolution level are equal to the truncated integer values of the<br>
dimension sizes at the next higher resolution level, divided by 2.<br><br>I've ignored the Oracle documentation and I've run it anyway... It toked 0.5 seconds to run !<br><br>In my case that code would not create any pyramids as I have already run sdo_geor.generatePyramid(gr, 'resampling=NN'); which would build the maximun levels of pyramids...<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
And the gdaladdo command should look like that:<br>
<br>
gdaladdo georaster:geoserver,geoserver,MFPRODUK_11G,fluvd04q200pj,georaster,id=1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536<br>
<br>
Best regards,<br><font color="#888888">
<br>
Ivan</font><div><div></div><div class="h5"><br>
<br>
<br>
Sebastian E. Ovide wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Ivan,<br>
<br>
<br>
<br>
Yes!<br>
<br>
and<br>
<br>
No!<br>
<br>
That query creates a *cursor* to go through the whole raster,<br>
meaning, all the rows on the RasterDataTable that satisfy that query<br>
in the order stipulated by it.<br>
<br>
It does require a some memory but it looks like you got it. <br>
<br>
mmm... that makes me little bit nervous... I am testing it with a small map. Its is only UK with 5mx5m pixel.... Just wondering how this approach would scale to larger maps... US is 40 times bigger than UK... and they have more accurated maps.... and more than a single layer.... Just wondering how many manual configuration I'll be forced to do.... (Oracle created Spatial extention exactly for this reason... so the developer do not to think about handling blobs for him self anymore... reducing costs and risks)<br>
<br>
<br>
By the way, how long does it take to produce a geotiff file? Have<br>
loaded that image on QuantumGIS using the oracle_raster plugin? Hoes<br>
does it perform?<br>
<br>
<br>
it is not possible to create a TIFF as it would be too big (max size is 4GB)... and UK would be arounf 16GB (300MB in Oracle as I'm using deflate)<br>
<br>
I am testing Oracle MapViewer on the same table and it HAS the same problem.... The strange thing is that using MapBuilder (Oracle software to prepare the maps to use with MapViewer) the maps are displayed very fast at ANY zoom level !... therefore there is a way to do it fast (as MapBuilder does...)<br>
<br>
<br>
I was expecting to find in the logs some query that reads a<br>
subset of the whole image (just the tile/metatile that MapServer<br>
is serving) for example using SDO_GEOR.getRasterSubset..<br>
<br>
<br>
That would be very slow. The GDAL driver access the BLOB directly.<br>
<br>
not sure about that... well I guess that at least it releases some work from the Oracle server... Anyway, as I have a spatial index, why don't just query only the right blobs?<br>
<br>
<br>
I have more questions:<br>
<br>
Are you using Mapserver FastCGI with a recent version?<br>
<br>
<br>
nop... I have not tried that yet... I'll try on Monday... I have tried as cgi and recently as mod_python.<br>
<br>
If you do, them the process will remains in memory, the GDALDataset<br>
associated with that GeoRaster will be keet, the *cursor* you remain<br>
alive and all the zooms and pans are going to work faster. Like for<br>
QGIS. Unless, of course, Mapserver is feeling the need to re-project<br>
or produce a new overview tiles on the fly. Can you see that on the log?<br>
<br>
Regards,<br>
<br>
Ivan<br>
<br>
<br>
regards<br>
<br>
<br>
-- <br>
Sebastian E. Ovide<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sebastian E. Ovide<br><br><br><br><br>