[Geomoose-users] Estimating tile size

Wed Jan 30 08:51:00 PST 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20130130/f5581c76/attachment.html>