Re: Vector Integration

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

Cameron Shorter
Erik,
Excellent to see this moving forward, and welcome to the vector branch
team. :)

I stopped work on the vector  branch around Christmas when the OGC
Testbed project that was funding me completed.

I assume Pierre and Bertil have extended the work further since then.
But they can talk to that.

I think we can target this is two stages if we want to.
Stage 1: Vector rendering / GML parsing / preliminary WFS

Stage 2: Add in tools.
Bertil was doing some good work with editing tools.

At Christmas, this was the state of the code:

Stage 1:
* Vector rendering code worked without any bugs.
* GML passing works
* I think Pierre has a WFS layer working. Although this is a complicated
issue to address if done properly. Issues like. Should you use tiling on
WFS? What do you do about features that cross tiles? Do you try to
minimize the features loaded. Etc.
* 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
* There were no unit tests
* There was no wiki documentation
* I'm not sure what the state of our UML design at the moment, but I
suspect it should be updated. This was a useful method of communicating
design, and would probably be worth maintaining for all of the
OpenLayers codebase. (Although this may be out of scope, as there is a
day or two involved in setting up a simple UML diagram for a project
this size - unless you can find a JS->UML translator)

Stage 2:
* Bertil had a number of vector editing tools working.
* However we didn't have a decent concept of a toolbar. This should be
addressed as part of stage 2. Of note, it ties in very closely with the
Mapbuilder integration with OL because we need to link from the
Mapbuilder tools to the OpenLayers tools, and this probably should be
done through the toolbar. Olivier Terril is currently looking at this
problem from the Mapbuilder end. Refer to
http://trac.openlayers.org/ticket/417



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

_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

Erik Uzureau
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?

> * 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.

> * 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. 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
>
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

Cameron Shorter
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

_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
> >
> >
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

Bertil-2
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 <[hidden email]> 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 <[hidden email]> 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
> > >
> > >
> >

_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

Pierre GIRAUD
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > > >
> > > >
> > >
>
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

John Cole X
In reply to this post by Cameron Shorter
What is the IRC info for this?  I'd like to monitor it.

Thanks,

John

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Pierre GIRAUD
Sent: Monday, March 05, 2007 6:47 AM
To: bchapuis
Cc: Eric Lemoine; [hidden email]; 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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.
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Vector Integration

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

Regards

On 3/5/07, John Cole <[hidden email]> wrote:

> What is the IRC info for this?  I'd like to monitor it.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Pierre GIRAUD
> Sent: Monday, March 05, 2007 6:47 AM
> To: bchapuis
> Cc: Eric Lemoine; [hidden email]; 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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.
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev