[Geomoose-users] Estimating tile size

Mon Mar 11 03:54:27 PDT 2013

Hello Mark,

thanks, we will try Mapcache until new Openlayers version is completed.

Regards,
Matej Serc

2013/3/5 Mark Volz <MarkVolz at co.lyon.mn.us>

>  Hello,****
>
> ** **
>
> I think this has more to do with Openlayers, which GeoMOOSE uses to
> display maps on the client side.  GeoMOOSE uses Openlayers 2.x, which to my
> knowledge, does not load load tiles in this way.  I think the next version
> of Openlayers, which is in development will subsample existing tiles so
> that there is never any white space on the map.  I don’t remember what the
> presentation is called, however I think it is on youtube.  In the meantime
> I have been quite satisfied with mapcache, which is included with some
> Mapserver installations. It takes about 16ms to 100ms to serve tiles.****
>
> ** **
>
> ** **
>
> ** **
>
> Mark Volz****
>
> GIS Specialist****
>
> ** **
>
> *From:* geomoose-users-bounces at lists.osgeo.org [mailto:
> geomoose-users-bounces at lists.osgeo.org] *On Behalf Of *Matej Mailing
> *Sent:* Tuesday, March 05, 2013 7:41 AM
> *To:* Paul Wickman
>
> *Cc:* geomoose-users at lists.osgeo.org
> *Subject:* Re: [Geomoose-users] Estimating tile size****
>
>  ** **
>
> Hi,
>
> this is almost like spamming, but it is related to the issue: Google Maps
> for example shows very rough rasters when zooming and then loads more
> details when you stop zooming or moving. We also have a number of
> installations where such raster's display (first rough and then detailed)
> would be very useful. Can this be done with GM and perhaps more Mapserver?
>
> Thanks,****
>
> Matej****
>
> ** **
>
> 2013/1/30 Paul Wickman <paul at flatrockgeo.com>****
>
> Thanks for the spreadsheet, Jim.  That helps a lot.****
>
> ** **
>
> On Wed, Jan 30, 2013 at 10:07 AM, James Klassen <klassen.js at gmail.com>
> wrote:****
>
> I'd guess is in JPEGs you are looking at ~23GB and about 346GB
> uncompressed for all levels.  The top level (most pixels) will be ~2/3 the
> size of all of the levels combined.  I've attached a spreadsheet (ODS) that
> I've worked up to estimate tile sizes.  (My guess is it will get blocked by
> the list, so if anyone is interested email me.)****
>
> ** **
>
> Which tool you use kind of depends on how you plan on serving it.  Direct
> from MapServer has a different optimization strategy than if you are using
> MapCache or MapProxy.  I'm not sure how portable the tools I worked on are.
>  The one I did at the city was all in C and was essentially a modified
> shp2img with the tile calculation added and some extra stuff removed.  What
> I am using now is ruby based and relies on PostGIS for indexes and
> MapServer for rendering.  The net result is the same though.****
>
> ** **
>
> The big thing quality wise it to be sure to use -r average (GDAL) or
> PROCESSING "RESAMPLE=AVERAGE" (mapserver) so the zoomed out levels aren't
> all speckled as happens when using the default nearest neighbor sampling.*
> ***
>
> ** **
>
> On Tue, Jan 29, 2013 at 1:25 PM, Basques, Bob (CI-StPaul) <
> bob.basques at ci.stpaul.mn.us> wrote:****
>
> Paul,****
>
>  ****
>
> The fastest approach has and seems to still be using MapServer to generate
> the tiles, via a script.  Jim K. has even verified this within the last
> couple of weeks, since he tried improving on the original system we used
> here and came back to it in the end with some minor upgrades.****
>
>  ****
>
> It doesn’t really matter how you get there, even if it takes a little
> longer.  I think there are some MapServer utilities that we used originally
> on this layer.  You may want to experiment for yourself on what works best
> for what.****
>
>  ****
>
> Also, in our experience, we’ve had best results using Jpeg (NOT
> JPEG2000!!) for aerials and PNGs for overlay tiles.****
>
>  ****
>
> Bobb****
>
>  ****
>
>  ****
>
> *From:* Paul Wickman [mailto:paul at flatrockgeo.com]
> *Sent:* Tuesday, January 29, 2013 1:18 PM
> *To:* Basques, Bob (CI-StPaul)
> *Cc:* Brent Fraser; geomoose-users at lists.osgeo.org****
>
>
> *Subject:* Re: [Geomoose-users] Estimating tile size****
>
>  ****
>
> Thank you kindly, Bob.  Did you use gdal2tiles.py or is there another
> utility you like better?****
>
>  ****
>
> On Tue, Jan 29, 2013 at 1:08 PM, Basques, Bob (CI-StPaul) <
> bob.basques at ci.stpaul.mn.us> wrote:****
>
> Paul,****
>
>  ****
>
> For reference, I’m looking at a layer here for the City, about 56sq mi
> coverage at 6in pxels.  Using Jpeg tiles, 1000x1000pxels (500x500 ground
> units).****
>
>  ****
>
> Keep in mind that the City is not a rectangle . . . but the levels break
> down like so:****
>
>  ****
>
> (L0) ~27,000 tiles = 1.5 GB****
>
> (L1) ~ 4500 tiles = 420MB****
>
> (L2) ~ 1140 Tiles = 123MB****
>
> (L3) ~ 293 tiles = 35MB****
>
> (L4) ~ 83 tiles = 9.4MB****
>
> (L5) ~ 28 tiles = 2.5MB****
>
>  ****
>
> These were generated from MRSID files originally, so I can’t give you a
> number on disksize, since MRSIDs are basically compiled Pyramids to begin
> with.  I have some other layers that started as flat rasters such as your
> TIFFs if you want me to put something together for those, let me know.****
>
>  ****
>
> Bobb****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* geomoose-users-bounces at lists.osgeo.org [mailto:
> geomoose-users-bounces at lists.osgeo.org] *On Behalf Of *Paul Wickman
> *Sent:* Tuesday, January 29, 2013 11:28 AM
> *To:* Brent Fraser
> *Cc:* geomoose-users at lists.osgeo.org
> *Subject:* Re: [Geomoose-users] Estimating tile size****
>
>  ****
>
> Yes, bytes.  Zowie...   I have a TIFF of an air photo for one of our other
> municipalities (also 6-inch resolution), which is 20 GB (uncompress).  That
> coverage is only ~40 square miles.  So, for a single ~800 square mile
> county also at 6-inch resolution I'd potentially be looking at 400 GB for
> the uncompressed source or...  somewhere on the order of ~800 GB tiled?
>  Does that sound right?****
>
>  ****
>
> Anybody from MnGeo on this list with any input?****
>
>  ****
>
> On Tue, Jan 29, 2013 at 11:15 AM, Brent Fraser <bfraser at geoanalytic.com>
> wrote:****
>
> Do you mean how many bytes?
>
> Looking at my Landsat tile pyramids (levels 4 to 12), they're about the
> same number of bytes (hmm, I expected them to be double...)
>
> But my source images:
>     - no compression on existing files (tiffs, e.g not jpeg)
>     - 3 band (color) imagery
>
> The resulting tiles:
>     - compressed PNGs
>     - four bands (one alpha channel for transparency)
>
> So  my guess is somewhere between "same size" to "double the number of
> bytes" (unless the source imagery is compressed, then it will be 5 to 10
> times larger)****
>
> Best Regards,****
>
> Brent Fraser****
>
>  On 1/28/2013 5:53 PM, Paul Wickman wrote:****
>
>   Greetings, ****
>
>  ****
>
> I know this type of question goes around often in various flavors.
>  Difficult to estimate exact size of rendered tiles, but thought I'd try to
> get some opinions.****
>
>  ****
>
> I see this questions asked in a variety of ways and I know it's not
> exactly precise on how to get the answer, but I'll throw my question out to
> see what I get ;)****
>
>  ****
>
> We have a client who would like us to tile and serve up high-resolution
> aerial photography that they own. The area is about 800 square miles and
> the imagery is 6-inch resolution. They'd like to be able to view the
> imagery at zoom levels 11 through 20 (with level 20 being 1 pixel=6
> inches). Is there any way at all to determine how large a resulting raster
> tile set might be?****
>
>  ****
>
> Many thanks,****
>
>   Paul****
>
>  ****
>
> --
> Paul Wickman
> CTO | Flat Rock Geographics
> 612.280.5850 | paul at flatrockgeo.com
> www.flatrockgeo.com | twitter.com/flatrockgeo ****
>
>  ****
>
> _______________________________________________****
>
> Geomoose-users mailing list****
>
> Geomoose-users at lists.osgeo.org****
>
> http://lists.osgeo.org/mailman/listinfo/geomoose-users****
>
>   ****
>
>
>
> ****
>
>  ****
>
> --
> Paul Wickman
> CTO | Flat Rock Geographics
> 612.280.5850 | paul at flatrockgeo.com
> www.flatrockgeo.com | twitter.com/flatrockgeo ****
>
>
>
> ****
>
>  ****
>
> --
> Paul Wickman
> CTO | Flat Rock Geographics
> 612.280.5850 | paul at flatrockgeo.com
> www.flatrockgeo.com | twitter.com/flatrockgeo ****
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Paul Wickman
> CTO | Flat Rock Geographics
> 612.280.5850 | paul at flatrockgeo.com
> www.flatrockgeo.com | twitter.com/flatrockgeo ****
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20130311/e7f57c35/attachment-0001.html>