[gdal-dev] OGR Feature Style Specification

[Ari Jolma]

Andrey Kiselev kirjoitti:
> I am the one who like to see more powerful and flexible style
> implementation in OGR. OGC adopted the style specification not that long
> ago:
>
>  http://www.opengeospatial.org/standards/symbol
>
> and it is quite suitable for my needs at the moment.

I also agree that this is definitely the spec to start. I does not do 
all that I want but almost.

> Also I do not think
> that the old OFS spec and implementation should be obsoleted in any way,
> these two can co-exist together. It can be done just like the coordinate
> system support: internal style handling model (based on OGC spec) and
> number of import/export functions for particular style formats.

Yes.

> Old
> style will be one of the possible formats. The old API remains untouched
> and complemented of the new style handling API, I am sure we can do that
> without sacrificing backward compatibility.
>   

After looking some time at the symbology encoding it seems to me that 
the new API would connect to the existing API in a couple of places:

- CoverageStyle object is associated with GDALDataset and OGRLayer 
objects (need get and set methods). I.e. if a driver produces either 
object, it should also produce a CoverageStyle object, if there is style 
information available. Also a CoverageStyle object can be created and 
associated with Dataset or Layer objects. If a driver saves those, it 
should also save the style information in its native format. 
CoverageStyle can also be independently stored/read from symbology XML
- CoverageStyle objects contain rules, which should be supported in 
OGRLayer as a new SetRuleFilter method

This might be all that's needed. I currently don't see the point of 
having a top level FeatureStyle class since we more or less always deal 
with coverages in programs and real data exist as coverages.

The drivers and others then of course need an API to construct or query 
CoverageStyle objects, but this is separate from existing GDAL API.

For applications that use GDAL for accessing data that is to be 
rendered, CoverageStyle objects need to provide some services to know 
how a particular feature is to be rendered. These are also separate from 
the existing API. Generally, the style to be used is defined by the 
rule, which is known, if it is used as a filter, or there should be a 
method to test whether a given feature matches the rule. Additional 
information (for rules that apply to specific scales) that is needed is 
scale.

Things that I'd like to add to the OGC spec are:

- render raster cells with symbols (the flow direction arrow!)
- render polygons as symbols or as labels (eliminate the need for point 
features; placement algorithms needed!)
- scale rules should be usable also when rendering to SVG, PS or such

BTW, this might be what Markus was looking for in the first place. This 
could be a separate library also.

> I think we should go with the OGC specification, because I do not see
> how pure SVG styles will suite our needs (needs of geography mapping).
>   

I agree.

> The only question remains: who has enough time and manpower to do this
> work?
>   

The third option would be of course money (which is sometimes tradeable 
with university credit points). But I would ask, can we afford not to 
begin it? :)

Cheers,

Ari

> Best regards,
> Andrey
>
>   


-- 
Prof. Ari Jolma
Geoinformatiikka / Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma