[OpenLayers-Dev] Implemented a few features in our branch
dparker at forwardslope.com
Wed Nov 12 13:51:49 EST 2008
I've implemented a few features in our local copy of OpenLayers that we
needed for one of our projects. (I work for Forward Slope, Inc; contact
info in my signature). If you are interested in integrating any of
these into OpenLayers, I'd be happy to supply patches/set up a sandbox.
If some of these have already been implemented and we're just behind the
times, let me know!
1. Multiple geometries per feature. I want to have geometries in their
own named columns, but for now multiple geometries just stack up in a
geometry collection in the OpenLayers.Feature.Vector::geometry field.
2. Multiple symbolizers per feature. We need error estimations around
points to be rendered a certain way/differently than the points
themselves; it's kind of a hack right now, though.
Point/Line/PolygonSymbolizers end up storing their styling information
in "Point", "Line", and "Polygon" keys in the style hash and the
Elements-based renderers pick these out as necessary when iterating
through a geometry collection. It's especially hackish since the
'Geometry' element of a symbolizer is ignored since we only have one
3. Full OGC expression support. Add, Sub, Mul, Div, Function,
PropertyName, and Literal all as JS objects; the Comparison class should
use Expressions rather than strings as its operands.
4. Dynamic compilation of OGC filters and expressions. You can eval()
them to a new function and use that instead of having the Filter and
Expression objects evaluate themselves. (Actually, they do this
themselves by replacing their own evaluate() method when first called.)
I know eval is evil, but it speeds up filter evaluation in this case.
5. Support for TextSymbolizers. SVG only; supports 'Font', 'Fill', and
'PointPlacement' (kinda--AnchorPoint is ignored). 'Halo' could be
added, by creating another text node with a stroke before the text node
with a fill; it's not exactly what the OGC calls for, but it works.
6. Fuller support for SLD. I started this before running into serious
incompatibilities with the way the Elements renderers work. OGC
Symbolizers are read into Symbolizer objects. Everything that is
supposed to be a ParameterValueType is read into arrays of
strings|numeric literals|Expressions. When rendering features, every
symbolizer in every matching rule is rendered in reverse-painter's
order, allowing multiple symbolizers of any given type (like the example
of a road with a casing). The OGC says that any kind of symbolizer can
be applied to any kind of geometry. However, we have drawing layers
whose features can be points, lines, or polygons, and we need each
geometry type to receive one and only one symbolizer. I.e. we need to
specify how all three geometry types should look but without applying a
PointSymbolizer to a feature with a polygon as its geometry (which would
put a point at its centroid). However, it shouldn't be the case that
PointSymbolizers just don't apply to polygons as it could be useful,
such as labeling the centroid of a country's borders with its flag. I'm
stumped on this issue for now.
I want to convert the SLD reader to use recursive descent; the current
method accepts invalid contents and takes twice as much stack space as a
recursive-descent parser anyway.
7. A static lookupNamespaceURI function for the XML class. This is for
compatibility with IE and uses the built-in function where available.
Maybe a cross-browser DOM library would be a better approach?
8. Some other helper methods for the XML class.
Speaking of static methods, I notice methods in some classes that don't
refer to class members at all and only refer to functions that don't
refer to class members, either. These should be made static, I think.
They probably don't waste any extra memory per instance because of the
way js prototyping works, but still....
Also, should OpenLayers wrap its scripts in function literals like some
other libraries? This would allow locally-scoped aliases (var
Vector=OpenLayers.Layer.Vector;) which could be safely minified by, say,
the YUI compressor.
Forward Slope, Inc.
Work: 619 299 4400x214
Cell: 619 277 2591
More information about the Dev