Closed GoogleCodeExporter closed 9 years ago
Original comment by rinke.he...@gmail.com
on 8 Jan 2014 at 10:36
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
> 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
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
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
Issue 196 has been merged into this issue.
Original comment by jus...@gmail.com
on 6 Feb 2014 at 2:47
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:
I see, I will take a closer look on monday!
Original comment by rinke.he...@gmail.com
on 7 Feb 2014 at 7:33
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
[deleted comment]
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
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
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
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
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:
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
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:
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:
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
Original issue reported on code.google.com by
jonathan...@warwickshire.gov.uk
on 28 Nov 2013 at 3:07