I need to implement a custom renderer for a FeatureLayer that generate symbols based on some GeoElement attributes. The problem is that in API 100.1.0 it's impossible to subclass abstract Renderer class because the getSymbol method isn't abstract or virtual. What's the meaning of declaring Renderer as abstract without an abstract getSymbol method?
Any suggestion/workaround?
Thanks in advance.
Mauro
Hi,
Please can you provide more details about the symbols, rendering, and attribute data you would like to use?
Cheers
Mike
Hi Mike,
the problem I'm trying to address is displaying a FeatureLayer based on a ServiceFeatureTable using custom-generated PictureMarkerSymbols.
These symbols are available as bitmaps exposed by a symbol server via a REST service which needs the symbol code as parameter.
For example:
http://symbolserver.mydomain.org/symbol?code=123
The symbol code is available as a feature attribute defined in the feature table.
If I could create a custom Renderer I would implement getSymbol method to retrieve my symbol based on the code in the GeoElement parameter, build a PictureMarkerSymbol and return it.
I know that I could query the ServiceFeatureTable, loop returned features and use a GraphicsOverlay to draw them using Graphics with custom PictureMarkerSymbols.
I would really prefer to use a FeatureLayer with all the advantages of the optimized auto-management of the underlying ServiceFeatureTable.
I noticed that Renderer class in the Java Runtime SDK 100.1.0 doesn't have this limitation, being defined abstract:
I would like to know if it is a mistake in the .NET API 100.1.0 or if there is any reason to limitation.
I would also appreciate any possibile workaround for my use case that let me still use a FeatureLayer.
Cheers.
Mauro
Custom renderers are not supported.
> What's the meaning of declaring Renderer as abstract without an abstract getSymbol method?
It's abstract so the concrete classes SimpleRenderer, ClassBreakRenderer and UniqueValueRenderer etc can implement it.
Due to the underlying native classes, there's at this point no extensibility model for renderer. It would be way too expensive to call back out to managed code generate a symbol for each feature getting rendered during the rendering cycle. It would also break the sharing model throughout the entire ArcGIS System.
The point of the GetSymbol method is for your code to be able to figure out which symbol a specific feature would be rendered with (which could be useful for popups, legends etc). The point isn't for generating custom renderers.
You can use the graphics overlay and assign a symbol to each graphic individually, or even better look into using visual variables in the upcoming release to better control symbol rendering with more advanced rules.