Save/Load bookmarks outside of a browser

[GoogleCodeExporter]

The ability for a user to save their bookmark external to their browser, and 
also to load other, externally supplied bookmarks. This would provide a 
function like an ArcGIS Workspace (.mxd) or QGIS Project (.qgs) file.

This should include the following:

- Create a new button for the toolbar which when clicked will bring up a dialog 
asking where the current workspace should be saved.
- This workspace should remember everything about all layers currently included 
in the project. I.e. opacity, ordering, style, etc.
- This workspace should also include OpenLayers configuration like viewing 
location, max/min extent, projection etc.
- This file can be transferred to other users in conventional ways.
- A button for "Load from configuration" that can be added to the toolbar. 
Should open a dialog which looks for files of the applicable extension.
- When a workspace file is loaded, Heron reverts to whatever is in this 
configuration. The view will go to the right location, the only layers included 
will be those listed in the workspace file, etc.

If possible, we'd prefer this to be done in a way compatible with Web Map 
Contexts -http://www.opengeospatial.org/standards/wmc

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 28 Nov 2013 at 3:07

[GoogleCodeExporter]

Original comment by rinke.he...@gmail.com on 8 Jan 2014 at 10:36

• Changed state: Started

[GoogleCodeExporter]

Made quite some progess on this issue last week with saving as Web Map Context.

As mime type I use 'text/xml'
The Web Map Context file is then saved as an .XML file
Could not find a specific mime type for Web Map Context. 

Is this correct?

Original comment by rinke.he...@gmail.com on 17 Jan 2014 at 3:55

[GoogleCodeExporter]

P.S. I save now as text/xml with file extension .wmc

Original comment by rinke.he...@gmail.com on 17 Jan 2014 at 4:15

[GoogleCodeExporter]

WMC 1.0 states:

"6.1 XML Encoding and MIME Type
The eXtensible Markup Language (XML) [XML 1.0] encoding of a Context document 
shall be valid according to the XML Schema in annex A.1 of this document. This 
XML Schema specifies the required and optional content of the Context document 
and how this document is formatted.
A Context document may reference an exact copy of the XML Schema in annex A.1 
of this document. The XML Schema shall be located at a fully-qualified and 
accessible URL to permit an XML validating process to retrieve it.
When used with a MIME type, the context XML format should be identified by 
"application/vnd.ogc.context+xml".
A specified filename extension such as .cml and .ccml is suggested for Contexts 
and Context Collections."

So it does declare a MIME type.

However, the WMC 1.1 specification doesn't seem to declare a MIME type. The 
same section reads:
"6.1 XML Encoding
The eXtensible Markup Language (XML) [XML 1.0] encoding of a Context document 
shall be valid according to the XML Schema in annex A.1 of this document. This 
XML Schema specifies the required and optional content of the Context document 
and how this document is formatted.
A Context document may reference an exact copy of the XML Schema in annex A.1 
of this document. The XML Schema shall be located at a fully-qualified and 
accessible URL to permit an XML validating process to retrieve it.
A specified filename extension such as .cml and .ccml is suggested for Contexts 
and Context Collections."

I leave it to wiser minds than mine to decide how to proceed. :-)

Original comment by jonathan...@warwickshire.gov.uk on 17 Jan 2014 at 5:03

[GoogleCodeExporter]

Note - see also that they specify suggested filename extensions (.cml or .ccml).

Original comment by jonathan...@warwickshire.gov.uk on 17 Jan 2014 at 5:07

[GoogleCodeExporter]

I would suggest  to make both mime-type and file extension configurable with 
the defaults of plain XML:

* text/xml;charset=UTF-8
* extension: .xml

Also based on an example here: http://portal.onegeology.org (made with 
ExtJS/OpenLayers).

Original comment by jus...@gmail.com on 20 Jan 2014 at 2:23

[GoogleCodeExporter]

