OGR Autostyling and other providers, styling RFC?

Daniel Morissette dmorissette at MAPGEARS.COM
Mon Nov 19 17:15:48 EST 2007

Frank Warmerdam wrote:
> 1) I have to trick the Postgres provider into including the ogr_style
> field in the request.  Currently I do this by having a bogus expression
> using the [ogr_style] field on the class.

I presume this is because STYLEITEM "my_style" was never fully 
implemented. If/when we do support it then I guess msLayerWhichItems() 
should be modified to pick up the style attribute and include it 

> 2) Things are hardcoded to a particular field name.  I'm guessing from the
> way that STYLEITEM "AUTO" is setup, that the original intent was that a
> field name could be the argument to STYLEITEM, instead of "AUTO", but that
> this was just never done.  Likewise the styleitemindex field does not 
> appear
> to ever be actually used currently.

That's correct, the original intent was to eventually be able to support 
reading the style string from an attribute but that's never been 
implemented. STYLEITEM AUTO is really what the users were asking for, so 
that those who wish to keep their data in MapInfo format can be up and 
running quickly. There has never been much demand for reading styles 
from an attribute.

> 3) The msPOSTGISLayerGetAutoStyle() is currently implemented to assume that
> the style comes from the last record read with msPOSTGISLayertNextShape().
> Does autostyling really need to work with "randomly read" features?  Is
> it used ever to style query results?
> 4) I can't help but wonder if the GetAutoStyle() function shouldn't pass in
> the shape being operated on instead of passing in the tile/record 
> values. In
> some/many cases the style will be right in the shape.

Without having reviewed the code, I can't think of uses of those 
functions other than to fetch the style info for the last shape that was 
read, either via NextShape() or GetShape(). Actually, my comment in 
msLayerGetAutoStyle() suggests exactly that as the optimal usage 
scenario and thinking about it some more we could probably ditch the 
tile and record attributes and make the function operate on the last 
shape read since this is the only way it is being used now:

** Fills a classObj with style info from the specified shape.  This is used
** with STYLEITEM AUTO when rendering shapes.
** For optimal results, this should be called immediately after
** GetNextShape() or GetShape() so that the shape doesn't have to be read
** twice.
int msLayerGetAutoStyle(mapObj *map, layerObj *layer, classObj *c,
                         int tile, long record)

> 5) Do we want to support non-OGR styling mechanisms in data providers?  
> Should
> there be styling "dialects"?

I think Tamas has a point when he writes that he doesn't think we should 
be using OGR style strings in non-OGR drivers... unless we consider OGR 
style strings to be a standard... if we decide to push for wider 
adoption of OGR style strings then I think at a minimum we'd need to 
some work to cleanup the style string document 
(http://gdal.org/ogr/ogr_feature_style.html)... I'm not too happy with 
the way it is at the moment.

If we want a standard then we should probably consider using SLD 
constructs (symbolizers) instead for non-OGR drivers... but I'm not sure 
that I prefer that option...

> I'm considering writing an RFC to broaden the "STYLEITEM" mechanism to more
> providers and to pulling the style string from an arbitrary field.  Can 
> anyone
> think of stuff I ought to take into consideration in writing up such a 
> thing?

If we follow Tamas' logic and do not let non-OGR providers use OGR style 
strings then that RFC could become a huge piece of work.

Daniel Morissette

More information about the mapserver-dev mailing list