All, Related to this . . .
>From our perspective, which was to allow for the most flexibilty with regard >to queries in the size of the images, we were willing to sacrifice the highest >level of performance. Most of the effort here was in organizing the tiles >(tree index) behind the MapServer service. Setting up the Mapfiles to >generally drop pixels vs interpolating them (adding new ones) was a big piece >of the performance issue in our configuration for example. Simply setting the >MIN/MAX scale params accordingly helped a great deal. MapServer (and most >other products BTW), seems to be better at dropping pixels (reducing the image >size) on the fly, vs interpolating to add them in to scale the image up. >There is still some pxel replacement going on, but generally making an image >smaller is faster than scaling one up. Since we wanted to be able to query for >any image size, we concentrated on setting up Mapserver to build from a tree >index as fast as possible. This is our mainstay setup at this point and how all services run in production mode. Our biggest bottleneck recently is network lag. I'm looking at the various tiling conventions as well for caching, probably a dynamic on demand caching system would be best in the end, and there is no reason this couldn't be applied to our current setup as a front end to tile based clients. One big reason we went with the architecture that we did, was to allow for high resolution importing for our AutoCAD based online customers for raster imagery and such. There were also some groups of layer data that would prove much to costly to implement as separately configured cartographic layers as web services, See this layer output for example: http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=563896.8404047444%20154119.8027878841%20568990.907012015%20157551.40786712753&mapsize=1146%20772&mode=map ( http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=563896.8404047444%20154119.8027878841%20568990.907012015%20157551.40786712753&mapsize=1146%20772&mode=map ) http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=565159.2094367743%20155007.330481188%20567467.6297618784%20156562.39199164204&mapsize=1146%20772&mode=map ( http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=565159.2094367743%20155007.330481188%20567467.6297618784%20156562.39199164204&mapsize=1146%20772&mode=map ) http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=566363.9818826721%20153592.63001268354%20568111.2314970943%20154769.66029395218&mapsize=1146%20772&mode=map ( http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=566363.9818826721%20153592.63001268354%20568111.2314970943%20154769.66029395218&mapsize=1146%20772&mode=map ) http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=567200.2527496096%20153998.18707850928%20568073.8775568207%20154586.7022191436&mapsize=1146%20772&mode=map ( http://gis.ci.stpaul.mn.us/datasets/RASTER/SAINT_PAUL/PUBLIC_WORKS/PROPERTY/property_public.map?mapext=567200.2527496096%20153998.18707850928%20568073.8775568207%20154586.7022191436&mapsize=1146%20772&mode=map ) These layers (there's 50 plus ion there for example) would be a bear to maintain. So I decided to cheat and use a raster presentation layer instead that is generated automatically from our ACAD DWGs. These were major considerations for our design of the system, and may not apply to your situation. bobb >>> Jason Birch <ja...@jasonbirch.com> wrote: I've often wondered if power-of-two was the best approach from a perception viewpoint. It definitely makes the most sense from a code perspective. Anyone know of any research on this? On 2010-05-22, Christopher Schmidt <crschm...@crschmidt.net> wrote: > On Fri, May 21, 2010 at 06:24:26PM -0300, Fabio Renzo Panettieri wrote: >> On Fri, 2010-05-21 at 13:17 -0700, Karsten-3-2 wrote: >> > Yes. What I want to do is simply to find out the fastest options to >> > render on >> > the fly from raw data imagery >> > (no tiles whatsoever stored on disk in addition to the raw data ). I >> > will >> > check out what SpatialCache is... > > >From raw aerial imagery: > 1. Store everything as uncompressed tiffs. > 2. Make images as large as possible. (This probably requires BigTIFF > support.) > 3. Use overviews -- usually one for every power-of-two level from the base > image up to the point where you have 256 x 256 overviews > (gdaladdo) > 4. If you have too many images to make one large image practical, create > one reduced size image that you use at lower zoom levels. > > All of this is based around serving with MapServer. I have no experience > using other imagery servers to solve this problem. > > Regards, > -- > Christopher Schmidt > Web Developer > _______________________________________________ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