I think the default extension should be .cml (or .ccml) - both specifications 
are clear on that (although they don't make it a "should" requirement).

The 1.0 specification does say "should" though for the mime type.

Original comment by jonathan...@warwickshire.gov.uk on 20 Jan 2014 at 2:31

[GoogleCodeExporter]

Rev. 1268
First implementation of save and load WMC file.
Works at least with the mapopensave example.

First I've set the default to text/xml .cml, but this is configurable.
I was not sure whether I have to add extra processing for charset=UTF-8, 
otherwise I can make that the default.

New example:
mapopensave

At this time configurable with:
Heron.options.map.toolbar = [
    {type: "mapopen"},
    {type: "mapsave", options : {
        mime: 'text/xml',
        fileName: 'heron_map',
        fileExt: '.cml'
    }}
];

Adds the buttons as in attached png.

Original comment by rinke.he...@gmail.com on 23 Jan 2014 at 11:24

Attachments:

• MapOpenSaveButtons.png

[GoogleCodeExporter]

Thanks Rinke, Excellent. We should add this to the standard toolbar 
(DefaultlOptions(NL).js) used in most examples. Also will test other 
contexts/projections. Only a few remarks:

- the icons: very creative, but maybe hard to read, most geoportals use 
ordinary 'map', 'diskette' icons, but I leave this  up to Jonathan
- when loading after save and reloading page, it looks like the zoom level 
differs 1 level from the saved zoomlevel, e.g. saved with zoom=8 but loads with 
zoom=7
- the "open" popup is rather broad and needs some CSS styling
- the "open" popup shows exclamation mark icon and red underlining for 
"required field"
- we need to think about the interaction with populated LayerTrees: some have 
explicit population
- reading the original item I was under the impression that this issue would be 
an extension to the existing bookmark feature and bookmark panel. Appearantly 
not also as save/load is part of any geoportal. This scenario is still possible 
by loading a bookmark  and saving it as a WMC. We may think of storing the 
current bookmarks (in local storage) as encoded WMC docs....
- code: MapContext.js does not need an initComponent() function as this is not 
an ExtJS class, but basically utility functions wrapped in the namespace 
Heron.data.MapContext

Other than that: great work, good to see you have found your way into the data 
subdir, OL WMC, and heron.cgi! This is all advanced Heron/ExtJS/OL programming. 
I can foresee lots of new possibilities with WMC!

Original comment by jus...@gmail.com on 24 Jan 2014 at 12:51

[GoogleCodeExporter]

Had to dig deep to get it working (especially communication for up- and 
download is always a bit fuzzy in the beginning), but was impressed with the 
capabilities of WMC. Although it does not everything "out-of-the-box".

- the icons: very creative, but maybe hard to read, most geoportals use 
ordinary 'map', 'diskette' icons, but I leave this  up to Jonathan
-> I made special icons to differ between other already used icons and not 
confuse users with layer upload, data download,... So I made the combination 
between map and open / save

- when loading after save and reloading page, it looks like the zoom level 
differs 1 level from the saved zoomlevel, e.g. saved with zoom=8 but loads with 
zoom=7
-> I set the extent to the bounding box in the WMC. Have to look at it.

- the "open" popup is rather broad and needs some CSS styling
- the "open" popup shows exclamation mark icon and red underlining for 
"required field"
-> I totally agree, also wondered if we can avoid using the popup and go to the 
filebrowser right away and upload the selected file.

- we need to think about the interaction with populated LayerTrees: some have 
explicit population
-> That's right the folders in a LayerTree are not n the WMC

- code: MapContext.js does not need an initComponent() function as this is not 
an ExtJS class, but basically utility functions wrapped in the namespace 
Heron.data.MapContext
-> I was not able to call loadContext from within MapContext, the initComponent 
seemed to solve it, but probably there must be a better way.

Original comment by rinke.he...@gmail.com on 24 Jan 2014 at 1:21

[GoogleCodeExporter]

Comments:
 - The "Open" dialog - I'm with you in that we can probably skip this and go straight to "open file".

--
In the CML file:
- Can we have some whitespace/Return characters used? It'll increase the file 
size a small amount but make it actually human-readable without having to do a 
reg-exp search-replace first.

---
Icons
- I'm with Just in that they're hard to read. Those ones would work better if 
the icons could be larger. I think a icon with a single item/theme to it rather 
than two together works better, especially with such small sizes.

----
Bookmarks
- I'm also with Just on the bookmarks thought. I'd kind of envisioned some sort 
of tighter integration, though at the same time having it as a separately 
useable function as you've developed.

Original comment by jonathan...@warwickshire.gov.uk on 27 Jan 2014 at 12:32

[GoogleCodeExporter]

Comments:
 - The "Open" dialog - I'm with you in that we can probably skip this and go straight to "open file".
-> I'll try to get it working that way.
--
In the CML file:
- Can we have some whitespace/Return characters used? It'll increase the file 
size a small amount but make it actually human-readable without having to do a 
reg-exp search-replace first.
-> It might be a bit off-scope, but it can also be handy for debugging so I'll 
do some formatting as you suggested.
---
Icons
- I'm with Just in that they're hard to read. Those ones would work better if 
the icons could be larger. I think a icon with a single item/theme to it rather 
than two together works better, especially with such small sizes.
-> Then I'll revert to the "standard" open (folder) and save (diskette) 
buttons. For now I will leave the new buttons in the resource so someone can 
still chose those.
----
Bookmarks
- I'm also with Just on the bookmarks thought. I'd kind of envisioned some sort 
of tighter integration, though at the same time having it as a separately 
useable function as you've developed.
-> I thought the bookmarks were only marking the layers which where on (and 
extend etc) but without all layers (including all definitions). As Web Map 
Contexts was proposed to use, I focused on using WMC. If the direction is not 
right we have to get this clear, because there is no time now to developed both 
options. 

Original comment by rinke.he...@gmail.com on 27 Jan 2014 at 2:18

[GoogleCodeExporter]

Just - do you have any thoughts on the bookmark integration?
I put it there as it's something that seems fairly logical but didn't have any 
specific designs for it.

Original comment by jonathan...@warwickshire.gov.uk on 27 Jan 2014 at 3:47

[GoogleCodeExporter]

IMO the current implementation follows the issue description. I was just 
triggered by the word "bookmark" in the first sentence: "The ability for a user 
to save their bookmark external to their browser...". 

But anyway, I think that internal/local bookmarks, saved in browser 
localstorage should be integrated at some point but not part of this issue. 

Thoughts:

- both externalized map contexts and internal bookmarks should use WMC format
- internal bookmarks can be stored using encoded WMC docs as Strings
- add an "export" button to each internal bookmark such that it can be saved to 
a WMC file
- the latter is basically a shortcut for: load internal bookmark+save map 
context
- importing WMC directly into local bookmarks does not seem to make sense, one 
can always load a WMC file and then decide to make it a  local bookmark
- also note that internal bookmarks are always tied to the specific page/webapp 
while WMS is generic over (web)apps

Original comment by jus...@gmail.com on 27 Jan 2014 at 4:13

[GoogleCodeExporter]

Rev 1290
Reverted to "normal" open/save buttons.
Formatted XML output (heron.cgi had to be changed because python len() does not 
count newlines, so XML was chopped of at the end).
Changed to base64 encoding/decoding (was url encoding/decoding), 
Exporter-all.js does not contain base64 decoding so extra util: 
lib/ux/WebToolKit-base64.js. 
and added encoding to heron.cgi.

Could not reproduce the difference in zooming level.
Been trying to avoid open file dialog, is quite complicated, I'll focus on the 
core functionality first.
At this time I'm working on the layertree, try to get it as extended info in 
the WMC.

Original comment by rinke.he...@gmail.com on 29 Jan 2014 at 4:00

[GoogleCodeExporter]

I succeeded in saving the layertree into XML and put it in the WMC file.

Now I have to refresh or reload the layertree, but I cannot figure out yet how 
to get this object to reload with the tree information I've loaded from the WMC 
file.
Is there a way to get to this LayerTree object, or do we have to create an 
instance of the LayerTree first?

Original comment by rinke.he...@gmail.com on 4 Feb 2014 at 9:45

[GoogleCodeExporter]

Giving the layertreepanel an id in DefaultConfig.js makes me getting access to 
the layertree. I also manage to change the hropts.tree in this object, but 
reload does not yet do what I want.

Original comment by rinke.he...@gmail.com on 4 Feb 2014 at 11:14

[GoogleCodeExporter]

Getting a component by id is not portable. ExtJS also provides a  
Container.findByType('<type>');
e.g. Heron.App.topComponent.findByType('hr_layertreepanel');

I realize that the layertree integration is quite hard to solve, if even 
possible. There are basically two config-types for a LayerTreePanel: automatic 
or an explicit parent-child tree. The first provides BaseLayers and Overlays 
folders. I can imagine mapping this to WMC, since this is automatic. But 
mapping any custom tree is a challenge. IMO this gets too far and we should not 
attempt to do this. Basically Save/Load should replace the current Map. Any 
LayerTree should act on events from the OL Map. This may need to be fixed in 
the LayerTreePanel. Probably the Save/Load code should not be interacting with 
LayerTree code. 

Original comment by jus...@gmail.com on 4 Feb 2014 at 12:54

• Removed labels: Project-None

[GoogleCodeExporter]

I agree with you. It cost me already many days to sort things out, get the info 
from the LayerTree and try to change or replace the LayerTree.

Will take this issue to end first based on "plain" WMC and then head on to the 
next issue.

Original comment by rinke.he...@gmail.com on 4 Feb 2014 at 1:12

[GoogleCodeExporter]

LayerTreePanel is a small Heron-wrapper for the "real code" that resides in 
GeoExt regarding LayerTrees. 

At least for automatic Baselayers/Overlay trees, the GeoExt LayerLoader.js 
should act on Map Layer add/remove via the GeoExt LayerStore. So when loading a 
new WMC, the existing Layers are removed from the OL Map and then the new 
Layers added as I see in Mapcontext.loadContext). Or is this working already 
for automatic LayerTrees without ineraction with the tree? Even if the WMC is 
in another projection like NL?

