From pspencer at dmsolutions.ca Wed May 3 21:39:21 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed May 3 21:39:29 2006 Subject: [tiling] questions/concerns about the wms tile caching proposal Message-ID: Hi folks, just found out about this list from irc this afternoon and thought I would toss in a couple of cents to see what kind of controversy I could spark :) It seems the primary purpose of the list centers around the http://wiki.osgeo.org/index.php/WMS_Tile_Caching page, although I am hoping that it might lead to some discussions on the practical issues of implementing tile services and tile clients. My comments are derived from my experience writing ka-Map, a tile- based map viewer. ka-Map includes a simple php-mapscript based tile server/cache but is actually mostly independent (as I demonstrated recently on the webmap-discuss list, it can be used with no server- side dependency by requesting wms tiles directly). I am very keen to ensure that the ka-Map API be compatible with whatever direction the open standards folks move in. Before you read on, I've realised that this has become quite lengthy. Not sure how to make this potential thread useable/ readable. Each section could easily be a thread on its own! But fire away and create new threads if you think it will be more readable/understandable/useful. My comments are in no particular order. First, I do not think it should be based on WMS GetMap requests. I believe that a Map and a Tile are semantically different things. A map is a whole, whereas a tile is a part of the whole. While using GetMap may seem convenient, it introduces a raft of problems, most of which have been encapsulated as 'constraints' in the proposal as written. As an alternative, I propose a new WMS request type, GetTile. GetTile can then be spec'd out to include the constraints noted without changing the meaning of the existing GetMap. It can also eliminate meaningless arguments such as STYLES. Second, there seems to be a consistent assumption that scales could be calculated using a quantization factor (2 seems to be the factor of choice). While this seems reasonable, my experience is that cartographic output does not necessarily fall into such neat scale ranges. The proposal needs to acknowledge this. My feeling is that the spec should provide for layer-specific scales. The use of specific scales brings up an issue that I don't understand well, but here goes. Different mapping engines use different algorithms and different basic assumptions to calculate scale (dpi, great circle distances, etc come to mind). The practical result of this is that a scale value in one WMS can mean something quite radically different in another. I have direct experience in this combining WMS layers from MapServer and CubeServ that were configured for the same scale ranges but didn't show properly near the limits of the ranges. One possible solution is to enforce a particular algorithm so that every compliant tile server produces the same result for a given scale. Third, a GetTile request (note my assumption that you will agree with point 1 :) should contain exactly one named entity to draw. I would say layer, but layer has different meaning to different folks. In many cases it is necessary for a tile client (at least a web-based one) to reduce the number of separate layers that are displayed because browser performance and network performance quickly becomes unacceptable. Ideally, many layers are combined into a single layer used as the 'base' set of tiles, and then specific layers are rendered individually depending on the purpose of the app. Rendering specific layers is only useful if you actually want to control layer visibility or opacity separately from that defined by the scale restrictions defined by the server (i.e. you want to turn a layer on/ off when it is in scale). Fourth, I think that caching and tile generation should be considered as separate issues. Being able to generate a tile (i.e. a piece of a map as opposed to the whole map) in a way that different clients can reliably find and ingest the tiles is very important to be set in stone. However, caching and distributed caching are implementation details that are not required to get the tiles to the client. Obviously caching is extremely important because without it, tiling becomes much less desirable. But tiling could easily be introduced anywhere from the client itself to the tile server. Fifth, on the subject of caching and the possibility of stale caches, I am starting to be of the opinion that the tile server needs to advertise a version for each tiled entity and that it is the responsibility of the client to request only valid versions. A versioning scheme could allow for multiple versions or a range (time support for instance) or a specific version. If the client is required to get the latest supported tile version for a given tile service/entity, then all requests will include the valid version and be unique. Any intermediate caching system would begin caching the new tiles and hopefully flush the old ones based on some least recently used algorithm (because stale tiles would not be requested ever again, except by misbehaving clients which would fail when hitting an uncached geographic area) Sixth, on the subject of caching and separation of tile generation from cache, it is conceivable and, in fact desirable, that tile clients would want to ingest data sources that need to be tiled (to be displayed) but that should not be cached for some reason. The tile service c/should advertise a CacheHint property that tile clients could use in some fashion. Some other thoughts/details I agree with Norm's assessment of the minimum request parameters being layer (or entity), scale, row and column. Row and column could be geographic coordinates of a corner (lower, left?) or an index based on the number of tiles available at a given scale. Um. I guess you could reduce row and column to a single number which would be num_columns * (row-1) + column. One thing missing that is a requirement for advertising a tile service is the need for an origin in row/column coordinates, which would likely be 0,0 to keep things simple. By this, I mean it is not enough to request a bbox and tile size, but the bbox must be restricted to the tile grid as well. I have found that using 0,0 for the bottom/left of one tile allows me to convert easily between display space (in pixels) and geographic space if I know the geographic size of a single pixel (which can be calculated from the scale - same problem I noted above about calculations though). There are many practical issues with tile generation as well. My biggest concern right now is with labeling across tile boundaries. Thanks for reading this far !!! Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Applications & Software Development | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From bob.basques at ci.stpaul.mn.us Thu May 4 00:09:47 2006 From: bob.basques at ci.stpaul.mn.us (Blammo) Date: Thu May 4 00:09:50 2006 Subject: [tiling] questions/concerns about the wms tile caching proposal In-Reply-To: References: Message-ID: <44597E8B.5070700@ci.stpaul.mn.us> It got bigger yet, sorry everyone. Paul Spencer wrote: > Hi folks, > > just found out about this list from irc this afternoon and thought I > would toss in a couple of cents to see what kind of controversy I > could spark :) It seems the primary purpose of the list centers > around the http://wiki.osgeo.org/index.php/WMS_Tile_Caching page, > although I am hoping that it might lead to some discussions on the > practical issues of implementing tile services and tile clients. > > My comments are derived from my experience writing ka-Map, a tile- > based map viewer. ka-Map includes a simple php-mapscript based tile > server/cache but is actually mostly independent (as I demonstrated > recently on the webmap-discuss list, it can be used with no server- > side dependency by requesting wms tiles directly). I am very keen to > ensure that the ka-Map API be compatible with whatever direction the > open standards folks move in. > > Before you read on, I've realised that this has become quite > lengthy. Not sure how to make this potential thread useable/ > readable. Each section could easily be a thread on its own! But > fire away and create new threads if you think it will be more > readable/understandable/useful. > > My comments are in no particular order. > > First, I do not think it should be based on WMS GetMap requests. I > believe that a Map and a Tile are semantically different things. A > map is a whole, whereas a tile is a part of the whole. While using > GetMap may seem convenient, it introduces a raft of problems, most of > which have been encapsulated as 'constraints' in the proposal as > written. As an alternative, I propose a new WMS request type, > GetTile. GetTile can then be spec'd out to include the constraints > noted without changing the meaning of the existing GetMap. It can > also eliminate meaningless arguments such as STYLES. I agree with this approach as well. Without going in to details, the WMS method of retrieval adds in more problems than it solves, especially in the long run. > > Second, there seems to be a consistent assumption that scales could > be calculated using a quantization factor (2 seems to be the factor > of choice). While this seems reasonable, my experience is that > cartographic output does not necessarily fall into such neat scale > ranges. The proposal needs to acknowledge this. My feeling is that > the spec should provide for layer-specific scales. Hmm, not so sure I agree with this, although I could be convinced that a dataset scale range value might be in order, where all the available scales are listed as a single retrievable value by the client. The result would indicate the scale of each available resolution level and possibly the spacing between them. The resolution changes could increase exponentially instead of just doubling for example. > > The use of specific scales brings up an issue that I don't understand > well, but here goes. Different mapping engines use different > algorithms and different basic assumptions to calculate scale (dpi, > great circle distances, etc come to mind). The practical result of > this is that a scale value in one WMS can mean something quite > radically different in another. I have direct experience in this > combining WMS layers from MapServer and CubeServ that were configured > for the same scale ranges but didn't show properly near the limits of > the ranges. One possible solution is to enforce a particular > algorithm so that every compliant tile server produces the same > result for a given scale. Another method (and throw something at me if I'm way off base here) would be to locate each tile based on the center (or other anchor point, and spread the error out around the edges. The tiles could overlap by a pixel or two to get rid of the errors for example. This brings up the question though of doing edge matched tiles vs Overlaping tiles. a buffer around the tile extents may be desireable in some configurations where a potential for a gap to appear might be possible. > > Third, a GetTile request (note my assumption that you will agree with > point 1 :) should contain exactly one named entity to draw. I would > say layer, but layer has different meaning to different folks. In > many cases it is necessary for a tile client (at least a web-based > one) to reduce the number of separate layers that are displayed > because browser performance and network performance quickly becomes > unacceptable. There may be some room in this statement for arguement, a simple CGI could stream a tile set for a particular extents in a predictable manner for example, and has the potential for incrasing performance and even aid in predictive rendering, I dragged from left to right two time in a row, lets paint the edge I've been heading in first based on the previous shift in view. > Ideally, many layers are combined into a single layer used as the > 'base' set of tiles, and then specific layers are rendered > individually depending on the purpose of the app. Rendering specific > layers is only useful if you actually want to control layer > visibility or opacity separately from that defined by the scale > restrictions defined by the server (i.e. you want to turn a layer on/ > off when it is in scale). More and more apps (mine included) are using this type of control and it's important to plan for I think. > > Fourth, I think that caching and tile generation should be considered > as separate issues. Being able to generate a tile (i.e. a piece of a > map as opposed to the whole map) in a way that different clients can > reliably find and ingest the tiles is very important to be set in > stone. However, caching and distributed caching are implementation > details that are not required to get the tiles to the client. Another piece missing here is dynamic datasets on the server side. While I haven't built a Tiled dataset such as this (yet), I can see the obvious benefits of using a tiled service that is updated automatically by the server (not based on browser requests, but rather by a change in the sourced dataset, RDBMs, or large SHP file or ??? > Obviously caching is extremely important because without it, tiling > becomes much less desirable. But tiling could easily be introduced > anywhere from the client itself to the tile server. Some layers that are highly dynamic (database layers for example) may be more suitable to being generated upon request. > > Fifth, on the subject of caching and the possibility of stale caches, > I am starting to be of the opinion that the tile server needs to > advertise a version for each tiled entity and that it is the > responsibility of the client to request only valid versions. A > versioning scheme could allow for multiple versions or a range (time > support for instance) or a specific version. Hmmm, makes me think of a few other possibilities with regard to this whole thread. Doing something as above, could be used as an animation technique in the client by playing the tiles of a GPS track for example. > If the client is required to get the latest supported tile version > for a given tile service/entity, then all requests will include the > valid version and be unique. Any intermediate caching system would > begin caching the new tiles and hopefully flush the old ones based on > some least recently used algorithm (because stale tiles would not be > requested ever again, except by misbehaving clients which would fail > when hitting an uncached geographic area) > > Sixth, on the subject of caching and separation of tile generation > from cache, it is conceivable and, in fact desirable, that tile > clients would want to ingest data sources that need to be tiled (to > be displayed) but that should not be cached for some reason. The > tile service c/should advertise a CacheHint property that tile > clients could use in some fashion. > > Some other thoughts/details > > I agree with Norm's assessment of the minimum request parameters > being layer (or entity), scale, row and column. Row and column could > be geographic coordinates of a corner (lower, left?) or an index > based on the number of tiles available at a given scale. Um. I > guess you could reduce row and column to a single number which would > be num_columns * (row-1) + column. What if I wanted to use a hexagonal pattern (remember you wanted to sir things up :c) I would need one more axis. Then if I went 3D with the same hexgonal approach, I would need 6 more axis to track. I'm going to do this some day, I swear. > > One thing missing that is a requirement for advertising a tile > service is the need for an origin in row/column coordinates, which > would likely be 0,0 to keep things simple. By this, I mean it is not > enough to request a bbox and tile size, but the bbox must be > restricted to the tile grid as well. I have found that using 0,0 for > the bottom/left of one tile allows me to convert easily between > display space (in pixels) and geographic space if I know the > geographic size of a single pixel (which can be calculated from the > scale - same problem I noted above about calculations though). > > There are many practical issues with tile generation as well. One thing I've been wanting to experiment with is CGI tiling based on number of elements in a tile. Where an attempt is made to build the same size files but with possible differing tile bounds and raster sizes. High density areas vs sparsely populated areas might be better off with smaller/larger tiles, or even no tile at all being generated (empty) > My biggest concern right now is with labeling across tile boundaries. Labels seem like something that can be generated fairly quickly, overlaying them using a larger tile size might be an option in some instances. bobb From adoyle at eogeo.org Thu May 4 10:25:56 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Thu May 4 10:25:59 2006 Subject: [tiling] questions/concerns about the wms tile caching proposal In-Reply-To: <44597E8B.5070700@ci.stpaul.mn.us> References: <44597E8B.5070700@ci.stpaul.mn.us> Message-ID: On May 4, 2006, at 00:09, Blammo wrote: > It got bigger yet, sorry everyone. > > Paul Spencer wrote: > >> Hi folks, >> >> just found out about this list from irc this afternoon and thought >> I would toss in a couple of cents to see what kind of controversy >> I could spark :) It seems the primary purpose of the list >> centers around the http://wiki.osgeo.org/index.php/ >> WMS_Tile_Caching page, although I am hoping that it might lead to >> some discussions on the practical issues of implementing tile >> services and tile clients. That page is a writeup by Schuyler after he, nhv, and I had an irc conversation on #eogeo. The list predates the wiki page and thus the list history more or less trumps the page. However, we can/should try to make the page become a reflection of the list. >> >> My comments are derived from my experience writing ka-Map, a tile- >> based map viewer. ka-Map includes a simple php-mapscript based >> tile server/cache but is actually mostly independent (as I >> demonstrated recently on the webmap-discuss list, it can be used >> with no server- side dependency by requesting wms tiles >> directly). I am very keen to ensure that the ka-Map API be >> compatible with whatever direction the open standards folks move in. >> >> Before you read on, I've realised that this has become quite >> lengthy. Not sure how to make this potential thread useable/ >> readable. Each section could easily be a thread on its own! But >> fire away and create new threads if you think it will be more >> readable/understandable/useful. >> >> My comments are in no particular order. >> >> First, I do not think it should be based on WMS GetMap requests. >> I believe that a Map and a Tile are semantically different >> things. A map is a whole, whereas a tile is a part of the >> whole. While using GetMap may seem convenient, it introduces a >> raft of problems, most of which have been encapsulated as >> 'constraints' in the proposal as written. As an alternative, I >> propose a new WMS request type, GetTile. GetTile can then be >> spec'd out to include the constraints noted without changing the >> meaning of the existing GetMap. It can also eliminate >> meaningless arguments such as STYLES. > > I agree with this approach as well. Without going in to details, > the WMS method of retrieval adds in more problems than it solves, > especially in the long run. I think there can be a general theory of tiling. But I believe that there needs to be a WMS manifestation of that theory. WMS instances abound in the wild, and I don't see it being very useful to develop yet another protocol. Furthermore, I believe that it's possible to do a WMS tiling scheme simply by constraining the WMS requests to (a) use a specific parameter ordering and (b) to only request specific BBOX/WIDTH/HEIGHT (BWH) combinations. See [A] below... > >> >> Second, there seems to be a consistent assumption that scales >> could be calculated using a quantization factor (2 seems to be >> the factor of choice). While this seems reasonable, my >> experience is that cartographic output does not necessarily fall >> into such neat scale ranges. The proposal needs to acknowledge >> this. My feeling is that the spec should provide for layer- >> specific scales. > > Hmm, not so sure I agree with this, although I could be convinced > that a dataset scale range value might be in order, where all the > available scales are listed as a single retrievable value by the > client. The result would indicate the scale of each available > resolution level and possibly the spacing between them. The > resolution changes could increase exponentially instead of just > doubling for example. > >> >> The use of specific scales brings up an issue that I don't >> understand well, but here goes. Different mapping engines use >> different algorithms and different basic assumptions to calculate >> scale (dpi, great circle distances, etc come to mind). The >> practical result of this is that a scale value in one WMS can >> mean something quite radically different in another. I have >> direct experience in this combining WMS layers from MapServer and >> CubeServ that were configured for the same scale ranges but >> didn't show properly near the limits of the ranges. One possible >> solution is to enforce a particular algorithm so that every >> compliant tile server produces the same result for a given scale. > > Another method (and throw something at me if I'm way off base > here) would be to locate each tile based on the center (or other > anchor point, and spread the error out around the edges. The > tiles could overlap by a pixel or two to get rid of the errors for > example. This brings up the question though of doing edge matched > tiles vs Overlaping tiles. a buffer around the tile extents may be > desireable in some configurations where a potential for a gap to > appear might be possible. I don't think scale based on scale-hint or perceived pixel size is the right way to think about tile scales. Tile scales should be based on the ratio of the BBOX to the WIDTH/HEIGHT. In particular, if you pick a specific tile size, say 256x256 pixels, then the BBOX should increase/decrease by factors of 2, or whatever factor people pick. > >> >> Third, a GetTile request (note my assumption that you will agree >> with point 1 :) should contain exactly one named entity to draw. >> I would say layer, but layer has different meaning to different >> folks. In many cases it is necessary for a tile client (at least >> a web-based one) to reduce the number of separate layers that are >> displayed because browser performance and network performance >> quickly becomes unacceptable. > > There may be some room in this statement for arguement, a simple > CGI could stream a tile set for a particular extents in a > predictable manner for example, and has the potential for incrasing > performance and even aid in predictive rendering, I dragged from > left to right two time in a row, lets paint the edge I've been > heading in first based on the previous shift in view. [A] I would argue that given the constraints of fixed argument order and specific BBOX/WIDTH/HEIGHT (BWH) values, a WMS request *becomes* a "named entity to draw". Don't be fooled by the "?" and "&" characters in the request. If you were to shut off any CGI mechanism, an httpd would be quite happy to look for a file in its space with a name identical to the request. I've tested this with Apache and it works just fine. As a thought experiment, realize that you can take a WMS request, copy it, paste it into the tinyurl.com URL generator, and get back a "named entity to draw" that happens to be a bit random. Try this: http://tinyurl.com/s9ftp > >> Ideally, many layers are combined into a single layer used as >> the 'base' set of tiles, and then specific layers are rendered >> individually depending on the purpose of the app. Rendering >> specific layers is only useful if you actually want to control >> layer visibility or opacity separately from that defined by the >> scale restrictions defined by the server (i.e. you want to turn a >> layer on/ off when it is in scale). > > More and more apps (mine included) are using this type of control > and it's important to plan for I think. Yes, this is true. The Demis mapserver can do this automatically and it's one of the nice things about their server. They worked hard to come up with a pleasing combination at various scales. However, you can use either individual layers or you can combine layers in a WMS. It's up to the provider. I think it would be ideal to not only develop a tiling scheme, but to also develop a set of "Well Known Layers" (WKL). There might be 5-10 WKLs. E.g. "Political", "Topographic", "Cities", "Local", etc. where Political does the right thing, like Demis, with country, state, etc. boundaries. "Topographic" is something like Landsat or BlueMarble. "Cities" shows nicely placed city dots and labels. "Local" shows roads like any of the GYM maps. Once you have the set of WKL's and the set of BWH's, it's a simple (!) matter of disk space. And this is where GYM shine. They have everything pre-rendered, on multiple disks no doubt, and can serve any WKL/BWH combination in milliseconds. Our community does have access to this kind of disk space and some rather fat pipes at Telascience... > >> >> Fourth, I think that caching and tile generation should be >> considered as separate issues. Being able to generate a tile >> (i.e. a piece of a map as opposed to the whole map) in a way that >> different clients can reliably find and ingest the tiles is very >> important to be set in stone. However, caching and distributed >> caching are implementation details that are not required to get >> the tiles to the client. > > Another piece missing here is dynamic datasets on the server side. > While I haven't built a Tiled dataset such as this (yet), I can see > the obvious benefits of using a tiled service that is updated > automatically by the server (not based on browser requests, but > rather by a change in the sourced dataset, RDBMs, or large SHP file > or ??? There can be cache validity parameters. Or some tiles can still be dynamic. > >> Obviously caching is extremely important because without it, >> tiling becomes much less desirable. But tiling could easily be >> introduced anywhere from the client itself to the tile server. > > Some layers that are highly dynamic (database layers for example) > may be more suitable to being generated upon request. > >> >> Fifth, on the subject of caching and the possibility of stale >> caches, I am starting to be of the opinion that the tile server >> needs to advertise a version for each tiled entity and that it is >> the responsibility of the client to request only valid versions. >> A versioning scheme could allow for multiple versions or a range >> (time support for instance) or a specific version. > > Hmmm, makes me think of a few other possibilities with regard to > this whole thread. Doing something as above, could be used as an > animation technique in the client by playing the tiles of a GPS > track for example. > >> If the client is required to get the latest supported tile >> version for a given tile service/entity, then all requests will >> include the valid version and be unique. Any intermediate >> caching system would begin caching the new tiles and hopefully >> flush the old ones based on some least recently used algorithm >> (because stale tiles would not be requested ever again, except by >> misbehaving clients which would fail when hitting an uncached >> geographic area) >> >> Sixth, on the subject of caching and separation of tile >> generation from cache, it is conceivable and, in fact desirable, >> that tile clients would want to ingest data sources that need to >> be tiled (to be displayed) but that should not be cached for some >> reason. The tile service c/should advertise a CacheHint property >> that tile clients could use in some fashion. >> >> Some other thoughts/details >> >> I agree with Norm's assessment of the minimum request parameters >> being layer (or entity), scale, row and column. Row and column >> could be geographic coordinates of a corner (lower, left?) or an >> index based on the number of tiles available at a given scale. >> Um. I guess you could reduce row and column to a single number >> which would be num_columns * (row-1) + column. > > What if I wanted to use a hexagonal pattern (remember you wanted to > sir things up :c) I would need one more axis. Then if I went 3D > with the same hexgonal approach, I would need 6 more axis to > track. I'm going to do this some day, I swear. > >> >> One thing missing that is a requirement for advertising a tile >> service is the need for an origin in row/column coordinates, >> which would likely be 0,0 to keep things simple. By this, I mean >> it is not enough to request a bbox and tile size, but the bbox >> must be restricted to the tile grid as well. I have found that >> using 0,0 for the bottom/left of one tile allows me to convert >> easily between display space (in pixels) and geographic space if >> I know the geographic size of a single pixel (which can be >> calculated from the scale - same problem I noted above about >> calculations though). >> >> There are many practical issues with tile generation as well. > > One thing I've been wanting to experiment with is CGI tiling based > on number of elements in a tile. Where an attempt is made to build > the same size files but with possible differing tile bounds and > raster sizes. High density areas vs sparsely populated areas > might be better off with smaller/larger tiles, or even no tile at > all being generated (empty) > >> My biggest concern right now is with labeling across tile >> boundaries. > > Labels seem like something that can be generated fairly quickly, > overlaying them using a larger tile size might be an option in some > instances. > bobb Continue the thought experiment on any WMS request being a "named entity to draw" from [A] above. Now imagine that you have two different WMS clients. One client is tile-aware and uses a specific WKL/BWH scheme. Once client is not. Call them "TileClient" and "RandomClient" Assume you put a cache (squid, mod_cache, etc) in front of a vanilla WMS. If you do nothing else, TileClient will cause the cache to slowly fill up with useful stuff. If other TileClients come along, it becomes likely that there will be cache hits, requiring no drawing by the WMS to satisfy requests. However, if RandomClient comes along, the cache becomes poisoned with one-off things that are unlikely to be useful ever again. What you need is a way to tell the two apart. There are a number of ways to do that. I think it would be possible to do a quick and dirty experiment on the efficiency of caching by simply setting the user-agent of all TileClients to a unique value. Then tell the cache only to cache things from TileClient user-agents. RandomClients would not have the right user-agent value and their requests would not be cached. Of course, a malicious RandomClient can fake it, right? So the next step is to have a very simple bit of code check the URLs for proper form. It would be trivial to (a) throw out requests with improper parameter order and then (b) check for proper BWH values. Then the good stuff can be cached, etc. You can even restrict caching to WKLs. Next, assume that a TileClient really wants to have a view that is nicely rendered but falls between the zoom levels. Well, it can make a WMS request that doesn't use the tile scheme. The cache recognizes it as non-standard, thus it passes the request to the WMS and does not cache the result. The TileClient gets what it wants, the cache is maintained, and the WMS is none the wiser. So, I really don't buy the notion that we should not use WMS requests. The potential win of doing a WMS-based tile cache is so enormous that it seems like a no-brainer to me. Now on to my soapbox about multiple schemes. Sure, there are many different tiling schemes that can be used. So what? Pick one. Set up a cache that knows to only cache the good stuff and pass the non- standard through. If you want a different tiling scheme? Set up another cache. If you only have enough disk space for one type, fine. Someone else will have the space for another. Eventually the cache people will say it's silly to have duplicate caches (after all, we're smarter than GYM who each maintain their own for competitive reasons, right?) and one scheme will prevail. My vote is to start with one scheme. Try it out. See the gains that are possible. Stop wringing your hands about labels on tile boundaries. If it's a big deal, don't cache the labels. Serve labels as a dynamic layer, and cache the stuff that is not sensitive to being sliced. Worried about stale tiles? Look into http's headers, there's stuff there to deal with it. Worried about not having enough space for the whole cache? Spread it around. Set up multiple caches, put them behind a cascading WMS. Or build clients that are somehow P2P aware that can get tiles from multiple places. But start somewhere. Avoid premature optimization. Allan > > _______________________________________________ > tiling mailing list > tiling@lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > -- Allan Doyle +1.781.433.2695 adoyle@eogeo.org From adam.hill at gmail.com Thu May 4 11:16:32 2006 From: adam.hill at gmail.com (Adam Hill) Date: Thu May 4 11:16:35 2006 Subject: [tiling] questions/concerns about the wms tile caching proposal In-Reply-To: References: <44597E8B.5070700@ci.stpaul.mn.us> Message-ID: Alan's last suggestion is exactly what Lucian's code does for OnEarth, sniffs out WorldWind and passes all others to WMS - http://www.twobeds.com/upload/userfiles/adamhill/lucians%20code%20-%20cache_1_1.gz If someone could implement this on Telescience with some layers the WorldWind community doesnt have (geology, temperature buoys, etc.) we could probably get a nice test going on. If they became permanent and endorsed by OSGeo or some other organization (NASA is a little skitish), we might be able to get them included in the base install. Adam Hill Free Earth Foundation