From mikel_maron at yahoo.com Wed Apr 26 06:58:02 2006 From: mikel_maron at yahoo.com (Mikel Maron) Date: Wed Apr 26 06:58:07 2006 Subject: [tiling] OnEarth tiling description correction Message-ID: <20060426105802.71523.qmail@web30812.mail.mud.yahoo.com> It's been pointed out that my description of the OnEarth tiling scheme had an error. Specifically, the negative sign on Latitude values was omitted! Mea culpa. For clarity, the lowest resolution level request should be: http://wms.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/jpeg&styles=&width=512&height=512&bbox=-180,-166,76,90 http://wms.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/jpeg&styles=&width=512&height=512&bbox=76,-166,332,90 The next level tiles are [-180,-38,-52,90] [-52,-38,76,90] [76,-38,204,90] [-180,-166,-52,-38] [-52,-166,76,-38] [76,-166,204,-38] A very compact description of the scheme is ... Tile size 512x512, JPEG, coverage [-180,-90,180,90], top-left aligned, lowest resolution 256 degrees per tile, highest resolution 2**-5 degrees per tile. The tile locations are a direct result of the top-left alignment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20060426/ff1792b5/attachment.htm From paul.neave at gmail.com Wed Apr 26 07:20:25 2006 From: paul.neave at gmail.com (Paul Neave) Date: Wed Apr 26 07:20:29 2006 Subject: [tiling] OnEarth tiling description correction In-Reply-To: <20060426105802.71523.qmail@web30812.mail.mud.yahoo.com> References: <20060426105802.71523.qmail@web30812.mail.mud.yahoo.com> Message-ID: Hi Mikel and group, I'm not sure if this is the correct group (or even person) to ask, but is it possible to set the tile image's JPEG compression quality settings via the wms.cgi request? I notice you can pass format=image/jpeg but if we could pass in quality=60 (or something similar, say compression=60) that would be fantastic as it could speed up the download times of the tile server, especially if image quality can be sacrificed for speed. Thanks for any info, Paul. On 26/04/06, Mikel Maron wrote: > > It's been pointed out that my description of the OnEarth tiling scheme had > an error. Specifically, the negative sign on Latitude values was omitted! > Mea culpa. > > For clarity, > > the lowest resolution level request should be: > http://wms.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/jpeg&styles=&width=512&height=512&bbox=-180,-166,76,90 > http://wms.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/jpeg&styles=&width=512&height=512&bbox=76,-166,332,90 > > The next level tiles are > [-180,-38,-52,90] [-52,-38,76,90] [76,-38,204,90] > [-180,-166,-52,-38] [-52,-166,76,-38] [76,-166,204,-38] > > A very compact description of the scheme is ... > > Tile size 512x512, JPEG, coverage [-180,-90,180,90], top-left aligned, > lowest resolution 256 degrees per tile, highest resolution 2**-5 degrees per > tile. > > The tile locations are a direct result of the top-left alignment. > > _______________________________________________ > tiling mailing list > tiling@lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > From adoyle at eogeo.org Wed Apr 26 09:12:30 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Wed Apr 26 09:45:31 2006 Subject: [tiling] OnEarth tiling description correction In-Reply-To: References: <20060426105802.71523.qmail@web30812.mail.mud.yahoo.com> Message-ID: <58EC37E6-E696-4CBA-B787-0EF2F142358C@eogeo.org> Paul, You probably want to try wms-dev if you want to talk about general WMS things. http://lists.eogeo.org/mailman/listinfo/wms-dev Allan On Apr 26, 2006, at 07:20, Paul Neave wrote: > Hi Mikel and group, > > I'm not sure if this is the correct group (or even person) to ask, but > is it possible to set the tile image's JPEG compression quality > settings via the wms.cgi request? > > I notice you can pass format=image/jpeg but if we could pass in > quality=60 (or something similar, say compression=60) that would be > fantastic as it could speed up the download times of the tile server, > especially if image quality can be sacrificed for speed. > > Thanks for any info, > Paul. > > > On 26/04/06, Mikel Maron wrote: >> >> It's been pointed out that my description of the OnEarth tiling >> scheme had >> an error. Specifically, the negative sign on Latitude values was >> omitted! >> Mea culpa. >> >> For clarity, >> >> the lowest resolution level request should be: >> http://wms.jpl.nasa.gov/wms.cgi? >> request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/ >> jpeg&styles=&width=512&height=512&bbox=-180,-166,76,90 >> http://wms.jpl.nasa.gov/wms.cgi? >> request=GetMap&layers=global_mosaic&srs=EPSG:4326&format=image/ >> jpeg&styles=&width=512&height=512&bbox=76,-166,332,90 >> >> The next level tiles are >> [-180,-38,-52,90] [-52,-38,76,90] [76,-38,204,90] >> [-180,-166,-52,-38] [-52,-166,76,-38] [76,-166,204,-38] >> >> A very compact description of the scheme is ... >> >> Tile size 512x512, JPEG, coverage [-180,-90,180,90], top-left >> aligned, >> lowest resolution 256 degrees per tile, highest resolution 2**-5 >> degrees per >> tile. >> >> The tile locations are a direct result of the top-left alignment. >> >> _______________________________________________ >> tiling mailing list >> tiling@lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling >> >> >> > _______________________________________________ > tiling mailing list > tiling@lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > -- Allan Doyle +1.781.433.2695 adoyle@eogeo.org From steven.ottens at geodan.nl Fri Apr 28 07:19:06 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Apr 28 07:19:28 2006 Subject: [tiling] tiling discussion on webmap-discuss Message-ID: <1146223147.14951.42.camel@localhost.localdomain> Hi list, I thought you might be interested in the discussion on tiling happening on the webmap-discuss mailing list of osgeo: https://mail.osgeo.org/servlets/SummarizeList?listName=webmap-discuss (the thread is called OGC and Google style tiling) It discusses some of the issues with the implementation of tiling in current software (UMN mapserver, ka-map and mapbuilder). Also the more fundamental issues of tiling are being discussed. Cheers, Steven From bob.basques at ci.stpaul.mn.us Fri Apr 28 09:26:41 2006 From: bob.basques at ci.stpaul.mn.us (Blammo) Date: Fri Apr 28 09:26:51 2006 Subject: [tiling] [webmap-discuss] OGC and google style tiling Message-ID: <44521811.4030108@ci.stpaul.mn.us> All, Just to throw another wrench in . . . . I've been working with Tiles as a data source for many years now, long before Google showed the masses. Tiling here at the City has evolved in a slightly different direction. The main emphasis in the beginning was to increase the performance of the display of our first 6in pixel aerial photo dataset, which when delivered was a huge (at the time) dataset. Each of the 260 image tiles was a 40meg MrSID file. Just moving these things around the network started to cause problems the first week of use. Something had to be setup to more easily distribute the stuff. I had used some home brewed versions of tiling on my own within my own DHTML clients even before this, but only for a couple levels of resolution. This time around we would have 6-7 levels of resolution, all the way from city wide ~50k ft on the ground down to 500 ft on the ground per image tile result. The Idea of using these descrete levels of resolution for results was not our first choice and the earlier attempts at setting this up while they worked very effectively, as in fast, always left something to be desired when trying to fill a particular scaled view with a particular amount of data. Many times the end result had more buffer in the image than was desired since the next step in the resolution needed to be used to get the desired area of interest. The idea of getting the layer in only static scales was becoming more and more of a problem for our (business) needs, which required rather tight scale to view ratios. What I came up with was to put the tiling scheme behind the scenes, behind the map Service. Mapserver servers up a complete view dynamically from these tiled datasets behind the scenes by using the appropriate layer in the tile pyramid to render the composite tile to the screen. While there are server side hits in performance, this ended up with a net effect of running all tiled layers very quickly, since there were only ever four tiles being queried behind the scenes for any one request. From our experience, this runs very quickly. I haven't had time (in the last five or sx years to load test it properly :c) but it's in production now with very good results. I auctually built a tiler in AutoCAD with AutoLISP to get around the labelling problems. It also aloowed me to re-run the tiles repeatedly to tun them for size. I use 1000 pixel tiles exclusively behind the scenes at the moment. We push the display end of things to the screen limits, so 1000 pixels was approximately half of the 21in high def monitor sizes at the time. It still seem to work even across multiple head systems when the browser is stretched across them. The same capabilities could easily be implemented with a wrapper around mapserver as well. I can go into more detail and even show some things online, we only run an internal version of this at the moment, but I can set up a tunnel into the internal server if anyone is interested. What this really helped with in my opinion, was to leave the MapServer requesting mechanism in place and do the (pre-) processing as a dataset tuning task. I'm optimistic, that our service could be run like this for smaller tiles in a dynamic fashion and come very close performance wise to serving up a straight cached version of the tile via many server requests of smaller results. What I would like to see built into MapServer (and we may do it ourselve in the end) is a way for MapServer to tune a dataset in the fashion described by building the tiled data sceme automatically behind the scences, this would aid in upkeep as well, where dynamic data layers (yes we do some of this same stuff for larger databased housed data) can be automatically updated by running MapServer to reproduce the tile. bobb