Steven, Your suggestions work for me. Steven M. Ottens wrote: > Cameron Shorter wrote: >> Andreas Hocevar wrote: >>> Cameron, >>> >>> On Nov 14, 2007 10:32 PM, Cameron Shorter >>> <[EMAIL PROTECTED]> wrote: >> Yes, I agree. API keys should be stored as a config parameter for >> MapPaneOL. > Actually right now, the api key is in the index.html file; there's a > script tag that requests the googlemaps-client with API key straight > from google, but it would make sense to store it in config and let > Mapbuilder request the script from google. But to be honest it sounds > like a lot of work to get it done correctly (timing problems spring to > mind) so I prefer to leave it for the 1.5 release and look into it > after the release. >>>> 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> > Right now I use: > <Layer queryable="0" hidden="0"> > <Server service="Google" version="1.0.0" title="Google Map"> > <OnlineResource xlink:type="simple" xlink:href="Google"/> > </Server> > </Layer> > > And it just looks to service="Google" and skips everything else > basically. If we are going for API key stored in config the online > resource would become: http://maps.google.com/maps? and mapbuilder > needs to add: > file=api&v=2&key=ABQIAAAAjpkAC9ePGem0lIq5XcMiuhR_wWLPFku8Ix9i2SXYRVK3e45q1BQUd_beF8dtzKET_EteAjPdGDwqpQ > > > So we can use the version attribute as well :) >> 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> > I'm not sure what you are trying to achieve here, in my opinion it can > just be: > <Layer queryable="0" hidden="0"> > <Server service="Google" version="2" title="Google Map"> > <OnlineResource xlink:type="simple" > xlink:href="http://maps.google.com/maps?"/> > </Server> > </Layer> > Leaving the Satellite/Roads/Hybrid option, but maybe we can use the > <Style><name> tag for it? > >>>> 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. > To be honest my problem is *not* how to store the google in > OWSContext, there are enough ways to do it right now, we just need to > decide on one which we will recommend upstream. My problem is the way > we will handle google in mappaneol. The BaseLayer needs to be defined > very early in the process, so mapbuilder needs to know quickly that it > is about to show google and use that as a baselayer. > > We can use a function that decides what the baselayer is going to be > somewhere around the current baselayer definition on line 246, but > this means that we need to parse the context doc twice: once to see if > there's a baselayer-class layer and once to add all layers. Or we can > use my current approach that once it discovers a google layer that it > will destroy the previous baselayer and replace it. But this is a very > risky approach because it can discover google 'too late' when a few > other layers are already initialised with a different baselayer and if > it discovers multiple baselayer-class layers it will create a mess. > > I'm in favor of the first option, but I'm hoping there's another > approach which is cleaner. > > regards, > Steven > > > > > >
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
