[OpenLayers-Dev] Implemented a few features in our branch
tschaub at opengeo.org
Thu Nov 13 16:35:09 EST 2008
Dustin Parker wrote:
> Hello all,
> 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!
This is a really impressive list of features. Looks like you have done
some great work.
It would be terrific to see this as a list of tickets with patches.
That is obviously a lot of work. If there are features that you think
are easier to contribute, please ask for any help you need.
> 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
> geometry column.
> 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.
OpenGeo - http://opengeo.org
Expert service straight from the developers.
More information about the Dev