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. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