Original comment by jus...@gmail.com on 4 Feb 2014 at 1:23

[GoogleCodeExporter]

When having a LayerTree it does not really work well, even if you load a map 
with exactly the same LayerTree.
It also looks like not all layers are loaded. I see now the tiled services TMS 
are not in the WMC file.

In default LayerPanel (baselayers/overlays) I've seen problems with changing 
projection, I will look into that now.

Original comment by rinke.he...@gmail.com on 4 Feb 2014 at 1:42

[GoogleCodeExporter]

Hi Rinke - thanks for your work on this. Layer Trees are currently very 
important for how we use Heron (see http://maps.warwickshire.gov.uk/historical/ 
for example) and will probably remain so even after we get the catalogue 
function added. We certainly need them to be usable with this feature.

Original comment by jonathan...@warwickshire.gov.uk on 4 Feb 2014 at 1:56

[GoogleCodeExporter]

One thing of help could be that an ExtJS Layer Tree may be created from a JSON 
config. This is actually used in Heron LayerTreePanel, line 135, both for 
automatic and custom trees:      

treeConfig = new OpenLayers.Format.JSON().write(treeConfig, true);

So theoretically we could tie 'treeConfig' to the component as 
this.jsonTreeConfig, take the JSON string, save this as an extension element in 
WMC on saving. On Loading we can check if the app has a Heron LayerTreePanel 
(ExtJS search by classname) and if so reload the Map and rerfresh  the 
Layertree with the JSON.

