You need to log in before you can comment on or make changes to this bug.
Problem: when we load a context document with Chameleon and then save it back, most of the top-level metadata elements (title, abstract, contact info, etc.) are lost. Background info: When a Map Context document is read by MapServer, a good number of metadata fields from the context are stored in the map->web->metadata. However, the UploadContext widget uses a temporary mapObj to read the context file, and then manually copies selected fields from the temporary mapObj to the main mapObj in the user's session. I guess the first question is why do we do that? Why not just replace the mapObj inside the session completely? The problem with this approach is that as MapServer evolves, there may be more or less fields to copy, so this will always be a potential source of problems. Anyway, assuming there are good reasons to copy the mapObj members one by one, then the code will have to be modified to maintain all the map->web->metadata values that relate to the context so that they are properly written back if you save the context document later on. Here is a partial list of metadata fields that were lost and need to be transported: wms_context_version wms_title wms_keywordlist wms_abstract wms_dataurl wms_logourl_* wms_descriptionurl_* wms_contact*, wms_address*, etc.
Changed target to 1.99 RC 1.
I think the reason was that there are a number of things that are configured by chameleon like: extents web metadata keymap object reference object scalebar object output format there are a lot of things that chameleon configures for the user based on widgets. Most widgets try to be intelligent and not do all the processing and updating except the first time. The code is not structured such that we could set a flag to cause everything to re-initialize nor is it a simple task to identify all the things chameleon may have changed on the user's behalf. An enhancement would be to recode all widgets to test for an 'initialize' flag but that seems like a huge amount of work :( What would be easier would be a method of extracting all metadata from an object and passing it to another object. This must be available at some level since you can clone most objects. Can you clone metadata?
Daniel, do you have any further comment on this?
I don't understand what the widgets have to do with that. Right now you're copying layers one by one and member by member when calling $map->loadMapContext() on the original mapObj would do the same or be better. You do not need to create a new mapObj to load a context, you can just load it into an existing map and it appends the layer to the existing map. Most of the items that you listed remain untouched, except perhaps the extents: BTW, if you really can't trust msp->loadMapContext() to do the right thing then you might at least want to consider using the optional second argument to ms_newLayerObj() which can be used to create a new layer in a map that's a copy of the specified layer.
need to consolidate on a single loadContext function used by the core and by this widget, and then fix this by copying layers and all the (known) web-level metadata (note the function in chameleon.php already uses the layer copying approach). In the future, hope to have a php_mapscript function to iterate through metadata (as per swig mapscript).
working on this now
fixed in cvs. There is a new file, ows.php, that contains a loadContext function that is now used by both Chameleon and the UploadContext widget. This function does the following (with error checking): load context into new map object optionally delete existing layers (when not appending) copy layers into existing map object (copies layer level metadata) optionally sets map level properties and metadata (when not appending) - metadata is manually copied based on an array of known metadata keys. optionally resizes map
