Hi Andreas et al,
On Thu, 2007-11-22 at 02:09 +0100, Andreas Hocevar wrote:
> It was agreed to not add it to the branch. And thus the last merge
> from trunk to 1_5 did not contain this change.
OK. Steven confirmed the same thing, so that is clear for us now.
> But if you want us to vote on that again, I would kindly ask you to
> explain a little bit on what you have done. At this point, I have too
> little information to vote.
Of course I'm more than willing to explain my changes in the hope it
makes it into the 1.5 release! ;-)
> If I understand your code right, when parsing the context, you check
> for the id attribute of the layer, and if it is not found you fall
> back to the layer name. This will be backwards compatible, as long as
> there is no id attribute to the Layer/FeatureType in the context.
> Which is good.
That is correct. One extra thing: when you add a layer that has no 'id'
to a context, one will be generated automatically (layerName + '_' +
random 4 digit number). There is no check if that near-random id already
exists.
A similar thing holds for adding a layer that *has* an id. Although
OWSContext.js assumes that adding a layer with the same id means
replacing the old one with the new one (which seems logical).
>
> There is one thing you would definitely have to change: you changed
> the code in OwsContext.js to read out layers and feature types using a
> ResourceList/* xpath. This will break the new base layer code which is
> currently in trunk and will be in the release. You would have to
> change that back to ResourceList/Layer and ResourceList/FeatureType,
> or at least make sure to exclude ResourceList/BaseLayer.
I will change that in the trunk. Thanks for pointing this out.
I also will change the line of code that Gertjan pointed out:
> + var newObject;
> + if (window[objectType] && (newObject = new
window[objectType](configNode, this))) {
>Blech, embedded assignment. Please don't do that.
>[And note to Cameron: should we extend our JavaScript style
guide, e.g.
>by looking at the OpenLayers style guide?]
Thanks for finding that one Gertjan!
>
> > Side note:
> > Our Lisasoft patch for GeoRSS has been committed to the trunk of OL and
> > will be part of OL 2.6.
>
> Congratulations on that, and also Congratulations on the positive
> feedback Chris gave you.
Thanks Andreas. Most work has been done by my former colleague Eric Lam.
Therefore he deserves most of the credits, as well as Cameron for making
it possible for us to contribute to OSS projects at work.
I saw that your latest contribution to OL is coming very soon as well:
SLD support! That is a huge one!
>
> > Since MB 1.5 will ship with OL 2.5, is it desirable to have a GeoRSS
> > example and therefore have a patched OL 2.5 with GeoRSS support in it?
>
> We already have a GeoRSS example (shipTracks), which transforms a
> GeoRSS feed to a FeatureCollection with xsl and uses GmlRendererOL to
> add it to the map. This also works with lines and polygons. If I
> understand your patch right, it improves OpenLayers.Format.GeoRSS, but
> OpenLayers.Layer.GeoRSS does not use this code. So I assume you create
> a OpenLayers.Layer.Vector layer with the features created from the
> feed using OpenLayers.Format.GeoRSS.read. Please correct me if I'm
> wrong.
Our GeoRSS example uses a GML layer with a GeoRSS format.
OpenLayers.Layer.GeoRSS is effectively a markers layer. The GeoRSS
improvement to OL effectively allows for any kind of GML geometry in a
GeoRSS feed.
> I don't know if you are aware that any vector layer will not let
> events through to layers below.
I did not know that and that is useful information.
> > This is new functionality and might be a little too fresh for 1.5.
> > Please vote for this one as well.
>
> -1, because we have an alternative. But I'm eager to see this in the trunk.
Understandable, especially since it would force us to use a custom
OL.js. If I want to get this working in the trunk, it would require a
custom/unreleased version of OL.js there. Is that desirable? If so, then
we might as well take the latest trunk version of OL.
Kind regards,
Roald
--
Roald de Wit
Software Engineer
[EMAIL PROTECTED]
Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
mapbuilder-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
