[OpenLayers-Dev] Implemented a few features in our branch

[Tim Schaub]

Hey-

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.

Tim


> 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.
> 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.