But still, strictly spoken, I don't see the requirement to also load/save 
layertrees in the original issue description...Possibly for a next iteration. 
The feature itself can be extremely useful for general use. Imagine having just 
one empty Heron app and a catalogue of WMCs...

But offcourse WMC save/load without layertrees should play nicely with 
layertrees present in the app and maybe my proposed solution above will be 
easiest to achieve this...

Original comment by jus...@gmail.com on 5 Feb 2014 at 10:45

[GoogleCodeExporter]

I believe we did spell it out in the specification:

"- This workspace should remember everything about all layers currently 
included in the project. I.e. opacity, *ordering*,"

Specifically "ordering"; we certainly intended for layertrees to be included in 
that as they're a key component of the ordering that we use.

Original comment by jonathan...@warwickshire.gov.uk on 5 Feb 2014 at 10:58

[GoogleCodeExporter]

I was just checking the GeoExt example: 
http://api.geoext.org/1.1/examples/tree.html
There is some configuration change on the fly as well.

I succeeded this week in saving the LayerTree info in the XML (as XML, thought 
it might be too tricky and not right to save JSON in an XML file). Also I was 
not able to find the info ready for saving as JSON for the treeConfig, but 
maybe I didn't look at the right place (only found the initial treeConfig, 
which is not right after reordering).

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 11:10

[GoogleCodeExporter]

Yes this GeoExt example confirms my view: the JSON config is central, not the 
Heron Tree config. The relevant code in the example to reload the tree is in 
the Save button handler in tree editor: 

                text: "Save",
                handler: function() {
                    var value = Ext.getCmp("treeconfig").getValue()
                    try {
                        var root = tree.getRootNode();
                        root.attributes.children = Ext.decode(value);
                        tree.getLoader().load(root);
                    } catch(e) {
                        alert("Invalid JSON");
                        return;
                    }
                    treeConfig = value;
                    treeConfigWin.hide();
                }

I would not try to convert the JSON to XML and v.v.. Why not put it as a string 
in an WMC Extension element, someting like:

      <Extension>
        <heron:treeConfig>
             [
    {
        "nodeType": "gx_baselayercontainer"
    },
    {
        "nodeType": "gx_overlaylayercontainer",
        "expanded": true,
        "loader": {
            "baseAttrs": {
                "radioGroup": "foo",
                "uiProvider": "layernodeui"
            }
        }
    },
    {
        "nodeType": "gx_layer",
        "layer": "Tasmania (Group Layer)",
        "isLeaf": false,
        "loader": {
            "param": "LAYERS"
        }
    }
]
         <heron:treeConfig>
      </Extension>

