Michael Schulz schrieb:
Hi Christoph,
I believe the administration tool does not have to be altered. Maybe I have
to explain the background of my previous post: I'm working on web map
context documents, which store the layers of the client in an XML document.
When I'm representing both map frames (plus their layer settings) in the WMC
document, I have no way of finding out the layer settings of the overview.
The default settings are overwritten by changes made to the main map.
Example: Assume a WMS is available in both overview and the main map. Then
hide layers of that WMS via the treeGDE module.
Just to be curious, does the wmc spec have an option to store
information about an overview? I thought this is merely a flat list of
layers ...
It is a flat list of layers. We plan to store the information whether a
layer belongs to the overview in an extension tag. Currently, it is just
based on karma.
Although you could put together a context collection with one wmc for
each mapobject. In that case you are right, wms setting changes
shouldn't cross map object scopes.
Unfortunately, context collection only have links (URLs) to other WMC
documents. The documents cannot be stored in-line. We have asked the OGC
context revision workgroup to change this behaviour for future specs.
Other solutions could be discussed, like
* reload the default settings from the database
* always show all layers of the overview WMS
For me, a wmc makes sense if it stores the current layer settings, not
some initial default, but presumably you have a special focus.
The problem is that the current settings for the overview are not
available (anymore) in the client. So by reloading them from the
database, I would just fake having the current settings.
Christoph
but both solutions don't seem elegant to me, especially if you imagine
having 7 maps and 3 overviews in one applications.
wow, i'd like to see that one ... ;-)
Michael
I believe when Mapbender had been designed it was not intended to ever do
sth. with the overview window after its instantiation, so then it made
perfect sense. Now, we need more.
Cheers, Michael
Please enlighten me if you have an explanation why the current solution
is
superior.
Christoph
--
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
--
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
--
_______________________________________
W h e r e G r o u p GmbH & Co. KG
Siemensstraße 8
53121 Bonn
Germany
Christoph Baudson
Anwendungsentwickler
Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
