From crschmidt at metacarta.com Thu Sep 14 09:22:26 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: OpenLayers/ka-Map Merging BOF Results Message-ID: <20060914132226.GC29355@metacarta.com> So, the OpenLayers/Ka-Map merger BOF was much more than that -- in fact, it was a similar gathering to the tiling BOF, in that every web map client was well represented at the session and the goal was a consensus, with possibly some compromises, which would suit all persons involved. After much discussion, we came down to the idea of a general set of functionality that all webmapping client developers could use -- specifically, it should be possible to take any div on a page, and draw a map inside that div using this library. The library will work in such a way that it will have the following bits of code: * Map * Layer * A few useful subclasses of layer (WMS) * Event handling The idea is to make a small library for displaying image tiles in a div, and make everything else up to the application. Doing this means that we can combine the work on actually doing tiled map drawing -- a tile renderer is something that many people, from Ka-Map to MapBuilder to maybe MapBender, MapGuide, etc. could use. The core of this is going to be a small subset of OpenLayers which does not depend on Prototype: Essentially, the Map, Layer, and Events classes we have currently developed will be modified such that they can fit in with other clients as well as possible. The goal is to pick a limited subset of useful infrastructure, and attempt to make it possible for all web mapping applications -- OpenLayers, kaMap, and others -- to be built on top of it. To do that, a limited subset of a tile rendering engine is neccesary. We're going to have a goal of a draft version of the newly discussed "WebMap.js" in the next 2 months ish, with the hopes of making sure that all projects who are interested -- from MapGuide to OpenLayers -- can be built on top of the framework, with no dependancies which block other development. I've been working on this email for far too long -- so, I'll send it, and hopefully in the relatively short term, it can start being backed up with code. Please feel free to augment this post with further exlanation and discussion :) Regards, -- Christopher Schmidt MetaCarta From lorenzo at ominiverdi.com Thu Sep 14 10:40:34 2006 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] OpenLayers/ka-Map Merging BOF Results In-Reply-To: <20060914132226.GC29355@metacarta.com> References: <20060914132226.GC29355@metacarta.com> Message-ID: Good work Chris, as I've seen on rss Schuyler started posting some comments on the wiki. http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF Please everybody who was there help refining. ciao Lorenzo On 14/set/06, at 15:22, Christopher Schmidt wrote: > So, the OpenLayers/Ka-Map merger BOF was much more than that -- in > fact, > it was a similar gathering to the tiling BOF, in that every web map > client was well represented at the session and the goal was a > consensus, > with possibly some compromises, which would suit all persons involved. > > After much discussion, we came down to the idea of a general set of > functionality that all webmapping client developers could use -- > specifically, it should be possible to take any div on a page, and > draw > a map inside that div using this library. The library will work in > such > a way that it will have the following bits of code: > > * Map > * Layer > * A few useful subclasses of layer (WMS) > * Event handling > > The idea is to make a small library for displaying image tiles in a > div, > and make everything else up to the application. Doing this means > that we > can combine the work on actually doing tiled map drawing -- a tile > renderer is something that many people, from Ka-Map to MapBuilder to > maybe MapBender, MapGuide, etc. could use. > > The core of this is going to be a small subset of OpenLayers which > does not > depend on Prototype: Essentially, the Map, Layer, and Events > classes we > have currently developed will be modified such that they can fit in > with > other clients as well as possible. The goal is to pick a limited > subset > of useful infrastructure, and attempt to make it possible for all web > mapping applications -- OpenLayers, kaMap, and others -- to be > built on > top of it. To do that, a limited subset of a tile rendering engine is > neccesary. > > We're going to have a goal of a draft version of the newly discussed > "WebMap.js" in the next 2 months ish, with the hopes of making sure > that > all projects who are interested -- from MapGuide to OpenLayers -- > can be > built on top of the framework, with no dependancies which block other > development. > > I've been working on this email for far too long -- so, I'll send it, > and hopefully in the relatively short term, it can start being > backed up > with code. > > Please feel free to augment this post with further exlanation and > discussion :) > > Regards, > -- > Christopher Schmidt > MetaCarta > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > From crschmidt at crschmidt.net Thu Sep 14 11:00:33 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] OpenLayers/ka-Map Merging BOF Results In-Reply-To: References: <20060914132226.GC29355@metacarta.com> Message-ID: <20060914150033.GA10397@crschmidt.net> On Thu, Sep 14, 2006 at 04:40:34PM +0200, Lorenzo Becchi wrote: > Good work Chris, > as I've seen on rss Schuyler started posting some comments on the wiki. > http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF > > Please everybody who was there help refining. Note that the primary mailing list for Tiling discussion is the eogeo tiling list: There's a summary of the BOF at: http://lists.eogeo.org/pipermail/tiling/2006-September/000050.html and the signup for that list is at: http://lists.eogeo.org/mailman/listinfo/tiling -- Christopher Schmidt Web Developer From lorenzo at ominiverdi.com Thu Sep 14 11:07:35 2006 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] OpenLayers/ka-Map Merging BOF Results In-Reply-To: <20060914150033.GA10397@crschmidt.net> References: <20060914132226.GC29355@metacarta.com> <20060914150033.GA10397@crschmidt.net> Message-ID: sorry, sleeping again... On 14/set/06, at 17:00, Christopher Schmidt wrote: > On Thu, Sep 14, 2006 at 04:40:34PM +0200, Lorenzo Becchi wrote: >> Good work Chris, >> as I've seen on rss Schuyler started posting some comments on the >> wiki. >> http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF >> >> Please everybody who was there help refining. > > Note that the primary mailing list for Tiling discussion is the eogeo > tiling list: There's a summary of the BOF at: > > http://lists.eogeo.org/pipermail/tiling/2006-September/000050.html > > and the signup for that list is at: > > http://lists.eogeo.org/mailman/listinfo/tiling > > -- > Christopher Schmidt > Web Developer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > From bluecarto at gmail.com Wed Sep 20 05:15:07 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:42 2006 Subject: alistapart css framework Message-ID: Someone (didn't remember who) talked about some css framework he found on the "A List Apart" website during a BOF (ka-map / OpenLayers) at the FOSS4G2006 meeting, but I'm unable to find it. Can someone point me to the correct ressource ? Regards Pierre GIRAUD camptocamp From pspencer at dmsolutions.ca Wed Sep 20 05:51:04 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] alistapart css framework In-Reply-To: References: Message-ID: <75CF0B32-AF69-4388-B56A-D91163D6D15A@dmsolutions.ca> this search: http://www.google.com/search?client=safari&rls=en&q=css +framework&ie=UTF-8&oe=UTF-8 yields a few interesting results, the first one seems to have the usual layouts that css frameworks seem to discuss. This site: http://www.thenoodleincident.com/tutorials/box_lesson/boxes.html is one that I particularly like (but it doesn't show up in the above search results) Cheers Paul On 20-Sep-06, at 5:15 AM, Pierre GIRAUD wrote: > Someone (didn't remember who) talked about some css framework he found > on the "A List Apart" website during a BOF (ka-map / OpenLayers) at > the FOSS4G2006 meeting, but I'm unable to find it. > > Can someone point me to the correct ressource ? > > Regards > > Pierre GIRAUD > camptocamp > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From damien.corpataux at camptocamp.com Wed Sep 20 09:19:04 2006 From: damien.corpataux at camptocamp.com (Damien Corpataux) Date: Fri Dec 22 15:49:42 2006 Subject: Hi, this is a test In-Reply-To: <1147359294.24517.ezmlm@mail.osgeo.org> References: <1147359294.24517.ezmlm@mail.osgeo.org> Message-ID: <45113FC8.1080504@camptocamp.com> Just a dummy mail to test my subscription to this list, as I haven't received mails since ages from this list, I suspect I didn't subscribe properly. From usuari79 at moviments.net Wed Sep 20 09:43:42 2006 From: usuari79 at moviments.net (mr) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] CSS In-Reply-To: References: Message-ID: <61523.80.35.87.44.1158759822.squirrel@secure.moviments.net> >>links? dig down here http://cssplay.co.uk/menu/ more? > Someone (didn't remember who) talked about some css framework he found > on the "A List Apart" website during a BOF (ka-map / OpenLayers) at > the FOSS4G2006 meeting, but I'm unable to find it. > > Can someone point me to the correct ressource ? > > Regards > > Pierre GIRAUD > camptocamp http://search.atomz.com/search/?sp-q=image+map&sp-a=sp1002d27b&sp-f=ISO-8859-1&sp-p=All&sp-k=All ..maybe, it wasn?t me.. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > From crschmidt at metacarta.com Wed Sep 20 16:23:07 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: WMS Requests: Rounding BBOX Message-ID: <20060920202307.GB27340@metacarta.com> Today, an OpenLayers user asked me why we weren't rounding BBOX values in our tiled image requests, since it was causing problems with his reverse proxy caching to have OpenLayers not do so. The primary reason this isn't done at the moment is that I couldn't pick a good value to use :) 6 decimal places seems to be a generally good value to cut-off at when working in degrees: that gets you down to half-meter accuracy (I think?). Does anyone have any other thoughts on this? How have you addressed rounding BBOX requests in your own applications? -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Wed Sep 20 20:15:55 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <20060920202307.GB27340@metacarta.com> References: <20060920202307.GB27340@metacarta.com> Message-ID: <3AEAB70B-86B3-4895-8521-6FA6F89E892A@dmsolutions.ca> Chris, I think you should go with whatever Schuyler puts into the spec for cacheable WMS :) Would you implement this for just the WMS tiled layer or for all layers (I'm thinking about a possible impact on ka-Map of course) Paul On 20-Sep-06, at 4:23 PM, Christopher Schmidt wrote: > Today, an OpenLayers user asked me why we weren't rounding BBOX values > in our tiled image requests, since it was causing problems with his > reverse proxy caching to have OpenLayers not do so. The primary reason > this isn't done at the moment is that I couldn't pick a good value to > use :) > > 6 decimal places seems to be a generally good value to cut-off at when > working in degrees: that gets you down to half-meter accuracy (I > think?). Does anyone have any other thoughts on this? How have you > addressed rounding BBOX requests in your own applications? > > -- > Christopher Schmidt > MetaCarta > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From crschmidt at crschmidt.net Wed Sep 20 20:53:00 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <3AEAB70B-86B3-4895-8521-6FA6F89E892A@dmsolutions.ca> References: <20060920202307.GB27340@metacarta.com> <3AEAB70B-86B3-4895-8521-6FA6F89E892A@dmsolutions.ca> Message-ID: <20060921005300.GI544@crschmidt.net> On Wed, Sep 20, 2006 at 08:15:55PM -0400, Paul Spencer wrote: > Chris, > > I think you should go with whatever Schuyler puts into the spec for > cacheable WMS :) Right, but we have to make that decision at some point as a group. I have no problem with leading that discussion here and now. > Would you implement this for just the WMS tiled layer or for all > layers (I'm thinking about a possible impact on ka-Map of course) Rounding should happen as late as possible. In ka-Map, there are two places it happens: tiles are rounded to nearest tile -- pixel modulu tile size -- and scale is rounded to four decimal places. BBOX values will be rounded where used in tile loading -- this is for WFS, and images which use a BBOX. -- Christopher Schmidt Web Developer From scott at davisworld.org Wed Sep 20 22:35:21 2006 From: scott at davisworld.org (Scott Davis) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] alistapart css framework In-Reply-To: References: Message-ID: <8642CB53-9253-4E4D-92FC-028CDA945907@davisworld.org> http://www.contentwithstyle.co.uk/Articles/17/ Clearly the problem finding it on A List Apart is, well, umm, the fact that it *isn't* on ALA. Sorry for the misdirection. The good news: google for "css framework", and it's your first hit. Cheers, s Scott Davis scott@davisworld.org On Sep 20, 2006, at 3:15 AM, Pierre GIRAUD wrote: > Someone (didn't remember who) talked about some css framework he found > on the "A List Apart" website during a BOF (ka-map / OpenLayers) at > the FOSS4G2006 meeting, but I'm unable to find it. > > Can someone point me to the correct ressource ? > > Regards > > Pierre GIRAUD > camptocamp > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > From steven.ottens at geodan.nl Thu Sep 21 06:20:01 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <20060920202307.GB27340@metacarta.com> References: <20060920202307.GB27340@metacarta.com> Message-ID: <45126751.2080108@geodan.nl> Christopher Schmidt wrote: > Today, an OpenLayers user asked me why we weren't rounding BBOX values > in our tiled image requests, since it was causing problems with his > reverse proxy caching to have OpenLayers not do so. The primary reason > this isn't done at the moment is that I couldn't pick a good value to > use :) > > 6 decimal places seems to be a generally good value to cut-off at when > working in degrees: that gets you down to half-meter accuracy (I > think?). Does anyone have any other thoughts on this? How have you > addressed rounding BBOX requests in your own applications? 6 decimal places for lat/long is fine. I don't think we need to be able to give bounding boxes in mm on lat/long systems anyway. But 6 decimal places for projected ones is a bit overkill. Can you make sure that those bounding boxes are rounded in a more sensible way? Steven -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From crschmidt at metacarta.com Thu Sep 21 06:32:39 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <45126751.2080108@geodan.nl> References: <20060920202307.GB27340@metacarta.com> <45126751.2080108@geodan.nl> Message-ID: <20060921103239.GA29905@metacarta.com> On Thu, Sep 21, 2006 at 12:20:01PM +0200, Steven M. Ottens wrote: > Christopher Schmidt wrote: > > Today, an OpenLayers user asked me why we weren't rounding BBOX values > > in our tiled image requests, since it was causing problems with his > > reverse proxy caching to have OpenLayers not do so. The primary reason > > this isn't done at the moment is that I couldn't pick a good value to > > use :) > > > > 6 decimal places seems to be a generally good value to cut-off at when > > working in degrees: that gets you down to half-meter accuracy (I > > think?). Does anyone have any other thoughts on this? How have you > > addressed rounding BBOX requests in your own applications? > 6 decimal places for lat/long is fine. I don't think we need to be able > to give bounding boxes in mm on lat/long systems anyway. But 6 decimal > places for projected ones is a bit overkill. Can you make sure that > those bounding boxes are rounded in a more sensible way? What is sensible? I know that I can implement it in OpenLayers, but there needs to be some kind of agreement on what makes sense... the problem being that what makes sense for you or I doesn't make sense for everyone. For systems using meters, usually two decimal places is overkill... but there might be someone working with extremely large scale cad drawings (1:10, or 1:100) where webmap clients make sense... and that 1 cm difference could be major. Should rounding be based on the current scale? I think that's the only way to make sure that requests are never going to lose precision which is neccesary for correctly displaying the map -- otherwise, when you get into 1px = 1unit, you'll run into problems with most any rounding... Does anyone have use cases where rounding has played an effect? I know that when I was first working with ka-map, I actually did see rounding have an effect. THe ka-Map tiling engine rounded scale requests to the nearest integer. Since ka-Map requires you to enter fixed scales, this had never been a problem: but when you try to combined OpenLayers and ka-map, it did become a problem -- rounding scale to the nearest integer caused errors that could be as high as half a tile as the tile got further and further from the geographic meridians. So, I'm aware that these things do matter... but not sure at what point they matter. Rounding the scale to four decimal places brought any such differences to being invisible -- but is that enough for bounding boxes? -- Christopher Schmidt MetaCarta From adoyle at eogeo.org Thu Sep 21 09:49:04 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <20060921103239.GA29905@metacarta.com> References: <20060920202307.GB27340@metacarta.com> <45126751.2080108@geodan.nl> <20060921103239.GA29905@metacarta.com> Message-ID: On Sep 21, 2006, at 06:32, Christopher Schmidt wrote: > On Thu, Sep 21, 2006 at 12:20:01PM +0200, Steven M. Ottens wrote: >> Christopher Schmidt wrote: >>> Today, an OpenLayers user asked me why we weren't rounding BBOX >>> values >>> in our tiled image requests, since it was causing problems with his >>> reverse proxy caching to have OpenLayers not do so. The primary >>> reason >>> this isn't done at the moment is that I couldn't pick a good >>> value to >>> use :) >>> >>> 6 decimal places seems to be a generally good value to cut-off at >>> when >>> working in degrees: that gets you down to half-meter accuracy (I >>> think?). Does anyone have any other thoughts on this? How have you >>> addressed rounding BBOX requests in your own applications? >> 6 decimal places for lat/long is fine. I don't think we need to be >> able >> to give bounding boxes in mm on lat/long systems anyway. But 6 >> decimal >> places for projected ones is a bit overkill. Can you make sure that >> those bounding boxes are rounded in a more sensible way? > > What is sensible? I know that I can implement it in OpenLayers, but > there needs to be some kind of agreement on what makes sense... the > problem being that what makes sense for you or I doesn't make sense > for > everyone. > > For systems using meters, usually two decimal places is overkill... > but > there might be someone working with extremely large scale cad drawings > (1:10, or 1:100) where webmap clients make sense... and that 1 cm > difference could be major. > Should rounding be based on the current scale? I think that's the only > way to make sure that requests are never going to lose precision which > is neccesary for correctly displaying the map -- otherwise, when > you get > into 1px = 1unit, you'll run into problems with most any rounding... Let's not forget that by the time you have 1cm resolution, while it's nice to have cacheability and tiling, you're at a point of diminishing returns. The higher the resolution, the less likely you are to wind up working in an area that's already cached. Also, at such high resolutions, I could envision setting up local caches/tiles when needed. So maybe there's a step function rather than a specific rounding:scale ratio that's maintained. This again seems to be a case that favors a "simple" and an "extended" version. The simple version can be good to 1cm or 10 cm and most mashup-level things will be perfectly happy. Even 1m seems overkill for all but 1% of use cases. Allan > > Does anyone have use cases where rounding has played an effect? > > I know that when I was first working with ka-map, I actually did see > rounding have an effect. THe ka-Map tiling engine rounded scale > requests > to the nearest integer. Since ka-Map requires you to enter fixed > scales, > this had never been a problem: but when you try to combined OpenLayers > and ka-map, it did become a problem -- rounding scale to the nearest > integer caused errors that could be as high as half a tile as the tile > got further and further from the geographic meridians. So, I'm aware > that these things do matter... but not sure at what point they matter. > Rounding the scale to four decimal places brought any such differences > to being invisible -- but is that enough for bounding boxes? > > -- > Christopher Schmidt > MetaCarta > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > -- Allan Doyle +1.781.433.2695 adoyle@eogeo.org From pspencer at dmsolutions.ca Thu Sep 21 10:28:45 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <20060921103239.GA29905@metacarta.com> References: <20060920202307.GB27340@metacarta.com> <45126751.2080108@geodan.nl> <20060921103239.GA29905@metacarta.com> Message-ID: <7410F277-7387-4696-A3CC-AA8137092008@dmsolutions.ca> Chris, could the amount of rounding be configurable per layer with a reasonable default of 6 ... so that if you know you are working in a different projection where that doesn't make sense, you can override it? Paul On 21-Sep-06, at 6:32 AM, Christopher Schmidt wrote: > On Thu, Sep 21, 2006 at 12:20:01PM +0200, Steven M. Ottens wrote: >> Christopher Schmidt wrote: >>> Today, an OpenLayers user asked me why we weren't rounding BBOX >>> values >>> in our tiled image requests, since it was causing problems with his >>> reverse proxy caching to have OpenLayers not do so. The primary >>> reason >>> this isn't done at the moment is that I couldn't pick a good >>> value to >>> use :) >>> >>> 6 decimal places seems to be a generally good value to cut-off at >>> when >>> working in degrees: that gets you down to half-meter accuracy (I >>> think?). Does anyone have any other thoughts on this? How have you >>> addressed rounding BBOX requests in your own applications? >> 6 decimal places for lat/long is fine. I don't think we need to be >> able >> to give bounding boxes in mm on lat/long systems anyway. But 6 >> decimal >> places for projected ones is a bit overkill. Can you make sure that >> those bounding boxes are rounded in a more sensible way? > > What is sensible? I know that I can implement it in OpenLayers, but > there needs to be some kind of agreement on what makes sense... the > problem being that what makes sense for you or I doesn't make sense > for > everyone. > > For systems using meters, usually two decimal places is overkill... > but > there might be someone working with extremely large scale cad drawings > (1:10, or 1:100) where webmap clients make sense... and that 1 cm > difference could be major. > > Should rounding be based on the current scale? I think that's the only > way to make sure that requests are never going to lose precision which > is neccesary for correctly displaying the map -- otherwise, when > you get > into 1px = 1unit, you'll run into problems with most any rounding... > > Does anyone have use cases where rounding has played an effect? > > I know that when I was first working with ka-map, I actually did see > rounding have an effect. THe ka-Map tiling engine rounded scale > requests > to the nearest integer. Since ka-Map requires you to enter fixed > scales, > this had never been a problem: but when you try to combined OpenLayers > and ka-map, it did become a problem -- rounding scale to the nearest > integer caused errors that could be as high as half a tile as the tile > got further and further from the geographic meridians. So, I'm aware > that these things do matter... but not sure at what point they matter. > Rounding the scale to four decimal places brought any such differences > to being invisible -- but is that enough for bounding boxes? > > -- > Christopher Schmidt > MetaCarta > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From noreply at geocartic.com Thu Sep 21 13:27:31 2006 From: noreply at geocartic.com (Tim Schaub) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <7410F277-7387-4696-A3CC-AA8137092008@dmsolutions.ca> Message-ID: <005001c6dda3$38a08710$15fea8c0@meridian> I think some of this responsibility (for determining precision) should be assigned to the server. By that, I mean that a server offering tiled WMS should have to advertise the resolution of it's tiles (in map units per pixel). This resolution would then be used as the basis for determining the precision of client requests. Say that everybody agrees that a pixel edge lines up with the origin of your (map) coordinate system. (This doesn't mean that a client has to enforce that pixel[0,0] = map[0,0] - only that they agree that the coordinate system's origin lines up with a pixel edge.) If there is agreement here, then all BBOX requests should be integer multiples of the advertised resolutions. Specifically: bbox_top = (res * round(top/res)).toFixed(precision) where precision is the decimal precision of the advertised resolution and the rest is obvious. So if a server says it has tiles at a resolution of 0.333, then it means 333 map units per 1000 pixels, and all requests should be integer multiples of 0.333 (rounded to the nearest thousandth). I know this doesn't do anything for people who find meaning in things like zoom and ScaleHint. However, given the chance to come up with a new standard, it would be nice to start with something a bit more logical. This also somewhat limits people putting together a tiled WMS. It means you can't have a tile resolution of 0.333 and expect to serve a tile that starts at (10.000, 10.000) or something. However, I can't see how this is a real problem. Perhaps this doesn't advance the discussion at all, but I just wanted to add my thoughts. I guess I also agree with Paul that decimal precision should be a property of the layer - so the person configuring the client application checks the server to see what the appropriate precision for each layer should be. And now I see that the immediate issue is how to cater to servers that are caching based on URL - so picking a default decimal precision (for layers) makes sense. Tim > -----Original Message----- > From: Paul Spencer [mailto:pspencer@dmsolutions.ca] > Sent: Thursday, September 21, 2006 8:29 AM > To: webmap-discuss@mail.osgeo.org > Subject: Re: [webmap-discuss] WMS Requests: Rounding BBOX > > Chris, could the amount of rounding be configurable per layer > with a reasonable default of 6 ... so that if you know you > are working in a different projection where that doesn't make > sense, you can override it? > > Paul > > On 21-Sep-06, at 6:32 AM, Christopher Schmidt wrote: > > > On Thu, Sep 21, 2006 at 12:20:01PM +0200, Steven M. Ottens wrote: > >> Christopher Schmidt wrote: > >>> Today, an OpenLayers user asked me why we weren't rounding BBOX > >>> values in our tiled image requests, since it was causing problems > >>> with his reverse proxy caching to have OpenLayers not do so. The > >>> primary reason this isn't done at the moment is that I > couldn't pick > >>> a good value to use :) > >>> > >>> 6 decimal places seems to be a generally good value to cut-off at > >>> when working in degrees: that gets you down to half-meter > accuracy > >>> (I think?). Does anyone have any other thoughts on this? How have > >>> you addressed rounding BBOX requests in your own applications? > >> 6 decimal places for lat/long is fine. I don't think we need to be > >> able to give bounding boxes in mm on lat/long systems > anyway. But 6 > >> decimal places for projected ones is a bit overkill. Can you make > >> sure that those bounding boxes are rounded in a more sensible way? > > > > What is sensible? I know that I can implement it in OpenLayers, but > > there needs to be some kind of agreement on what makes sense... the > > problem being that what makes sense for you or I doesn't make sense > > for everyone. > > > > For systems using meters, usually two decimal places is > overkill... > > but > > there might be someone working with extremely large scale > cad drawings > > (1:10, or 1:100) where webmap clients make sense... and that 1 cm > > difference could be major. > > > > Should rounding be based on the current scale? I think > that's the only > > way to make sure that requests are never going to lose > precision which > > is neccesary for correctly displaying the map -- otherwise, > when you > > get into 1px = 1unit, you'll run into problems with most any > > rounding... > > > > Does anyone have use cases where rounding has played an effect? > > > > I know that when I was first working with ka-map, I > actually did see > > rounding have an effect. THe ka-Map tiling engine rounded scale > > requests to the nearest integer. Since ka-Map requires you to enter > > fixed scales, this had never been a problem: but when you try to > > combined OpenLayers and ka-map, it did become a problem -- rounding > > scale to the nearest integer caused errors that could be as high as > > half a tile as the tile got further and further from the geographic > > meridians. So, I'm aware that these things do matter... but > not sure > > at what point they matter. > > Rounding the scale to four decimal places brought any such > differences > > to being invisible -- but is that enough for bounding boxes? > > > > -- > > Christopher Schmidt > > MetaCarta > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/| > +-----------------------------------------------------------------+ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > From crschmidt at metacarta.com Thu Sep 21 16:20:38 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <005001c6dda3$38a08710$15fea8c0@meridian> References: <7410F277-7387-4696-A3CC-AA8137092008@dmsolutions.ca> <005001c6dda3$38a08710$15fea8c0@meridian> Message-ID: <20060921202038.GB31224@metacarta.com> On Thu, Sep 21, 2006 at 11:27:31AM -0600, Tim Schaub wrote: > I think some of this responsibility (for determining precision) should be > assigned to the server. By that, I mean that a server offering tiled WMS > should have to advertise the resolution of it's tiles (in map units per > pixel). This resolution would then be used as the basis for determining the > precision of client requests. > > Say that everybody agrees that a pixel edge lines up with the origin of your > (map) coordinate system. (This doesn't mean that a client has to enforce > that pixel[0,0] = map[0,0] - only that they agree that the coordinate > system's origin lines up with a pixel edge.) If there is agreement here, > then all BBOX requests should be integer multiples of the advertised > resolutions. Specifically: > > bbox_top = (res * round(top/res)).toFixed(precision) > > where precision is the decimal precision of the advertised resolution and > the rest is obvious. Is it trivial to find out the precision of a number in various languages? I don't know how to do it off the top of my head in Javascript, but maybe I'm being a bit naive. > So if a server says it has tiles at a resolution of 0.333, then it means 333 > map units per 1000 pixels, and all requests should be integer multiples of > 0.333 (rounded to the nearest thousandth). > > I know this doesn't do anything for people who find meaning in things like > zoom and ScaleHint. However, given the chance to come up with a new > standard, it would be nice to start with something a bit more logical. I don't know what scaleHint is, but zoom is usually just a shorthand for describing resolutions, and scale is just an inverse of resolution: 1:150M is around 1.2 degrees/pixel assuming 72 pixels/inch. We discussed at the tiling meeting that scale is a relic, and should not be considered as a canonical term when dealing with on-screen webmapping. Using precision of resolution as advertised by a server seems to make sense to me. -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Thu Sep 21 16:54:35 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: webmap-discuss archieves? Message-ID: <4512FC0B.8010307@gmail.com> Is this webmap-discuss email list being archeived? Auke, If not, could we please organise for it to be archieved. -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Thu Sep 21 17:02:53 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: Strategic Direction In-Reply-To: <0D8F8888-2423-4849-9D9E-80CE0CA701C2@dmsolutions.ca> References: <450F01B3.5010601@gmail.com> <20060921093952.GG15938@metacarta.com> <0D8F8888-2423-4849-9D9E-80CE0CA701C2@dmsolutions.ca> Message-ID: <4512FDFD.5070809@gmail.com> This thread has become more about WebMap.js and so I'm moving it to the webmap list, (and will start a "What sucks about Mapbuilder" thread for the mapbuilder list. Thanks all for filling me in, as I wasn't at FOSS4G I'm playing catchup. Paul, I don't understand what your definition of Managed and Unmanaged. Could you please expand. Paul, I like your ASCII art, we should put it into a graphic somewhere to help users pick a suitable webmapping client. Maybe on an OSGeo page titled "Picking a suitable Webmapping client". FYI: There is a cool ASCII art program at http://www.jave.de/ Paul Spencer wrote: > I'd have to agree with Schuyler. Each project has a different > underlying philosophy ... To help me understand it, I've divided them > into four groups - two categories with two sub-categories. > > First category is how the template is done. Second is how the maps are > created/used. > > Templating can be managed or unmanaged > > Maps can be client side (direct from OGC services) or server side > (rendered by MapServer/MapGuide) > > The divisions are not precise, obviously! Here is my horrible attempt > at ASCII art ... > > managed | unmanaged > | > mapbender | mapbuilder > client | OpenLayers (2) > | > ----------- > -----------------| WebMap.js |------------ > ----------- > | > | chameleon > server mapguide | ka-map (1) > | > | > > (1) ka-Map is actually a client side app and can do client-side direct > from WMS but its not the primary mechanism and the default install > requires a server side component. > > (2) OpenLayers can do server-side from ka-Map, but its not the primary > mechanism > > Not sure where cartoweb fits in the picture, I don't know much about > it. And I probably missed some ... not sure which. > > In my view of the world, then, the AJAX BOF was discussing something > that could easily fit into the center of this diagram ... this is the > proposed WebMap.js. > > So we end up with each project owning and promoting a particular space > in my view of the AJAX web mapping world. I think there are benefits > and drawbacks to each space and its excellent to be able to chose a > different solution for any given client based on what they really need. > > Cheers > > Paul > > On 21-Sep-06, at 5:39 AM, Schuyler Erle wrote: > >> * On 18-Sep-2006 at 4:30PM EDT, Cameron Shorter said: >> >>> >>> There are a number of AJAX Web Mapping clients and not all of them will >>> thrive. In particular, OpenLayers is addressing the simple mapping use >>> cases and is cutting into Mapbuilder's potential user base. We should >>> set our development path toward merging with OpenLayers. >> >> >> Well, I hope we're not cutting into each other's user bases, so much >> as serving somewhat different use cases in the same general sphere. >> >> At the FOSS4G conference in Lausanne last week, we had a web mapping >> client BoF session, in which it was agreed that the OpenLayers team >> should try to split off a basic core for fetching map images/tiles and >> displaying them in an HTML div. >> >> Our hope is that our fellow AJAX mapping projects will be able to >> incorporate this map display library in their code, providing us all >> with a common stable base on which to build better web mapping apps. >> Provisionally, we've been calling this code "Webmap.js" (or something >> similar). >> >> In the meantime, we would appreciate any kind of direction that >> Mapbuilder and the other AJAX mapping projects have to offer about >> what the shape of this shared map display core should look like. Our >> plan is to have a rough cut of the library available in the next >> couple weeks. >> >> I think this is a very exciting opportunity for all of us to >> collaborate, and I hope that we can make it work for everyone! >> >> SDE >> >> ---------------------------------------------------------------------- >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> mapbuilder-devel mailing list >> mapbuilder-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel > > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/| > +-----------------------------------------------------------------+ > > > > > -- Cameron Shorter http://cameron.shorter.net From adoyle at eogeo.org Thu Sep 21 17:20:06 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] webmap-discuss archieves? In-Reply-To: <4512FC0B.8010307@gmail.com> References: <4512FC0B.8010307@gmail.com> Message-ID: On Sep 21, 2006, at 16:54, Cameron Shorter wrote: > Is this webmap-discuss email list being archeived? yes - https://mail.osgeo.org/servlets/SummarizeList?listName=webmap-discuss > > Auke, > If not, could we please organise for it to be archieved. > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > -- Allan Doyle +1.781.433.2695 adoyle@eogeo.org From pspencer at dmsolutions.ca Thu Sep 21 18:14:32 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: Strategic Direction In-Reply-To: <4512FDFD.5070809@gmail.com> References: <450F01B3.5010601@gmail.com> <20060921093952.GG15938@metacarta.com> <0D8F8888-2423-4849-9D9E-80CE0CA701C2@dmsolutions.ca> <4512FDFD.5070809@gmail.com> Message-ID: <06056B50-D950-4216-B62C-CBA909162FBC@dmsolutions.ca> Managed Templates are web pages in which the layout is managed by the toolkit ... MapBender and MapGuide both fall into this camp ... you don't edit an HTML file, you configure the application through a web interface (MapBender) or some other GUI (MapGuide). Unmanaged templates require the app developer to actually edit/modify the HTML page (both MapBuilder and Chameleon are in this camp). I'll see about a page on osgeo for this ... good idea ... Cheers Paul On 21-Sep-06, at 5:02 PM, Cameron Shorter wrote: > This thread has become more about WebMap.js and so I'm moving it to > the webmap list, (and will start a "What sucks about Mapbuilder" > thread for the mapbuilder list. > > Thanks all for filling me in, as I wasn't at FOSS4G I'm playing > catchup. > > Paul, I don't understand what your definition of Managed and > Unmanaged. Could you please expand. > > Paul, I like your ASCII art, we should put it into a graphic > somewhere to help users pick a suitable webmapping client. Maybe on > an OSGeo page titled "Picking a suitable Webmapping client". > > FYI: There is a cool ASCII art program at http://www.jave.de/ > > Paul Spencer wrote: >> I'd have to agree with Schuyler. Each project has a different >> underlying philosophy ... To help me understand it, I've divided >> them into four groups - two categories with two sub-categories. >> First category is how the template is done. Second is how the >> maps are created/used. >> Templating can be managed or unmanaged >> Maps can be client side (direct from OGC services) or server side >> (rendered by MapServer/MapGuide) >> The divisions are not precise, obviously! Here is my horrible >> attempt at ASCII art ... >> managed | unmanaged >> | >> mapbender | mapbuilder >> client | OpenLayers (2) >> | >> ----------- >> -----------------| WebMap.js |------------ >> ----------- >> | >> | chameleon >> server mapguide | ka-map (1) >> | >> | >> (1) ka-Map is actually a client side app and can do client-side >> direct from WMS but its not the primary mechanism and the default >> install requires a server side component. >> (2) OpenLayers can do server-side from ka-Map, but its not the >> primary mechanism >> Not sure where cartoweb fits in the picture, I don't know much >> about it. And I probably missed some ... not sure which. >> In my view of the world, then, the AJAX BOF was discussing >> something that could easily fit into the center of this >> diagram ... this is the proposed WebMap.js. >> So we end up with each project owning and promoting a particular >> space in my view of the AJAX web mapping world. I think there >> are benefits and drawbacks to each space and its excellent to be >> able to chose a different solution for any given client based on >> what they really need. >> Cheers >> Paul >> On 21-Sep-06, at 5:39 AM, Schuyler Erle wrote: >>> * On 18-Sep-2006 at 4:30PM EDT, Cameron Shorter said: >>> >>>> >>>> There are a number of AJAX Web Mapping clients and not all of >>>> them will >>>> thrive. In particular, OpenLayers is addressing the simple >>>> mapping use >>>> cases and is cutting into Mapbuilder's potential user base. We >>>> should >>>> set our development path toward merging with OpenLayers. >>> >>> >>> Well, I hope we're not cutting into each other's user bases, so much >>> as serving somewhat different use cases in the same general sphere. >>> >>> At the FOSS4G conference in Lausanne last week, we had a web mapping >>> client BoF session, in which it was agreed that the OpenLayers team >>> should try to split off a basic core for fetching map images/ >>> tiles and >>> displaying them in an HTML div. >>> >>> Our hope is that our fellow AJAX mapping projects will be able to >>> incorporate this map display library in their code, providing us all >>> with a common stable base on which to build better web mapping apps. >>> Provisionally, we've been calling this code "Webmap.js" (or >>> something >>> similar). >>> >>> In the meantime, we would appreciate any kind of direction that >>> Mapbuilder and the other AJAX mapping projects have to offer about >>> what the shape of this shared map display core should look like. Our >>> plan is to have a rough cut of the library available in the next >>> couple weeks. >>> >>> I think this is a very exciting opportunity for all of us to >>> collaborate, and I hope that we can make it work for everyone! >>> >>> SDE >>> >>> -------------------------------------------------------------------- >>> -- --- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance >>> to share your >>> opinions on IT & business topics through brief surveys -- and >>> earn cash >>> http://www.techsay.com/default.php? >>> page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> mapbuilder-devel mailing list >>> mapbuilder-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/| >> +-----------------------------------------------------------------+ > > > -- > Cameron Shorter > http://cameron.shorter.net +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Thu Sep 21 18:41:31 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: webmap.js project structure Message-ID: <4513151B.1050905@gmail.com> I appologise if I'm going over ground already covered at FOSS4G. I've got a couple of house keeping questions about webmap.js. Are we planning to set up webmap.js as a project? Eg: webmap.sourceforge.net or webmap.osgeo.org or similar. Are we planning to set up a mailing list? I suggest that this list should become the webmap.js list. Where is the Subversion repository going to live? Where is the issue tracker going to live? What about a wiki? Actually - I think Chris mentioned this already. Are we going to set up a seperate Project Management Committee or will webmap.js be part of OpenLayers? Are we going to aim toward a common, Javascript API, or set of API convensions that all the webmapping projects use? (This will make it much easier for users to graduate from one project to another and their user requirements change and will reduce the vendor lock in that users hate.) I haven't fully thought through the feasibility of this yet. Has someone drafted a Javascript API and design yet? What is the relationship between Map and Layers? How do you treat special cases like 2 maps on the same webpage (eg a locator map and main map)? -- Cameron Shorter http://cameron.shorter.net From crschmidt at metacarta.com Thu Sep 21 19:13:55 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] webmap.js project structure In-Reply-To: <4513151B.1050905@gmail.com> References: <4513151B.1050905@gmail.com> Message-ID: <20060921231355.GA31564@metacarta.com> On Fri, Sep 22, 2006 at 08:41:31AM +1000, Cameron Shorter wrote: > I appologise if I'm going over ground already covered at FOSS4G. I've > got a couple of house keeping questions about webmap.js. > > Are we planning to set up webmap.js as a project? Eg: > webmap.sourceforge.net or webmap.osgeo.org or similar. webmap.osgeo.org requires being accepted by OSGeo in some way, as far as I understand it. At this point, WebMap.js has no official relationship with OSGeo... not the least because it doesn't exist yet. I don't personally like Sourceforge's tools -- I don't see that the infrastructure can't be provided by just about anyone with a webserver (see OpenLayers). > Are we planning to set up a mailing list? I suggest that this list > should become the webmap.js list. Agreed. > Where is the Subversion repository going to live? > Where is the issue tracker going to live? > What about a wiki? Actually - I think Chris mentioned this already. None of these exist yet. (Again, the project doesn't really exist yet.) > Are we going to set up a seperate Project Management Committee or will > webmap.js be part of OpenLayers? There seems to be more traction behind a community effort for Webmap.js than OpenLayers as a whole, and decisions for WebMap.js will affect a larger userbase. > Are we going to aim toward a common, Javascript API, or set of API > convensions that all the webmapping projects use? > (This will make it much easier for users to graduate from one project to > another and their user requirements change and will reduce the vendor > lock in that users hate.) The former was what we discussed. > Has someone drafted a Javascript API and design yet? Nope. Again, time is the blocker here. This will get done as soon as I get some time to do it -- probably in about two weeks. > What is the relationship between Map and Layers? How do you treat > special cases like 2 maps on the same webpage (eg a locator map and main > map)? Two maps on a single page isn't a special case. :) Linking a locator map to a main map should be done via event handling, which is one of the things that needs to be built into WebMap.js. The general seperation between layers and the map is probably going to match the one in OpenLayers currently -- a Map contains global information, such as projection, extents, etc., which the layer can ask for, and the layer then draws itself within the HTML elements controlled by the Map. Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Thu Sep 21 20:57:46 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] webmap.js project structure In-Reply-To: <4513151B.1050905@gmail.com> References: <4513151B.1050905@gmail.com> Message-ID: I realize Chris has also posted a response to this, but here's my take anyway (since I was already writing it) ... On 21-Sep-06, at 6:41 PM, Cameron Shorter wrote: > I appologise if I'm going over ground already covered at FOSS4G. > I've got a couple of house keeping questions about webmap.js. > > Are we planning to set up webmap.js as a project? Eg: > webmap.sourceforge.net or webmap.osgeo.org or similar. OpenLayers has applied for incubation in OSGeo. As far as I am concerned, webmap.js is going to be a build target of OpenLayers that includes the core Map and Layer components (any any utilities that they use). It will take very little work to produce WebMap.js, except for: * remove the prototype.js dependency so that any project can easily incorporate WebMap.js without having to change their coding style (prototype breaks for(var i in a) syntax for instance). * refactor the utility code so that only WebMap.js-related stuff is included in WebMap.js OpenLayers already has a good build system and the amount of effort to do the above should be relatively trivial due to the way the code has been written. The default distribution of WebMap.js will include all the Layer types that OpenLayers supports, but it will be possible to build a version that only includes the Layer types that a specific project is interested in. > > Are we planning to set up a mailing list? I suggest that this list > should become the webmap.js list. I think this should be part of the OpenLayers mailing list, but that assumes my hidden agenda/ulterior motive ... which is to make more of OpenLayers part of WebMap.js ... and call it OpenLayers :) Seriously, though, OpenLayers is currently a core API and a growing collection of UI widgets. We are currently talking about the core API, but my hope is that when(if) the community has adopted WebMap.js, the Control architecture of OpenLayers will be used by all the projects as well. This leaves a series of web pages that demonstrate how to use the core and UI widgets ... perfect world! > > Where is the Subversion repository going to live? OSGeo, should it be accepted into incubation. Otherwise, it should be left where it is (openlayers.org) > > Where is the issue tracker going to live? same > > What about a wiki? Actually - I think Chris mentioned this already. same ... wiki already exists > > Are we going to set up a seperate Project Management Committee or > will webmap.js be part of OpenLayers? Part of OpenLayers. I would suggest that a sub-committee of OpenLayers be formed that includes a representative from each of the major projects that intends to build on WebMap.js (MapBuilder, MapBender, Chameleon, ka-Map, MapGuide, ...). This subcommittee would report to the OpenLayers PSC and, if my ultimate goals are realised, would be merged with it. > > Are we going to aim toward a common, Javascript API, or set of API > convensions that all the webmapping projects use? > (This will make it much easier for users to graduate from one > project to another and their user requirements change and will > reduce the vendor lock in that users hate.) > I haven't fully thought through the feasibility of this yet. We have agreed to tackle part one, as it is more achievable and less contentious. The goal is to expose low level events (mouse, key etc) from the core, making it relatively simple to hook up existing controls in each project to WebMap.js. However, I believe that most of us will be tempted to start building on the OpenLayers Control API as well, and it will become the defacto standard through use ... this is trickier, though, as each project will require some changes to fit into its model I think. > > Has someone drafted a Javascript API and design yet? Apparently Chris has to sleep sometimes, so its not done yet :) > > What is the relationship between Map and Layers? How do you treat > special cases like 2 maps on the same webpage (eg a locator map and > main map)? I haven't checked, but I assume that OpenLayers can produce two or more maps on the same page. In fact, I know it can be done because Tim Schaub posted a cool reference map implementation using two OpenLayers Map objects :) Cheers Paul > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Thu Sep 21 21:45:09 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Re: Strategic Direction In-Reply-To: <4512FDFD.5070809@gmail.com> References: <450F01B3.5010601@gmail.com> <20060921093952.GG15938@metacarta.com> <0D8F8888-2423-4849-9D9E-80CE0CA701C2@dmsolutions.ca> <4512FDFD.5070809@gmail.com> Message-ID: http://wiki.osgeo.org/index.php/Choosing_a_Web_Mapping_Platform Please feel free to edit to your hearts content ... alternate views of the universe would also be welcome, as well as any changes in wording, grammer, content etc. Any projects missing from the matrix need to add themselves. All projects should come up with a blurb about the project and its main benefits/drawbacks that would help a potential new user (or even an existing one) select an appropriate project for a new application Cheers Paul On 21-Sep-06, at 5:02 PM, Cameron Shorter wrote: > This thread has become more about WebMap.js and so I'm moving it to > the webmap list, (and will start a "What sucks about Mapbuilder" > thread for the mapbuilder list. > > Thanks all for filling me in, as I wasn't at FOSS4G I'm playing > catchup. > > Paul, I don't understand what your definition of Managed and > Unmanaged. Could you please expand. > > Paul, I like your ASCII art, we should put it into a graphic > somewhere to help users pick a suitable webmapping client. Maybe on > an OSGeo page titled "Picking a suitable Webmapping client". > > FYI: There is a cool ASCII art program at http://www.jave.de/ > > Paul Spencer wrote: >> I'd have to agree with Schuyler. Each project has a different >> underlying philosophy ... To help me understand it, I've divided >> them into four groups - two categories with two sub-categories. >> First category is how the template is done. Second is how the >> maps are created/used. >> Templating can be managed or unmanaged >> Maps can be client side (direct from OGC services) or server side >> (rendered by MapServer/MapGuide) >> The divisions are not precise, obviously! Here is my horrible >> attempt at ASCII art ... >> managed | unmanaged >> | >> mapbender | mapbuilder >> client | OpenLayers (2) >> | >> ----------- >> -----------------| WebMap.js |------------ >> ----------- >> | >> | chameleon >> server mapguide | ka-map (1) >> | >> | >> (1) ka-Map is actually a client side app and can do client-side >> direct from WMS but its not the primary mechanism and the default >> install requires a server side component. >> (2) OpenLayers can do server-side from ka-Map, but its not the >> primary mechanism >> Not sure where cartoweb fits in the picture, I don't know much >> about it. And I probably missed some ... not sure which. >> In my view of the world, then, the AJAX BOF was discussing >> something that could easily fit into the center of this >> diagram ... this is the proposed WebMap.js. >> So we end up with each project owning and promoting a particular >> space in my view of the AJAX web mapping world. I think there >> are benefits and drawbacks to each space and its excellent to be >> able to chose a different solution for any given client based on >> what they really need. >> Cheers >> Paul >> On 21-Sep-06, at 5:39 AM, Schuyler Erle wrote: >>> * On 18-Sep-2006 at 4:30PM EDT, Cameron Shorter said: >>> >>>> >>>> There are a number of AJAX Web Mapping clients and not all of >>>> them will >>>> thrive. In particular, OpenLayers is addressing the simple >>>> mapping use >>>> cases and is cutting into Mapbuilder's potential user base. We >>>> should >>>> set our development path toward merging with OpenLayers. >>> >>> >>> Well, I hope we're not cutting into each other's user bases, so much >>> as serving somewhat different use cases in the same general sphere. >>> >>> At the FOSS4G conference in Lausanne last week, we had a web mapping >>> client BoF session, in which it was agreed that the OpenLayers team >>> should try to split off a basic core for fetching map images/ >>> tiles and >>> displaying them in an HTML div. >>> >>> Our hope is that our fellow AJAX mapping projects will be able to >>> incorporate this map display library in their code, providing us all >>> with a common stable base on which to build better web mapping apps. >>> Provisionally, we've been calling this code "Webmap.js" (or >>> something >>> similar). >>> >>> In the meantime, we would appreciate any kind of direction that >>> Mapbuilder and the other AJAX mapping projects have to offer about >>> what the shape of this shared map display core should look like. Our >>> plan is to have a rough cut of the library available in the next >>> couple weeks. >>> >>> I think this is a very exciting opportunity for all of us to >>> collaborate, and I hope that we can make it work for everyone! >>> >>> SDE >>> >>> -------------------------------------------------------------------- >>> -- --- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance >>> to share your >>> opinions on IT & business topics through brief surveys -- and >>> earn cash >>> http://www.techsay.com/default.php? >>> page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> mapbuilder-devel mailing list >>> mapbuilder-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/| >> +-----------------------------------------------------------------+ > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From noreply at geocartic.com Fri Sep 22 15:21:17 2006 From: noreply at geocartic.com (Tim Schaub) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] WMS Requests: Rounding BBOX In-Reply-To: <20060921202038.GB31224@metacarta.com> Message-ID: <001c01c6de7c$48448980$15fea8c0@meridian> > > Is it trivial to find out the precision of a number in > various languages? I don't know how to do it off the top of > my head in Javascript, but maybe I'm being a bit naive. > I'm talking about the decimal precision (as opposed to significant figures) of an advertised (in GetCapabilities) resolution. If a person manually configures a client application, then they will be reading the GetCapabilities response and figuring out the appropriate precision. If you've got a client application that can parse GetCapabilities responses and pull out the resolution as a string, then it would do something like: resolution.length - resolution.indexOf(decimalSeparator) - 1 to figure out the decimal precision. Again, this implies that servers are responsible for advertising resolutions and intentionally specifying decimal precision (1.00 is different from 1.0). > Using precision of resolution as advertised by a server seems > to make sense to me. Cool, me too. Tim From claude.philipona at camptocamp.com Fri Sep 22 15:59:06 2006 From: claude.philipona at camptocamp.com (Claude Philipona) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Re: Strategic Direction Message-ID: <4514408A.1080002@camptocamp.com> I added CartoWeb to the matrix on the Wiki. We are indeed very interested to be active in this cross project, even though we could not get involved as much as we wanted too considering the time we put in foss4g2006 organization. A few month ago we made a comparison analysis of some js library used for Webmapping, mainly on a poitn aof view for advanced editing. We will translate the matrix to english and post it to the group. It might help future thinking. we will try very soon to integrate OpenLayers into CartoWeb to see how far we can go and major problems. On of the particularity of CartoWeb is that it offers extensible server-side treatments for advanced features, which would not be possible with pure OGS services. One of our concern is that the future unified js API's offers robust extensible OO API not only for basic functions (zoom, pan,..) but also for advanced features such as polygon editing with snappping, and that it can be extended to interact with advanced server-side treatment. So we are of course interested in contributing to specification of this unified project. Claude From pspencer at dmsolutions.ca Sat Sep 23 15:21:02 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: interesting read on html vs xhtml Message-ID: <36A4303D-2E79-4F62-9E2B-861C0FAAD683@dmsolutions.ca> I don't normally spam lists with links like this, but I found this a very useful document to explain the difference between XML, XHTML and HTML and what browsers do with them. Not at all what I expected, it turns out! http://webkit.org/blog/?p=68 Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Sat Sep 23 16:19:33 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Re: Strategic Direction In-Reply-To: <4514408A.1080002@camptocamp.com> References: <4514408A.1080002@camptocamp.com> Message-ID: <4047331A-E7D6-4DE5-8B7F-A857842E4F06@dmsolutions.ca> Thanks Claude. I am, in general, doing things the same way as you are ... I feel that there is benefit to be had by some server-side involvement, hence Chameleon is what it is :) I can't speak for the future evolution of the unified web-mapping API (umapi anyone?) but I think, in general, that the tools are designed to gather user input and advertise this through an event mechanism. This means that a set of basic rendering functions would just draw on the screen and advertise that drawing is complete. Depending on the toolkit using the API, this could be interpreted as a POLYGON for a WFS filter or sent to a server side script for some sort of intelligent query plus extraction function (or data insertion). I've got a general need for feature creation and editing and am building a generic architecture for OpenLayers that would hopefully provide decent cross-platform support for the basic primitive operations like drawing. There is also some work being done in MapBuilder on an SVG/VML implementation of something similar that I haven't seen but have heard about. I would hope that over time, these implementations come closer together, or merge, around the OpenLayers API ... Cheers Paul On 22-Sep-06, at 3:59 PM, Claude Philipona wrote: > I added CartoWeb to the matrix on the Wiki. We are indeed very > interested to be active in this cross project, even though we could > not get involved as much as we wanted too considering the time we > put in foss4g2006 organization. > > A few month ago we made a comparison analysis of some js library > used for Webmapping, mainly on a poitn aof view for advanced > editing. We will translate the matrix to english and post it to the > group. It might help future thinking. > > we will try very soon to integrate OpenLayers into CartoWeb to see > how far we can go and major problems. On of the particularity of > CartoWeb is that it offers extensible server-side treatments for > advanced features, which would not be possible with pure OGS services. > > One of our concern is that the future unified js API's offers > robust extensible OO API not only for basic functions (zoom, > pan,..) but also for advanced features such as polygon editing with > snappping, and that it can be extended to interact with advanced > server-side treatment. > > So we are of course interested in contributing to specification of > this unified project. > > Claude > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Sun Sep 24 06:22:16 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: webmap-discuss archieves? In-Reply-To: <1F32A3238CA6734CA58915EEC60D632B2EE274@SP-EXCHMBC.sp.corp.collab.net> References: <1F32A3238CA6734CA58915EEC60D632B2EE274@SP-EXCHMBC.sp.corp.collab.net> Message-ID: <45165C58.3050505@gmail.com> Any chance the email footer could point to the archieve/unsubscribe web page? Auke Jilderda wrote: > Hey Cameron, > > yes, the list is archived at [1]. > > > Auke > > 1. > https://mail.osgeo.org/servlets/SummarizeList?listName=webmap-discuss > > On 21 September 2006 22:55, Cameron Shorter wrote: > >>Is this webmap-discuss email list being archeived? >> >>Auke, >>If not, could we please organise for it to be archieved. >> >>-- >>Cameron Shorter >>http://cameron.shorter.net > > -- Cameron Shorter http://cameron.shorter.net From richard.greenwood at gmail.com Sun Sep 24 09:58:50 2006 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri Dec 22 15:49:42 2006 Subject: Choosing a Web Mapping Platform Wiki Message-ID: I like the "Choosing a Web Mapping Platform" Wiki that Paul Spencer started at: http://wiki.osgeo.org/index.php/Choosing_a_Web_Mapping_Platform A few questions: 1. Is the focus of the Wiki really a Platform, or a Client? It seems like the focus is on clients and a separate page might be appropriate for servers. Where platform = server + client. 2. How about an expanded matrix detailing more functionality and requirements like: - templates (managed / unmanaged) (this is in Paul's matrix) - consumes (OGC, proprietary, Google, etc.) (Client/Server in Paul's matrix) - server side requirements to support the client - legend / layer selector - measure and area tools - digitizing - tiled "slippy" map panning - JavaScript library(s) - other important stuff Do other people see value in this level of detail? Would people from the various projects be willing to provide details for their projects? Can an HTML table be put into a Wiki page, or are we limited to ASCII art? Rich -- Richard Greenwood richard.greenwood@gmail.com www.greenwoodmap.com From pspencer at dmsolutions.ca Sun Sep 24 10:40:44 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Choosing a Web Mapping Platform Wiki In-Reply-To: References: Message-ID: Rich, I struggled with wording and have no problems changing it. Perhaps we need to develop a dictionary/glossary for web-mapping terms so that everything we talk about has some static reference point that (hopefully) we agree on. For instance, client can mean: * the application produced by a developer using the toolkit (client - server) * browser technology * person (developer) choosing which toolkit to use * end user of the application that the person (developer) is going to make * person (company) hiring person (developer) to build an application for their clients Expanding the matrix is a bit problematic since we are limited to two dimensions. I was hoping that it would be somehow really simple. Perhaps the whole thing would be better presented as a flow chart and a series of binary questions that direct a potential developer. In any case, I was hoping that each project would develop a project profile that highlighted some of the benefits, limitations and use- cases for their projects and that profile would include some of the detail that you are talking about here. Interested in feedback ... Cheers Paul On 24-Sep-06, at 9:58 AM, Richard Greenwood wrote: > I like the "Choosing a Web Mapping Platform" Wiki that Paul Spencer > started at: > > http://wiki.osgeo.org/index.php/Choosing_a_Web_Mapping_Platform > > A few questions: > > 1. Is the focus of the Wiki really a Platform, or a Client? It seems > like the focus is on clients and a separate page might be appropriate > for servers. Where platform = server + client. > > 2. How about an expanded matrix detailing more functionality and > requirements like: > - templates (managed / unmanaged) (this is in Paul's matrix) > - consumes (OGC, proprietary, Google, etc.) (Client/Server in > Paul's matrix) > - server side requirements to support the client > - legend / layer selector > - measure and area tools > - digitizing > - tiled "slippy" map panning > - JavaScript library(s) > - other important stuff > Do other people see value in this level of detail? > Would people from the various projects be willing to provide details > for their projects? > Can an HTML table be put into a Wiki page, or are we limited to > ASCII art? > > Rich > > -- > Richard Greenwood > richard.greenwood@gmail.com > www.greenwoodmap.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/| +-----------------------------------------------------------------+ From richard.greenwood at gmail.com Sun Sep 24 14:49:18 2006 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Choosing a Web Mapping Platform Wiki In-Reply-To: References: Message-ID: On 9/24/06, Paul Spencer wrote: > Rich, > > I struggled with wording and have no problems changing it. Perhaps > we need to develop a dictionary/glossary for web-mapping terms so > that everything we talk about has some static reference point that > (hopefully) we agree on. > > For instance, client can mean: > > * the application produced by a developer using the toolkit (client - > server) > * browser technology > * person (developer) choosing which toolkit to use > * end user of the application that the person (developer) is going to > make > * person (company) hiring person (developer) to build an application > for their clients Yep, "client" is a pretty broad term. I took the liberty of adding: "This page focuses primarily on Open Source browser-based clients (not the servers)." > Expanding the matrix is a bit problematic since we are limited to two > dimensions. I was hoping that it would be somehow really simple. > Perhaps the whole thing would be better presented as a flow chart and > a series of binary questions that direct a potential developer. I think a flow chart would be really hard because different project requirements are going to drive your priorities. For example, I have a project right now where the client is requiring that I use ArcIMS server, so a WMS client is my highest priority, and I would want it as the first junction in a flow chart. However somebody else may require digitizing, so they would want to start their flow with that. I'm still keen on a grid with foot notes and hyperlinks to add more dimensionality, but I'd like to hear comments from others. Rich -- Richard Greenwood richard.greenwood@gmail.com www.greenwoodmap.com From cameron.shorter at gmail.com Sun Sep 24 16:09:06 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Choosing a Web Mapping Platform Wiki In-Reply-To: References: Message-ID: <4516E5E2.6@gmail.com> Paul, Excellent start here, and next time I get a spare moment, I'd like to add to it. The target audience for this page should be web developers who know little or nothing about web mapping. So we should have a background section describing key issues to consider when designing a web application. Ie: * Bandwidth associated with sending vector graphics to the client. * Benefits of AJAX. * Benefits of tiling and caching. * Speed of rendering in browser and server. * Size of JS sent to client and relate that to time. * ... I agree with Richard that we need a table showing which applications provide which features. This should include size of JS downloaded for each application. Users will want to know that the application they fix is going to be supported and flexable in the future. So we should discuss WebMap.js, how it is being used by applications, whether is will be possible to migrate from one application to another in the future if conditions change. Paul Ramsey wrote an excellent "State of Open Source GIS" paper, which includes a section describing how to assess Open Source projects. http://www.refractions.net/white_papers/oss_briefing/2006-06-OSS-Briefing.pdf We should answer these questions for each project: * Is the project well document? * Is the development team transparent? * Is the software modular? * How wide is the development community? * how wide is the user community? We should have a section for each application which starts: Mapbuilder is .... You should choose Mapbuilder if you want ... Mapbuilder's future direction is ... Paul Spencer wrote: > Rich, > > I struggled with wording and have no problems changing it. Perhaps we > need to develop a dictionary/glossary for web-mapping terms so that > everything we talk about has some static reference point that > (hopefully) we agree on. > > For instance, client can mean: > > * the application produced by a developer using the toolkit (client - > server) > * browser technology > * person (developer) choosing which toolkit to use > * end user of the application that the person (developer) is going to make > * person (company) hiring person (developer) to build an application > for their clients > > Expanding the matrix is a bit problematic since we are limited to two > dimensions. I was hoping that it would be somehow really simple. > Perhaps the whole thing would be better presented as a flow chart and a > series of binary questions that direct a potential developer. > > In any case, I was hoping that each project would develop a project > profile that highlighted some of the benefits, limitations and use- > cases for their projects and that profile would include some of the > detail that you are talking about here. > > Interested in feedback ... > > Cheers > > Paul > > On 24-Sep-06, at 9:58 AM, Richard Greenwood wrote: > >> I like the "Choosing a Web Mapping Platform" Wiki that Paul Spencer >> started at: >> >> http://wiki.osgeo.org/index.php/Choosing_a_Web_Mapping_Platform >> >> A few questions: >> >> 1. Is the focus of the Wiki really a Platform, or a Client? It seems >> like the focus is on clients and a separate page might be appropriate >> for servers. Where platform = server + client. >> >> 2. How about an expanded matrix detailing more functionality and >> requirements like: >> - templates (managed / unmanaged) (this is in Paul's matrix) >> - consumes (OGC, proprietary, Google, etc.) (Client/Server in Paul's >> matrix) >> - server side requirements to support the client >> - legend / layer selector >> - measure and area tools >> - digitizing >> - tiled "slippy" map panning >> - JavaScript library(s) >> - other important stuff >> Do other people see value in this level of detail? >> Would people from the various projects be willing to provide details >> for their projects? >> Can an HTML table be put into a Wiki page, or are we limited to ASCII >> art? >> >> Rich >> >> -- >> Richard Greenwood >> richard.greenwood@gmail.com >> www.greenwoodmap.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >> For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/| > +-----------------------------------------------------------------+ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > -- Cameron Shorter http://cameron.shorter.net From usuari79 at moviments.net Tue Sep 26 07:04:52 2006 From: usuari79 at moviments.net (mr) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Choosing a Web Mapping Platform Wiki In-Reply-To: <4516E5E2.6@gmail.com> References: <4516E5E2.6@gmail.com> Message-ID: <2051.88.0.208.4.1159268692.squirrel@secure.moviments.net> As the intended audience are beginers, needs a link to peculiar mapping terminology wikipage which maybe it is not yet available. I don't know where if ther's.. + a features comparision table with 1-5, 1-10, checkbox.. I like the 2 main categories and 2 subcategories, perhaps some graphic improvement to give it a more "tree looking".. I would delete(i won't do it myself, sorry) "If you are new to this world ... or perhaps have a different type of project that won't work with the platform that you are familiar with," from "There are a great many web mapping platforms available to someone starting a new project. If you are new to this world ... or perhaps have a different type of project that won't work with the platform that you are familiar with, this page should help you decide which platform is right for your project." go on! > Paul, > Excellent start here, and next time I get a spare moment, I'd like to > add to it. > > The target audience for this page should be web developers who know > little or nothing about web mapping. > > So we should have a background section describing key issues to consider > when designing a web application. Ie: > * Bandwidth associated with sending vector graphics to the client. > * Benefits of AJAX. > * Benefits of tiling and caching. > * Speed of rendering in browser and server. > * Size of JS sent to client and relate that to time. > * ... > > I agree with Richard that we need a table showing which applications > provide which features. This should include size of JS downloaded for > each application. > > Users will want to know that the application they fix is going to be > supported and flexable in the future. So we should discuss WebMap.js, > how it is being used by applications, whether is will be possible to > migrate from one application to another in the future if conditions > change. > > Paul Ramsey wrote an excellent "State of Open Source GIS" paper, which > includes a section describing how to assess Open Source projects. > http://www.refractions.net/white_papers/oss_briefing/2006-06-OSS-Briefing.pdf > We should answer these questions for each project: > * Is the project well document? > * Is the development team transparent? > * Is the software modular? > * How wide is the development community? > * how wide is the user community? > > We should have a section for each application which starts: > Mapbuilder is .... > You should choose Mapbuilder if you want ... > Mapbuilder's future direction is ... > > Paul Spencer wrote: >> Rich, >> >> I struggled with wording and have no problems changing it. Perhaps we >> need to develop a dictionary/glossary for web-mapping terms so that >> everything we talk about has some static reference point that >> (hopefully) we agree on. >> >> For instance, client can mean: >> >> * the application produced by a developer using the toolkit (client - >> server) >> * browser technology >> * person (developer) choosing which toolkit to use >> * end user of the application that the person (developer) is going to >> make >> * person (company) hiring person (developer) to build an application >> for their clients >> >> Expanding the matrix is a bit problematic since we are limited to two >> dimensions. I was hoping that it would be somehow really simple. >> Perhaps the whole thing would be better presented as a flow chart and a >> series of binary questions that direct a potential developer. >> >> In any case, I was hoping that each project would develop a project >> profile that highlighted some of the benefits, limitations and use- >> cases for their projects and that profile would include some of the >> detail that you are talking about here. >> >> Interested in feedback ... >> >> Cheers >> >> Paul >> >> On 24-Sep-06, at 9:58 AM, Richard Greenwood wrote: >> >>> I like the "Choosing a Web Mapping Platform" Wiki that Paul Spencer >>> started at: >>> >>> http://wiki.osgeo.org/index.php/Choosing_a_Web_Mapping_Platform >>> >>> A few questions: >>> >>> 1. Is the focus of the Wiki really a Platform, or a Client? It seems >>> like the focus is on clients and a separate page might be appropriate >>> for servers. Where platform = server + client. >>> >>> 2. How about an expanded matrix detailing more functionality and >>> requirements like: >>> - templates (managed / unmanaged) (this is in Paul's matrix) >>> - consumes (OGC, proprietary, Google, etc.) (Client/Server in Paul's >>> matrix) >>> - server side requirements to support the client >>> - legend / layer selector >>> - measure and area tools >>> - digitizing >>> - tiled "slippy" map panning >>> - JavaScript library(s) >>> - other important stuff >>> Do other people see value in this level of detail? >>> Would people from the various projects be willing to provide details >>> for their projects? >>> Can an HTML table be put into a Wiki page, or are we limited to ASCII >>> art? >>> >>> Rich >>> >>> -- >>> Richard Greenwood >>> richard.greenwood@gmail.com >>> www.greenwoodmap.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >>> For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >>> >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/| >> +-----------------------------------------------------------------+ >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >> For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >> >> > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > From cameron.shorter at gmail.com Wed Sep 27 07:04:01 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: Google Map projection and EPSG codes In-Reply-To: <200609262038.k8QKclhB031617@tux.cubewerx.com> References: <200609262038.k8QKclhB031617@tux.cubewerx.com> Message-ID: <451A5AA1.80401@gmail.com> One of the commonly requested features for a webmapping client is to render WMS layers over Google Map basemaps. Unfortunately, this is tricky to implement because the projection used by Google Maps doesn't have a corresponding EPSG code which means that the projection cannot be selected using a standard WMS query. John Deck describes the problem, and a hack to get around it at: http://johndeck.blogspot.com/2005/09/overlaying-mercator-projected-wms.html John defines his own EPSG code in a mapserv config file. Questions: ========== 1. geoserver-devel, Is there a similar hack that can be used in Geoserver? 2. webmap-discuss, has anyone worked out a "less hacky" solution? 3. What is the process for defining a new EPSG code? Is this something we can make happen? Proposal: ========= webmap-discuss, geoserver-devel, mapserver people, If we cannot force a new EPSG code to be officially created, I suggest that all the Open Source projects define a de-facto EPSG code for Google Maps which Geoserv, Mapserv and the various webmapping clients all support. Craig Bruce wrote: > "Kralidis,Tom [Burlington]" wrote: > > >>Question: has there been any definition of an EPSG code as applied to >>the way Google Maps displays their data (I'm not exactly sure what the >>projection params, but I did find one def from the postgis-users mailing >>list [see: >>http://postgis.refractions.net/pipermail/postgis-users/2005-November/009 >>920.html])? >> >>I'm not sure if CubeWerx has defined one in the 42xxx series of >>'defacto' EPSG codes, or whether it's defined already, for that matter. > > > The closest match we have found is a simple Mercator projection. One is > defined in the OGC 41xxx space as: > > EPSG:41001: > > PROJCS["WGS84 / Simple Mercator", > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS_1984",6378137,298.257223563]], > PRIMEM["Greenwich",0], > UNIT["Decimal_Degree",0.0174532925199433]], > PROJECTION["Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",0], > PARAMETER["false_easting",0], > PARAMETER["false_northing",0], > UNIT["Meter",1]] > > This doesn't appear to be an exact match, however, as the mismatch grows > from the equator from zero to a few kilometers. There might be a scale > factor/secant involved. > > --------------------------+----------------------+-------------------------- > Dr. Craig S. Bruce | Ph 819-771-8303 x205 | CubeWerx Inc. > Senior Software Developer | Fax 819-771-8388 | Gatineau, Qu?bec, Canada > csbruce@cubewerx.com | http://csbruce.com/ | http://www.cubewerx.com/ > --------------------------+----------------------+-------------------------- > "Q: How many of your previous romantic relationships were failures? > A: All of them. > Q: So, what are the chances for your present relationship? > A: Well, let's check the statistics..." > -- Cameron Shorter http://cameron.shorter.net