[OpenLayers-Dev] Vector Integration

Pierre GIRAUD bluecarto at gmail.com
Mon Mar 5 08:55:15 EST 2007 

The IRC channel stands at irc://freenode/openlayers

Regards

On 3/5/07, John Cole <john.cole at uai.com> wrote:
> What is the IRC info for this?  I'd like to monitor it.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: dev-bounces at openlayers.org [mailto:dev-bounces at openlayers.org] On
> Behalf Of Pierre GIRAUD
> Sent: Monday, March 05, 2007 6:47 AM
> To: bchapuis
> Cc: Eric Lemoine; claude.philipona at camptocamp.com; openlayers
> Subject: Re: [OpenLayers-Dev] Vector Integration
>
> Hello all,
>
> There is a misanderstanding with Bertil on my holidays.
> I'm happy to tell that I'm back to the office this week.
>
> And I have 8 hours scheduled this week to help for the vector
> integration (answering questions, helping anderstanding the code, etc
> ...).
>
> Don't hesitate to ask. I'll be available on the IRC channel, and also
> on google talk (pierre dot giraud at gmail dot com, bluecarto at gmail
> dot com)
>
> Regards
>
> Pierre
>
> On 3/2/07, bchapuis <bertil.chapuis at camptocamp.com> wrote:
> > 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#Sour
> ce_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
> > > > >
> > > > >
> > > >
> >
> >
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.7/711 - Release Date: 3/5/2007
> 9:41 AM
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.7/711 - Release Date: 3/5/2007
> 9:41 AM
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
>

More information about the Dev mailing list