[OpenLayers-Dev] Vector Integration

[bchapuis]

Hello,

Thanks for your mail. For information Pierre comes back from holidays in
two weeks, but i will be available to answer your questions.

I have commit the doc files on the svn. For the unused classes, i think
that most of them are already removed.

regard,

Bertil




On Thu, 2007-03-01 at 19:14 -0600, Erik Uzureau wrote:
> 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
> > >
> > >
> >