[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 Webmap-discuss
mailing list