OGC Symbology and SLD for mulitpoint geometries

Feb 27, 2012 at 11:59 AM
Edited Feb 27, 2012 at 12:44 PM

Maybe this question is a bit off-topic regarding to milsym or too general... but might be interesting for thoughts about the ongoing development of multipoint geometries in your catalogue.

The OGC has standards defined for Symbology definitions but they are mostly focused onto point symbology (e.g. for placing a raster icon or font symbol onto a specific map point) or there is a tight coupling between geometry and visualization if using e.g. polygon symbolizer.

I expect those problems using OGC conformant aproach:

1. I don't see any default "multipoint" symbolizer, only a point symbolizer, a line symbolizer and a polygon symbolizer. Line and polygon symbolizers both don't fit because they only styles the line/polygon geometry ( => abstaction to mil2525c multipoint geometries and styling them using sld would be very complex... not to say impossible.)

2. Point symbolizer can call a mark factory (e.g. see GeoTools interface/implementation docs at http://docs.geotools.org/latest/javadocs/org/geotools/renderer/style/MarkFactory.html) to get a shape instead of a raster based symbol but there is no general approach to handle anchor points in a default manner.

3. If using the 2nd. approach using a point symbolizer: The problem of storing vector based data for symbology generation is not solved. ("Hand-made" generation by building the geometry seems to be an option, but is difficult to analyse or edit. What type is shape in the .net world or what would be the "universal" equivalent (System.Windows.Shapes.Path)?

IMHO: The MilSym project solves some of the "hand-made" hassles by storing the geometry and the anchor related points for transformation itself in a dictionary (see point 3). So this could be a good backing for a symbol generation lib (for mil2525c), especially because of the copy and paste ability to extend or manipulate the catalogue. (Easy task for single point symbols, should be the same for multipoint symbols, too.) Keep in mind when using this in multi-threaded environments: STAThead is required because of the strong dependency to WPF/Silverlight. Currently the usage is focused for bing maps / google maps based gis systems (with static scale lod) but the catalogue (Appendixes with symbol dictionaries) is already an independent build from the usage (through MilSym classes). But currently the MilSym itself needs to be more be flexible to use this lib in non-WPF-Clients without static scale lods. There is a starting point of abstraction creating an own MilSymFactory (see EsriSupport or BingSupport for example) but those provider libs are tightly coupled to WPF itself.

Does anyone know existing "multipoint" symbol storages with anchor definitions and corresponding standards (in .Net-World)?
Is there an interest to use such a storage mechanism in MilSym in the future (if existing) or to develop an access mechanism to get transformed "Shapes" (e.g. by using proj4 lib (as used in DotSpatial)?

An interface method like

TransformedShape GetTransformedShape(string sidc, double[] anchors, Projection proj, ...)

=> could be backed in a MarkFactory and called via uri as wkicon://GUTPY----*** together with geom/feature attributes. Would be cool to have such a powerfull lib accessible through SLD, don't you think so?

This article might be interesting related to mil2525* and symbol catalog access using SLD:


See http://docs.geoserver.org/latest/en/user/styling/sld-cookbook/points.html#example-points-layer for an example of Styled Layer Descriptor usage.

There is also a discussion about this topic: