[OpenLayers-Dev] Vector Integration

[Erik Uzureau]

Pierre et Autres,

Thank you so much for the detailed email! Apologies that none of us
has gotten back to you sooner but as usual, things have been very
crazy over here and we havent had a spare moment to think about
openlayers or the vector stuff.

Luckily, all that will change come monday, when we converge on Boston
to tackle the code full on. Your notes here will of course be
invaluable.

A question on a couple of the items that you mentioned should be done
before the week gets started:

 - commit the incomplete but started to be written documentation,
 - remove the unused classes,

have these happened? can they?

I believe that the general plan that we are are all taking is to spend
a few hours tomorrow or over the weekend to look through the code and
get a general sense of what it does and how it works.

On monday morning we will have a meeting to discuss the state of
affairs, organize the week and divide up tasks.

Is there a good way that we could get into contact with you guys via
IM ? If any of you will be available starting at about 9am (gmt -5)
That is when we will be having our initial discussion.

Thanks again to everyone for their helping getting things ready for
this week. It's going to be a bit of a mad rush, but we're all really
excited to get this code in the trunk!

Best,
Erik




On 2/19/07, Pierre GIRAUD <bluecarto at gmail.com> wrote:
> 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
> >
> >
>