Cameron, The solution as done now with <baseLayer> only works for 1 layer and is intended to have an easy way to have a single google layer in 1.5. We will need to modify the code to handle multiple baselayer-types in a context doc and allow for switching baselayers. We can discuss OWS context as well in that disuccion.
Steven Cameron Shorter wrote: > Steven, I think this is a good solution for 1.5, but think we can do a > better job with OWS Context for future versions. > > I think that we should aim to make OWS Context simple and for that I > think that <Layer>, <BaseLayer> and <FeatureType> should all be > merged. Ie: > <Layer service="Google"> > <Layer service="WMS"> > <Layer service="WFS"> > <Layer service="GML"> > ... > > Our applications then decide whether we treat a service as a baselayer > or not. > > Steven M. Ottens wrote: >> 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
