[webmap-discuss] vector layer - GML parsing and rendering - first test

[Paul Spencer]

Some comments on the code:

Layer.Vector

* doesn't use Renderer.getBestRenderer (which seems like an oversight)
* I think getBestRenderer needs to be moved into Layer.Vector and  
Renderer needs to be the base class for all renderers (see below)

Renderer base class ...

It seems to me that there are a lot of functions that are required of  
a renderer but these are not 'documented' in the base class.  This  
makes it difficult to understand how to implement a new renderer  
(like Canvas).  We need to create a base class Renderer that has all  
the public and private functions and attributes that external code  
relies on, and then subclass this for each of Vml, Svg, Canvas, and  
whatever else (wz for instance).

Here is my quick summary of the Svg and Vml code as I see it in svn:

(- means I think it is a private member, + means I think it is a  
public member)

Attributes:

+ eventManager (accessed directly in Layer.Vector)
- root
- style (note initialized directly rather than using Style class)
- svgns (in Svg only)
- vmlns (in Vml only)
- container (not declared)
- vmlRoot (not declared, in Vml only)
- svgRoot (not declared, in Svg only)
- rootWidth  (not declared, in Vml only)
- rootHeight (not declared, in Vml only)
- divWidth (not declared, in Vml only)
- divHeight (not declared, in Vml only)

Public Methods:

+ initialize (implicitly called by new operator)
+ setStyle
+ getStyle (in Svg only)
+ observe (called from generic code in vector.html)
+ dispose
+ setEventManager (called from Layer.Vector)
+ drawRoot (called from Layer.Vector)
+ clearRoot
+ setExtent (called from Layer.Vector)
+ setSize (called from Layer.Vector)
+ highlightGeometry (in Vml only)
+ drawGeometry (called from Layer.Vector, Control.Editing)
+ eraseElement (called from Layer.Vector, Control.Editing)

Private Methods
- triggEditingEvent
- drawPoint
- drawRectangle
- drawCircle (in Svg only)
- drawEllipse
- drawLineString
- drawLinearRing
- drawPolygon
- drawCurve
- drawSurface
- _setStyle (in Svg only)
- _getFillElement (in Vml only)
- _getStrokeElement (in Vml only)
- _getVmlBoundingBox (in Vml only)
- _nodeFactory
- _vmlParseFloat (in Vml only)

I am going to propose some changes based on the following comments  
and observations:

* I don't like Style being a part of the renderer.  I think the Style  
should be associated with the layer and geometry objects

* I don't like using a new renderer instance for each layer, I think  
it would be better to use a single renderer for multiple layers

* I don't like the way the eventManager and observe/dispose work.  It  
seems difficult to follow how it works.  It also won't work if the  
above change is made.  I think this can be moved into Layer.Vector  
without too much difficulty by:

   - overloading setMap in Layer.Vector and registering for the  
events there
   - generic eventHandler function in Layer.Vector that calls  
this.renderer.GetGeometryFromEvent on renderer (for Vml/Svg, this  
would be the basic

This seems a lot cleaner to me.

* drawRoot/clearRoot renamed to attach/detach - attach a renderer to  
a layer.

* I think setExtent and setSize should be merged and setExtent should  
take top, left, width, height in pixel positions (managed by the layer)

* there are some implementation details and concepts in Vml and Svg  
rendering that have no meaning in Canvas and don't really seem to fit  
the model.  The big one seems to be that in Vml and Svg, the rendered  
element is actually a dom element and needs to have an id and be  
attached in the dom somewhere.  There is no parallel for this in  
Canvas.  I am undecided as to whether this is a problem and how to  
deal with it.  We can either go with the Vml/Svg model and just  
ignore stuff in Canvas, remove it in the general case and create a  
new sub-class for vector-based renders (yuck), or move the  
implementation details of Vml/Svg into the code rather than the  
public interface (my preference).

I've committed a new version of Renderer.js to the vector sandbox  
(since I don't think it will break anything - it wasn't used anywhere  
AFAIK) that implements my proposed base class.

There are some changes that I would like to make to the Svg and Vml  
renderers to implement the new architecture.  I'm hoping to have a  
bit of time today to work on that plus the start of a Canvas renderer.

Cheers

Paul

On 10-Nov-06, at 1:53 AM, Pierre GIRAUD wrote:

> I do know that the OL team tries not to depend on prototype. It was
> debated at the FOSS4G meeting.
> I think that the only method I'm using is the each() iterator. It
> wouldn't be difficult to rewrite it and include it OL.
> I will try today. Or I would be pleased if someone helps.
>
> Regards
>
> On 11/10/06, Cameron Shorter <cameron.shorter at gmail.com> wrote:
>> Pierre, Bertil,
>> I notice you have a dependancy upon prototype.js.
>> As I understand it, Openlayers are trying to break this  
>> dependancy. Are
>> you able to remove the requirement for prototype?
>>
>> Pierre GIRAUD wrote:
>> > Sorry, was thinking Firefox (not Safari) !
>> >
>> > On 11/9/06, Steven M. Ottens <steven.ottens at geodan.nl> wrote:
>> >
>> >> Looks good, it works in firefox as well, strangely not in flock a
>> >> mozilla based browser which I use besides my heavily pimped  
>> firefox. It
>> >> takes a few seconds to load/parse the gml (about 10 rough  
>> count) and
>> >> after that it's fast
>> >>
>> >> Steven
>> >>
>> >> Pierre GIRAUD wrote:
>> >> > At the url below you will find a first quick and dirty test  
>> for a GML
>> >> > parser (WFS file).
>> >> > It loads a xml file (that simulates a WFS response) and  
>> renders the
>> >> > features geometries on the map.
>> >> > May only work on safari for the moment.
>> >> >
>> >> > Note that the datastore (us intersate) comprise 13379 vertices.
>> >> >
>> >> > http://dev.openlayers.org/sandbox/bertil/examples/ 
>> wfs_features.html
>> >> >
>> >>
>> >>
>> >> --
>> >> Geodan S&R Amsterdam
>> >>
>> >> -------------------------------------
>> >> Geodan S&R
>> >> President Kennedylaan 1
>> >> 1079 MB Amsterdam (NL)
>> >> -------------------------------------
>> >> Tel: +31 (0)20 - 5711 311
>> >> Fax: +31 (0)20 - 5711 333
>> >> -------------------------------------
>> >> E-mail: steven.ottens at geodan.nl
>> >> Website: www.geodan.nl
>> >> Disclaimer: www.geodan.nl/disclaimer
>> >> -------------------------------------
>> >>
>> >>
>> >>
>> >>  
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
>> >> For additional commands, e-mail: webmap-discuss- 
>> help at mail.osgeo.org
>> >>
>> >>
>> >
>> >  
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
>> > For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org
>> >
>> >
>>
>>
>> --
>> Cameron Shorter
>> http://cameron.shorter.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
>> For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org
>

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+