[gdal-dev] OGR Feature Style Specification
ari.jolma at tkk.fi
Thu Apr 17 12:50:20 EDT 2008
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
> 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.
> 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
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).
> The only question remains: who has enough time and manpower to do this
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? :)
> Best regards,
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
More information about the gdal-dev