[OpenLayers-Dev] Vector Integration

[Pierre GIRAUD]

As the Camptocamp team still wants to be involved in the OpenLayers
development, in particular in the vector branch, here is a try to
summarize the work done during the last passed weeks or months. And
also how we can or at least would like to contribute.

As already mentionned by Cameron, the UML diagram is worth being
updated with the effective implementation. The main ideas were
preserved though.

Following are listed the main points, that were, to my mind, added to
the main branch in a more or less chronological order :

 - Feature : it's the class used to store the business objects, that
means attributive data and geometry

 - Geometry : all the geometries (primitive or composite) inherit from
this class. The renderer knows how to render those. I think I remember
that we followed the SFS on that point. As an example of composite
geometries, a Multipolygon (Aggregate) is composed by (components)
Polygon(s) that are composed by LinearRing(s). Some uneeded classes
(Surface) may be removed.

 - Layer.Vector : it's a generic vector layer. This type of layer as a
renderer for property as it is built and some methods to add, or
remove features.

 - Renderer : depending on the browser a VML or SVG renderer is in
charge to draw the geometries.

 - Parser.GML : allows to build geometries and features by reading gml
files. Is called by the WFS layer to read the server response.

 - Editing Tools : this was probably the trickiest part, and it
probably the most incomplete. First Bertil started with the Controls
to handle the editing tools but we thought that it might be better to
separate the controls and the mouse events handlers on the map. The
MouseListener class was created in that goal. All the editingListeners
classes inherits from it.
One more important thing to look at in particular are the different
snapping modes. Some are used for simple editing action to help user,
or sometimes required by tools (addPathPoint and segmentSnapping).

 - Layer.WFS : this last point was the icing on the cake and probably
most impressive usage of the vector functionnalities. I also think
that this would have to be detailed in a separate topic. A not so
simple tile and feature management is used, and a important code
review is probably needed.

What should be done (by the camptocamp guys) before the code is reviewed :

 - redraw the events handling design schema,
 - commit the incomplete but started to be written documentation,
 - remove the unused classes,
 - help other developper understand the code and answer most of the
questions they want ask.

So don't hesitate to inquire us.

To be noticed : I started to write unit tests at the very begining of
our work, but they are obviously incomplete.

As a conclusion, I would say that we would be proud to continue
contributing actively on this code as much as we can and we would be
interested to cooperate.

Regards

Pierre

On 2/14/07, Cameron Shorter <cameron.shorter at gmail.com> wrote:
> Erik Uzureau wrote:
> > Thanks a bunch for this summary, Cameron. This is a great start
> > towards the integration.
> >
> > For the moment at least, the breakdown of stage 1 / stage 2 seems
> > reasonable, and I think most of what we are immediately concerned with
> > (for the 5 day coding spree) is stage 1.
> >
> > I think we should tackle the following in this order:
> >
> >> * I'm not sure what the state of our UML design at the moment, but I
> >> suspect it should be updated.
> >
> > I did not know there was a UML diagram for this code. That would be a
> > huge help to see if you have it and it is accurate. Keeping in mind
> > that I know next to nothing about what has been done or how it works,
> > this is a great starting point for me at least to get the big picture
> > of how the code works. Could someone find that doc for us?
>
> This document is a bit out of date, but the general concepts have not
> changed much.
> http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design
>
> In particular, the source UML diagram is referenced from:
> http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design#Source_UML
>
> Pierre and Bertil had their own UML diagram. I'm not sure how up to date
> it is now, or where it is.
>
> >
> >> * It could do with a solid code review and a few changes in certain
> >> places. (I remember noticing a few things like functions being in the
> >> wrong package), but generally is was pretty good.
> >> * JSDocs were patchy in areas
> > Once the main design has been reviewed and approved, the next logical
> > step is to go over the code carefully, making sure it flows well with
> > the rest of the OL codebase. As we do this we can go along updating
> > the JSDOC tags.
> >
> >> * There was no wiki documentation
> > This shouldnt be too terribly difficult. The important thing to do
> > here is to write out a few basic tutorial style docs and make some
> > example html files that demonstrate the functionality. The idea that
> > we've been shooting for in OL is to make most of the API-ish
> > documentation automatically generated from the JSDOC tags. Assuming we
> > get those in place and uptodate, we shouldnt have to worry *too* much
> > about this.
>
> What is the current situation with regards to converting jsdoc tags to
> documentation?
> Do we have a tool that will convert these yet?
> Or is someone working to get such a tool to work for OpenLayers?
>
> >
> >> * There were no unit tests
> > This is a _must_do_ if we want to insure the integrity of the code for
> > future OL releases and development.
> Agreed.
> > My hope is that we will have time
> > to get some of the basic framework for the testing set up and
> > underway. Test writing is something that can easily be done in
> > parallel and without too much coordination effort, so we should
> > concentrate on getting the framework in place and then dividing up the
> > task for people to work on individually.
> >
> > I'll reiterate here that we are open to help with this from anyone out
> > there in the community who knows this code or who is interested in
> > getting to know it a little better. At this point, the major design
> > decisions have been made and implemented, so the idea is not so much
> > setting up a forum for ideas but rather more of a collective push to
> > put the final touches and polishing on this code and get it fully
> > integrated into the main branch.
> >
> > Thanks again to anyone interested,
> > Erik
> >
> >> Erik Uzureau wrote:
> >> > Dear Vector OLers,
> >> >
> >> > Hello there, my name is Erik and I'm one of the developers of
> >> > OpenLayers. My colleague chris schmidt passed me your three names as
> >> > the main people in charge of the Vector branch.
> >> >
> >> > I sent out an email a few weeks ago stating our intentions to try to
> >> > merge the Vector branch into the trunk (as a build option, of course)
> >> > and didn't get any feedback at the time. I thought maybe I would be
> >> > better off addressing the three of you personally.
> >> >
> >> > The reason I'm writing is that I am travelling to Boston for the first
> >> > week of March with specific instructions to pow-wow with chris and
> >> > schuyler (two other original OL developers) and do the integration.
> >> >
> >> > Lamentably, due to time constraints, I have not been able to follow
> >> > along the vector branch development as you guys have been working on
> >> > it, so I'm very out of the loop.
> >> >
> >> > Chris has been somewhat monitoring the list, but I know that it would
> >> > be enormously helpful for all of us if maybe one of the three of you
> >> > could send us a quick summary email of the status of the branch.
> >> >
> >> > How far along is the development? What remains to be done? Are there
> >> > any design decisions that remain to be taken? Unresolvable bugs?
> >> >
> >> > Part of the integration, of course, will be going through the code to
> >> > match coding standards, as well as producing at least some basic
> >> > documentation on how to use the new tools. Any help in this department
> >> > would of course be well received.
> >> >
> >> > I hope this email finds you well. We are excited to finally have the
> >> > resources (time) to dedicate to bringing this body of your work into
> >> > the main trunk and making it easier for more people to use it. Thanks
> >> > for all your hard work on this and hope to hear from you.
> >> >
> >> > Cheers,
> >> > Erik
> >> >
> >>
> >>
> >> --
> >> Cameron Shorter
> >> Systems Architect, http://lisasoft.com.au
> >> Tel: +61 (0)2 8570 5011
> >> Mob: +61 (0)419 142 254
> >>
> >>
> >
>
>
> --
> Cameron Shorter
> Systems Architect, http://lisasoft.com.au
> Tel: +61 (0)2 8570 5011
> Mob: +61 (0)419 142 254
>
>