Original comment by jus...@gmail.com on 5 Feb 2014 at 11:31

[GoogleCodeExporter]

I cannot get the current treeConfig (only the initial one).
Ext.getCmp("treeconfig") is undefined in my case.

At this time I retrieve the tree info from the root Node 
(Ext.tree.AsyncTreeNode):
  .attributes.children[]

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 12:00

[GoogleCodeExporter]

Ext.getCmp("treeconfig")  is in the GeoExt example. In our case we need to save 
the JSON String in LayerTreePanel line 135 via 'this', like:

    this.jsonTreeConfig = new OpenLayers.Format.JSON().write(treeConfig, true);

and use this.jsonTreeConfig where earlier 'treeConfig' was used.

Finding the component when saving would be something like (use null checks.. 
offcourse):

       Heron.App.topComponent.findByType('hr_layertreepanel')[0].jsonTreeConfig;

Original comment by jus...@gmail.com on 5 Feb 2014 at 12:06

[GoogleCodeExporter]

That works indeed, but the ordering is still the initial ordering.
Probably we have the same problem here as in Issue 332.
The order change is not detected by GeoExt.

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 12:28

[GoogleCodeExporter]

I really think I'm getting somewhere now. I will commit today a version that 
works on LayerTrees ???
Having extra troubles because the Kadaster layers used in the Heron examples 
seem to be offline or out of order (this might also be the problem with tiled 
services I had before).

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 2:42

[GoogleCodeExporter]

Rev 1304
Support for LayerTrees implemented.
LayerTrees is completely refreshed.
Ordering is in initial ordering. 
Will have to look at the ordering issue (332) first.

In this rev also a better FileOpen dialog, thanks to Anke. She has tried to 
avoid the extra dialog, but is very hard in combination with toolbar. Dialog is 
much better now with Cancel button.

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 3:25

[GoogleCodeExporter]

Thanks for your work on this.

Using http://lib.heron-mc.org/heron/latest/examples/mapopensave/

- Created the attached (in Opera), but when I open it (in Chrome), the map is 
in the right place and everything, but
-- The layer list is entirely empty
-- The legend is different.

------

Minor observation, not really a problem but thought I should bring it up:
When saving in FF and Chrome, for <Online Resource> types, the order of xlink, 
xmlns is different than if it's saved in IE.
So IE:
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" 
xlink:href="http://maps.opengeo.org/geowebcache/service/wms"/>

FF, Chrome:
<OnlineResource xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" 
xlink:href="http://maps.opengeo.org/geowebcache/service/wms"/>

Original comment by jonathan...@warwickshire.gov.uk on 5 Feb 2014 at 3:37

Attachments:

• asdf.xml

[GoogleCodeExporter]

Also the projection change should be fixed in rev 1304.

