child element which contains the description if you compare to other OGC Web Services. Having the TileMap contain their own href feels a bit uncomfortable (call me traditional OGC :-), but I guess that's inline with REST as well. Even if so, why not use <OnlineResource> all the time? I miss the image format in the TileMap declaration. Why give the SRS already, but the image format only later? What's the logic behind that? To be more inline with traditional OGC, I guess you would use a DescribeTileMap request? Why use units-per-pixel and not ScaleDenominator? If using the first, should you not at least specify the unit? Maybe specify the origin as a gml:Point? Or do you think that's overkill :-) ? Can you explain the background behind your unit-per-pixel formula for the global profile? Thanks again. Best regards, Bart Paul Ramsey schreef: > I have placed a first thin draft here: > > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > > Call me trendy, but I went for a "RESTful" approach to the problem, > which has the added effect of making "serverless" services simpler to > generate. > > Paul > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > -- Bart van den Eijnden OSGIS, Open Source GIS bartvde at osgis.nl http://www.osgis.nl From pramsey at refractions.net Mon Oct 23 11:44:56 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 23 Oct 2006 11:44:56 -0700 Subject: [tiling] Tile Map Service In-Reply-To: <453CF1F0.40608@osgis.nl> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> <453CF1F0.40608@osgis.nl> Message-ID: <1161629096.453d0da8dd51f@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061023/43dd0236/attachment.asc From pramsey at refractions.net Thu Oct 26 22:25:43 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Thu, 26 Oct 2006 22:25:43 -0700 Subject: [tiling] Tiling Specification Message-ID: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> I have made some minor edits to the tiling spec <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> but nothing to rock the house. I am waiting for some complaints about the spec, the hard stuff. Jason Birch mentioned that it might be hard to implement under IIS, lacking mod_rewrite. There's no point in having a hard-to-implement spec, that defeats my goals, for sure. What do other people thing of that? (Note that the service root does not have to be a bare server URL. It could equally be http://mygreatserver.com/mytms/ as http:// tms.osgeo.org/) ) Paul From pramsey at refractions.net Fri Oct 27 08:39:30 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 08:39:30 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027151634.GA3349@crschmidt.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> Message-ID: <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> Actually, I think if the program is set as a cgi-bin, a rewrite might not be required, since everything after the cgi-bin gets sent to the program... see: http://mapserver.refractions.net/cgi-bin/mapserv48/foo/bar On 27-Oct-06, at 8:16 AM, Christopher Schmidt wrote: > On Thu, Oct 26, 2006 at 10:25:43PM -0700, Paul Ramsey wrote: > (Reordering for clarity) > >> <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> >> (Note that the service root does not have to be a bare server URL. >> It could equally be http://mygreatserver.com/mytms/ as http:// >> tms.osgeo.org/) ) > >> Jason Birch mentioned that it might be >> hard to implement under IIS, lacking mod_rewrite. > > Couldn't the service root also be: > > http://tile.example.com/mytms?url= > > After which you would get: > > http://tile.example.com/mytms?url=/1.0.0/landsat2000/1/8500/8500.png > > This seems like it would be a solution for the IIS case, since > presumably IIS could do the parsing of the QUERY_STRING argument. > > This seems possible to me given the spec, but I could be wrong. > > Regards, > -- > Christopher Schmidt > Web Developer From crschmidt at crschmidt.net Fri Oct 27 08:16:34 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri, 27 Oct 2006 11:16:34 -0400 Subject: [tiling] Tiling Specification In-Reply-To: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> Message-ID: <20061027151634.GA3349@crschmidt.net> On Thu, Oct 26, 2006 at 10:25:43PM -0700, Paul Ramsey wrote: (Reordering for clarity) > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > (Note that the service root does not have to be a bare server URL. > It could equally be http://mygreatserver.com/mytms/ as http:// > tms.osgeo.org/) ) > Jason Birch mentioned that it might be > hard to implement under IIS, lacking mod_rewrite. Couldn't the service root also be: http://tile.example.com/mytms?url= After which you would get: http://tile.example.com/mytms?url=/1.0.0/landsat2000/1/8500/8500.png This seems like it would be a solution for the IIS case, since presumably IIS could do the parsing of the QUERY_STRING argument. This seems possible to me given the spec, but I could be wrong. Regards, -- Christopher Schmidt Web Developer From crschmidt at crschmidt.net Fri Oct 27 08:54:08 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri, 27 Oct 2006 11:54:08 -0400 Subject: [tiling] Tiling Specification In-Reply-To: <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> Message-ID: <20061027155408.GB3349@crschmidt.net> On Fri, Oct 27, 2006 at 08:39:30AM -0700, Paul Ramsey wrote: > Actually, I think if the program is set as a cgi-bin, a rewrite might > not be required, since everything after the cgi-bin gets sent to the > program... see: > > http://mapserver.refractions.net/cgi-bin/mapserv48/foo/bar That may be setup specific. I wouldn't expect that to neccesarily be the case with IIS, which is the use case that was being addressed. Additionally, I'm not sure that all servers provide PATH_INFO to scripting langauges. (I would hope so, but can't be sure.) Regards, -- Christopher Schmidt Web Developer From pramsey at refractions.net Fri Oct 27 10:02:42 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 10:02:42 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027155408.GB3349@crschmidt.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> Message-ID: <1161968562.45423bb25ed93@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/de43c051/attachment.asc From schuyler at nocat.net Fri Oct 27 10:26:38 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Fri, 27 Oct 2006 10:26:38 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <1161968562.45423bb25ed93@ssl.refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> Message-ID: <20061027172638.GE30475@vishnu.tridity.org> * On 27-Oct-2006 at 10:02AM PDT, Paul Ramsey said: > At a minimum, in a CGI environment, the server has to provide the full calling > URL to the executable, so the information will be there. You're right about > IIS, I am not sure of the behavior for http://server/cgi-bin/exec/foo/bar is > specified anywhere, and the Apache behavior could just be a lucky break. No, that's part of the NCSA CGI spec: http://hoohoo.ncsa.uiuc.edu/cgi/env.html However, MS seems to think it's a security risk, so it needs to be explicitly enabled, apparently: http://support.microsoft.com/kb/q184320/ SDE From pramsey at refractions.net Fri Oct 27 10:34:09 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 10:34:09 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027172638.GE30475@vishnu.tridity.org> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> <20061027172638.GE30475@vishnu.tridity.org> Message-ID: <1161970449.45424311c7b67@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/79da0a83/attachment.pot From sgillies at frii.com Fri Oct 27 10:49:25 2006 From: sgillies at frii.com (Sean Gillies) Date: Fri, 27 Oct 2006 11:49:25 -0600 Subject: [tiling] Tiling Specification In-Reply-To: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> Message-ID: <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> On Oct 26, 2006, at 11:25 PM, Paul Ramsey wrote: > I have made some minor edits to the tiling spec > > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > > but nothing to rock the house. I am waiting for some complaints about > the spec, the hard stuff. Jason Birch mentioned that it might be > hard to implement under IIS, lacking mod_rewrite. There's no point > in having a hard-to-implement spec, that defeats my goals, for sure. > What do other people thing of that? > > (Note that the service root does not have to be a bare server URL. > It could equally be http://mygreatserver.com/mytms/ as http:// > tms.osgeo.org/) ) > > Paul Paul, I like how the spec is developing. Anyone who can't implement the necessary URL traversal on their current web app server can modernize or go home ;) Seriously, this spec shouldn't be encumbered by limitations of CGI or IIS. Cheers, Sean --- Sean Gillies http://zcologia.com From pavlenko at users.berlios.de Fri Oct 27 12:32:16 2006 From: pavlenko at users.berlios.de (Artem Pavlenko) Date: Fri, 27 Oct 2006 20:32:16 +0100 Subject: [tiling] Tiling Specification In-Reply-To: <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> Message-ID: <45425EC0.2020206@users.berlios.de> Paul, I just want second Sean on this one. Please, keep it simple! Make sure that all URLs are _nice_ and don't get distracted by cgi-bin:). This spec is very timely, indeed. I might be implementing it in the next couple months:P. Now that we can render tiles - http://mapnik.org/tiling_demo, we need a way to publish them. Cheers, Artem. Sean Gillies wrote: > On Oct 26, 2006, at 11:25 PM, Paul Ramsey wrote: > > >> I have made some minor edits to the tiling spec >> >> <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> >> >> but nothing to rock the house. I am waiting for some complaints about >> the spec, the hard stuff. Jason Birch mentioned that it might be >> hard to implement under IIS, lacking mod_rewrite. There's no point >> in having a hard-to-implement spec, that defeats my goals, for sure. >> What do other people thing of that? >> >> (Note that the service root does not have to be a bare server URL. >> It could equally be http://mygreatserver.com/mytms/ as http:// >> tms.osgeo.org/) ) >> >> Paul >> > > Paul, I like how the spec is developing. Anyone who can't implement > the necessary URL traversal on their current web app server can > modernize or go home ;) Seriously, this spec shouldn't be encumbered > by limitations of CGI or IIS. > > Cheers, > Sean > > --- > Sean Gillies > http://zcologia.com > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > From pramsey at refractions.net Fri Oct 27 15:17:25 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 15:17:25 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <45425EC0.2020206@users.berlios.de> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> <45425EC0.2020206@users.berlios.de> Message-ID: <1161987445.454285755beda@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/b0c68eee/attachment.asc From pramsey at refractions.net Fri Oct 27 15:43:46 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 15:43:46 -0700 Subject: [tiling] Supporting Mercator and Plate Carre Message-ID: <1161989026.45428ba25e98d@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/f919e6a1/attachment.pot From jason at jasonbirch.com Fri Oct 27 21:58:32 2006 From: jason at jasonbirch.com (Jason Birch) Date: Fri, 27 Oct 2006 21:58:32 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027172638.GE30475@vishnu.tridity.org> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> <20061027172638.GE30475@vishnu.tridity.org> Message-ID: <4542E378.6010509@jasonbirch.com> Schuyler Erle wrote: > However, MS seems to think it's a security risk, so it needs to be > explicitly enabled, apparently: > > http://support.microsoft.com/kb/q184320/ Heh. I should watch what I say to Paul :) I believe that this issue is specific to IIS4, or has at least been fixed by IIS6. I've just tested on an IIS6 server with PHP5, and PATH_INFO is returned. And it doesn't need to be in cgi-bin (but you need the file extension). As long as it's legal for the root resource to be /tms.php (or aspx, or py, or jsp) instead of /, then there doesn't appear to be a problem. My concern is that I would have to make IIS respond to all requests under / with a specific script. You can do it with a custom 404 error handler, but that's really abusing the server. Hmm. For users with the ability to install ISAPI extensions, there appears to be an open source mod_rewrite for IIS available (wasn't there last time I looked into this; honest...): http://www.iismods.com/url-rewrite/index.htm While it's tempting to say "use another server", in some environments the chances of getting Apache (or Lighty, or whatever) installed are slim to none. If a standard is created that cannot be used by a server that has a reasonable share of the "enterprise" market, then in making this choice you are accepting that you might also be restricting access to valuable data. Jason From pramsey at refractions.net Fri Oct 27 23:43:16 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 23:43:16 -0700 Subject: [tiling] Server Implementation Message-ID: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> At the risk of looking foolish (it's late, I'm tired, and I have tested it as many as 6 times) here is a an implementation of the draft TMS specification: http://mapserver.refractions.net/cgi-bin/tms Paul noted that I haven't documented error handling in the spec yet, and he's right. So look for some new sections coming soon. Paul From pramsey at refractions.net Sat Oct 28 10:53:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 10:53:34 -0700 Subject: [tiling] RESTful Completeness Message-ID: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> Looking at the server logs of my implementation, I see a couple requests that look like this: /cgi-bin/tms/1.0.0/global_mosaic/0/ From the PoV of the REST interface, this is a request for the <TileSet> resource for the first resolution level I defined. (The actual tiles would be at /cgi-bin/tms/1.0.0/global_mosaic/0/0/0.jpg) However, in the specification, I didn't bother to define an explicit <TileSet> resource, since once you get the the <TileMap> resource you have enough information, as a client, to formulate direct tile requests. The <TileSet> is sort of redundant. Should any information be returned at that resource level? Thoughts? Defining the <TileSet> and then a <TileSetColumn> resource would allow me to complete a "true" REST API to the service, since then it would be possible to traverse from the root resource all the way to the tile images just be following the href information through the resources. Right now, from an API PoV, the system just dead-ends at TileMap, and the gap is filled opaquely through the description in the spec doc. Any feedback would be nice. Paul From pspencer at dmsolutions.ca Sat Oct 28 11:08:49 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sat, 28 Oct 2006 14:08:49 -0400 Subject: [tiling] RESTful Completeness In-Reply-To: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> References: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> Message-ID: <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> Paul, in thinking though my own implementation of this, I am following this logic: * separate path_info into the script_file (i.e. the /cgi-bin/tms part) and the rest (pun intended) * split rest on / into an array * count(rest) = 0: emit <Services> * count(rest) = 1: emit <TileMapService> for requested version * count(rest) = 2: emit <TileMap> for requested version and map * count(rest) = 5: emit appropriate tile image Anything else will result in a 404 (i.e. 3, 4 or more than 6) Also requesting an unsupported version or TileMap will result in a 404. I don't see the benefit of adding responses for 3 (scale) and 4 (column) other than completeness. If it is not RESTful to make tileset/column/row mandatory then I guess we should add appropriate responses. If we do, the tileset response could just return the units per pixel and perhaps (this might be useful) the minimum and maximum values that can be requested from the columns ... and the column response could return the minimum and maximum values that can be requested from the rows. I guess for completeness they would also return the href too ... Cheers Paul On 28-Oct-06, at 1:53 PM, Paul Ramsey wrote: > Looking at the server logs of my implementation, I see a couple > requests that look like this: > > /cgi-bin/tms/1.0.0/global_mosaic/0/ > > From the PoV of the REST interface, this is a request for the > <TileSet> resource for the first resolution level I defined. (The > actual tiles would be at /cgi-bin/tms/1.0.0/global_mosaic/0/0/0.jpg) > > However, in the specification, I didn't bother to define an explicit > <TileSet> resource, since once you get the the <TileMap> resource you > have enough information, as a client, to formulate direct tile > requests. The <TileSet> is sort of redundant. Should any > information be returned at that resource level? Thoughts? > > Defining the <TileSet> and then a <TileSetColumn> resource would > allow me to complete a "true" REST API to the service, since then it > would be possible to traverse from the root resource all the way to > the tile images just be following the href information through the > resources. Right now, from an API PoV, the system just dead-ends at > TileMap, and the gap is filled opaquely through the description in > the spec doc. > > Any feedback would be nice. > > Paul > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sat Oct 28 22:44:28 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 22:44:28 -0700 Subject: [tiling] Error Handling Message-ID: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> I have added error handling to the specification and my implementation for those who are doing testing / client building. I decided to stick with just two HTTP error codes: - 404 Not Found - 500 Internal Server Error They seemed to contain all the likely problems a TMS might encounter normally, and anything else could be shoehorned into 500. P From pramsey at refractions.net Sat Oct 28 22:50:48 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 22:50:48 -0700 Subject: [tiling] RESTful Completeness In-Reply-To: <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> References: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> Message-ID: <FDF95CD5-6E4A-484F-8EC2-253F9DD63B86@refractions.net> On 28-Oct-06, at 11:08 AM, Paul Spencer wrote: > I don't see the benefit of adding responses for 3 (scale) and 4 > (column) other than completeness. If it is not RESTful to make > tileset/column/row mandatory then I guess we should add appropriate > responses. > > If we do, the tileset response could just return the units per > pixel and perhaps (this might be useful) the minimum and maximum > values that can be requested from the columns ... and the column > response could return the minimum and maximum values that can be > requested from the rows. > > I guess for completeness they would also return the href too ... That would be the point, to provide a chain of hrefs that eventually lead to the tile itself. However, if noone really needs to do the full traversal, it seems like a waste of specification space, and implementors time, to provide resources that clients will always ignore. I could move information from the TileMap into the TileSet, but then I am forcing clients to traverse down another level just to satisfy my didactic urge to encapsulate things at the "right" level. I think I will leave well enough alone until the REST police come to rough me up. Sean? Paul From pramsey at refractions.net Sun Oct 29 08:34:37 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 08:34:37 -0800 Subject: [tiling] Error Handling In-Reply-To: <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> Message-ID: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Adam, How about 410 (Gone)? Or 204 (No Content) in conjunction with a transparent image? I also remembered that I am trying to make the spec implementable just by piling files under an HTTP server without configuration, which means that the XML content in the 404 and 500 errors will have to be optional. The error string that goes with the code is also mutable, so I could, evilly, suggest that anyone who wants to send back a custom error message simply stuff it in there. P. On 29-Oct-06, at 8:25 AM, Adam Hill wrote: > Seeing someone else asked, I will bring up an annoying issue we > have in World Wind - telling the client there is actually NODATA at > this tile vs other systemic errors, so later on it can "do the > right thing" (like never ask for that tile again). Since there > doesn't seem to be a convienient HTTP code for this someone has to > decide on one for convention. > > Have any other implememntations dealt with this (Mapserver, > Geoserver)? > > Adam Hill > World Wind Developer From pspencer at dmsolutions.ca Sun Oct 29 11:42:52 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 14:42:52 -0500 Subject: [tiling] Error Handling In-Reply-To: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Message-ID: <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> Paul, Adam, neither of those is a good fit, in my mind. I think that a 404 Not Found should be sufficient - 404 is returned by a correctly configured TMS that doesn't support something you've asked for - either invalid version, map, or tileset/column/row combination (or image format). 404 is really no content at the requested location. 500 is used if the service is incorrectly configured or suffers an internal error on a request it *might* otherwise have been able to handle. I think that worldwind could safely assume that if it gets a 404 from a TMS, it should never send that request (whatever it was) again. Paul, it is possible with most web servers to set a custom error handler which would enable a static tile set to handle missing images with a reasonable error message if the administrator so desires, although the only requirement should be to return a 404 - any content describing the problem is for convenience only, recommended but not required. That's my take, anyway. Cheers Paul On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: > Adam, > > How about 410 (Gone)? Or 204 (No Content) in conjunction with a > transparent image? > I also remembered that I am trying to make the spec implementable > just by piling files under an HTTP server without configuration, > which means that the XML content in the 404 and 500 errors will have > to be optional. The error string that goes with the code is also > mutable, so I could, evilly, suggest that anyone who wants to send > back a custom error message simply stuff it in there. > > P. > > On 29-Oct-06, at 8:25 AM, Adam Hill wrote: > >> Seeing someone else asked, I will bring up an annoying issue we >> have in World Wind - telling the client there is actually NODATA at >> this tile vs other systemic errors, so later on it can "do the >> right thing" (like never ask for that tile again). Since there >> doesn't seem to be a convienient HTTP code for this someone has to >> decide on one for convention. >> >> Have any other implememntations dealt with this (Mapserver, >> Geoserver)? >> >> Adam Hill >> World Wind Developer > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Sat Oct 28 15:20:32 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sat, 28 Oct 2006 18:20:32 -0400 Subject: [tiling] Server Implementation In-Reply-To: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> References: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> Message-ID: <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> Paul, more on error messages: 500 Internal Server Error used for misconfiguration of the service that prevents the service from running. Some examples from my testing: * cannot load mapscript for some reason * path to a mapfile is incorrect * mapfile syntax is incorrect (cannot load a map file) 404 Not Found used for: * incorrect formatting of version * unsupported version (you seem to be returning a 500 for this) * requesting a TileMapService that doesn't exist * requesting a tileset, column or row that doesn't exist There are probably more errors that fall into one of these categories. Also, implementations should be encouraged to return content with the error that describes the actual error that happened. Finally, a comment on your implementation - one level returns incorrectly formatted xml (at least that's what firefox says) because (I think) the <?xml ?> tag isn't the first line of the output! I've got as far as outputting a TileMapService block, need to do TileMap next. Cheers paul On 28-Oct-06, at 2:43 AM, Paul Ramsey wrote: > At the risk of looking foolish (it's late, I'm tired, and I have > tested it as many as 6 times) here is a an implementation of the > draft TMS specification: > > http://mapserver.refractions.net/cgi-bin/tms > > Paul noted that I haven't documented error handling in the spec yet, > and he's right. So look for some new sections coming soon. > > Paul > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 13:23:51 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 13:23:51 -0800 Subject: [tiling] Server Implementation In-Reply-To: <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> References: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> Message-ID: <CBAA78FB-36F0-4336-B497-40CFF0BA07D8@refractions.net> I agree with your interpretations of the codes, and I think the two codes are going to service us pretty well. On 28-Oct-06, at 3:20 PM, Paul Spencer wrote: > more on error messages: > > 500 Internal Server Error > > used for misconfiguration of the service that prevents the service > from running. Some examples from my testing: > > * cannot load mapscript for some reason > * path to a mapfile is incorrect > * mapfile syntax is incorrect (cannot load a map file) > > 404 Not Found > > used for: > > * incorrect formatting of version > * unsupported version (you seem to be returning a 500 for this) Have a URL? I cannot replicate that. I should only be returning 500 when NASA feeds me errors. > * requesting a TileMapService that doesn't exist > * requesting a tileset, column or row that doesn't exist > > There are probably more errors that fall into one of these categories. > > Also, implementations should be encouraged to return content with > the error that describes the actual error that happened. > > Finally, a comment on your implementation - one level returns > incorrectly formatted xml (at least that's what firefox says) > because (I think) the <?xml ?> tag isn't the first line of the output! I fixed this yesterday, but through the magic of caching you're still getting the broken one. Try a hard refresh. :) Pual From pramsey at refractions.net Sun Oct 29 15:23:56 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 15:23:56 -0800 Subject: [tiling] Relative URLs Message-ID: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> Question, Should relative URLs be allowed in the HREF elements of the tms resources? (I think "yes", but if we are allowing it we need to warn the implementors of clients so they can handle it appropriately.) P From pspencer at dmsolutions.ca Sun Oct 29 15:43:01 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 18:43:01 -0500 Subject: [tiling] Relative URLs In-Reply-To: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> Message-ID: <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> do you have an example of how this might be used? Paul On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: > Question, > > Should relative URLs be allowed in the HREF elements of the tms > resources? > > (I think "yes", but if we are allowing it we need to warn the > implementors of clients so they can handle it appropriately.) > > P > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 15:51:40 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 15:51:40 -0800 Subject: [tiling] Relative URLs In-Reply-To: <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> Message-ID: <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> What it looks like: http://mapserver.refractions.net/cgi-bin/tms <?xml version="1.0" ?> <Services> <TileMapService version="1.0.0" href="1.0.0" /> </Services> Why it would be useful: When you create a static tms by shredding existing imagery into tiles, it would be nice to be able to move that static tms around just be copying it from place to place. If the URLs are absolute they would have to be edited after every copy. Why I thought of it: I was pondering Chris Tweedies insane idea of putting tiles into S3 and whether it was possible under the tms spec (it is) and how one would do it (shred something and stuff it up there). If you have to know the absolute path of everything ahead of time it is just a little less convenient. Processing relative URLs properly is a bit of a pain though, lots of different cases to deal with. P On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: > do you have an example of how this might be used? > > Paul > > On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: > >> Question, >> >> Should relative URLs be allowed in the HREF elements of the tms >> resources? >> >> (I think "yes", but if we are allowing it we need to warn the >> implementors of clients so they can handle it appropriately.) >> >> P >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > From pspencer at dmsolutions.ca Sun Oct 29 17:17:47 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 20:17:47 -0500 Subject: [tiling] Relative URLs In-Reply-To: <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> Message-ID: <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> I like it, but I think we need to be careful what is allowed. For instance, ../<something> /<something> are these allowed? Do you envision a static tms being one that has xml docs in each of the directories and these would be set up in the web server as the default document ... index.xml? Cheers Paul On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: > What it looks like: > > http://mapserver.refractions.net/cgi-bin/tms > > <?xml version="1.0" ?> > <Services> > <TileMapService version="1.0.0" href="1.0.0" /> > </Services> > > Why it would be useful: > > When you create a static tms by shredding existing imagery into > tiles, it would be nice to be able to move that static tms around > just be copying it from place to place. If the URLs are absolute > they would have to be edited after every copy. > > Why I thought of it: > > I was pondering Chris Tweedies insane idea of putting tiles into S3 > and whether it was possible under the tms spec (it is) and how one > would do it (shred something and stuff it up there). If you have > to know the absolute path of everything ahead of time it is just a > little less convenient. > > Processing relative URLs properly is a bit of a pain though, lots > of different cases to deal with. > > P > > > On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: > >> do you have an example of how this might be used? >> >> Paul >> >> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >> >>> Question, >>> >>> Should relative URLs be allowed in the HREF elements of the tms >>> resources? >>> >>> (I think "yes", but if we are allowing it we need to warn the >>> implementors of clients so they can handle it appropriately.) >>> >>> P >>> _______________________________________________ >>> tiling mailing list >>> tiling at lists.eogeo.org >>> http://lists.eogeo.org/mailman/listinfo/tiling >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> > +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 17:46:09 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 17:46:09 -0800 Subject: [tiling] Relative URLs In-Reply-To: <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> Message-ID: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Remember, there is no rule about the URL format, only about URL traversal... So my root resource could the tms.rri.net/root.xml and it could reference my version at tms.rri.net/tilemapservice.xml and that could reference a tilemap at tms.rri.net/tilemap.xml and that would have the info about the tilesets would would allow the client to construct tile requests like tms.rrs.net/l1/1/1.jpg which hopefully explains my concern about breaking the url traversal rule for getting to the tile resources themselves... it's such a powerful concept it seems a shame to break it. On the other hand, if I cannot think of a use case, I am not going to stick it in. P On 29-Oct-06, at 5:17 PM, Paul Spencer wrote: > I like it, but I think we need to be careful what is allowed. For > instance, > > ../<something> > /<something> > > are these allowed? > > Do you envision a static tms being one that has xml docs in each of > the directories and these would be set up in the web server as the > default document ... index.xml? > > Cheers > > Paul > > On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: > >> What it looks like: >> >> http://mapserver.refractions.net/cgi-bin/tms >> >> <?xml version="1.0" ?> >> <Services> >> <TileMapService version="1.0.0" href="1.0.0" /> >> </Services> >> >> Why it would be useful: >> >> When you create a static tms by shredding existing imagery into >> tiles, it would be nice to be able to move that static tms around >> just be copying it from place to place. If the URLs are absolute >> they would have to be edited after every copy. >> >> Why I thought of it: >> >> I was pondering Chris Tweedies insane idea of putting tiles into >> S3 and whether it was possible under the tms spec (it is) and how >> one would do it (shred something and stuff it up there). If you >> have to know the absolute path of everything ahead of time it is >> just a little less convenient. >> >> Processing relative URLs properly is a bit of a pain though, lots >> of different cases to deal with. >> >> P >> >> >> On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: >> >>> do you have an example of how this might be used? >>> >>> Paul >>> >>> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >>> >>>> Question, >>>> >>>> Should relative URLs be allowed in the HREF elements of the tms >>>> resources? >>>> >>>> (I think "yes", but if we are allowing it we need to warn the >>>> implementors of clients so they can handle it appropriately.) >>>> >>>> P >>>> _______________________________________________ >>>> tiling mailing list >>>> tiling at lists.eogeo.org >>>> http://lists.eogeo.org/mailman/listinfo/tiling >>> >>> +-----------------------------------------------------------------+ >>> |Paul Spencer pspencer at dmsolutions.ca | >>> +-----------------------------------------------------------------+ >>> |Chief Technology Officer | >>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>> +-----------------------------------------------------------------+ >>> >>> >>> >>> >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > From pramsey at refractions.net Sun Oct 29 22:20:54 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 22:20:54 -0800 Subject: [tiling] Common non-EPSG SRSs Message-ID: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> All, The usual issue about how to signify SRSs which are not in the EPSG database arises for the TMS. And because Mercator is both (a) not in EPSG and (b) commonly used for tiled web mapping, this is not an issue that can be put off. I think that TMS just needs to define the SRSs it needs inside the specification itself, and by virtue of being a living and collaborative spec, should be able to work that way. The open issue is what authority prefix to use for these definitions. I have stubbed in a section with some example systems. I used the "EPSG:" authority prefix. This is actually the prefix I found them with in the wild, on the web, in live WMS instances. In terms of interoperability, it makes sense to stick with what is being used. Why break what is not broken? In terms of respecting the idea of an "authority prefix" it makes no sense. Where does the community come down on this? P From pramsey at refractions.net Sun Oct 29 22:22:18 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 22:22:18 -0800 Subject: [tiling] Relative URLs In-Reply-To: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Message-ID: <1222695A-5C2F-4C3F-8B56-D54E784BE5E9@refractions.net> FYI, I wrote in some relative URL examples in the spec. I think it would be very nice for data deployers. This is the time for client writers to get vocal if it is in fact too great an imposition. Speak now for forever hold your peace. P On 29-Oct-06, at 5:46 PM, Paul Ramsey wrote: > Remember, there is no rule about the URL format, only about URL > traversal... > > So my root resource could the > > tms.rri.net/root.xml > > and it could reference my version at > > tms.rri.net/tilemapservice.xml > > and that could reference a tilemap at > > tms.rri.net/tilemap.xml > > and that would have the info about the tilesets would would allow the > client to construct tile requests like > > tms.rrs.net/l1/1/1.jpg > > which hopefully explains my concern about breaking the url traversal > rule for getting to the tile resources themselves... it's such a > powerful concept it seems a shame to break it. On the other hand, if > I cannot think of a use case, I am not going to stick it in. > > P > > On 29-Oct-06, at 5:17 PM, Paul Spencer wrote: > >> I like it, but I think we need to be careful what is allowed. For >> instance, >> >> ../<something> >> /<something> >> >> are these allowed? >> >> Do you envision a static tms being one that has xml docs in each of >> the directories and these would be set up in the web server as the >> default document ... index.xml? >> >> Cheers >> >> Paul >> >> On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: >> >>> What it looks like: >>> >>> http://mapserver.refractions.net/cgi-bin/tms >>> >>> <?xml version="1.0" ?> >>> <Services> >>> <TileMapService version="1.0.0" href="1.0.0" /> >>> </Services> >>> >>> Why it would be useful: >>> >>> When you create a static tms by shredding existing imagery into >>> tiles, it would be nice to be able to move that static tms around >>> just be copying it from place to place. If the URLs are absolute >>> they would have to be edited after every copy. >>> >>> Why I thought of it: >>> >>> I was pondering Chris Tweedies insane idea of putting tiles into >>> S3 and whether it was possible under the tms spec (it is) and how >>> one would do it (shred something and stuff it up there). If you >>> have to know the absolute path of everything ahead of time it is >>> just a little less convenient. >>> >>> Processing relative URLs properly is a bit of a pain though, lots >>> of different cases to deal with. >>> >>> P >>> >>> >>> On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: >>> >>>> do you have an example of how this might be used? >>>> >>>> Paul >>>> >>>> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >>>> >>>>> Question, >>>>> >>>>> Should relative URLs be allowed in the HREF elements of the tms >>>>> resources? >>>>> >>>>> (I think "yes", but if we are allowing it we need to warn the >>>>> implementors of clients so they can handle it appropriately.) >>>>> >>>>> P >>>>> _______________________________________________ >>>>> tiling mailing list >>>>> tiling at lists.eogeo.org >>>>> http://lists.eogeo.org/mailman/listinfo/tiling >>>> >>>> +-----------------------------------------------------------------+ >>>> |Paul Spencer pspencer at dmsolutions.ca | >>>> +-----------------------------------------------------------------+ >>>> |Chief Technology Officer | >>>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>>> +-----------------------------------------------------------------+ >>>> >>>> >>>> >>>> >>> >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From Martin.Daly at cadcorp.com Mon Oct 30 00:03:55 2006 From: Martin.Daly at cadcorp.com (Martin Daly) Date: Mon, 30 Oct 2006 08:03:55 -0000 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> Message-ID: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> > The open issue is what authority prefix to use for these > definitions. I have stubbed in a section with some example > systems. > I used the "EPSG:" authority prefix. This is actually the > prefix I found them with in the wild, on the web, in live WMS > instances. In terms of interoperability, it makes sense to > stick with what is being used. Why break what is not broken? > In terms of respecting the idea of an "authority prefix" it > makes no sense. > > Where does the community come down on this? Why not extend the WMS AUTO CRS concept to cover Mercator, etc? From pedro.goncalves at terradue.com Mon Oct 30 02:16:49 2006 From: pedro.goncalves at terradue.com (Pedro Goncalves) Date: Mon, 30 Oct 2006 11:16:49 +0100 Subject: [tiling] Error Handling In-Reply-To: <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> Message-ID: <D978B51D-977E-4549-928D-9763A630E347@terradue.com> Hi Paul Do you think is possible to add (or strongly recommend) the usage of the 304 response code (Not modified). This is quite useful when performing requests with the 'if-modified-since' header thanks and all the best Pedro On Oct 29, 2006, at 8:42 PM, Paul Spencer wrote: > Paul, Adam, > > neither of those is a good fit, in my mind. > > I think that a 404 Not Found should be sufficient - 404 is returned > by a correctly configured TMS that doesn't support something you've > asked for - either invalid version, map, or tileset/column/row > combination (or image format). 404 is really no content at the > requested location. > > 500 is used if the service is incorrectly configured or suffers an > internal error on a request it *might* otherwise have been able to > handle. > > I think that worldwind could safely assume that if it gets a 404 from > a TMS, it should never send that request (whatever it was) again. > > Paul, it is possible with most web servers to set a custom error > handler which would enable a static tile set to handle missing images > with a reasonable error message if the administrator so desires, > although the only requirement should be to return a 404 - any content > describing the problem is for convenience only, recommended but not > required. > > That's my take, anyway. > > Cheers > > Paul > > On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: > >> Adam, >> >> How about 410 (Gone)? Or 204 (No Content) in conjunction with a >> transparent image? >> I also remembered that I am trying to make the spec implementable >> just by piling files under an HTTP server without configuration, >> which means that the XML content in the 404 and 500 errors will have >> to be optional. The error string that goes with the code is also >> mutable, so I could, evilly, suggest that anyone who wants to send >> back a custom error message simply stuff it in there. >> >> P. >> >> On 29-Oct-06, at 8:25 AM, Adam Hill wrote: >> >>> Seeing someone else asked, I will bring up an annoying issue we >>> have in World Wind - telling the client there is actually NODATA at >>> this tile vs other systemic errors, so later on it can "do the >>> right thing" (like never ask for that tile again). Since there >>> doesn't seem to be a convienient HTTP code for this someone has to >>> decide on one for convention. >>> >>> Have any other implememntations dealt with this (Mapserver, >>> Geoserver)? >>> >>> Adam Hill >>> World Wind Developer >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061030/df10b41a/attachment.html From nhv at cape.com Mon Oct 30 07:02:05 2006 From: nhv at cape.com (Norman Vine) Date: Mon, 30 Oct 2006 10:02:05 -0500 Subject: [tiling] Error Handling In-Reply-To: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Message-ID: <200610301502.k9UF25Y8015977@smtp11.cape.com> Paul Ramsey writes: > I also remembered that I am trying to make the spec > implementable just by piling files under an HTTP server > without configuration, Granted the most common implementation will probably be 'piling files under an HTTP server', but it would be good to remember that an http spec is about 'known' Http 'strings' and nothing todo with implementation details For example tiles could all be stored in one packed file or perhps even all created on demand Cheers Norman From cholmes at openplans.org Mon Oct 30 07:43:06 2006 From: cholmes at openplans.org (Chris Holmes) Date: Mon, 30 Oct 2006 10:43:06 -0500 Subject: [tiling] Error Handling In-Reply-To: <D978B51D-977E-4549-928D-9763A630E347@terradue.com> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> <D978B51D-977E-4549-928D-9763A630E347@terradue.com> Message-ID: <45461D8A.3080506@openplans.org> Yeah, I've been mulling things related this to as well. I believe it's also useful when you have a 'must-revalidate' call, which is used as an example in the spec. I suppose using a 304 is actually more useful for the server that's generating the responses in the first place - like the WMS that the TMS is tiling. Then the TMS can just do the revalidate instead of making the backend generate the response again. But even if a TMS is just returning static tiles, a 304 is useful so that it doesn't have to make the roundtrip. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3 And if your TMS is an engine that generates tiles _and_ does the caching (like ka-map's engine), then I think a 304 could be even more useful for revalidation. The engine could be built with knowledge of if the backend database had been modified (like listening to the WFS-T that access the service, or database triggers), and can return 304's until something's changed. Then your max-age becomes an indication of how likely the server is to change, since if you do max-age and must-revalidate then it doesn't have to revalidate until max-age is reached. Chris Pedro Goncalves wrote: > Hi Paul > > Do you think is possible to add (or strongly recommend) the usage of the > 304 response code (Not modified). This is quite useful when performing > requests with the 'if-modified-since' header > > thanks and all the best > Pedro > > > > > On Oct 29, 2006, at 8:42 PM, Paul Spencer wrote: > >> Paul, Adam, >> >> neither of those is a good fit, in my mind. >> >> I think that a 404 Not Found should be sufficient - 404 is returned >> by a correctly configured TMS that doesn't support something you've >> asked for - either invalid version, map, or tileset/column/row >> combination (or image format). 404 is really no content at the >> requested location. >> >> 500 is used if the service is incorrectly configured or suffers an >> internal error on a request it *might* otherwise have been able to >> handle. >> >> I think that worldwind could safely assume that if it gets a 404 from >> a TMS, it should never send that request (whatever it was) again. >> >> Paul, it is possible with most web servers to set a custom error >> handler which would enable a static tile set to handle missing images >> with a reasonable error message if the administrator so desires, >> although the only requirement should be to return a 404 - any content >> describing the problem is for convenience only, recommended but not >> required. >> >> That's my take, anyway. >> >> Cheers >> >> Paul >> >> On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: >> >>> Adam, >>> >>> How about 410 (Gone)? Or 204 (No Content) in conjunction with a >>> transparent image? >>> I also remembered that I am trying to make the spec implementable >>> just by piling files under an HTTP server without configuration, >>> which means that the XML content in the 404 and 500 errors will have >>> to be optional. The error string that goes with the code is also >>> mutable, so I could, evilly, suggest that anyone who wants to send >>> back a custom error message simply stuff it in there. >>> >>> P. >>> >>> On 29-Oct-06, at 8:25 AM, Adam Hill wrote: >>> >>>> Seeing someone else asked, I will bring up an annoying issue we >>>> have in World Wind - telling the client there is actually NODATA at >>>> this tile vs other systemic errors, so later on it can "do the >>>> right thing" (like never ask for that tile again). Since there >>>> doesn't seem to be a convienient HTTP code for this someone has to >>>> decide on one for convention. >>>> >>>> Have any other implememntations dealt with this (Mapserver, >>>> Geoserver)? >>>> >>>> Adam Hill >>>> World Wind Developer >>> >>> _______________________________________________ >>> tiling mailing list >>> tiling at lists.eogeo.org <mailto:tiling at lists.eogeo.org> >>> http://lists.eogeo.org/mailman/listinfo/tiling >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca >> <mailto:pspencer at dmsolutions.ca> | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org <mailto:tiling at lists.eogeo.org> >> http://lists.eogeo.org/mailman/listinfo/tiling >> > > !DSPAM:1003,4545d2d2138581510810322! > > > ------------------------------------------------------------------------ > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > !DSPAM:1003,4545d2d2138581510810322! -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061030/375b22aa/attachment.vcf From sgillies at frii.com Mon Oct 30 10:52:38 2006 From: sgillies at frii.com (Sean Gillies) Date: Mon, 30 Oct 2006 10:52:38 -0800 Subject: [tiling] Relative URLs In-Reply-To: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Message-ID: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> On Oct 29, 2006, at 5:46 PM, Paul Ramsey wrote: > Remember, there is no rule about the URL format, only about URL > traversal... > > So my root resource could the > > tms.rri.net/root.xml > > and it could reference my version at > > tms.rri.net/tilemapservice.xml > > and that could reference a tilemap at > > tms.rri.net/tilemap.xml > > and that would have the info about the tilesets would would allow the > client to construct tile requests like > > tms.rrs.net/l1/1/1.jpg Paul, How about -- excuse my shorthand notation -- this: GET [Accept: image/jpeg] http://tms.rrs.net/l1/1/1.jpg Few providers are going to implement a "1" leaf resource that can viewed in more than one format, but using the accept headers lets us make more reliable contracts about content type. If this is already in the spec, disregard my note. I'm just starting to catch up on your flurry of emails. BTW, I'm not too concerned about relative links. In practice, we'll be using web frameworks that take care of this, or scripting the deployment of tiles, yes? Sean --- Sean Gillies http://zcologia.com From pramsey at refractions.net Mon Oct 30 11:02:52 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:02:52 -0800 Subject: [tiling] Relative URLs In-Reply-To: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> Message-ID: <77EA9FD0-EA7B-40DA-8877-FF99CAD9F48B@refractions.net> It would be nice if, when creating a static tile stack, I didn't have to specify the full server paths ahead of time. It is not a requirement, but it makes the spec more flexible. I am trying to balance this niceness against what I hear from the client writers on the issues with supporting relatively URLs. On 30-Oct-06, at 10:52 AM, Sean Gillies wrote: > BTW, I'm not too concerned about relative links. In practice, we'll > be using web frameworks that take care of this, or scripting the > deployment of tiles, yes? From pramsey at refractions.net Mon Oct 30 11:07:01 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:07:01 -0800 Subject: [tiling] Relative URLs In-Reply-To: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> Message-ID: <91FABEC2-51DC-4477-9E8D-5C740681DFC1@refractions.net> What problem is this solving? The TileMap specifies the Tile format as a mime-type, and the return value for the tile request will have a Content-type. If I have specified image/jpeg and you say you accept image/png, what should I be doing? On 30-Oct-06, at 10:52 AM, Sean Gillies wrote: > How about -- excuse my shorthand notation -- this: > > GET [Accept: image/jpeg] http://tms.rrs.net/l1/1/1.jpg > > Few providers are going to implement a "1" leaf resource that can > viewed in more than one format, but using the accept headers lets us > make more reliable contracts about content type. If this is already > in the spec, disregard my note. I'm just starting to catch up on your > flurry of emails. From sgillies at frii.com Mon Oct 30 11:11:43 2006 From: sgillies at frii.com (Sean Gillies) Date: Mon, 30 Oct 2006 11:11:43 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> References: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> Message-ID: <502EBD6F-CAA2-4E3C-9037-1DE477E35BAD@frii.com> On Oct 29, 2006, at 10:20 PM, Paul Ramsey wrote: > All, > > The usual issue about how to signify SRSs which are not in the EPSG > database arises for the TMS. And because Mercator is both (a) not in > EPSG and (b) commonly used for tiled web mapping, this is not an > issue that can be put off. > > I think that TMS just needs to define the SRSs it needs inside the > specification itself, and by virtue of being a living and > collaborative spec, should be able to work that way. > > The open issue is what authority prefix to use for these > definitions. I have stubbed in a section with some example systems. > I used the "EPSG:" authority prefix. This is actually the prefix I > found them with in the wild, on the web, in live WMS instances. In > terms of interoperability, it makes sense to stick with what is being > used. Why break what is not broken? In terms of respecting the idea > of an "authority prefix" it makes no sense. > > Where does the community come down on this? > > P I'd be happy with EPSG:N and another block of URNs for non-EPSG. Could be urn:osgeo:crs:mercator (finally something concrete from OSGeo ;) or even urn:ramsey:crs:mercator. Sean --- Sean Gillies http://zcologia.com From pramsey at refractions.net Mon Oct 30 11:13:26 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:13:26 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> Message-ID: <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> I don't want an AUTO CRS, I want a fixed ID... the clients are mostly relatively dumb, they aren't going to be doing coordinate conversions, just comparing tokens and looking for identity (hey, these are the same, I can overlay them!). How about we set up our own authority, OSGEO: and start filling 'er up. I mean, there's nothing holy about EPSG, they just had a good pre- existing database. All the utility since then has been based on the agreement of everyone to look there for IDs. For some reason no other authority has been bothered with, which exacerbates EPSG's limitations. P On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> The open issue is what authority prefix to use for these >> definitions. I have stubbed in a section with some example >> systems. >> I used the "EPSG:" authority prefix. This is actually the >> prefix I found them with in the wild, on the web, in live WMS >> instances. In terms of interoperability, it makes sense to >> stick with what is being used. Why break what is not broken? >> In terms of respecting the idea of an "authority prefix" it >> makes no sense. >> >> Where does the community come down on this? > > Why not extend the WMS AUTO CRS concept to cover Mercator, etc? From bob.basques at ci.stpaul.mn.us Mon Oct 30 11:17:49 2006 From: bob.basques at ci.stpaul.mn.us (Bob Basques) Date: Mon, 30 Oct 2006 13:17:49 -0600 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> Message-ID: <45464FDD.7020007@ci.stpaul.mn.us> Paul Ramsey wrote: > I don't want an AUTO CRS, I want a fixed ID... the clients are mostly > relatively dumb, they aren't going to be doing coordinate > conversions, just comparing tokens and looking for identity (hey, > these are the same, I can overlay them!). > > How about we set up our own authority, OSGEO: and start filling 'er up. > > I mean, there's nothing holy about EPSG, they just had a good pre- > existing database. All the utility since then has been based on the > agreement of everyone to look there for IDs. For some reason no > other authority has been bothered with, which exacerbates EPSG's > limitations. > > Here, here. I second this, can a master catalog of sorts be arrived at where individuals or authoritative groups could apply for inclusion into the Catalog. I need the projections for the Counties in the State of Mn and Western Wi, for example. Each state has a EPSG (like) listing for their respective Counties, but no where are they in the same distributed catalog. bobb > P > > On 30-Oct-06, at 12:03 AM, Martin Daly wrote: > > >>> The open issue is what authority prefix to use for these >>> definitions. I have stubbed in a section with some example >>> systems. >>> I used the "EPSG:" authority prefix. This is actually the >>> prefix I found them with in the wild, on the web, in live WMS >>> instances. In terms of interoperability, it makes sense to >>> stick with what is being used. Why break what is not broken? >>> In terms of respecting the idea of an "authority prefix" it >>> makes no sense. >>> >>> Where does the community come down on this? >>> >> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >> > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > -- **************** You can't be late until you show up. *************** ************ You never learn anything by doing it right. ************ *** War doesn't determine who's right. War determines who's left. *** -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.basques.vcf Type: text/x-vcard Size: 309 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061030/ac4cb838/attachment.vcf From pramsey at refractions.net Mon Oct 30 11:23:45 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:23:45 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <45464FDD.7020007@ci.stpaul.mn.us> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> <45464FDD.7020007@ci.stpaul.mn.us> Message-ID: <F9A47264-091C-4A73-9340-D7DFFDACA8BC@refractions.net> The don't just use stateplane? Savages. I thought the whole point of stateplane was to get the counties into a standard set of projections. P On 30-Oct-06, at 11:17 AM, Bob Basques wrote: > Paul Ramsey wrote: >> I don't want an AUTO CRS, I want a fixed ID... the clients are >> mostly relatively dumb, they aren't going to be doing coordinate >> conversions, just comparing tokens and looking for identity (hey, >> these are the same, I can overlay them!). >> >> How about we set up our own authority, OSGEO: and start filling >> 'er up. >> >> I mean, there's nothing holy about EPSG, they just had a good pre- >> existing database. All the utility since then has been based on >> the agreement of everyone to look there for IDs. For some reason >> no other authority has been bothered with, which exacerbates >> EPSG's limitations. >> >> > Here, here. I second this, can a master catalog of sorts be > arrived at where individuals or authoritative groups could apply > for inclusion into the Catalog. I need the projections for the > Counties in the State of Mn and Western Wi, for example. Each > state has a EPSG (like) listing for their respective Counties, but > no where are they in the same distributed catalog. > > bobb > >> P >> >> On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> >> >>>> The open issue is what authority prefix to use for these >>>> definitions. I have stubbed in a section with some example >>>> systems. >>>> I used the "EPSG:" authority prefix. This is actually the >>>> prefix I found them with in the wild, on the web, in live WMS >>>> instances. In terms of interoperability, it makes sense to >>>> stick with what is being used. Why break what is not broken? >>>> In terms of respecting the idea of an "authority prefix" it >>>> makes no sense. >>>> >>>> Where does the community come down on this? >>>> >>> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >>> >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling >> >> > > > -- > > **************** You can't be late until you show up. > *************** > ************ You never learn anything by doing it right. > ************ > *** War doesn't determine who's right. War determines who's left. > *** > > <bob.basques.vcf> From SCHUTP at AGR.GC.CA Mon Oct 30 11:31:25 2006 From: SCHUTP at AGR.GC.CA (Schut, Peter) Date: Mon, 30 Oct 2006 14:31:25 -0500 Subject: [tiling] Common non-EPSG SRSs Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> OGC is coming up with an alternative based on URNs, and it is pretty much ready to go. Cheers, Peter. -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey Sent: Monday, October 30, 2006 2:13 PM To: Martin Daly Cc: tiling at lists.eogeo.org Subject: Re: [tiling] Common non-EPSG SRSs I don't want an AUTO CRS, I want a fixed ID... the clients are mostly relatively dumb, they aren't going to be doing coordinate conversions, just comparing tokens and looking for identity (hey, these are the same, I can overlay them!). How about we set up our own authority, OSGEO: and start filling 'er up. I mean, there's nothing holy about EPSG, they just had a good pre- existing database. All the utility since then has been based on the agreement of everyone to look there for IDs. For some reason no other authority has been bothered with, which exacerbates EPSG's limitations. P On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> The open issue is what authority prefix to use for these >> definitions. I have stubbed in a section with some example >> systems. >> I used the "EPSG:" authority prefix. This is actually the >> prefix I found them with in the wild, on the web, in live WMS >> instances. In terms of interoperability, it makes sense to >> stick with what is being used. Why break what is not broken? >> In terms of respecting the idea of an "authority prefix" it >> makes no sense. >> >> Where does the community come down on this? > > Why not extend the WMS AUTO CRS concept to cover Mercator, etc? _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From adoyle at eogeo.org Mon Oct 30 12:32:51 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Mon, 30 Oct 2006 15:32:51 -0500 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> References: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> Message-ID: <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> I guess I have never understood the need for a URN when something like EPSG:4326 or OSGEO:12345 would do. It's just more typing for what seems to be fairly little gain. A string is a string. I guess you can register your URN namespace at IANA or somewhere and this can provide a warm feeling of officialness. Allan On Oct 30, 2006, at 14:31, Schut, Peter wrote: > OGC is coming up with an alternative based on URNs, and it is pretty > much ready to go. > > Cheers, Peter. > > > > -----Original Message----- > From: tiling-bounces at lists.eogeo.org > [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey > Sent: Monday, October 30, 2006 2:13 PM > To: Martin Daly > Cc: tiling at lists.eogeo.org > Subject: Re: [tiling] Common non-EPSG SRSs > > I don't want an AUTO CRS, I want a fixed ID... the clients are mostly > relatively dumb, they aren't going to be doing coordinate > conversions, just comparing tokens and looking for identity (hey, > these are the same, I can overlay them!). > > How about we set up our own authority, OSGEO: and start filling > 'er up. > > I mean, there's nothing holy about EPSG, they just had a good pre- > existing database. All the utility since then has been based on the > agreement of everyone to look there for IDs. For some reason no > other authority has been bothered with, which exacerbates EPSG's > limitations. > > P > > On 30-Oct-06, at 12:03 AM, Martin Daly wrote: > >>> The open issue is what authority prefix to use for these >>> definitions. I have stubbed in a section with some example >>> systems. >>> I used the "EPSG:" authority prefix. This is actually the >>> prefix I found them with in the wild, on the web, in live WMS >>> instances. In terms of interoperability, it makes sense to >>> stick with what is being used. Why break what is not broken? >>> In terms of respecting the idea of an "authority prefix" it >>> makes no sense. >>> >>> Where does the community come down on this? >> >> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -- Allan Doyle +1.781.433.2695 adoyle at eogeo.org From pramsey at refractions.net Mon Oct 30 12:55:10 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 12:55:10 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> References: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> Message-ID: <7D0396E5-23E7-4A28-9E97-4B331BCD6724@refractions.net> Hail Allen, scourge of complexity! Yes, just because EPSG: got abused (because there was no safely valve for things that didn't) doesn't mean the concept is broken. We don't have that deep a hierarchy of information that we need a huge urn, and besides, it's not the token we care about, it's the friction-free process for adding items to the token-space. I feel "OSGEO:" starting to warm the cockles of my heart. Can't wait to hear what the board thinks... I'm pretty sure we said standards were going to be one of the few things *not* in the OSGEO mission :) P On 30-Oct-06, at 12:32 PM, Allan Doyle wrote: > I guess I have never understood the need for a URN when something > like EPSG:4326 or OSGEO:12345 would do. It's just more typing for > what seems to be fairly little gain. A string is a string. > > I guess you can register your URN namespace at IANA or somewhere and > this can provide a warm feeling of officialness. > > Allan > > On Oct 30, 2006, at 14:31, Schut, Peter wrote: > >> OGC is coming up with an alternative based on URNs, and it is pretty >> much ready to go. >> >> Cheers, Peter. >> >> >> >> -----Original Message----- >> From: tiling-bounces at lists.eogeo.org >> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey >> Sent: Monday, October 30, 2006 2:13 PM >> To: Martin Daly >> Cc: tiling at lists.eogeo.org >> Subject: Re: [tiling] Common non-EPSG SRSs >> >> I don't want an AUTO CRS, I want a fixed ID... the clients are mostly >> relatively dumb, they aren't going to be doing coordinate >> conversions, just comparing tokens and looking for identity (hey, >> these are the same, I can overlay them!). >> >> How about we set up our own authority, OSGEO: and start filling >> 'er up. >> >> I mean, there's nothing holy about EPSG, they just had a good pre- >> existing database. All the utility since then has been based on the >> agreement of everyone to look there for IDs. For some reason no >> other authority has been bothered with, which exacerbates EPSG's >> limitations. >> >> P >> >> On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> >>>> The open issue is what authority prefix to use for these >>>> definitions. I have stubbed in a section with some example >>>> systems. >>>> I used the "EPSG:" authority prefix. This is actually the >>>> prefix I found them with in the wild, on the web, in live WMS >>>> instances. In terms of interoperability, it makes sense to >>>> stick with what is being used. Why break what is not broken? >>>> In terms of respecting the idea of an "authority prefix" it >>>> makes no sense. >>>> >>>> Where does the community come down on this? >>> >>> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > -- > Allan Doyle > +1.781.433.2695 > adoyle at eogeo.org > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From SCHUTP at AGR.GC.CA Mon Oct 30 13:01:01 2006 From: SCHUTP at AGR.GC.CA (Schut, Peter) Date: Mon, 30 Oct 2006 16:01:01 -0500 Subject: [tiling] Common non-EPSG SRSs Message-ID: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> A string is a string, but you do want to be sure it is unambiguous and unique. For example, with a URN you could take a snapshot of EPSG and bury under an OSGEO heading, and then be able to extend EPSG under the auspices of OSGEO, and ensure that people don't get confused with how the European Peteroleum folks evolve their codes. If you just use EPSG:4326 then you are at the mercy of the changes made by that organization. Peter. -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Allan Doyle Sent: Monday, October 30, 2006 3:33 PM To: tiling at lists.eogeo.org Subject: Re: [tiling] Common non-EPSG SRSs I guess I have never understood the need for a URN when something like EPSG:4326 or OSGEO:12345 would do. It's just more typing for what seems to be fairly little gain. A string is a string. I guess you can register your URN namespace at IANA or somewhere and this can provide a warm feeling of officialness. Allan From adoyle at eogeo.org Mon Oct 30 13:08:11 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Mon, 30 Oct 2006 16:08:11 -0500 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> References: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> Message-ID: <B7C922CD-591C-483D-91EF-24E81EACC2C3@eogeo.org> On Oct 30, 2006, at 16:01, Schut, Peter wrote: > A string is a string, but you do want to be sure it is unambiguous and > unique. For example, with a URN you could take a snapshot of EPSG and > bury under an OSGEO heading, and then be able to extend EPSG under the > auspices of OSGEO, and ensure that people don't get confused with how > the European Peteroleum folks evolve their codes. If you just use > EPSG:4326 then you are at the mercy of the changes made by that > organization. Are you saying we can do OSGEO:EPSG:4326 (with appropriate additional URN trimmings?) I would suspect that EPSG would be a bit unhappy with that, especially given the major flareups over the years about the use of 4326 in WMS. But what the heck. We already have an issue with the "modern" interpretation of EPSG:4326. I'm not anti-URN. I'm sure it has its place. But I'm not in favor of throwing in references to other specs unless they are really needed. The more of that you do, the harder it is to implement everything properly without first becoming an expert in everything else. Allan > > Peter. > > > -----Original Message----- > From: tiling-bounces at lists.eogeo.org > [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Allan Doyle > Sent: Monday, October 30, 2006 3:33 PM > To: tiling at lists.eogeo.org > Subject: Re: [tiling] Common non-EPSG SRSs > > I guess I have never understood the need for a URN when something > like EPSG:4326 or OSGEO:12345 would do. It's just more typing for > what seems to be fairly little gain. A string is a string. > > I guess you can register your URN namespace at IANA or somewhere and > this can provide a warm feeling of officialness. > > Allan > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -- Allan Doyle +1.781.433.2695 adoyle at eogeo.org From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 05:49:16 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 08:49:16 -0500 Subject: [tiling] global profile Message-ID: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> hello all first off, I love this spec. I think it holds a lot of promise when using tile sets in both browsers and rich clients like ArcMap. kudos to everyone who got it off the ground. so, I can understand why EPSG:4326 is used as a common denominator but all the big GYM providers use Mercator World for their tiles. Any chance this could used as the global standard? I could see many people wanting to overlay their tiles over the existing GYM satellite images. just a thought... cheers brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/6bd62538/attachment.html From pramsey at refractions.net Tue Oct 31 07:44:25 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 07:44:25 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> Message-ID: <F41499EC-0445-490B-BE08-D0FAD64A9EDF@refractions.net> Brian, There are two (wait, three) reasons I went for EPSG:4326 in the first draft: - I figured that the tile sets for the 3D clients were largely in 4326 (at least, Worldwind's are) - I knew that most/all of the WMS servers supported 4326 (standard says it is mandatory, and most do support it) and lots of TMS servers will be used to front for WMS servers. - I know that almost no WMS servers support world mercator (hacked EPSG:41001) so getting tiles out into that projection will be harder than with EPSG:4326, where one can simply front a WMS. You do lots of KML / GEarth, so you would know: since the web clients will have a hard time integrating mercator and 4326, can the 3D clients trivially do it. For example, can GEarth consume a tile cache of data in Mercator using the regions mechanism? Paul On 31-Oct-06, at 5:49 AM, Brian Flood wrote: > hello all > > first off, I love this spec. I think it holds a lot of promise when > using tile sets in both browsers and rich clients like ArcMap. > kudos to everyone who got it off the ground. > > > > so, I can understand why EPSG:4326 is used as a common denominator > but all the big GYM providers use Mercator World for their tiles. > Any chance this could used as the global standard? I could see many > people wanting to overlay their tiles over the existing GYM > satellite images. > > > > just a thought? > > > > cheers > > brian > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/603e6c91/attachment-0001.htm From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 09:15:17 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 12:15:17 -0500 Subject: [tiling] global profile In-Reply-To: <F41499EC-0445-490B-BE08-D0FAD64A9EDF@refractions.net> Message-ID: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> hi Paul well, those are all good reasons. If it weren't for my specialized need to integrate with the GYM stuff, I would have to agree with you on all counts. I'll do some tests and see how badly the data lines up if we draw in 4326. Most of our users will be using this for visualization anyway, any GIS operation/analysis would occur against the raw data. My biggest issue is with small text labels and how distorted they get when the tiles are reprojected but then again, this is an issue that will plague any tileset that contains labels GE - as it stands, GE would not be able to consume a tileset natively however a simple server script to calc/write the regions and then redirect their contents towards the appropriate image url should suffice. The WMS redirect could be a starting point. Another thing with GE ground overlays is that they prefer slightly larger images (say 512x512) over the smaller 256 ones used in the browsers. I'm kinda deciding now if I want to produce 2 sets or instead to reply on a server script to combine a quad of images just before the region contents are sent to GE. YMMV and I still have a lot of testing to do now on the positive side, once the above issues are dealt with, the tilesets could overlay really well in GE. as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. I'll have to look if those tile caches could be indexed but if memory serves, I don't think they use the y folder, x file naming convention you have laid out. cheers brian -----Original Message----- From: Paul Ramsey [mailto:pramsey at refractions.net] Sent: Tuesday, October 31, 2006 10:44 AM To: Brian Flood Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile Brian, There are two (wait, three) reasons I went for EPSG:4326 in the first draft: - I figured that the tile sets for the 3D clients were largely in 4326 (at least, Worldwind's are) - I knew that most/all of the WMS servers supported 4326 (standard says it is mandatory, and most do support it) and lots of TMS servers will be used to front for WMS servers. - I know that almost no WMS servers support world mercator (hacked EPSG:41001) so getting tiles out into that projection will be harder than with EPSG:4326, where one can simply front a WMS. You do lots of KML / GEarth, so you would know: since the web clients will have a hard time integrating mercator and 4326, can the 3D clients trivially do it. For example, can GEarth consume a tile cache of data in Mercator using the regions mechanism? Paul On 31-Oct-06, at 5:49 AM, Brian Flood wrote: hello all first off, I love this spec. I think it holds a lot of promise when using tile sets in both browsers and rich clients like ArcMap. kudos to everyone who got it off the ground. so, I can understand why EPSG:4326 is used as a common denominator but all the big GYM providers use Mercator World for their tiles. Any chance this could used as the global standard? I could see many people wanting to overlay their tiles over the existing GYM satellite images. just a thought... cheers brian _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From cholmes at openplans.org Tue Oct 31 10:59:04 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 13:59:04 -0500 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> Message-ID: <45479CF8.1010609@openplans.org> > Another thing with > GE ground overlays is that they prefer slightly larger images (say > 512x512) over the smaller 256 ones used in the browsers. Why? Where does this preference come from? My reading of the region spec seemed to give implementors leeway over the size of images returned. Or is this just from experience that it looks/performs better with bigger tiles? > I'm kinda > deciding now if I want to produce 2 sets or instead to reply on a server > script to combine a quad of images just before the region contents are > sent to GE. If you could get it to perform well it seems the latter would be preferable, I would at least play with that approach a bit. best regards, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/882ee376/attachment.vcf From stein at geofusion.com Tue Oct 31 10:54:01 2006 From: stein at geofusion.com (Chuck Stein) Date: Tue, 31 Oct 2006 10:54:01 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> Message-ID: <092801c6fd1d$f5f9b720$d1a63e05@lapchuck> I assume you mean ESRI's ArcGlobe inside Explorer. This uses the GeoMatrix tiling system that I submitted to this group as a paper a month or so ago. The GeoMatrix system uses a combination of Geographic (EPSG:4326) between +/-45 latitude and what I call Square Polar projection above and below 45 degrees. This system might sound overly complex but it is designed for use in texture mapping. The square polar projection provides a much more efficient representation of the polar areas than Geographic or Mercator and it is more compact and reduces bandwidth requirements. You will also see that the distortion at the poles is much less that you see on GE and WW. You can see it in our web-enabled GeoPlayer at www.geoplayer.com/gateways (warning: requires PC and IE - we will be upgrading very soon with support for Firefox and Mac). With regards to distorted text because it is burned into the imagery. Best to keep the text out of the imagery. There will always be different systems using different projections. If the goal is cross-system compatibility this will always be a problem. Chuck GeoFusion > as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them > into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. > I'll have to look if those tile caches could be indexed but if memory serves, I don't think they > use the y folder, x file naming convention you have laid out. From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 11:37:54 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 14:37:54 -0500 Subject: [tiling] global profile In-Reply-To: <45479CF8.1010609@openplans.org> Message-ID: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> 512x512 - yea, just what I (and others) have found. something about how they manage the video memory. but you're correct in saying there is no specific size that is necessary tile combo - I'll let you know how it goes... cheers brian -----Original Message----- From: Chris Holmes [mailto:cholmes at openplans.org] Sent: Tuesday, October 31, 2006 1:59 PM To: Brian Flood Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile > Another thing with > GE ground overlays is that they prefer slightly larger images (say > 512x512) over the smaller 256 ones used in the browsers. Why? Where does this preference come from? My reading of the region spec seemed to give implementors leeway over the size of images returned. Or is this just from experience that it looks/performs better with bigger tiles? > I'm kinda > deciding now if I want to produce 2 sets or instead to reply on a server > script to combine a quad of images just before the region contents are > sent to GE. If you could get it to perform well it seems the latter would be preferable, I would at least play with that approach a bit. best regards, Chris From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 11:41:31 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 14:41:31 -0500 Subject: [tiling] global profile In-Reply-To: <092801c6fd1d$f5f9b720$d1a63e05@lapchuck> Message-ID: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> that's interesting chuck. yea, I assume that's what's under the covers in AGX, its using the globe control. makes sense for the polar data I guess did esri ever upgrade to your latest software bits? cheers brian -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Chuck Stein Sent: Tuesday, October 31, 2006 1:54 PM To: tiling at lists.eogeo.org Subject: Re: [tiling] global profile I assume you mean ESRI's ArcGlobe inside Explorer. This uses the GeoMatrix tiling system that I submitted to this group as a paper a month or so ago. The GeoMatrix system uses a combination of Geographic (EPSG:4326) between +/-45 latitude and what I call Square Polar projection above and below 45 degrees. This system might sound overly complex but it is designed for use in texture mapping. The square polar projection provides a much more efficient representation of the polar areas than Geographic or Mercator and it is more compact and reduces bandwidth requirements. You will also see that the distortion at the poles is much less that you see on GE and WW. You can see it in our web-enabled GeoPlayer at www.geoplayer.com/gateways (warning: requires PC and IE - we will be upgrading very soon with support for Firefox and Mac). With regards to distorted text because it is burned into the imagery. Best to keep the text out of the imagery. There will always be different systems using different projections. If the goal is cross-system compatibility this will always be a problem. Chuck GeoFusion > as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them > into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. > I'll have to look if those tile caches could be indexed but if memory serves, I don't think they > use the y folder, x file naming convention you have laid out. _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 11:44:14 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 11:44:14 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> Message-ID: <1162323854.4547a78e2da23@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/08d587f0/attachment.pot From pramsey at refractions.net Tue Oct 31 11:45:46 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 11:45:46 -0800 Subject: [tiling] Polar Projection In-Reply-To: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> Message-ID: <1162323946.4547a7eab3c71@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/3cdfb636/attachment.asc From cholmes at openplans.org Tue Oct 31 12:02:53 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 15:02:53 -0500 Subject: [tiling] global profile In-Reply-To: <1162323854.4547a78e2da23@ssl.refractions.net> References: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> <1162323854.4547a78e2da23@ssl.refractions.net> Message-ID: <4547ABED.3040300@openplans.org> Yeah, I was thinking this as well. +1 Paul Ramsey wrote: > Back to the global-profile. We could define a *second* global-profile, that is > mercator based. A global profile is just a projection and an agreed set of > scales, so there could be a mercator one as well. If we started with the whole > world and went down from there by factors of two again, the two profiles could be > used together with a little linear stretching, for those who don't mind some > intra-tile inaccuracies. > > P > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547a7ba62727731818748! > -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/5d7f8696/attachment.vcf From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 12:05:50 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 15:05:50 -0500 Subject: [tiling] global profile In-Reply-To: <4547ABED.3040300@openplans.org> Message-ID: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> agreed, that makes sense to me -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Chris Holmes Sent: Tuesday, October 31, 2006 3:03 PM To: Paul Ramsey Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile Yeah, I was thinking this as well. +1 Paul Ramsey wrote: > Back to the global-profile. We could define a *second* global-profile, that is > mercator based. A global profile is just a projection and an agreed set of > scales, so there could be a mercator one as well. If we started with the whole > world and went down from there by factors of two again, the two profiles could be > used together with a little linear stretching, for those who don't mind some > intra-tile inaccuracies. > > P > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547a7ba62727731818748! > -- Chris Holmes The Open Planning Project http://topp.openplans.org From stein at geofusion.com Tue Oct 31 12:11:20 2006 From: stein at geofusion.com (Chuck Stein) Date: Tue, 31 Oct 2006 12:11:20 -0800 Subject: [tiling] Polar Projection In-Reply-To: <1162323946.4547a7eab3c71@ssl.refractions.net> Message-ID: <095901c6fd28$c2191260$d1a63e05@lapchuck> Completey non-standard? It has been our standard (and ESRI's and others) for 5 years :^). I have never tried the WKT. I would definetly like to get it into OSGEO (make it yet another real standard). What do we need to do? By the way, while Paul Hansen invented the square polar on his own, he was not the first so it is not 'ours'. > Chuck, is your polar projection completely non-standard, > or is it expressable in WKT? > Could you add it to the OSGEO: projection list if possible? > P ESRI got a dump of the bits recently. It is not clear to me how easy it is for them to integrate at this point. > did esri ever upgrade to your latest software bits? > brian chuck From pramsey at refractions.net Tue Oct 31 12:43:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 12:43:34 -0800 Subject: [tiling] Polar Projection In-Reply-To: <095901c6fd28$c2191260$d1a63e05@lapchuck> References: <095901c6fd28$c2191260$d1a63e05@lapchuck> Message-ID: <1162327414.4547b576d34be@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/7aaa48d2/attachment.asc From pramsey at refractions.net Tue Oct 31 12:43:58 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 12:43:58 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> Message-ID: <1162327438.4547b58e481b5@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/300e13f5/attachment.pot From tisham at apogee.com.au Tue Oct 31 14:43:19 2006 From: tisham at apogee.com.au (tisham at apogee.com.au) Date: Wed, 01 Nov 2006 08:43:19 +1000 Subject: [tiling] tiling Digest, Vol 9, Issue 10 In-Reply-To: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> References: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> Message-ID: <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> Hi all, News from the Worldwind world. We have a functional Virtual Earth Plugin in the SVN Unstable branch now. This demonstrates reprojection on the fly of VE tiles from mercator to 4326(well latlon) using proj.dll as the calculation engine. This is done on the fly and without any significant overhead, so it is possible.We can do exactly the same for Google or Yahoo, but the lawyers keep us at bay. Regards, Tisham Dhar(aka what_nick) Worldwind Open Source Developer Apogee Imaging International http://www.apogee.com.au ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From cholmes at openplans.org Tue Oct 31 14:58:57 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 17:58:57 -0500 Subject: [tiling] tiling Digest, Vol 9, Issue 10 In-Reply-To: <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> References: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> Message-ID: <4547D531.3080400@openplans.org> tisham at apogee.com.au wrote: > Hi all, > > News from the Worldwind world. > > We have a functional Virtual Earth Plugin in the SVN Unstable branch now. This > demonstrates reprojection on the fly of VE tiles from mercator to 4326(well > latlon) using proj.dll as the calculation engine. > > This is done on the fly and without any significant overhead, so it is > possible.We can do exactly the same for Google or Yahoo, but the lawyers keep > us at bay. Very cool. Can you do 4326 to mercator? It seems like the lawyers would be fine with that, overlaying worldwind tiles on google or yahoo maps, no? And that's the direction we're interested in going as well, I believe - having the TMS store its tiles in 4326, and go on the fly to mercator to be overlaid on google and yahoo. best regards, Chris > > Regards, > > Tisham Dhar(aka what_nick) > Worldwind Open Source Developer > Apogee Imaging International > http://www.apogee.com.au > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547d35687191429667743! > -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/25ca286e/attachment.vcf From schuyler at nocat.net Tue Oct 31 17:14:33 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Tue, 31 Oct 2006 17:14:33 -0800 Subject: [tiling] WMS Tiling Client Recommendation Message-ID: <20061101011433.GM30475@vishnu.tridity.org> I've finally published a tiling WMS recommendation, although I seem to have gone a bit overboard from what Paul probably envisioned when he titled the wiki page "WMS Tiling Client Recommendation".[1] I did, at any rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I don't think I missed anything important. Comments? Questions? Complaints? Should the page be renamed? Or should the server extensions be thrown away in favor of TMS? [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF SDE From pramsey at refractions.net Tue Oct 31 20:25:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:25:34 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <7DB60670-2FB2-4764-8719-DC1929628C4A@refractions.net> Schuyler, I've thrown some edits into the page, * I think the initial resolution is wrong for the first global profile, * I have changed the BoundingBox to LatLonBoundingBox (or, you can change the extents for the mercator profile to coordinates in mercator) * I have changed EPSG:41001 to OSGEO:41001 to match the TMS spec and stay on EPSG's good side I think you need to give a precise required ordering of all the possible getmap parameters. Paul On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 20:30:51 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:30:51 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <2B77C974-8097-42AB-BCC0-950286754F05@refractions.net> Arg, *and* you need to be very specific about the encoding of things in URLs, since some clients are sloppy about whether/how they encode some aspects of the URL (Do you have to encode the ":" in the "EPSG: 4326"?). You should be clear about whether you want "+" as the encoding for " " or %22. Etc etc etc. All the reasons why WMS is a PITA to make cachable -- it's so hard to get people to say the same thing in exactly the same way. (I am not sure about the "server extensions" part, it might be better just to get all the clients talking the same way, with "TILED=TRUE" in the URL, and if the server maintainer sees lots of TILED=TRUE requests coming in, it's time to turn on mod_cache and start getting some free performance boosting.) P On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 20:48:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:48:34 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net> There are some mandatory WMS request parameters that are not in the list of parameters, like VERSION. The more I think about this, the more it seems like a fools errand to try and constrain WMS requests sufficiently to get acceptable shared caching behavior. On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling

From paul.neave at gmail.com Tue Oct 3 15:58:05 2006 From: paul.neave at gmail.com (Paul Neave) Date: Tue, 3 Oct 2006 23:58:05 +0100 Subject: [tiling] When will we have WMS tile caching? Message-ID: Hi group, I'm currently building an web-based mapping application that uses imagery from the WMS server, but it's currently very slow compared to other mapping services (Google Maps etc.) that use cached imagery rather than the single server with a single cgi script I see there has been some progress on creating a cached WMS tile server: http://lists.eogeo.org/pipermail/tiling/2006-September/000050.html but was just wondering how long do people think it will take before this is implemented? It's been no problem for me to use the usual 'bbox' values and so on to create the tiles, the only issue is that's is sooo slow (well at least is seems so in comparison...) On similar note, speed improvements could also be made by mirroring the cgi script on different subdomains. Google Maps and the others do this to balance the load and allow multiple downloads, such as http://tile0.servername.com/script? http://tile1.servername.com/script? and so on. Browsers can only download 2 files at once from the same server, so by having 4 subdomains this allows 8 simultaneous downloads. What do you think? Thanks for any help, Paul. From schuyler at nocat.net Tue Oct 3 19:27:10 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Tue, 3 Oct 2006 19:27:10 -0700 Subject: [tiling] When will we have WMS tile caching? In-Reply-To: References: Message-ID: <20061004022710.GC2621@vishnu.tridity.org> * On 3-Oct-2006 at 4:04PM PDT, Paul Neave said: > > I see there has been some progress on creating a cached WMS tile server: > http://lists.eogeo.org/pipermail/tiling/2006-September/000050.html > > but was just wondering how long do people think it will take before > this is implemented? It's been no problem for me to use the usual > 'bbox' values and so on to create the tiles, the only issue is that's > is sooo slow (well at least is seems so in comparison...) I'm sketching out the WMS tiling recommendations right now, and I think Paul Ramsey is working on a similar "Web Tile Service" writeup, based on the FOSS4G discussions. I'll post my draft to the OSGeo wiki by Thursday, and ping the list again, I promise. ;) The tiled WMS recommendation will be blessedly short, as all such documents should be. As for implementations, well, that's the next step, isn't it? SDE From paul.neave at gmail.com Wed Oct 4 07:28:37 2006 From: paul.neave at gmail.com (Paul Neave) Date: Wed, 4 Oct 2006 15:28:37 +0100 Subject: [tiling] When will we have WMS tile caching? In-Reply-To: <20061004022710.GC2621@vishnu.tridity.org> References: <20061004022710.GC2621@vishnu.tridity.org> Message-ID: On 04/10/06, Schuyler Erle wrote: > I'm sketching out the WMS tiling recommendations right now, and I > think Paul Ramsey is working on a similar "Web Tile Service" writeup, > based on the FOSS4G discussions. Brilliant, thanks a lot - looking forward to it! Paul. From pramsey at refractions.net Sun Oct 22 18:01:09 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 22 Oct 2006 18:01:09 -0700 Subject: [tiling] Tile Map Service Message-ID: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> I have placed a first thin draft here: Call me trendy, but I went for a "RESTful" approach to the problem, which has the added effect of making "serverless" services simpler to generate. Paul From bob.basques at ci.stpaul.mn.us Mon Oct 23 09:05:06 2006 From: bob.basques at ci.stpaul.mn.us (Bob Basques) Date: Mon, 23 Oct 2006 11:05:06 -0500 Subject: [tiling] Tile Map Service In-Reply-To: <1161618812.453ce57ca625f@ssl.refractions.net> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> <453CDC44.8010009@ci.stpaul.mn.us> <1161618812.453ce57ca625f@ssl.refractions.net> Message-ID: <453CE832.5020209@ci.stpaul.mn.us> Paul Ramsey wrote: > > > Not sure what you mean by "overlapping" scales... each tileset has only one > scale (one value for "units-per-pixel") so I don't see how they can overlap, > unless they are identical. > Instead of descrete levels and cut-offs of the coverage areas, the Levels may have overlapping scales of coverage, instead of doubling the scale everytime, you might only go half way up so that the lower Level covers the same resolution as the lower half of the next highest level. > >> One last thought, how would you see something similar working for 3D data? >> > > Well, assuming the data is properly partitionable, a "cube server" would be a > trivial extension. The trouble is, people mean a lot of different things when > they say "3D data". > Hmm, cube might work, but for the real world, the Z direction is pretty small in comparison to the X/Y axis of the data. I was mostly interested in coincident data and stuff like that. How to break 3D elements at the edges, etc. bobb > P > > > > > -- **************** You can't be late until you show up. *************** ************ You never learn anything by doing it right. ************ *** War doesn't determine who's right. War determines who's left. *** -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.basques.vcf Type: text/x-vcard Size: 309 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061023/4818560d/attachment.vcf From bob.basques at ci.stpaul.mn.us Mon Oct 23 08:34:33 2006 From: bob.basques at ci.stpaul.mn.us (Bob Basques) Date: Mon, 23 Oct 2006 10:34:33 -0500 Subject: [tiling] Tile Map Service In-Reply-To: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> Message-ID: <453CE109.4070506@ci.stpaul.mn.us> Paul Ramsey wrote: > I have placed a first thin draft here: > > > > Call me trendy, but I went for a "RESTful" approach to the problem, > which has the added effect of making "serverless" services simpler to > generate. > Hello, Are you talking about the X for Folder and Y for Filename schema. Very interesting way of approaching it actually. I've always put all the tiles for each level in the same folder. I'm wondering though, how you see this helping with things? Granted my largest layer only has 14,000+ tiles in it, so file system lookups haven't been a problem as of yet, but even splitting them out vertically by the "X" value can only reduce the number of tiles so much. I wonder, does it make any sense to build the same chopping idea into the "y" value as well? Where there ends up an essentially pre-tiled set of folders for Spatial Indexing before any data is even examined? BTW, I use a Zoomlevel identifiers of "L1, L2, L3, etc". L0 = 1ft per pixel, (yes we have some negative values too. "-L1, -L2, etc) while this might not sit well for everyone. I also like to use integers for the coordinate names, starting my origins at 0,0 and tiling from there. Not sure if this is good or bad practice. Based on the description you have for capabilities, it looks like overlapping scales of tile sets would be supported as well (Just ask, I'll explain why this is important to me :c) I know I'm picking on some of the details early, don't mind me on that account. One last thought, how would you see something similar working for 3D data? bobb > Paul > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > -- **************** You can't be late until you show up. *************** ************ You never learn anything by doing it right. ************ *** War doesn't determine who's right. War determines who's left. *** -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.basques.vcf Type: text/x-vcard Size: 309 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061023/c9535d24/attachment.vcf From pramsey at refractions.net Mon Oct 23 08:53:32 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 23 Oct 2006 08:53:32 -0700 Subject: [tiling] Tile Map Service In-Reply-To: <453CDC44.8010009@ci.stpaul.mn.us> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> <453CDC44.8010009@ci.stpaul.mn.us> Message-ID: <1161618812.453ce57ca625f@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061023/f289d2f8/attachment.pot From bartvde at osgis.nl Mon Oct 23 09:46:41 2006 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Mon, 23 Oct 2006 18:46:41 +0200 Subject: [tiling] Tile Map Service In-Reply-To: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> Message-ID: <453CF1F0.40608@osgis.nl> Hey Paul, first of all thanks for this initiative! Why did you leave the traditional OGC GetCapabilities interface? I know this is closer to REST principles, but do you expect other OGC Web Services to move to this approach as well? Once you use TileMapServer where you mean TileMapService I guess. Also with the TileMap element, I would expect it to have a child element which contains the description if you compare to other OGC Web Services. Having the TileMap contain their own href feels a bit uncomfortable (call me traditional OGC :-), but I guess that's inline with REST as well. Even if so, why not use <OnlineResource> all the time? I miss the image format in the TileMap declaration. Why give the SRS already, but the image format only later? What's the logic behind that? To be more inline with traditional OGC, I guess you would use a DescribeTileMap request? Why use units-per-pixel and not ScaleDenominator? If using the first, should you not at least specify the unit? Maybe specify the origin as a gml:Point? Or do you think that's overkill :-) ? Can you explain the background behind your unit-per-pixel formula for the global profile? Thanks again. Best regards, Bart Paul Ramsey schreef: > I have placed a first thin draft here: > > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > > Call me trendy, but I went for a "RESTful" approach to the problem, > which has the added effect of making "serverless" services simpler to > generate. > > Paul > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > -- Bart van den Eijnden OSGIS, Open Source GIS bartvde at osgis.nl http://www.osgis.nl From pramsey at refractions.net Mon Oct 23 11:44:56 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 23 Oct 2006 11:44:56 -0700 Subject: [tiling] Tile Map Service In-Reply-To: <453CF1F0.40608@osgis.nl> References: <4B2A824E-E2EC-4F54-A5F3-FF44A54CE688@refractions.net> <453CF1F0.40608@osgis.nl> Message-ID: <1161629096.453d0da8dd51f@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061023/43dd0236/attachment.asc From pramsey at refractions.net Thu Oct 26 22:25:43 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Thu, 26 Oct 2006 22:25:43 -0700 Subject: [tiling] Tiling Specification Message-ID: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> I have made some minor edits to the tiling spec <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> but nothing to rock the house. I am waiting for some complaints about the spec, the hard stuff. Jason Birch mentioned that it might be hard to implement under IIS, lacking mod_rewrite. There's no point in having a hard-to-implement spec, that defeats my goals, for sure. What do other people thing of that? (Note that the service root does not have to be a bare server URL. It could equally be http://mygreatserver.com/mytms/ as http:// tms.osgeo.org/) ) Paul From pramsey at refractions.net Fri Oct 27 08:39:30 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 08:39:30 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027151634.GA3349@crschmidt.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> Message-ID: <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> Actually, I think if the program is set as a cgi-bin, a rewrite might not be required, since everything after the cgi-bin gets sent to the program... see: http://mapserver.refractions.net/cgi-bin/mapserv48/foo/bar On 27-Oct-06, at 8:16 AM, Christopher Schmidt wrote: > On Thu, Oct 26, 2006 at 10:25:43PM -0700, Paul Ramsey wrote: > (Reordering for clarity) > >> <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> >> (Note that the service root does not have to be a bare server URL. >> It could equally be http://mygreatserver.com/mytms/ as http:// >> tms.osgeo.org/) ) > >> Jason Birch mentioned that it might be >> hard to implement under IIS, lacking mod_rewrite. > > Couldn't the service root also be: > > http://tile.example.com/mytms?url= > > After which you would get: > > http://tile.example.com/mytms?url=/1.0.0/landsat2000/1/8500/8500.png > > This seems like it would be a solution for the IIS case, since > presumably IIS could do the parsing of the QUERY_STRING argument. > > This seems possible to me given the spec, but I could be wrong. > > Regards, > -- > Christopher Schmidt > Web Developer From crschmidt at crschmidt.net Fri Oct 27 08:16:34 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri, 27 Oct 2006 11:16:34 -0400 Subject: [tiling] Tiling Specification In-Reply-To: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> Message-ID: <20061027151634.GA3349@crschmidt.net> On Thu, Oct 26, 2006 at 10:25:43PM -0700, Paul Ramsey wrote: (Reordering for clarity) > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > (Note that the service root does not have to be a bare server URL. > It could equally be http://mygreatserver.com/mytms/ as http:// > tms.osgeo.org/) ) > Jason Birch mentioned that it might be > hard to implement under IIS, lacking mod_rewrite. Couldn't the service root also be: http://tile.example.com/mytms?url= After which you would get: http://tile.example.com/mytms?url=/1.0.0/landsat2000/1/8500/8500.png This seems like it would be a solution for the IIS case, since presumably IIS could do the parsing of the QUERY_STRING argument. This seems possible to me given the spec, but I could be wrong. Regards, -- Christopher Schmidt Web Developer From crschmidt at crschmidt.net Fri Oct 27 08:54:08 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri, 27 Oct 2006 11:54:08 -0400 Subject: [tiling] Tiling Specification In-Reply-To: <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> Message-ID: <20061027155408.GB3349@crschmidt.net> On Fri, Oct 27, 2006 at 08:39:30AM -0700, Paul Ramsey wrote: > Actually, I think if the program is set as a cgi-bin, a rewrite might > not be required, since everything after the cgi-bin gets sent to the > program... see: > > http://mapserver.refractions.net/cgi-bin/mapserv48/foo/bar That may be setup specific. I wouldn't expect that to neccesarily be the case with IIS, which is the use case that was being addressed. Additionally, I'm not sure that all servers provide PATH_INFO to scripting langauges. (I would hope so, but can't be sure.) Regards, -- Christopher Schmidt Web Developer From pramsey at refractions.net Fri Oct 27 10:02:42 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 10:02:42 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027155408.GB3349@crschmidt.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> Message-ID: <1161968562.45423bb25ed93@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/de43c051/attachment.asc From schuyler at nocat.net Fri Oct 27 10:26:38 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Fri, 27 Oct 2006 10:26:38 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <1161968562.45423bb25ed93@ssl.refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> Message-ID: <20061027172638.GE30475@vishnu.tridity.org> * On 27-Oct-2006 at 10:02AM PDT, Paul Ramsey said: > At a minimum, in a CGI environment, the server has to provide the full calling > URL to the executable, so the information will be there. You're right about > IIS, I am not sure of the behavior for http://server/cgi-bin/exec/foo/bar is > specified anywhere, and the Apache behavior could just be a lucky break. No, that's part of the NCSA CGI spec: http://hoohoo.ncsa.uiuc.edu/cgi/env.html However, MS seems to think it's a security risk, so it needs to be explicitly enabled, apparently: http://support.microsoft.com/kb/q184320/ SDE From pramsey at refractions.net Fri Oct 27 10:34:09 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 10:34:09 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027172638.GE30475@vishnu.tridity.org> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> <20061027172638.GE30475@vishnu.tridity.org> Message-ID: <1161970449.45424311c7b67@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/79da0a83/attachment.pot From sgillies at frii.com Fri Oct 27 10:49:25 2006 From: sgillies at frii.com (Sean Gillies) Date: Fri, 27 Oct 2006 11:49:25 -0600 Subject: [tiling] Tiling Specification In-Reply-To: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> Message-ID: <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> On Oct 26, 2006, at 11:25 PM, Paul Ramsey wrote: > I have made some minor edits to the tiling spec > > <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> > > but nothing to rock the house. I am waiting for some complaints about > the spec, the hard stuff. Jason Birch mentioned that it might be > hard to implement under IIS, lacking mod_rewrite. There's no point > in having a hard-to-implement spec, that defeats my goals, for sure. > What do other people thing of that? > > (Note that the service root does not have to be a bare server URL. > It could equally be http://mygreatserver.com/mytms/ as http:// > tms.osgeo.org/) ) > > Paul Paul, I like how the spec is developing. Anyone who can't implement the necessary URL traversal on their current web app server can modernize or go home ;) Seriously, this spec shouldn't be encumbered by limitations of CGI or IIS. Cheers, Sean --- Sean Gillies http://zcologia.com From pavlenko at users.berlios.de Fri Oct 27 12:32:16 2006 From: pavlenko at users.berlios.de (Artem Pavlenko) Date: Fri, 27 Oct 2006 20:32:16 +0100 Subject: [tiling] Tiling Specification In-Reply-To: <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> Message-ID: <45425EC0.2020206@users.berlios.de> Paul, I just want second Sean on this one. Please, keep it simple! Make sure that all URLs are _nice_ and don't get distracted by cgi-bin:). This spec is very timely, indeed. I might be implementing it in the next couple months:P. Now that we can render tiles - http://mapnik.org/tiling_demo, we need a way to publish them. Cheers, Artem. Sean Gillies wrote: > On Oct 26, 2006, at 11:25 PM, Paul Ramsey wrote: > > >> I have made some minor edits to the tiling spec >> >> <http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification> >> >> but nothing to rock the house. I am waiting for some complaints about >> the spec, the hard stuff. Jason Birch mentioned that it might be >> hard to implement under IIS, lacking mod_rewrite. There's no point >> in having a hard-to-implement spec, that defeats my goals, for sure. >> What do other people thing of that? >> >> (Note that the service root does not have to be a bare server URL. >> It could equally be http://mygreatserver.com/mytms/ as http:// >> tms.osgeo.org/) ) >> >> Paul >> > > Paul, I like how the spec is developing. Anyone who can't implement > the necessary URL traversal on their current web app server can > modernize or go home ;) Seriously, this spec shouldn't be encumbered > by limitations of CGI or IIS. > > Cheers, > Sean > > --- > Sean Gillies > http://zcologia.com > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > From pramsey at refractions.net Fri Oct 27 15:17:25 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 15:17:25 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <45425EC0.2020206@users.berlios.de> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <359AFAB9-81EA-4160-A0BC-693FB34188B8@frii.com> <45425EC0.2020206@users.berlios.de> Message-ID: <1161987445.454285755beda@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/b0c68eee/attachment.asc From pramsey at refractions.net Fri Oct 27 15:43:46 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 15:43:46 -0700 Subject: [tiling] Supporting Mercator and Plate Carre Message-ID: <1161989026.45428ba25e98d@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061027/f919e6a1/attachment.pot From jason at jasonbirch.com Fri Oct 27 21:58:32 2006 From: jason at jasonbirch.com (Jason Birch) Date: Fri, 27 Oct 2006 21:58:32 -0700 Subject: [tiling] Tiling Specification In-Reply-To: <20061027172638.GE30475@vishnu.tridity.org> References: <ADC99FCA-8385-44EF-9A02-775350C9EBBB@refractions.net> <20061027151634.GA3349@crschmidt.net> <7284BF27-B021-4E52-928C-0497E4448E8C@refractions.net> <20061027155408.GB3349@crschmidt.net> <1161968562.45423bb25ed93@ssl.refractions.net> <20061027172638.GE30475@vishnu.tridity.org> Message-ID: <4542E378.6010509@jasonbirch.com> Schuyler Erle wrote: > However, MS seems to think it's a security risk, so it needs to be > explicitly enabled, apparently: > > http://support.microsoft.com/kb/q184320/ Heh. I should watch what I say to Paul :) I believe that this issue is specific to IIS4, or has at least been fixed by IIS6. I've just tested on an IIS6 server with PHP5, and PATH_INFO is returned. And it doesn't need to be in cgi-bin (but you need the file extension). As long as it's legal for the root resource to be /tms.php (or aspx, or py, or jsp) instead of /, then there doesn't appear to be a problem. My concern is that I would have to make IIS respond to all requests under / with a specific script. You can do it with a custom 404 error handler, but that's really abusing the server. Hmm. For users with the ability to install ISAPI extensions, there appears to be an open source mod_rewrite for IIS available (wasn't there last time I looked into this; honest...): http://www.iismods.com/url-rewrite/index.htm While it's tempting to say "use another server", in some environments the chances of getting Apache (or Lighty, or whatever) installed are slim to none. If a standard is created that cannot be used by a server that has a reasonable share of the "enterprise" market, then in making this choice you are accepting that you might also be restricting access to valuable data. Jason From pramsey at refractions.net Fri Oct 27 23:43:16 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Fri, 27 Oct 2006 23:43:16 -0700 Subject: [tiling] Server Implementation Message-ID: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> At the risk of looking foolish (it's late, I'm tired, and I have tested it as many as 6 times) here is a an implementation of the draft TMS specification: http://mapserver.refractions.net/cgi-bin/tms Paul noted that I haven't documented error handling in the spec yet, and he's right. So look for some new sections coming soon. Paul From pramsey at refractions.net Sat Oct 28 10:53:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 10:53:34 -0700 Subject: [tiling] RESTful Completeness Message-ID: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> Looking at the server logs of my implementation, I see a couple requests that look like this: /cgi-bin/tms/1.0.0/global_mosaic/0/ From the PoV of the REST interface, this is a request for the <TileSet> resource for the first resolution level I defined. (The actual tiles would be at /cgi-bin/tms/1.0.0/global_mosaic/0/0/0.jpg) However, in the specification, I didn't bother to define an explicit <TileSet> resource, since once you get the the <TileMap> resource you have enough information, as a client, to formulate direct tile requests. The <TileSet> is sort of redundant. Should any information be returned at that resource level? Thoughts? Defining the <TileSet> and then a <TileSetColumn> resource would allow me to complete a "true" REST API to the service, since then it would be possible to traverse from the root resource all the way to the tile images just be following the href information through the resources. Right now, from an API PoV, the system just dead-ends at TileMap, and the gap is filled opaquely through the description in the spec doc. Any feedback would be nice. Paul From pspencer at dmsolutions.ca Sat Oct 28 11:08:49 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sat, 28 Oct 2006 14:08:49 -0400 Subject: [tiling] RESTful Completeness In-Reply-To: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> References: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> Message-ID: <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> Paul, in thinking though my own implementation of this, I am following this logic: * separate path_info into the script_file (i.e. the /cgi-bin/tms part) and the rest (pun intended) * split rest on / into an array * count(rest) = 0: emit <Services> * count(rest) = 1: emit <TileMapService> for requested version * count(rest) = 2: emit <TileMap> for requested version and map * count(rest) = 5: emit appropriate tile image Anything else will result in a 404 (i.e. 3, 4 or more than 6) Also requesting an unsupported version or TileMap will result in a 404. I don't see the benefit of adding responses for 3 (scale) and 4 (column) other than completeness. If it is not RESTful to make tileset/column/row mandatory then I guess we should add appropriate responses. If we do, the tileset response could just return the units per pixel and perhaps (this might be useful) the minimum and maximum values that can be requested from the columns ... and the column response could return the minimum and maximum values that can be requested from the rows. I guess for completeness they would also return the href too ... Cheers Paul On 28-Oct-06, at 1:53 PM, Paul Ramsey wrote: > Looking at the server logs of my implementation, I see a couple > requests that look like this: > > /cgi-bin/tms/1.0.0/global_mosaic/0/ > > From the PoV of the REST interface, this is a request for the > <TileSet> resource for the first resolution level I defined. (The > actual tiles would be at /cgi-bin/tms/1.0.0/global_mosaic/0/0/0.jpg) > > However, in the specification, I didn't bother to define an explicit > <TileSet> resource, since once you get the the <TileMap> resource you > have enough information, as a client, to formulate direct tile > requests. The <TileSet> is sort of redundant. Should any > information be returned at that resource level? Thoughts? > > Defining the <TileSet> and then a <TileSetColumn> resource would > allow me to complete a "true" REST API to the service, since then it > would be possible to traverse from the root resource all the way to > the tile images just be following the href information through the > resources. Right now, from an API PoV, the system just dead-ends at > TileMap, and the gap is filled opaquely through the description in > the spec doc. > > Any feedback would be nice. > > Paul > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sat Oct 28 22:44:28 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 22:44:28 -0700 Subject: [tiling] Error Handling Message-ID: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> I have added error handling to the specification and my implementation for those who are doing testing / client building. I decided to stick with just two HTTP error codes: - 404 Not Found - 500 Internal Server Error They seemed to contain all the likely problems a TMS might encounter normally, and anything else could be shoehorned into 500. P From pramsey at refractions.net Sat Oct 28 22:50:48 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sat, 28 Oct 2006 22:50:48 -0700 Subject: [tiling] RESTful Completeness In-Reply-To: <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> References: <5745E57F-C58E-4852-8631-6B4810784821@refractions.net> <E79AC64F-C015-4B7E-96A7-D377680AD475@dmsolutions.ca> Message-ID: <FDF95CD5-6E4A-484F-8EC2-253F9DD63B86@refractions.net> On 28-Oct-06, at 11:08 AM, Paul Spencer wrote: > I don't see the benefit of adding responses for 3 (scale) and 4 > (column) other than completeness. If it is not RESTful to make > tileset/column/row mandatory then I guess we should add appropriate > responses. > > If we do, the tileset response could just return the units per > pixel and perhaps (this might be useful) the minimum and maximum > values that can be requested from the columns ... and the column > response could return the minimum and maximum values that can be > requested from the rows. > > I guess for completeness they would also return the href too ... That would be the point, to provide a chain of hrefs that eventually lead to the tile itself. However, if noone really needs to do the full traversal, it seems like a waste of specification space, and implementors time, to provide resources that clients will always ignore. I could move information from the TileMap into the TileSet, but then I am forcing clients to traverse down another level just to satisfy my didactic urge to encapsulate things at the "right" level. I think I will leave well enough alone until the REST police come to rough me up. Sean? Paul From pramsey at refractions.net Sun Oct 29 08:34:37 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 08:34:37 -0800 Subject: [tiling] Error Handling In-Reply-To: <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> Message-ID: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Adam, How about 410 (Gone)? Or 204 (No Content) in conjunction with a transparent image? I also remembered that I am trying to make the spec implementable just by piling files under an HTTP server without configuration, which means that the XML content in the 404 and 500 errors will have to be optional. The error string that goes with the code is also mutable, so I could, evilly, suggest that anyone who wants to send back a custom error message simply stuff it in there. P. On 29-Oct-06, at 8:25 AM, Adam Hill wrote: > Seeing someone else asked, I will bring up an annoying issue we > have in World Wind - telling the client there is actually NODATA at > this tile vs other systemic errors, so later on it can "do the > right thing" (like never ask for that tile again). Since there > doesn't seem to be a convienient HTTP code for this someone has to > decide on one for convention. > > Have any other implememntations dealt with this (Mapserver, > Geoserver)? > > Adam Hill > World Wind Developer From pspencer at dmsolutions.ca Sun Oct 29 11:42:52 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 14:42:52 -0500 Subject: [tiling] Error Handling In-Reply-To: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Message-ID: <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> Paul, Adam, neither of those is a good fit, in my mind. I think that a 404 Not Found should be sufficient - 404 is returned by a correctly configured TMS that doesn't support something you've asked for - either invalid version, map, or tileset/column/row combination (or image format). 404 is really no content at the requested location. 500 is used if the service is incorrectly configured or suffers an internal error on a request it *might* otherwise have been able to handle. I think that worldwind could safely assume that if it gets a 404 from a TMS, it should never send that request (whatever it was) again. Paul, it is possible with most web servers to set a custom error handler which would enable a static tile set to handle missing images with a reasonable error message if the administrator so desires, although the only requirement should be to return a 404 - any content describing the problem is for convenience only, recommended but not required. That's my take, anyway. Cheers Paul On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: > Adam, > > How about 410 (Gone)? Or 204 (No Content) in conjunction with a > transparent image? > I also remembered that I am trying to make the spec implementable > just by piling files under an HTTP server without configuration, > which means that the XML content in the 404 and 500 errors will have > to be optional. The error string that goes with the code is also > mutable, so I could, evilly, suggest that anyone who wants to send > back a custom error message simply stuff it in there. > > P. > > On 29-Oct-06, at 8:25 AM, Adam Hill wrote: > >> Seeing someone else asked, I will bring up an annoying issue we >> have in World Wind - telling the client there is actually NODATA at >> this tile vs other systemic errors, so later on it can "do the >> right thing" (like never ask for that tile again). Since there >> doesn't seem to be a convienient HTTP code for this someone has to >> decide on one for convention. >> >> Have any other implememntations dealt with this (Mapserver, >> Geoserver)? >> >> Adam Hill >> World Wind Developer > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Sat Oct 28 15:20:32 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sat, 28 Oct 2006 18:20:32 -0400 Subject: [tiling] Server Implementation In-Reply-To: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> References: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> Message-ID: <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> Paul, more on error messages: 500 Internal Server Error used for misconfiguration of the service that prevents the service from running. Some examples from my testing: * cannot load mapscript for some reason * path to a mapfile is incorrect * mapfile syntax is incorrect (cannot load a map file) 404 Not Found used for: * incorrect formatting of version * unsupported version (you seem to be returning a 500 for this) * requesting a TileMapService that doesn't exist * requesting a tileset, column or row that doesn't exist There are probably more errors that fall into one of these categories. Also, implementations should be encouraged to return content with the error that describes the actual error that happened. Finally, a comment on your implementation - one level returns incorrectly formatted xml (at least that's what firefox says) because (I think) the <?xml ?> tag isn't the first line of the output! I've got as far as outputting a TileMapService block, need to do TileMap next. Cheers paul On 28-Oct-06, at 2:43 AM, Paul Ramsey wrote: > At the risk of looking foolish (it's late, I'm tired, and I have > tested it as many as 6 times) here is a an implementation of the > draft TMS specification: > > http://mapserver.refractions.net/cgi-bin/tms > > Paul noted that I haven't documented error handling in the spec yet, > and he's right. So look for some new sections coming soon. > > Paul > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 13:23:51 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 13:23:51 -0800 Subject: [tiling] Server Implementation In-Reply-To: <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> References: <E2B842AF-0C01-4F7B-A135-9BC8433DCB22@refractions.net> <9D6B0FD6-33D4-475A-B10E-E1F1638BAD39@dmsolutions.ca> Message-ID: <CBAA78FB-36F0-4336-B497-40CFF0BA07D8@refractions.net> I agree with your interpretations of the codes, and I think the two codes are going to service us pretty well. On 28-Oct-06, at 3:20 PM, Paul Spencer wrote: > more on error messages: > > 500 Internal Server Error > > used for misconfiguration of the service that prevents the service > from running. Some examples from my testing: > > * cannot load mapscript for some reason > * path to a mapfile is incorrect > * mapfile syntax is incorrect (cannot load a map file) > > 404 Not Found > > used for: > > * incorrect formatting of version > * unsupported version (you seem to be returning a 500 for this) Have a URL? I cannot replicate that. I should only be returning 500 when NASA feeds me errors. > * requesting a TileMapService that doesn't exist > * requesting a tileset, column or row that doesn't exist > > There are probably more errors that fall into one of these categories. > > Also, implementations should be encouraged to return content with > the error that describes the actual error that happened. > > Finally, a comment on your implementation - one level returns > incorrectly formatted xml (at least that's what firefox says) > because (I think) the <?xml ?> tag isn't the first line of the output! I fixed this yesterday, but through the magic of caching you're still getting the broken one. Try a hard refresh. :) Pual From pramsey at refractions.net Sun Oct 29 15:23:56 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 15:23:56 -0800 Subject: [tiling] Relative URLs Message-ID: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> Question, Should relative URLs be allowed in the HREF elements of the tms resources? (I think "yes", but if we are allowing it we need to warn the implementors of clients so they can handle it appropriately.) P From pspencer at dmsolutions.ca Sun Oct 29 15:43:01 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 18:43:01 -0500 Subject: [tiling] Relative URLs In-Reply-To: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> Message-ID: <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> do you have an example of how this might be used? Paul On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: > Question, > > Should relative URLs be allowed in the HREF elements of the tms > resources? > > (I think "yes", but if we are allowing it we need to warn the > implementors of clients so they can handle it appropriately.) > > P > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 15:51:40 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 15:51:40 -0800 Subject: [tiling] Relative URLs In-Reply-To: <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> Message-ID: <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> What it looks like: http://mapserver.refractions.net/cgi-bin/tms <?xml version="1.0" ?> <Services> <TileMapService version="1.0.0" href="1.0.0" /> </Services> Why it would be useful: When you create a static tms by shredding existing imagery into tiles, it would be nice to be able to move that static tms around just be copying it from place to place. If the URLs are absolute they would have to be edited after every copy. Why I thought of it: I was pondering Chris Tweedies insane idea of putting tiles into S3 and whether it was possible under the tms spec (it is) and how one would do it (shred something and stuff it up there). If you have to know the absolute path of everything ahead of time it is just a little less convenient. Processing relative URLs properly is a bit of a pain though, lots of different cases to deal with. P On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: > do you have an example of how this might be used? > > Paul > > On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: > >> Question, >> >> Should relative URLs be allowed in the HREF elements of the tms >> resources? >> >> (I think "yes", but if we are allowing it we need to warn the >> implementors of clients so they can handle it appropriately.) >> >> P >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > From pspencer at dmsolutions.ca Sun Oct 29 17:17:47 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Sun, 29 Oct 2006 20:17:47 -0500 Subject: [tiling] Relative URLs In-Reply-To: <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> Message-ID: <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> I like it, but I think we need to be careful what is allowed. For instance, ../<something> /<something> are these allowed? Do you envision a static tms being one that has xml docs in each of the directories and these would be set up in the web server as the default document ... index.xml? Cheers Paul On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: > What it looks like: > > http://mapserver.refractions.net/cgi-bin/tms > > <?xml version="1.0" ?> > <Services> > <TileMapService version="1.0.0" href="1.0.0" /> > </Services> > > Why it would be useful: > > When you create a static tms by shredding existing imagery into > tiles, it would be nice to be able to move that static tms around > just be copying it from place to place. If the URLs are absolute > they would have to be edited after every copy. > > Why I thought of it: > > I was pondering Chris Tweedies insane idea of putting tiles into S3 > and whether it was possible under the tms spec (it is) and how one > would do it (shred something and stuff it up there). If you have > to know the absolute path of everything ahead of time it is just a > little less convenient. > > Processing relative URLs properly is a bit of a pain though, lots > of different cases to deal with. > > P > > > On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: > >> do you have an example of how this might be used? >> >> Paul >> >> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >> >>> Question, >>> >>> Should relative URLs be allowed in the HREF elements of the tms >>> resources? >>> >>> (I think "yes", but if we are allowing it we need to warn the >>> implementors of clients so they can handle it appropriately.) >>> >>> P >>> _______________________________________________ >>> tiling mailing list >>> tiling at lists.eogeo.org >>> http://lists.eogeo.org/mailman/listinfo/tiling >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> > +-----------------------------------------------------------------+ |Paul Spencer pspencer at dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pramsey at refractions.net Sun Oct 29 17:46:09 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 17:46:09 -0800 Subject: [tiling] Relative URLs In-Reply-To: <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> Message-ID: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Remember, there is no rule about the URL format, only about URL traversal... So my root resource could the tms.rri.net/root.xml and it could reference my version at tms.rri.net/tilemapservice.xml and that could reference a tilemap at tms.rri.net/tilemap.xml and that would have the info about the tilesets would would allow the client to construct tile requests like tms.rrs.net/l1/1/1.jpg which hopefully explains my concern about breaking the url traversal rule for getting to the tile resources themselves... it's such a powerful concept it seems a shame to break it. On the other hand, if I cannot think of a use case, I am not going to stick it in. P On 29-Oct-06, at 5:17 PM, Paul Spencer wrote: > I like it, but I think we need to be careful what is allowed. For > instance, > > ../<something> > /<something> > > are these allowed? > > Do you envision a static tms being one that has xml docs in each of > the directories and these would be set up in the web server as the > default document ... index.xml? > > Cheers > > Paul > > On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: > >> What it looks like: >> >> http://mapserver.refractions.net/cgi-bin/tms >> >> <?xml version="1.0" ?> >> <Services> >> <TileMapService version="1.0.0" href="1.0.0" /> >> </Services> >> >> Why it would be useful: >> >> When you create a static tms by shredding existing imagery into >> tiles, it would be nice to be able to move that static tms around >> just be copying it from place to place. If the URLs are absolute >> they would have to be edited after every copy. >> >> Why I thought of it: >> >> I was pondering Chris Tweedies insane idea of putting tiles into >> S3 and whether it was possible under the tms spec (it is) and how >> one would do it (shred something and stuff it up there). If you >> have to know the absolute path of everything ahead of time it is >> just a little less convenient. >> >> Processing relative URLs properly is a bit of a pain though, lots >> of different cases to deal with. >> >> P >> >> >> On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: >> >>> do you have an example of how this might be used? >>> >>> Paul >>> >>> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >>> >>>> Question, >>>> >>>> Should relative URLs be allowed in the HREF elements of the tms >>>> resources? >>>> >>>> (I think "yes", but if we are allowing it we need to warn the >>>> implementors of clients so they can handle it appropriately.) >>>> >>>> P >>>> _______________________________________________ >>>> tiling mailing list >>>> tiling at lists.eogeo.org >>>> http://lists.eogeo.org/mailman/listinfo/tiling >>> >>> +-----------------------------------------------------------------+ >>> |Paul Spencer pspencer at dmsolutions.ca | >>> +-----------------------------------------------------------------+ >>> |Chief Technology Officer | >>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>> +-----------------------------------------------------------------+ >>> >>> >>> >>> >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > From pramsey at refractions.net Sun Oct 29 22:20:54 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 22:20:54 -0800 Subject: [tiling] Common non-EPSG SRSs Message-ID: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> All, The usual issue about how to signify SRSs which are not in the EPSG database arises for the TMS. And because Mercator is both (a) not in EPSG and (b) commonly used for tiled web mapping, this is not an issue that can be put off. I think that TMS just needs to define the SRSs it needs inside the specification itself, and by virtue of being a living and collaborative spec, should be able to work that way. The open issue is what authority prefix to use for these definitions. I have stubbed in a section with some example systems. I used the "EPSG:" authority prefix. This is actually the prefix I found them with in the wild, on the web, in live WMS instances. In terms of interoperability, it makes sense to stick with what is being used. Why break what is not broken? In terms of respecting the idea of an "authority prefix" it makes no sense. Where does the community come down on this? P From pramsey at refractions.net Sun Oct 29 22:22:18 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Sun, 29 Oct 2006 22:22:18 -0800 Subject: [tiling] Relative URLs In-Reply-To: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Message-ID: <1222695A-5C2F-4C3F-8B56-D54E784BE5E9@refractions.net> FYI, I wrote in some relative URL examples in the spec. I think it would be very nice for data deployers. This is the time for client writers to get vocal if it is in fact too great an imposition. Speak now for forever hold your peace. P On 29-Oct-06, at 5:46 PM, Paul Ramsey wrote: > Remember, there is no rule about the URL format, only about URL > traversal... > > So my root resource could the > > tms.rri.net/root.xml > > and it could reference my version at > > tms.rri.net/tilemapservice.xml > > and that could reference a tilemap at > > tms.rri.net/tilemap.xml > > and that would have the info about the tilesets would would allow the > client to construct tile requests like > > tms.rrs.net/l1/1/1.jpg > > which hopefully explains my concern about breaking the url traversal > rule for getting to the tile resources themselves... it's such a > powerful concept it seems a shame to break it. On the other hand, if > I cannot think of a use case, I am not going to stick it in. > > P > > On 29-Oct-06, at 5:17 PM, Paul Spencer wrote: > >> I like it, but I think we need to be careful what is allowed. For >> instance, >> >> ../<something> >> /<something> >> >> are these allowed? >> >> Do you envision a static tms being one that has xml docs in each of >> the directories and these would be set up in the web server as the >> default document ... index.xml? >> >> Cheers >> >> Paul >> >> On 29-Oct-06, at 6:51 PM, Paul Ramsey wrote: >> >>> What it looks like: >>> >>> http://mapserver.refractions.net/cgi-bin/tms >>> >>> <?xml version="1.0" ?> >>> <Services> >>> <TileMapService version="1.0.0" href="1.0.0" /> >>> </Services> >>> >>> Why it would be useful: >>> >>> When you create a static tms by shredding existing imagery into >>> tiles, it would be nice to be able to move that static tms around >>> just be copying it from place to place. If the URLs are absolute >>> they would have to be edited after every copy. >>> >>> Why I thought of it: >>> >>> I was pondering Chris Tweedies insane idea of putting tiles into >>> S3 and whether it was possible under the tms spec (it is) and how >>> one would do it (shred something and stuff it up there). If you >>> have to know the absolute path of everything ahead of time it is >>> just a little less convenient. >>> >>> Processing relative URLs properly is a bit of a pain though, lots >>> of different cases to deal with. >>> >>> P >>> >>> >>> On 29-Oct-06, at 3:43 PM, Paul Spencer wrote: >>> >>>> do you have an example of how this might be used? >>>> >>>> Paul >>>> >>>> On 29-Oct-06, at 6:23 PM, Paul Ramsey wrote: >>>> >>>>> Question, >>>>> >>>>> Should relative URLs be allowed in the HREF elements of the tms >>>>> resources? >>>>> >>>>> (I think "yes", but if we are allowing it we need to warn the >>>>> implementors of clients so they can handle it appropriately.) >>>>> >>>>> P >>>>> _______________________________________________ >>>>> tiling mailing list >>>>> tiling at lists.eogeo.org >>>>> http://lists.eogeo.org/mailman/listinfo/tiling >>>> >>>> +-----------------------------------------------------------------+ >>>> |Paul Spencer pspencer at dmsolutions.ca | >>>> +-----------------------------------------------------------------+ >>>> |Chief Technology Officer | >>>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>>> +-----------------------------------------------------------------+ >>>> >>>> >>>> >>>> >>> >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From Martin.Daly at cadcorp.com Mon Oct 30 00:03:55 2006 From: Martin.Daly at cadcorp.com (Martin Daly) Date: Mon, 30 Oct 2006 08:03:55 -0000 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> Message-ID: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> > The open issue is what authority prefix to use for these > definitions. I have stubbed in a section with some example > systems. > I used the "EPSG:" authority prefix. This is actually the > prefix I found them with in the wild, on the web, in live WMS > instances. In terms of interoperability, it makes sense to > stick with what is being used. Why break what is not broken? > In terms of respecting the idea of an "authority prefix" it > makes no sense. > > Where does the community come down on this? Why not extend the WMS AUTO CRS concept to cover Mercator, etc? From pedro.goncalves at terradue.com Mon Oct 30 02:16:49 2006 From: pedro.goncalves at terradue.com (Pedro Goncalves) Date: Mon, 30 Oct 2006 11:16:49 +0100 Subject: [tiling] Error Handling In-Reply-To: <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> Message-ID: <D978B51D-977E-4549-928D-9763A630E347@terradue.com> Hi Paul Do you think is possible to add (or strongly recommend) the usage of the 304 response code (Not modified). This is quite useful when performing requests with the 'if-modified-since' header thanks and all the best Pedro On Oct 29, 2006, at 8:42 PM, Paul Spencer wrote: > Paul, Adam, > > neither of those is a good fit, in my mind. > > I think that a 404 Not Found should be sufficient - 404 is returned > by a correctly configured TMS that doesn't support something you've > asked for - either invalid version, map, or tileset/column/row > combination (or image format). 404 is really no content at the > requested location. > > 500 is used if the service is incorrectly configured or suffers an > internal error on a request it *might* otherwise have been able to > handle. > > I think that worldwind could safely assume that if it gets a 404 from > a TMS, it should never send that request (whatever it was) again. > > Paul, it is possible with most web servers to set a custom error > handler which would enable a static tile set to handle missing images > with a reasonable error message if the administrator so desires, > although the only requirement should be to return a 404 - any content > describing the problem is for convenience only, recommended but not > required. > > That's my take, anyway. > > Cheers > > Paul > > On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: > >> Adam, >> >> How about 410 (Gone)? Or 204 (No Content) in conjunction with a >> transparent image? >> I also remembered that I am trying to make the spec implementable >> just by piling files under an HTTP server without configuration, >> which means that the XML content in the 404 and 500 errors will have >> to be optional. The error string that goes with the code is also >> mutable, so I could, evilly, suggest that anyone who wants to send >> back a custom error message simply stuff it in there. >> >> P. >> >> On 29-Oct-06, at 8:25 AM, Adam Hill wrote: >> >>> Seeing someone else asked, I will bring up an annoying issue we >>> have in World Wind - telling the client there is actually NODATA at >>> this tile vs other systemic errors, so later on it can "do the >>> right thing" (like never ask for that tile again). Since there >>> doesn't seem to be a convienient HTTP code for this someone has to >>> decide on one for convention. >>> >>> Have any other implememntations dealt with this (Mapserver, >>> Geoserver)? >>> >>> Adam Hill >>> World Wind Developer >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer at dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061030/df10b41a/attachment.html From nhv at cape.com Mon Oct 30 07:02:05 2006 From: nhv at cape.com (Norman Vine) Date: Mon, 30 Oct 2006 10:02:05 -0500 Subject: [tiling] Error Handling In-Reply-To: <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> Message-ID: <200610301502.k9UF25Y8015977@smtp11.cape.com> Paul Ramsey writes: > I also remembered that I am trying to make the spec > implementable just by piling files under an HTTP server > without configuration, Granted the most common implementation will probably be 'piling files under an HTTP server', but it would be good to remember that an http spec is about 'known' Http 'strings' and nothing todo with implementation details For example tiles could all be stored in one packed file or perhps even all created on demand Cheers Norman From cholmes at openplans.org Mon Oct 30 07:43:06 2006 From: cholmes at openplans.org (Chris Holmes) Date: Mon, 30 Oct 2006 10:43:06 -0500 Subject: [tiling] Error Handling In-Reply-To: <D978B51D-977E-4549-928D-9763A630E347@terradue.com> References: <B6D0B19C-8BEE-40D3-806A-C49637430996@refractions.net> <d5ec7b310610290825y5e67cfb7h9bd2dcd9d5ca8328@mail.gmail.com> <AD84112B-EBE3-48FA-B919-E13D8D7110BB@refractions.net> <CD7FE7AF-FD6B-4F42-B35E-A24D0D5013B8@dmsolutions.ca> <D978B51D-977E-4549-928D-9763A630E347@terradue.com> Message-ID: <45461D8A.3080506@openplans.org> Yeah, I've been mulling things related this to as well. I believe it's also useful when you have a 'must-revalidate' call, which is used as an example in the spec. I suppose using a 304 is actually more useful for the server that's generating the responses in the first place - like the WMS that the TMS is tiling. Then the TMS can just do the revalidate instead of making the backend generate the response again. But even if a TMS is just returning static tiles, a 304 is useful so that it doesn't have to make the roundtrip. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3 And if your TMS is an engine that generates tiles _and_ does the caching (like ka-map's engine), then I think a 304 could be even more useful for revalidation. The engine could be built with knowledge of if the backend database had been modified (like listening to the WFS-T that access the service, or database triggers), and can return 304's until something's changed. Then your max-age becomes an indication of how likely the server is to change, since if you do max-age and must-revalidate then it doesn't have to revalidate until max-age is reached. Chris Pedro Goncalves wrote: > Hi Paul > > Do you think is possible to add (or strongly recommend) the usage of the > 304 response code (Not modified). This is quite useful when performing > requests with the 'if-modified-since' header > > thanks and all the best > Pedro > > > > > On Oct 29, 2006, at 8:42 PM, Paul Spencer wrote: > >> Paul, Adam, >> >> neither of those is a good fit, in my mind. >> >> I think that a 404 Not Found should be sufficient - 404 is returned >> by a correctly configured TMS that doesn't support something you've >> asked for - either invalid version, map, or tileset/column/row >> combination (or image format). 404 is really no content at the >> requested location. >> >> 500 is used if the service is incorrectly configured or suffers an >> internal error on a request it *might* otherwise have been able to >> handle. >> >> I think that worldwind could safely assume that if it gets a 404 from >> a TMS, it should never send that request (whatever it was) again. >> >> Paul, it is possible with most web servers to set a custom error >> handler which would enable a static tile set to handle missing images >> with a reasonable error message if the administrator so desires, >> although the only requirement should be to return a 404 - any content >> describing the problem is for convenience only, recommended but not >> required. >> >> That's my take, anyway. >> >> Cheers >> >> Paul >> >> On 29-Oct-06, at 11:34 AM, Paul Ramsey wrote: >> >>> Adam, >>> >>> How about 410 (Gone)? Or 204 (No Content) in conjunction with a >>> transparent image? >>> I also remembered that I am trying to make the spec implementable >>> just by piling files under an HTTP server without configuration, >>> which means that the XML content in the 404 and 500 errors will have >>> to be optional. The error string that goes with the code is also >>> mutable, so I could, evilly, suggest that anyone who wants to send >>> back a custom error message simply stuff it in there. >>> >>> P. >>> >>> On 29-Oct-06, at 8:25 AM, Adam Hill wrote: >>> >>>> Seeing someone else asked, I will bring up an annoying issue we >>>> have in World Wind - telling the client there is actually NODATA at >>>> this tile vs other systemic errors, so later on it can "do the >>>> right thing" (like never ask for that tile again). Since there >>>> doesn't seem to be a convienient HTTP code for this someone has to >>>> decide on one for convention. >>>> >>>> Have any other implememntations dealt with this (Mapserver, >>>> Geoserver)? >>>> >>>> Adam Hill >>>> World Wind Developer >>> >>> _______________________________________________ >>> tiling mailing list >>> tiling at lists.eogeo.org <mailto:tiling at lists.eogeo.org> >>> http://lists.eogeo.org/mailman/listinfo/tiling >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer at dmsolutions.ca >> <mailto:pspencer at dmsolutions.ca> | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org <mailto:tiling at lists.eogeo.org> >> http://lists.eogeo.org/mailman/listinfo/tiling >> > > !DSPAM:1003,4545d2d2138581510810322! > > > ------------------------------------------------------------------------ > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > > !DSPAM:1003,4545d2d2138581510810322! -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061030/375b22aa/attachment.vcf From sgillies at frii.com Mon Oct 30 10:52:38 2006 From: sgillies at frii.com (Sean Gillies) Date: Mon, 30 Oct 2006 10:52:38 -0800 Subject: [tiling] Relative URLs In-Reply-To: <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> Message-ID: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> On Oct 29, 2006, at 5:46 PM, Paul Ramsey wrote: > Remember, there is no rule about the URL format, only about URL > traversal... > > So my root resource could the > > tms.rri.net/root.xml > > and it could reference my version at > > tms.rri.net/tilemapservice.xml > > and that could reference a tilemap at > > tms.rri.net/tilemap.xml > > and that would have the info about the tilesets would would allow the > client to construct tile requests like > > tms.rrs.net/l1/1/1.jpg Paul, How about -- excuse my shorthand notation -- this: GET [Accept: image/jpeg] http://tms.rrs.net/l1/1/1.jpg Few providers are going to implement a "1" leaf resource that can viewed in more than one format, but using the accept headers lets us make more reliable contracts about content type. If this is already in the spec, disregard my note. I'm just starting to catch up on your flurry of emails. BTW, I'm not too concerned about relative links. In practice, we'll be using web frameworks that take care of this, or scripting the deployment of tiles, yes? Sean --- Sean Gillies http://zcologia.com From pramsey at refractions.net Mon Oct 30 11:02:52 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:02:52 -0800 Subject: [tiling] Relative URLs In-Reply-To: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> Message-ID: <77EA9FD0-EA7B-40DA-8877-FF99CAD9F48B@refractions.net> It would be nice if, when creating a static tile stack, I didn't have to specify the full server paths ahead of time. It is not a requirement, but it makes the spec more flexible. I am trying to balance this niceness against what I hear from the client writers on the issues with supporting relatively URLs. On 30-Oct-06, at 10:52 AM, Sean Gillies wrote: > BTW, I'm not too concerned about relative links. In practice, we'll > be using web frameworks that take care of this, or scripting the > deployment of tiles, yes? From pramsey at refractions.net Mon Oct 30 11:07:01 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:07:01 -0800 Subject: [tiling] Relative URLs In-Reply-To: <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> References: <E8B0F657-BFA8-4841-875E-2D68D2954669@refractions.net> <C2BDDE7F-27AD-49B1-BFE3-B319C193859C@dmsolutions.ca> <07C93D9C-6CB7-4006-A30A-01EBCE0B1FA5@refractions.net> <ABF19056-F369-4C25-9B5F-8515CBF10B1E@dmsolutions.ca> <15D844F8-A20D-4F8C-B6BA-D68803CD1768@refractions.net> <81603F90-3F23-4C59-8766-94C800941E4A@frii.com> Message-ID: <91FABEC2-51DC-4477-9E8D-5C740681DFC1@refractions.net> What problem is this solving? The TileMap specifies the Tile format as a mime-type, and the return value for the tile request will have a Content-type. If I have specified image/jpeg and you say you accept image/png, what should I be doing? On 30-Oct-06, at 10:52 AM, Sean Gillies wrote: > How about -- excuse my shorthand notation -- this: > > GET [Accept: image/jpeg] http://tms.rrs.net/l1/1/1.jpg > > Few providers are going to implement a "1" leaf resource that can > viewed in more than one format, but using the accept headers lets us > make more reliable contracts about content type. If this is already > in the spec, disregard my note. I'm just starting to catch up on your > flurry of emails. From sgillies at frii.com Mon Oct 30 11:11:43 2006 From: sgillies at frii.com (Sean Gillies) Date: Mon, 30 Oct 2006 11:11:43 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> References: <D2A8CD2E-876F-4812-BA21-454693C08C5A@refractions.net> Message-ID: <502EBD6F-CAA2-4E3C-9037-1DE477E35BAD@frii.com> On Oct 29, 2006, at 10:20 PM, Paul Ramsey wrote: > All, > > The usual issue about how to signify SRSs which are not in the EPSG > database arises for the TMS. And because Mercator is both (a) not in > EPSG and (b) commonly used for tiled web mapping, this is not an > issue that can be put off. > > I think that TMS just needs to define the SRSs it needs inside the > specification itself, and by virtue of being a living and > collaborative spec, should be able to work that way. > > The open issue is what authority prefix to use for these > definitions. I have stubbed in a section with some example systems. > I used the "EPSG:" authority prefix. This is actually the prefix I > found them with in the wild, on the web, in live WMS instances. In > terms of interoperability, it makes sense to stick with what is being > used. Why break what is not broken? In terms of respecting the idea > of an "authority prefix" it makes no sense. > > Where does the community come down on this? > > P I'd be happy with EPSG:N and another block of URNs for non-EPSG. Could be urn:osgeo:crs:mercator (finally something concrete from OSGeo ;) or even urn:ramsey:crs:mercator. Sean --- Sean Gillies http://zcologia.com From pramsey at refractions.net Mon Oct 30 11:13:26 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:13:26 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> Message-ID: <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> I don't want an AUTO CRS, I want a fixed ID... the clients are mostly relatively dumb, they aren't going to be doing coordinate conversions, just comparing tokens and looking for identity (hey, these are the same, I can overlay them!). How about we set up our own authority, OSGEO: and start filling 'er up. I mean, there's nothing holy about EPSG, they just had a good pre- existing database. All the utility since then has been based on the agreement of everyone to look there for IDs. For some reason no other authority has been bothered with, which exacerbates EPSG's limitations. P On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> The open issue is what authority prefix to use for these >> definitions. I have stubbed in a section with some example >> systems. >> I used the "EPSG:" authority prefix. This is actually the >> prefix I found them with in the wild, on the web, in live WMS >> instances. In terms of interoperability, it makes sense to >> stick with what is being used. Why break what is not broken? >> In terms of respecting the idea of an "authority prefix" it >> makes no sense. >> >> Where does the community come down on this? > > Why not extend the WMS AUTO CRS concept to cover Mercator, etc? From bob.basques at ci.stpaul.mn.us Mon Oct 30 11:17:49 2006 From: bob.basques at ci.stpaul.mn.us (Bob Basques) Date: Mon, 30 Oct 2006 13:17:49 -0600 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> Message-ID: <45464FDD.7020007@ci.stpaul.mn.us> Paul Ramsey wrote: > I don't want an AUTO CRS, I want a fixed ID... the clients are mostly > relatively dumb, they aren't going to be doing coordinate > conversions, just comparing tokens and looking for identity (hey, > these are the same, I can overlay them!). > > How about we set up our own authority, OSGEO: and start filling 'er up. > > I mean, there's nothing holy about EPSG, they just had a good pre- > existing database. All the utility since then has been based on the > agreement of everyone to look there for IDs. For some reason no > other authority has been bothered with, which exacerbates EPSG's > limitations. > > Here, here. I second this, can a master catalog of sorts be arrived at where individuals or authoritative groups could apply for inclusion into the Catalog. I need the projections for the Counties in the State of Mn and Western Wi, for example. Each state has a EPSG (like) listing for their respective Counties, but no where are they in the same distributed catalog. bobb > P > > On 30-Oct-06, at 12:03 AM, Martin Daly wrote: > > >>> The open issue is what authority prefix to use for these >>> definitions. I have stubbed in a section with some example >>> systems. >>> I used the "EPSG:" authority prefix. This is actually the >>> prefix I found them with in the wild, on the web, in live WMS >>> instances. In terms of interoperability, it makes sense to >>> stick with what is being used. Why break what is not broken? >>> In terms of respecting the idea of an "authority prefix" it >>> makes no sense. >>> >>> Where does the community come down on this? >>> >> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >> > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > -- **************** You can't be late until you show up. *************** ************ You never learn anything by doing it right. ************ *** War doesn't determine who's right. War determines who's left. *** -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.basques.vcf Type: text/x-vcard Size: 309 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061030/ac4cb838/attachment.vcf From pramsey at refractions.net Mon Oct 30 11:23:45 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 11:23:45 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <45464FDD.7020007@ci.stpaul.mn.us> References: <AA31868BC8CE1B4DB132141A6556A20A0E5EF8@dev010_ex.Dev.cadcorp.net> <A75C91BC-D9DE-4333-B92D-68EAB44ACA24@refractions.net> <45464FDD.7020007@ci.stpaul.mn.us> Message-ID: <F9A47264-091C-4A73-9340-D7DFFDACA8BC@refractions.net> The don't just use stateplane? Savages. I thought the whole point of stateplane was to get the counties into a standard set of projections. P On 30-Oct-06, at 11:17 AM, Bob Basques wrote: > Paul Ramsey wrote: >> I don't want an AUTO CRS, I want a fixed ID... the clients are >> mostly relatively dumb, they aren't going to be doing coordinate >> conversions, just comparing tokens and looking for identity (hey, >> these are the same, I can overlay them!). >> >> How about we set up our own authority, OSGEO: and start filling >> 'er up. >> >> I mean, there's nothing holy about EPSG, they just had a good pre- >> existing database. All the utility since then has been based on >> the agreement of everyone to look there for IDs. For some reason >> no other authority has been bothered with, which exacerbates >> EPSG's limitations. >> >> > Here, here. I second this, can a master catalog of sorts be > arrived at where individuals or authoritative groups could apply > for inclusion into the Catalog. I need the projections for the > Counties in the State of Mn and Western Wi, for example. Each > state has a EPSG (like) listing for their respective Counties, but > no where are they in the same distributed catalog. > > bobb > >> P >> >> On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> >> >>>> The open issue is what authority prefix to use for these >>>> definitions. I have stubbed in a section with some example >>>> systems. >>>> I used the "EPSG:" authority prefix. This is actually the >>>> prefix I found them with in the wild, on the web, in live WMS >>>> instances. In terms of interoperability, it makes sense to >>>> stick with what is being used. Why break what is not broken? >>>> In terms of respecting the idea of an "authority prefix" it >>>> makes no sense. >>>> >>>> Where does the community come down on this? >>>> >>> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >>> >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling >> >> > > > -- > > **************** You can't be late until you show up. > *************** > ************ You never learn anything by doing it right. > ************ > *** War doesn't determine who's right. War determines who's left. > *** > > <bob.basques.vcf> From SCHUTP at AGR.GC.CA Mon Oct 30 11:31:25 2006 From: SCHUTP at AGR.GC.CA (Schut, Peter) Date: Mon, 30 Oct 2006 14:31:25 -0500 Subject: [tiling] Common non-EPSG SRSs Message-ID: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> OGC is coming up with an alternative based on URNs, and it is pretty much ready to go. Cheers, Peter. -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey Sent: Monday, October 30, 2006 2:13 PM To: Martin Daly Cc: tiling at lists.eogeo.org Subject: Re: [tiling] Common non-EPSG SRSs I don't want an AUTO CRS, I want a fixed ID... the clients are mostly relatively dumb, they aren't going to be doing coordinate conversions, just comparing tokens and looking for identity (hey, these are the same, I can overlay them!). How about we set up our own authority, OSGEO: and start filling 'er up. I mean, there's nothing holy about EPSG, they just had a good pre- existing database. All the utility since then has been based on the agreement of everyone to look there for IDs. For some reason no other authority has been bothered with, which exacerbates EPSG's limitations. P On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> The open issue is what authority prefix to use for these >> definitions. I have stubbed in a section with some example >> systems. >> I used the "EPSG:" authority prefix. This is actually the >> prefix I found them with in the wild, on the web, in live WMS >> instances. In terms of interoperability, it makes sense to >> stick with what is being used. Why break what is not broken? >> In terms of respecting the idea of an "authority prefix" it >> makes no sense. >> >> Where does the community come down on this? > > Why not extend the WMS AUTO CRS concept to cover Mercator, etc? _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From adoyle at eogeo.org Mon Oct 30 12:32:51 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Mon, 30 Oct 2006 15:32:51 -0500 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> References: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> Message-ID: <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> I guess I have never understood the need for a URN when something like EPSG:4326 or OSGEO:12345 would do. It's just more typing for what seems to be fairly little gain. A string is a string. I guess you can register your URN namespace at IANA or somewhere and this can provide a warm feeling of officialness. Allan On Oct 30, 2006, at 14:31, Schut, Peter wrote: > OGC is coming up with an alternative based on URNs, and it is pretty > much ready to go. > > Cheers, Peter. > > > > -----Original Message----- > From: tiling-bounces at lists.eogeo.org > [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey > Sent: Monday, October 30, 2006 2:13 PM > To: Martin Daly > Cc: tiling at lists.eogeo.org > Subject: Re: [tiling] Common non-EPSG SRSs > > I don't want an AUTO CRS, I want a fixed ID... the clients are mostly > relatively dumb, they aren't going to be doing coordinate > conversions, just comparing tokens and looking for identity (hey, > these are the same, I can overlay them!). > > How about we set up our own authority, OSGEO: and start filling > 'er up. > > I mean, there's nothing holy about EPSG, they just had a good pre- > existing database. All the utility since then has been based on the > agreement of everyone to look there for IDs. For some reason no > other authority has been bothered with, which exacerbates EPSG's > limitations. > > P > > On 30-Oct-06, at 12:03 AM, Martin Daly wrote: > >>> The open issue is what authority prefix to use for these >>> definitions. I have stubbed in a section with some example >>> systems. >>> I used the "EPSG:" authority prefix. This is actually the >>> prefix I found them with in the wild, on the web, in live WMS >>> instances. In terms of interoperability, it makes sense to >>> stick with what is being used. Why break what is not broken? >>> In terms of respecting the idea of an "authority prefix" it >>> makes no sense. >>> >>> Where does the community come down on this? >> >> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -- Allan Doyle +1.781.433.2695 adoyle at eogeo.org From pramsey at refractions.net Mon Oct 30 12:55:10 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Mon, 30 Oct 2006 12:55:10 -0800 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> References: <783BB96C25B79249A236DF62F559D6A501EE3159@onncrxms3.agr.gc.ca> <7C649481-A30B-42CE-AB17-BB093A493520@eogeo.org> Message-ID: <7D0396E5-23E7-4A28-9E97-4B331BCD6724@refractions.net> Hail Allen, scourge of complexity! Yes, just because EPSG: got abused (because there was no safely valve for things that didn't) doesn't mean the concept is broken. We don't have that deep a hierarchy of information that we need a huge urn, and besides, it's not the token we care about, it's the friction-free process for adding items to the token-space. I feel "OSGEO:" starting to warm the cockles of my heart. Can't wait to hear what the board thinks... I'm pretty sure we said standards were going to be one of the few things *not* in the OSGEO mission :) P On 30-Oct-06, at 12:32 PM, Allan Doyle wrote: > I guess I have never understood the need for a URN when something > like EPSG:4326 or OSGEO:12345 would do. It's just more typing for > what seems to be fairly little gain. A string is a string. > > I guess you can register your URN namespace at IANA or somewhere and > this can provide a warm feeling of officialness. > > Allan > > On Oct 30, 2006, at 14:31, Schut, Peter wrote: > >> OGC is coming up with an alternative based on URNs, and it is pretty >> much ready to go. >> >> Cheers, Peter. >> >> >> >> -----Original Message----- >> From: tiling-bounces at lists.eogeo.org >> [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Paul Ramsey >> Sent: Monday, October 30, 2006 2:13 PM >> To: Martin Daly >> Cc: tiling at lists.eogeo.org >> Subject: Re: [tiling] Common non-EPSG SRSs >> >> I don't want an AUTO CRS, I want a fixed ID... the clients are mostly >> relatively dumb, they aren't going to be doing coordinate >> conversions, just comparing tokens and looking for identity (hey, >> these are the same, I can overlay them!). >> >> How about we set up our own authority, OSGEO: and start filling >> 'er up. >> >> I mean, there's nothing holy about EPSG, they just had a good pre- >> existing database. All the utility since then has been based on the >> agreement of everyone to look there for IDs. For some reason no >> other authority has been bothered with, which exacerbates EPSG's >> limitations. >> >> P >> >> On 30-Oct-06, at 12:03 AM, Martin Daly wrote: >> >>>> The open issue is what authority prefix to use for these >>>> definitions. I have stubbed in a section with some example >>>> systems. >>>> I used the "EPSG:" authority prefix. This is actually the >>>> prefix I found them with in the wild, on the web, in live WMS >>>> instances. In terms of interoperability, it makes sense to >>>> stick with what is being used. Why break what is not broken? >>>> In terms of respecting the idea of an "authority prefix" it >>>> makes no sense. >>>> >>>> Where does the community come down on this? >>> >>> Why not extend the WMS AUTO CRS concept to cover Mercator, etc? >> >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling >> _______________________________________________ >> tiling mailing list >> tiling at lists.eogeo.org >> http://lists.eogeo.org/mailman/listinfo/tiling > > -- > Allan Doyle > +1.781.433.2695 > adoyle at eogeo.org > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From SCHUTP at AGR.GC.CA Mon Oct 30 13:01:01 2006 From: SCHUTP at AGR.GC.CA (Schut, Peter) Date: Mon, 30 Oct 2006 16:01:01 -0500 Subject: [tiling] Common non-EPSG SRSs Message-ID: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> A string is a string, but you do want to be sure it is unambiguous and unique. For example, with a URN you could take a snapshot of EPSG and bury under an OSGEO heading, and then be able to extend EPSG under the auspices of OSGEO, and ensure that people don't get confused with how the European Peteroleum folks evolve their codes. If you just use EPSG:4326 then you are at the mercy of the changes made by that organization. Peter. -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Allan Doyle Sent: Monday, October 30, 2006 3:33 PM To: tiling at lists.eogeo.org Subject: Re: [tiling] Common non-EPSG SRSs I guess I have never understood the need for a URN when something like EPSG:4326 or OSGEO:12345 would do. It's just more typing for what seems to be fairly little gain. A string is a string. I guess you can register your URN namespace at IANA or somewhere and this can provide a warm feeling of officialness. Allan From adoyle at eogeo.org Mon Oct 30 13:08:11 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Mon, 30 Oct 2006 16:08:11 -0500 Subject: [tiling] Common non-EPSG SRSs In-Reply-To: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> References: <783BB96C25B79249A236DF62F559D6A501EE315E@onncrxms3.agr.gc.ca> Message-ID: <B7C922CD-591C-483D-91EF-24E81EACC2C3@eogeo.org> On Oct 30, 2006, at 16:01, Schut, Peter wrote: > A string is a string, but you do want to be sure it is unambiguous and > unique. For example, with a URN you could take a snapshot of EPSG and > bury under an OSGEO heading, and then be able to extend EPSG under the > auspices of OSGEO, and ensure that people don't get confused with how > the European Peteroleum folks evolve their codes. If you just use > EPSG:4326 then you are at the mercy of the changes made by that > organization. Are you saying we can do OSGEO:EPSG:4326 (with appropriate additional URN trimmings?) I would suspect that EPSG would be a bit unhappy with that, especially given the major flareups over the years about the use of 4326 in WMS. But what the heck. We already have an issue with the "modern" interpretation of EPSG:4326. I'm not anti-URN. I'm sure it has its place. But I'm not in favor of throwing in references to other specs unless they are really needed. The more of that you do, the harder it is to implement everything properly without first becoming an expert in everything else. Allan > > Peter. > > > -----Original Message----- > From: tiling-bounces at lists.eogeo.org > [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Allan Doyle > Sent: Monday, October 30, 2006 3:33 PM > To: tiling at lists.eogeo.org > Subject: Re: [tiling] Common non-EPSG SRSs > > I guess I have never understood the need for a URN when something > like EPSG:4326 or OSGEO:12345 would do. It's just more typing for > what seems to be fairly little gain. A string is a string. > > I guess you can register your URN namespace at IANA or somewhere and > this can provide a warm feeling of officialness. > > Allan > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -- Allan Doyle +1.781.433.2695 adoyle at eogeo.org From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 05:49:16 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 08:49:16 -0500 Subject: [tiling] global profile Message-ID: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> hello all first off, I love this spec. I think it holds a lot of promise when using tile sets in both browsers and rich clients like ArcMap. kudos to everyone who got it off the ground. so, I can understand why EPSG:4326 is used as a common denominator but all the big GYM providers use Mercator World for their tiles. Any chance this could used as the global standard? I could see many people wanting to overlay their tiles over the existing GYM satellite images. just a thought... cheers brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/6bd62538/attachment.html From pramsey at refractions.net Tue Oct 31 07:44:25 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 07:44:25 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216CE@s25.local.spatialdatalogic.com> Message-ID: <F41499EC-0445-490B-BE08-D0FAD64A9EDF@refractions.net> Brian, There are two (wait, three) reasons I went for EPSG:4326 in the first draft: - I figured that the tile sets for the 3D clients were largely in 4326 (at least, Worldwind's are) - I knew that most/all of the WMS servers supported 4326 (standard says it is mandatory, and most do support it) and lots of TMS servers will be used to front for WMS servers. - I know that almost no WMS servers support world mercator (hacked EPSG:41001) so getting tiles out into that projection will be harder than with EPSG:4326, where one can simply front a WMS. You do lots of KML / GEarth, so you would know: since the web clients will have a hard time integrating mercator and 4326, can the 3D clients trivially do it. For example, can GEarth consume a tile cache of data in Mercator using the regions mechanism? Paul On 31-Oct-06, at 5:49 AM, Brian Flood wrote: > hello all > > first off, I love this spec. I think it holds a lot of promise when > using tile sets in both browsers and rich clients like ArcMap. > kudos to everyone who got it off the ground. > > > > so, I can understand why EPSG:4326 is used as a common denominator > but all the big GYM providers use Mercator World for their tiles. > Any chance this could used as the global standard? I could see many > people wanting to overlay their tiles over the existing GYM > satellite images. > > > > just a thought? > > > > cheers > > brian > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/603e6c91/attachment-0001.htm From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 09:15:17 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 12:15:17 -0500 Subject: [tiling] global profile In-Reply-To: <F41499EC-0445-490B-BE08-D0FAD64A9EDF@refractions.net> Message-ID: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> hi Paul well, those are all good reasons. If it weren't for my specialized need to integrate with the GYM stuff, I would have to agree with you on all counts. I'll do some tests and see how badly the data lines up if we draw in 4326. Most of our users will be using this for visualization anyway, any GIS operation/analysis would occur against the raw data. My biggest issue is with small text labels and how distorted they get when the tiles are reprojected but then again, this is an issue that will plague any tileset that contains labels GE - as it stands, GE would not be able to consume a tileset natively however a simple server script to calc/write the regions and then redirect their contents towards the appropriate image url should suffice. The WMS redirect could be a starting point. Another thing with GE ground overlays is that they prefer slightly larger images (say 512x512) over the smaller 256 ones used in the browsers. I'm kinda deciding now if I want to produce 2 sets or instead to reply on a server script to combine a quad of images just before the region contents are sent to GE. YMMV and I still have a lot of testing to do now on the positive side, once the above issues are dealt with, the tilesets could overlay really well in GE. as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. I'll have to look if those tile caches could be indexed but if memory serves, I don't think they use the y folder, x file naming convention you have laid out. cheers brian -----Original Message----- From: Paul Ramsey [mailto:pramsey at refractions.net] Sent: Tuesday, October 31, 2006 10:44 AM To: Brian Flood Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile Brian, There are two (wait, three) reasons I went for EPSG:4326 in the first draft: - I figured that the tile sets for the 3D clients were largely in 4326 (at least, Worldwind's are) - I knew that most/all of the WMS servers supported 4326 (standard says it is mandatory, and most do support it) and lots of TMS servers will be used to front for WMS servers. - I know that almost no WMS servers support world mercator (hacked EPSG:41001) so getting tiles out into that projection will be harder than with EPSG:4326, where one can simply front a WMS. You do lots of KML / GEarth, so you would know: since the web clients will have a hard time integrating mercator and 4326, can the 3D clients trivially do it. For example, can GEarth consume a tile cache of data in Mercator using the regions mechanism? Paul On 31-Oct-06, at 5:49 AM, Brian Flood wrote: hello all first off, I love this spec. I think it holds a lot of promise when using tile sets in both browsers and rich clients like ArcMap. kudos to everyone who got it off the ground. so, I can understand why EPSG:4326 is used as a common denominator but all the big GYM providers use Mercator World for their tiles. Any chance this could used as the global standard? I could see many people wanting to overlay their tiles over the existing GYM satellite images. just a thought... cheers brian _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From cholmes at openplans.org Tue Oct 31 10:59:04 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 13:59:04 -0500 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> Message-ID: <45479CF8.1010609@openplans.org> > Another thing with > GE ground overlays is that they prefer slightly larger images (say > 512x512) over the smaller 256 ones used in the browsers. Why? Where does this preference come from? My reading of the region spec seemed to give implementors leeway over the size of images returned. Or is this just from experience that it looks/performs better with bigger tiles? > I'm kinda > deciding now if I want to produce 2 sets or instead to reply on a server > script to combine a quad of images just before the region contents are > sent to GE. If you could get it to perform well it seems the latter would be preferable, I would at least play with that approach a bit. best regards, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/882ee376/attachment.vcf From stein at geofusion.com Tue Oct 31 10:54:01 2006 From: stein at geofusion.com (Chuck Stein) Date: Tue, 31 Oct 2006 10:54:01 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216E8@s25.local.spatialdatalogic.com> Message-ID: <092801c6fd1d$f5f9b720$d1a63e05@lapchuck> I assume you mean ESRI's ArcGlobe inside Explorer. This uses the GeoMatrix tiling system that I submitted to this group as a paper a month or so ago. The GeoMatrix system uses a combination of Geographic (EPSG:4326) between +/-45 latitude and what I call Square Polar projection above and below 45 degrees. This system might sound overly complex but it is designed for use in texture mapping. The square polar projection provides a much more efficient representation of the polar areas than Geographic or Mercator and it is more compact and reduces bandwidth requirements. You will also see that the distortion at the poles is much less that you see on GE and WW. You can see it in our web-enabled GeoPlayer at www.geoplayer.com/gateways (warning: requires PC and IE - we will be upgrading very soon with support for Firefox and Mac). With regards to distorted text because it is burned into the imagery. Best to keep the text out of the imagery. There will always be different systems using different projections. If the goal is cross-system compatibility this will always be a problem. Chuck GeoFusion > as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them > into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. > I'll have to look if those tile caches could be indexed but if memory serves, I don't think they > use the y folder, x file naming convention you have laid out. From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 11:37:54 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 14:37:54 -0500 Subject: [tiling] global profile In-Reply-To: <45479CF8.1010609@openplans.org> Message-ID: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> 512x512 - yea, just what I (and others) have found. something about how they manage the video memory. but you're correct in saying there is no specific size that is necessary tile combo - I'll let you know how it goes... cheers brian -----Original Message----- From: Chris Holmes [mailto:cholmes at openplans.org] Sent: Tuesday, October 31, 2006 1:59 PM To: Brian Flood Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile > Another thing with > GE ground overlays is that they prefer slightly larger images (say > 512x512) over the smaller 256 ones used in the browsers. Why? Where does this preference come from? My reading of the region spec seemed to give implementors leeway over the size of images returned. Or is this just from experience that it looks/performs better with bigger tiles? > I'm kinda > deciding now if I want to produce 2 sets or instead to reply on a server > script to combine a quad of images just before the region contents are > sent to GE. If you could get it to perform well it seems the latter would be preferable, I would at least play with that approach a bit. best regards, Chris From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 11:41:31 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 14:41:31 -0500 Subject: [tiling] global profile In-Reply-To: <092801c6fd1d$f5f9b720$d1a63e05@lapchuck> Message-ID: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> that's interesting chuck. yea, I assume that's what's under the covers in AGX, its using the globe control. makes sense for the polar data I guess did esri ever upgrade to your latest software bits? cheers brian -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Chuck Stein Sent: Tuesday, October 31, 2006 1:54 PM To: tiling at lists.eogeo.org Subject: Re: [tiling] global profile I assume you mean ESRI's ArcGlobe inside Explorer. This uses the GeoMatrix tiling system that I submitted to this group as a paper a month or so ago. The GeoMatrix system uses a combination of Geographic (EPSG:4326) between +/-45 latitude and what I call Square Polar projection above and below 45 degrees. This system might sound overly complex but it is designed for use in texture mapping. The square polar projection provides a much more efficient representation of the polar areas than Geographic or Mercator and it is more compact and reduces bandwidth requirements. You will also see that the distortion at the poles is much less that you see on GE and WW. You can see it in our web-enabled GeoPlayer at www.geoplayer.com/gateways (warning: requires PC and IE - we will be upgrading very soon with support for Firefox and Mac). With regards to distorted text because it is burned into the imagery. Best to keep the text out of the imagery. There will always be different systems using different projections. If the goal is cross-system compatibility this will always be a problem. Chuck GeoFusion > as far as AGX, there's no hook into the streaming mechanism so it might be difficult to get them > into AGX without ESRI intervention. It uses its own tiling schema for most of its base data. > I'll have to look if those tile caches could be indexed but if memory serves, I don't think they > use the y folder, x file naming convention you have laid out. _______________________________________________ tiling mailing list tiling at lists.eogeo.org http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 11:44:14 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 11:44:14 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> Message-ID: <1162323854.4547a78e2da23@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/08d587f0/attachment.pot From pramsey at refractions.net Tue Oct 31 11:45:46 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 11:45:46 -0800 Subject: [tiling] Polar Projection In-Reply-To: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A0216FF@s25.local.spatialdatalogic.com> Message-ID: <1162323946.4547a7eab3c71@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/3cdfb636/attachment.asc From cholmes at openplans.org Tue Oct 31 12:02:53 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 15:02:53 -0500 Subject: [tiling] global profile In-Reply-To: <1162323854.4547a78e2da23@ssl.refractions.net> References: <534364EA05A4824790821002CAD4570A0216FD@s25.local.spatialdatalogic.com> <1162323854.4547a78e2da23@ssl.refractions.net> Message-ID: <4547ABED.3040300@openplans.org> Yeah, I was thinking this as well. +1 Paul Ramsey wrote: > Back to the global-profile. We could define a *second* global-profile, that is > mercator based. A global profile is just a projection and an agreed set of > scales, so there could be a mercator one as well. If we started with the whole > world and went down from there by factors of two again, the two profiles could be > used together with a little linear stretching, for those who don't mind some > intra-tile inaccuracies. > > P > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547a7ba62727731818748! > -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/5d7f8696/attachment.vcf From BFLOOD at SPATIALDATALOGIC.COM Tue Oct 31 12:05:50 2006 From: BFLOOD at SPATIALDATALOGIC.COM (Brian Flood) Date: Tue, 31 Oct 2006 15:05:50 -0500 Subject: [tiling] global profile In-Reply-To: <4547ABED.3040300@openplans.org> Message-ID: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> agreed, that makes sense to me -----Original Message----- From: tiling-bounces at lists.eogeo.org [mailto:tiling-bounces at lists.eogeo.org] On Behalf Of Chris Holmes Sent: Tuesday, October 31, 2006 3:03 PM To: Paul Ramsey Cc: tiling at lists.eogeo.org Subject: Re: [tiling] global profile Yeah, I was thinking this as well. +1 Paul Ramsey wrote: > Back to the global-profile. We could define a *second* global-profile, that is > mercator based. A global profile is just a projection and an agreed set of > scales, so there could be a mercator one as well. If we started with the whole > world and went down from there by factors of two again, the two profiles could be > used together with a little linear stretching, for those who don't mind some > intra-tile inaccuracies. > > P > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547a7ba62727731818748! > -- Chris Holmes The Open Planning Project http://topp.openplans.org From stein at geofusion.com Tue Oct 31 12:11:20 2006 From: stein at geofusion.com (Chuck Stein) Date: Tue, 31 Oct 2006 12:11:20 -0800 Subject: [tiling] Polar Projection In-Reply-To: <1162323946.4547a7eab3c71@ssl.refractions.net> Message-ID: <095901c6fd28$c2191260$d1a63e05@lapchuck> Completey non-standard? It has been our standard (and ESRI's and others) for 5 years :^). I have never tried the WKT. I would definetly like to get it into OSGEO (make it yet another real standard). What do we need to do? By the way, while Paul Hansen invented the square polar on his own, he was not the first so it is not 'ours'. > Chuck, is your polar projection completely non-standard, > or is it expressable in WKT? > Could you add it to the OSGEO: projection list if possible? > P ESRI got a dump of the bits recently. It is not clear to me how easy it is for them to integrate at this point. > did esri ever upgrade to your latest software bits? > brian chuck From pramsey at refractions.net Tue Oct 31 12:43:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 12:43:34 -0800 Subject: [tiling] Polar Projection In-Reply-To: <095901c6fd28$c2191260$d1a63e05@lapchuck> References: <095901c6fd28$c2191260$d1a63e05@lapchuck> Message-ID: <1162327414.4547b576d34be@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/7aaa48d2/attachment.asc From pramsey at refractions.net Tue Oct 31 12:43:58 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 12:43:58 -0800 Subject: [tiling] global profile In-Reply-To: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> References: <534364EA05A4824790821002CAD4570A021700@s25.local.spatialdatalogic.com> Message-ID: <1162327438.4547b58e481b5@ssl.refractions.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.eogeo.org/pipermail/tiling/attachments/20061031/300e13f5/attachment.pot From tisham at apogee.com.au Tue Oct 31 14:43:19 2006 From: tisham at apogee.com.au (tisham at apogee.com.au) Date: Wed, 01 Nov 2006 08:43:19 +1000 Subject: [tiling] tiling Digest, Vol 9, Issue 10 In-Reply-To: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> References: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> Message-ID: <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> Hi all, News from the Worldwind world. We have a functional Virtual Earth Plugin in the SVN Unstable branch now. This demonstrates reprojection on the fly of VE tiles from mercator to 4326(well latlon) using proj.dll as the calculation engine. This is done on the fly and without any significant overhead, so it is possible.We can do exactly the same for Google or Yahoo, but the lawyers keep us at bay. Regards, Tisham Dhar(aka what_nick) Worldwind Open Source Developer Apogee Imaging International http://www.apogee.com.au ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From cholmes at openplans.org Tue Oct 31 14:58:57 2006 From: cholmes at openplans.org (Chris Holmes) Date: Tue, 31 Oct 2006 17:58:57 -0500 Subject: [tiling] tiling Digest, Vol 9, Issue 10 In-Reply-To: <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> References: <mailman.3.1162324803.14527.tiling@lists.eogeo.org> <20061101084319.mwoqg77un8k0c84g@webmail.apogee.com.au> Message-ID: <4547D531.3080400@openplans.org> tisham at apogee.com.au wrote: > Hi all, > > News from the Worldwind world. > > We have a functional Virtual Earth Plugin in the SVN Unstable branch now. This > demonstrates reprojection on the fly of VE tiles from mercator to 4326(well > latlon) using proj.dll as the calculation engine. > > This is done on the fly and without any significant overhead, so it is > possible.We can do exactly the same for Google or Yahoo, but the lawyers keep > us at bay. Very cool. Can you do 4326 to mercator? It seems like the lawyers would be fine with that, overlaying worldwind tiles on google or yahoo maps, no? And that's the direction we're interested in going as well, I believe - having the TMS store its tiles in 4326, and go on the fly to mercator to be overlaid on google and yahoo. best regards, Chris > > Regards, > > Tisham Dhar(aka what_nick) > Worldwind Open Source Developer > Apogee Imaging International > http://www.apogee.com.au > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling > > !DSPAM:1003,4547d35687191429667743! > -- Chris Holmes The Open Planning Project http://topp.openplans.org -------------- next part -------------- A non-text attachment was scrubbed... Name: cholmes.vcf Type: text/x-vcard Size: 269 bytes Desc: not available Url : http://lists.eogeo.org/pipermail/tiling/attachments/20061031/25ca286e/attachment.vcf From schuyler at nocat.net Tue Oct 31 17:14:33 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Tue, 31 Oct 2006 17:14:33 -0800 Subject: [tiling] WMS Tiling Client Recommendation Message-ID: <20061101011433.GM30475@vishnu.tridity.org> I've finally published a tiling WMS recommendation, although I seem to have gone a bit overboard from what Paul probably envisioned when he titled the wiki page "WMS Tiling Client Recommendation".[1] I did, at any rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I don't think I missed anything important. Comments? Questions? Complaints? Should the page be renamed? Or should the server extensions be thrown away in favor of TMS? [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF SDE From pramsey at refractions.net Tue Oct 31 20:25:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:25:34 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <7DB60670-2FB2-4764-8719-DC1929628C4A@refractions.net> Schuyler, I've thrown some edits into the page, * I think the initial resolution is wrong for the first global profile, * I have changed the BoundingBox to LatLonBoundingBox (or, you can change the extents for the mercator profile to coordinates in mercator) * I have changed EPSG:41001 to OSGEO:41001 to match the TMS spec and stay on EPSG's good side I think you need to give a precise required ordering of all the possible getmap parameters. Paul On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 20:30:51 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:30:51 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <2B77C974-8097-42AB-BCC0-950286754F05@refractions.net> Arg, *and* you need to be very specific about the encoding of things in URLs, since some clients are sloppy about whether/how they encode some aspects of the URL (Do you have to encode the ":" in the "EPSG: 4326"?). You should be clear about whether you want "+" as the encoding for " " or %22. Etc etc etc. All the reasons why WMS is a PITA to make cachable -- it's so hard to get people to say the same thing in exactly the same way. (I am not sure about the "server extensions" part, it might be better just to get all the clients talking the same way, with "TILED=TRUE" in the URL, and if the server maintainer sees lots of TILED=TRUE requests coming in, it's time to turn on mod_cache and start getting some free performance boosting.) P On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling From pramsey at refractions.net Tue Oct 31 20:48:34 2006 From: pramsey at refractions.net (Paul Ramsey) Date: Tue, 31 Oct 2006 20:48:34 -0800 Subject: [tiling] WMS Tiling Client Recommendation In-Reply-To: <20061101011433.GM30475@vishnu.tridity.org> References: <20061101011433.GM30475@vishnu.tridity.org> Message-ID: <74918EDB-7241-460F-BE94-889DD1EC26FC@refractions.net> There are some mandatory WMS request parameters that are not in the list of parameters, like VERSION. The more I think about this, the more it seems like a fools errand to try and constrain WMS requests sufficiently to get acceptable shared caching behavior. On 31-Oct-06, at 5:14 PM, Schuyler Erle wrote: > I've finally published a tiling WMS recommendation, although I seem to > have gone a bit overboard from what Paul probably envisioned when he > titled the wiki page "WMS Tiling Client Recommendation".[1] I did, > at any > rate, try to encapsulate the discussion from the BoF at FOSS4G[2]. I > don't think I missed anything important. Comments? Questions? > Complaints? Should the page be renamed? Or should the server > extensions be thrown away in favor of TMS? > > [1] http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation > [2] http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > SDE > _______________________________________________ > tiling mailing list > tiling at lists.eogeo.org > http://lists.eogeo.org/mailman/listinfo/tiling