[Geomoose-users] Estimating tile size

Tue Mar 5 05:40:43 PST 2013

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/20130305/32ecd188/attachment-0001.html>