OGR Autostyling and other providers, styling RFC?

[Tamas Szekeres]

2007/11/19, Frank Warmerdam <warmerdam at pobox.com>:
> I have prepared a patch that implements automatic use of a field named
> ogr_style using normal OGR->mapserver style conversion rules in my local
> tree.  But it has a number of "issues".
>
> 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.
>

Frank,

I don't think it's a good idea to utilize OGR specific things in a
different driver, unless we consider the OGR style strings as a
defacto standard for holding the style information. But  I guess the
primary purpose of this item is mainly to display the style, but
parsing this item in every feature might be quite sub-optimal.

BTW why don't we use the OGR postgis driver and implement this effort
at ogr level instead?

> 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 would be reasonable to extend this and it could be driver
independent as well. In this case IMO the driver wouldn't bother too
much with the actual contents of this field it could be processed at
the upper level rendering code.

> 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?
>

I'm afraid I couldn't follow this exactly. Currently the GetAutoStyle
function is called per-feature during the layer drawing process.

But my other problem related to this is that the style info is
assigned to the features but we cannot utilize layer level styles at
the data source. Therefore loading the styles happens in that time
when the features are actually drawn and the last loaded style is
preserved at layer level. Currently I have approx 3000 OGR layers with
syle info but I guess all of them use the same style for each feature
actually. This behaviour causes some known issues (like the problems
around rendering those layers in the legend) that have been been
discovered early but haven't been addressed yet.

> 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.
>

I consider feature level styles (at the data source) is beyond the
reason, definitely. Why do we conceptually want to group these
"randomly styled" features in the same layer at all? If we have some
rules for assigning different styles (like colorramp etc.) why don't
we implement such algoritm at the layer renderings.
Why don't we do some kind of normalization like storing only the
different styles in a different table and use style indexes at the
features instead. This could either have a generic implementation at
mapserver level or OGR level.

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

No. I guess we should tend to be mapserver specific at this point.

> 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?
>

That would be great but the implementation should be driver independent I think.

Best regards,

Tamas