Andreas, Steven, I believe quite strongly that the OWS Context document should allow Google/Yahoo map layers to be included.
The aim of OWS Context is to pass a map view from one application to another (think UDig) and for those views to look the same. Like it or not, the commercial providers have great maps and in the near term, users will want Google Maps as base layers. So if we want to inter-operate in a practical way with UDig and others by passing an OWS Context round, then we need to allow Google/Yahoo type layers to be included in a Context document. I believe that we will be able to change the OWS Context spec to accommodate commercial map layers, be it by extension or by getting the providers to become standards compliant. Steven M. Ottens wrote: > Hi Andreas, > > Thanks for your comments > > On Nov 14, 2007, at 6:38 PM, Andreas Hocevar wrote: > > >> Hi Steven, >> >> On Nov 14, 2007 12:26 PM, Steven M. Ottens >> <[EMAIL PROTECTED]> wrote: >> >>> I restored google-spherical support for MapPaneOL. I discovered >>> that it >>> is impossible to have two baselayers or to have google as a non >>> baselayer. So I opted to destroy the baseLayer in the case there's a >>> google layer. >>> Could you please review it and comment if this is a proper approach. >>> >> Ok, some comments: >> >> I think destroying the baselayer is not an option. But I have a >> completely different idea, which might make things simpler and be more >> standards compliant, because the context doc will not be mis-used. >> > > Obviously the baselayer as principle doesn't get destroyed, only the > empty WMS baselayer is replaced by a google baselayer. > >> See [1]: Therefore, it makes sense to consider a yahoo layer or a >> google layer to be at the same level as a WMS Context in your saved >> file." (which would be the config in the case of Mapbuilder). >> > > Hm, this means that the original idea of having everything in > OWSContext is not followed anymore. I'm not a big fan of having > 'mapserver' related information in the config file, we have a context > doc for that. On the other hand you are right that using google as > layer type does create invalid OWSContext docs. Or at least if google > is not recognised as layer type in OWSContext, I don't know that for > sure. > > >> Google Maps is not part of the OWS Context specification. Shouldn't we >> treat a Google layer exactly like the empty baselayer? This means that >> it would not be added using a context document, but using a config >> property of MapPaneOL. And it would not be part of any layer control >> tool. Which makes sense, because Google is a typical baselayer and >> should always be on the bottom of the layer stack and on. >> > > That is true, google, yahoo, MS and all the other proprietary map > providers are typically enforcing their own tilescheme and it's > inflexible so it's hard if not impossible to combine different > proprietary maps. So having them as baselayer only, as is the > original design of OL makes sense. > >> The same is true for the other commercial map providers (MS, Yahoo, >> MM,...). They also use EPSG:9009123. >> >> So the approach would be to add a new config property for >> MapPaneOL, e.g. >> <baselayer>google-hybrid</baselayer> >> >> Layer types would be google-hybrid, google-map, google-satellite and >> things like that. >> > > k > >> If no baselayer property is given, the empty baselayer will be used. >> If there is a baselayer property set, the according layer will be set >> as the baselayer, overriding projections of all layers in the context >> document to EPSG:900913. This has to be done, because otherwise things >> will just not work. >> > > If no baselayer is set the projection etc is taken from the first > layer it encounters? > >> Does that sound like a reasonable approach? >> >> > It sounds like a reasonable approach, it does mean that we've to > rewrite quite a bit of the AddLayer routine, but it shouldn't be too > hard. > > I'll try it tomorrow, unless you beat me to it :) > > Regards, > Steven > > >> Regards, >> Andreas. >> >> [1] http://lists.refractions.net/pipermail/udig-devel/2006-March/ >> 004374.html >> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > mapbuilder-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel > > -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Solutions http://www.lisasoft.com/LISAsoft/SupportedProducts.html ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
