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: 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
