OGR Autostyling and other providers, styling RFC?

[Frank Warmerdam]

Tamas Szekeres wrote:
> 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.

Tamas,

I am not aware of any overhead to having autostyling support
for a provider when it isn't in use.  If STYLEITEM is not "AUTO"
then the GetAutoStyle() virtual table function is never called
and there is no special processing.

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

This is possible, but imposes some limitations and performance loss due
to the extra layer of abstraction.

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

Note that STYLEITEM is not enabled unless the keyword appears in the
layer description.  Most OGR datasets are processed without use of
ogr autostyling (really OGR stored-with-feature-styling).

I agree that autostyled layers are likely hard to put properly in the
legend.

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

I would like to stress that the objective here is to support datasources
that intrinsically hold per-feature styling.  In OGR this is only (I think)
the Mapinfo and DGN drivers.  But this sort of behavior is very common with
CAD oriented data.  Often each feature in such formats has it's own color,
and other drawing characteristics.

I'm not suggesting this as a good approach, I'm just trying to make such
data reasonably renderable in MapServer.  And by extending the handling
to other data providers, I'm hoping that folks won't be locked into keeping
their data in the original format.

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

I'm not sure I understand what you mean by driver independent.  Currently the
plugin api defines a LayerGetStyleInfo() function which is called if the
styleitem is "AUTO".  So by this approach any data provider could implement
styling specific to their own datasource though in practice the only one using
this is OGR.

My current thinking is that using OGR type styling would be the default
behavior if STYLEITEM is set, and the data provider does not have any
override for the GetStyleInfo() method.  So ogr support would in a sense
be driver independent, in that it would be available for all providers that
don't override with some specific behavior for themselves.  However, it would
be dependent on the OGR library which is used to parse the style descriptions.



Daniel Morissette wrote:
 >> 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.

Improving the ogr_feature_style.html document is a bit beyond what I'm
really wanting to address at this time.  I am concerned about building
too much stuff around OGR style strings since I consider them a bit of
an evolutionary dead-end (but one that might well last another decade in
useful use).   But to me, what I'm proposing just taking advantage of
existing features (ogr to mapinfo style string handling).

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

This is why I wondered if we might need "style dialects", with the hope
of eventually adding more standards based styling mechanisms such as
SLD.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org