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

Cameron Shorter cameron.shorter at gmail.com
Sun Nov 12 14:20:22 EST 2006


Paul, a lot of good suggestions in here.

My only addition to your suggestion which I've been pushing is that we 
split the current Renderer class into one Renderer class and a Sheet class.

Renderer contains a paintGeometry function, and uses Geometry+Style to 
build drawing requests.

Sheet contains the base vector rendering functions: drawLine(), 
drawCircle() ...

We then create SvgSheet, VmlSheet, CanvasSheet etc.

This keeps the Graphics code seperate from the GIS code.

Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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




More information about the Mail_webmap-discuss mailing list