Thanks for your reply.
Michael Schulz schrieb:
Hi Christoph,
This means that you have at least one WMS in two or more map objects, so
manipulating it in a single map also alters it in the other. I assume
I tought, that only manipulation done in the wms_gui_settings change
the wms in both map objects (i.e. prior to loading the gui). When a
gui is loaded the wms in the different map objects can be changed
without affecting each other - otherwise changes to the wms in the
main mapframe via treegde would change the overview mapframe
accordingly. That is not the case.
The manipulation does not affect the overview window, this is correct. I
would have to check the code why not, but I assume that the overview is
"abandoned" after initialisation, in other words, it is not being refreshed.
removing the global WMS object and storing the data in each map object would
be more consistent.
I think your suggestion makes perfect sense. But wouldn't it create a
need for a more complex gui administration interface? Configure the
wms for map object x in application y. Although i think that would be
really powerful. At the moment the wms configuration for the overview
frame is pretty distributed and has a lot of additional magic when
accompanied by certain modules (dynamicOverview, SetBackground).
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.
Other solutions could be discussed, like
* reload the default settings from the database
* always show all layers of the overview WMS
but both solutions don't seem elegant to me, especially if you imagine
having 7 maps and 3 overviews in one applications.
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
