Hi all,
After discussing this with Andreas we decided for the following approach
for the 1.5 release:
GMAPS, VE, YMAPS and non WMS-baselayers are only supported in OWSContext
So if we have a standard WMC, we will add a hidden baseLayer, just as
Andreas did already, nothing changes there. It will not be possible to
add google etc on a standard WMC doc.
However if you use OWSContext there's a new LayerType called BaseLayer
where (at least for release 1.5) there can only be 1 in the entire
context doc. It looks like this:
<ows:BaseLayer>
<Server service="Google"/> <!-- the service attribute will decide
what kind of layer it is, in the case of a WMS you will need to add a
resource url -->
<Name>Google Hybrid</Name> <!-- used to set the name of the
baselayer -->
<ows:TileSet> <!-- this is taken from TileCache.py -->
<!-- <ows:resolutions/> --><!-- If prefered you can store you
custom resolutions, for ymap,ve and gmap it's not needed -->
<ows:SRS>EPSG:900913</ows:SRS> <!-- if set to EPSG:900913 it
will automatically switch to sphericalMercator -->
<ows:BoundingBox SRS="EPSG:900913" minx="-20037508"
miny="-20037508" maxx="20037508" maxy="20037508.34"/> <!-- unfortunately
this is currently being ignored, please use the OWS context bbox-->
<ows:Layers>hybrid</ows:Layers> <!-- here you can choose
aerial/satellite, road/normal or hybrid(default)-->
<!-- <ows:Width/> --> <!-- here you can specify a custom
tilesize, default is 256 -->
<!-- <ows:Format/> --> <!-- here you can specify a custom format -->
</ows:TileSet>
</ows:BaseLayer>
The BaseLayer will be ignored by all widgets except the MapPaneOL and if
there's no BaseLayer defined it falls back to the empty baseLayer, the
same as with a standard WMC.
So far I've only tested it with google; tried hybrid, roads and aerial
and it works.
Please try it and comment on it.
Regards,
Steven
Cameron Shorter wrote:
> Andreas, you solution sounds good for the 1.5 release.
> For 1.5 release candidate we want minimal impact changes and it sounds
> like you have that covered.
>
> Andreas Hocevar wrote:
>> Hi,
>>
>> while all that was said by Steven should be considered for the trunk,
>> we have to find a reliable solution for the upcoming release. I just
>> had a little chat with Steven, and we came up with the following
>> proposal:
>>
>> - Base layers are strongly tied with resolutions. Resolutions are
>> currently in the config, and base layers should also go there.
>>
>> - Switching base layers can be done by creating a new
>> BaseLayerSwitcher widget, which will have a list of base layers
>> (similar to the OverviewWidget, which has a list of layers for the
>> overview map). When changing the base layer through this widget, it
>> will fire a newModel event on the map and put a new baselayer in the
>> MapPaneOL config. When re-creating the map, the baselayer will be read
>> from the config.
>>
>> - Existing layer control widgets are not affected, they do not know
>> about base layers
>>
>> Please speak up now and tell us what you think about it.
>>
>> Regards,
>> Andreas.
>>
>> On Nov 20, 2007 2:16 PM, Steven M. Ottens <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Hi all,
>>>
>>> While refactoring MapPaneOL to accomodate non-wms baselayers I
>>> discovered that I missed an important problem during the last
>>> discussion:
>>> If we have multiple baselayers we will need a solution similar to OL's
>>> list of baselayers:
>>> We need to parse all layers in the context doc and pick those that are
>>> baseLayers and add them to a separate list and remove them from the
>>> normal layerlist and show them in a separate list with only
>>> radiobuttons.
>>> The resulting behavior will be similar to the mapViewer example:
>>> In the layerControl you get two type of layers:
>>> checkbox'ed normal layers
>>> radiobutton'ed baselayers.
>>>
>>> Ticking a radiobutton will result in a setBaseLayer call which will
>>> replace the current baselayer by the one ticked.
>>> This will mean that we need support for baselayer-radiobuttons in
>>> Legend
>>> and LayerControl, a setBaseLayer function in (OWS)Context and possibly
>>> rewrite the setOpaqueLayer in the mapViewer example to use setBaseLayer
>>> (since it is typical baselayer behavior it's showing)
>>>
>>> However! if we do this, we need to store which layers are baselayers in
>>> the context, or parse them each time which isn't a good idea since it
>>> will exclude all non-baselayer-only layers. So the question is how are
>>> we going to do it. The mapViewer example uses the opaque attribute:
>>> <Layer queryable="1" hidden="1" opaque="1">
>>> which to my knowledge isn't part of the official WMC spec.
>>> I'm fine with using @opaque or @baselayer, which seems a better name
>>> tbh. But it will break the specs.
>>>
>>> Alternatively we can:
>>> 2. just parse the context and hope that there's only 1 baselayer and
>>> run
>>> into trouble when there are multiple
>>> 3. parse the context for baselayers and create a dynamic baselayerlist
>>> which requires every widget/tool/model who uses layerlists to
>>> reparse it
>>> to check for baselayers
>>>
>>> I propose to hijack the WMC/OWSContext and add an extra attribute.
>>> Since
>>> the attribute is typically only required when there's a baselayer-only
>>> layer, eg. gmaps which isn't part of the WMC anyway. If there's no
>>> attribute set we will use the invisible empty wms layer as baselayer.
>>> This means that valid WMC docs cannot use GMAP layers and we need to
>>> introduce the @baselayer attribute to OWSContext to make sure that it
>>> will be valid to use it.
>>>
>>> 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
>>>
>>>
>>
>> -------------------------------------------------------------------------
>>
>> 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
>>
>>
>
>
-------------------------------------------------------------------------
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
