This "proposal" (more case of technical dept) will clean up the style interfaces by:
- Introduce read-write GeoTools interfaces for any new Symbology Encoding constructs
- Restoring setters methods; the only deprecations will remain those where a clear alternative is available (example setTitle is now getDescription().setTitle )
- TypeNarrow getters to be explicit about the GeoTools interface returned for any aggregations. Example: getDescription() will return the geotools Description interface
- Completing the StyleFactoryImpl2 implementation; this is an implementation of geoapi style factory where the created results are type-narrowed to explicitly be the GeoTools interfaces
- Updating StyleFactoryImpl to delegate to StyleFactoryImpl2 for the new "create" methods
Good ideas not included in this proposal:
- There is no new builders defined by this proposal
- The renderer will not be updated to account for new Symbology Encoding ideas like UoM
- Symbolizer GeometryPreProcessing will not be added
While the GeoAPI interfaces will be left in the mix as super classes (providing a read-only interface) the GeoTools codebase will continue to make use of the GeoTools interfaces which will offer a read-write extension. This arrangement allows us to use the excellent work that went into producing Symbology Encoding 1.1 interfaces while preserving our current work flow.
I would appreciate a timely response on this as:
- a group is working on UOM support which is one of the features of the SE 1.1 interfaces
- I am putting together a GeoTools tutorial and I cannot do so with the current number of deprecations
This proposal has received the following votes:
- Restore Setter methods for 2.5.x; and prepair patch
- Apply patch to 2.6.x; and proceed with extending any geoapi classes required (this is a formal review of the geoapi interfaces so some changes to the interfaces will be requried - some of the visit method for example are inconsistent)
- Go over StyleFactory from geoapi and make sure it is complete; it is complete when it can completely copy an existing style using a StyleVisitor
- With 2.6.x cleaned up the documentation examples can be updated; the documentation examples are stored in demo
- Andrea started a StyleBuilder in the "literate" of AttributeTypeBuilder rather than the existing StyleBuilder class which basically will fill in null values for you.
- Clone - the style classes are clonable; but not very well done. I have reports of people using this in the field so I am hard pressed to know how to kill it
The following lists one example (ContrastEnhancement); the same approach will be used to update all of the interfaces including the Symbolizers and FeatureTypeStyle.