While testing the committed code I notice the following:
In Chrome it seems to work
At this time you might only be able to load a map once (work to be done).
In FireFox I get no map while loading a WMC (maybe a cross browser problem, 
haven't found yet).

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 3:37

[GoogleCodeExporter]

> Having extra troubles because the Kadaster layers used in the Heron examples 
seem to be offline or out of order (this might also be the problem with tiled 
services I had before).
Today (25 minutes ago) Delete comment

Should be working now. We moved to a new server and there is still some 
tweaking.

Original comment by jus...@gmail.com on 5 Feb 2014 at 3:53

[GoogleCodeExporter]

There seems to be a problem with getElementsByTagName and some 
browser(versions).
I will see if I can solve that tomorrow

Original comment by rinke.he...@gmail.com on 5 Feb 2014 at 4:40

[GoogleCodeExporter]

Rev 1306
Firefox was very fussy about the generated XML so I made changes to prevent 
these problems.
Also put some extra try/catch with alert messages (note: the alerts are not set 
up yet for end-users).
There might still be some problems when loading more WMC files after one 
another.
Sometimes an error occurs.

Original comment by rinke.he...@gmail.com on 6 Feb 2014 at 11:08

[GoogleCodeExporter]

Issue 196 has been merged into this issue.

Original comment by jus...@gmail.com on 6 Feb 2014 at 2:47

[GoogleCodeExporter]

It's not even more broken I'm afraid.
I save a file in Chrome (attached) - when I try and open this I get an error:
"Problem with loading map after proj: Cannot convert 'a' to object"

Original comment by jonathan...@warwickshire.gov.uk on 7 Feb 2014 at 12:24

Attachments:

• use_me.cml

[GoogleCodeExporter]

I see, I will take a closer look on monday!

Original comment by rinke.he...@gmail.com on 7 Feb 2014 at 7:33

[GoogleCodeExporter]

Rev. 1336:
A minor revision to get code in line with other issues.

Since yesterday tangled in removing layers and tree nodes.
So this is not a complete working version yet.

Original comment by rinke.he...@gmail.com on 11 Feb 2014 at 10:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Rev 1337
Managed to bread-down and build-up the LayerTree in the order as in the config 
for now. It should be working for most maps/layers (WMC does only support WMS 
layers, so this feature is also supporting only WMS layers).

Removing the layers from the map did not (always) automatically remove the 
nodes in the tree. This was a major disturbance in the previous version.
Was quite a hassle to get it right because there is a lot of interference 
between map, layers and LayerTree. 
LayerTree Node cleanup is now managed specifically while loading a map from 
file.

Original comment by rinke.he...@gmail.com on 11 Feb 2014 at 2:50

[GoogleCodeExporter]

Jonathan,

With the LayerTrees included now, I hope we should have most of the 
functionality ready now.
Note: With revision 1337 you should not use the previous saved WMC/CML files 
(LayerTrees not present in file), but save new ones. 

As I've spend already about triple the time calculated for this issue I would 
like to work towards an end-version for this issue and define below points and 
possible new features for a future issue or leave it as is:
- As we decided to use WMC as exchange format, only WMS layers can be included 
in the map.
- Nodes (folders) which contained only non-WMS layers are empty.
- Layer ordering is same as in original treeConfig.

What is your opinion in this?

Original comment by rinke.he...@gmail.com on 11 Feb 2014 at 4:52

[GoogleCodeExporter]

Hi Rinke,
I understand your position and agree to coming to a close even if it doesn't 
have WFS or WMTS.
However we use TMS for all of our basemap needs and so we need those to be 
supported otherwise this is unusable for us. You can see them in our inspire 
project for example - Everything under "current maps" is a TMS - 
http://maps.warwickshire.gov.uk/inspire - I hope that's not too much work.

Original comment by jonathan...@warwickshire.gov.uk on 11 Feb 2014 at 5:09

[GoogleCodeExporter]

Hi Jonathan,

I will have look into TMS, must be custom implemented as it is not part of 
OpenLayers WMC.
When I get it to work you will not see empty folder anymore as you only use WMS 
and TMS.
So we drop the layer ordering in this issue.

Can you already test whether current version works right (you might see an 
empty baselayer folder when only containing TMS for now, but the WMS layers 
should work, I managed the absence of baselayers).

Original comment by rinke.he...@gmail.com on 12 Feb 2014 at 7:58

[GoogleCodeExporter]

Sorry but it simply doesn't work. The file it is creating is invalid - it gets 
cut off mid-text. See attached. Doesn't matter if I use FF or Chrome, always 
gets cut off in the same location. Obviously it then fails to load.
(I'm using a local copy on a test project I have).

Original comment by jonathan...@warwickshire.gov.uk on 12 Feb 2014 at 3:47

Attachments:

• heron_map.cml

[GoogleCodeExporter]

It opens all right in latest.
I also did a save in latest: goes OK.

Note: You should always get <heron:treeConfig> in the CML file.
You must be using an old version as this section is not in your file, probably 
you have update your local copy to the latest revision?

Original comment by rinke.he...@gmail.com on 12 Feb 2014 at 4:11

[GoogleCodeExporter]

Doh. That's because I attached the wrong file! :-/ See attached (this is using 
latest).
Sorry about that.

Original comment by jonathan...@warwickshire.gov.uk on 12 Feb 2014 at 4:15

Attachments:

• compass_map.cml

[GoogleCodeExporter]

That's meant to be declaring this layer tree. In this case as it's a test, some 
of the base layers are WMS and some are TMS.

Original comment by jonathan...@warwickshire.gov.uk on 12 Feb 2014 at 4:16

Attachments:

• Clipboard01.png

[GoogleCodeExporter]

I made a modification in heron.cgi (in rev 1290) because I also have had the 
chopping off of the formatted XML. 
It looks like it is the same behavior like you have now.
Can you send me the heron.cgi you use now, to be sure that's not the problem?

Original comment by rinke.he...@gmail.com on 12 Feb 2014 at 6:35