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!
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. -- Dustin Parker Forward Slope, Inc. Work: 619 299 4400x214 Cell: 619 277 2591 0tDaX0iWmunqkiR2WKCNG vHUT0iWqSJHZYoI0a8d1p E9Ilprp6QZrogbPZYoI0a 8aA0ekDQ6eyxQRo146A== _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
