Andreas Hocevar wrote: > Cameron, > > On Nov 14, 2007 10:32 PM, Cameron Shorter <[EMAIL PROTECTED]> wrote: > >> Andreas, Steven, I believe quite strongly that the OWS Context document >> should allow Google/Yahoo map layers to be included. >> > > Ok, but the question is *how*. > > >> 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. >> > > Agreed. But to enable that, you need information that cannot be stored > in a context doc, because it is server-specific: API keys. In the case > of Mapbuilder, those would still have to be stored in the config. > Yes, I agree. API keys should be stored as a config parameter for MapPaneOL.
> >> Like it or not, the commercial providers have great maps and in the near >> term, users will want Google Maps as base layers. >> > > As you said, *base layers*. This means that those maps cannot be > included like regular maps using a <Layer>, because the base layer > always has to be on the bottom of the stack. Furthermore, properties > are quite different. I would think a context document containing > commercial base layers would have to look something like this: > > <OWSContext> > <General> > ... > </General> > > <ResourceList> > <BaseLayer provider="Google" map="HYBRID"> > <Name>...</Name> > <Title>...</Title> > </BaseLayer> > <Layer ...> > ... > </Layer ...> > .... > </ResourceList> > </OWSContext> > That would be one option, but I'd prefer to keep the Context simple, and only have one layer tag. A similar related use case is being able to display the same layer as either a WMS or WFS layer. (WMS when zoomed out, WFS when zoomed in). So you would have something like: <Layer id="1"> <Name/> <Title/> <ServiceType default="true" type="WFS" url="http://geoserver.org/wfs"/> <ServiceType type="WMS" url="http://geoserver.org/wms"/> <ServiceType type="TitleBaseLayer" url="http://maps.google.com"/> </Layer> > > Just an idea. But there's more that can not be described in a OWS > Context document. Because as soon as you use a commercial map, you > have to use Spherical Mercator projection (EPSG:900913). So the > application would have to ignore SRS specifications of the other > layers. Having said that, this might be one more thing to change in > OWS Context, because it does not make sense: SRS should be a map > property, not a layer property. Or who wants a map with layers that do > not align? > Having layers with different SRS doesn't make sense in a browser, but would be ok in a heavy client which can do transformation on the fly. > >> 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. >> > > The latter would be better. > > Anyway, what we need now is a solution that will help us bring > commercial layer support into 1.5. So either we use the approach to > define the baselayer in the config, or we invent an OWS Context > derivate that might never become a standard. I'm undecided which way > to go, but I would not specify commercial layers like regular layers. > The reason for that, as described in my previous posting, is that > layer controls should not change the position of the base layer in the > stack of layers. > My priority is: 1. Try to use standards. 2. If standards are not good enough, then extend them, and encourage the standards bodies to follow us. Mapbuilder is leading the way with the OWS Context spec and many of the recent OWS Context updates started from Mapbuilder recommendations. > Regards, > Andreas. > > Having said all this, I'm not coming forth with the time to code it, and agree that getting Google support into 1.5 is highly desirable. And I'll back you getting it in, however that happens. -- 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
