[gdal-dev] OGR Feature Style Specification

[Tamas Szekeres]

Ari,

This sounds interesting, however I cannot imagine the actual
implementation of that. There's a couple of questions I have in my
mind related to the feature styles, some of these may be due to the
lack of my knowledge about the SVG feature styles.

1. Do we have an exact mapping between the OGR and the SVG style
parameters. Is OGR currently have a subset of the SVG style set?
2. The OGR style string is fairly compact and easy to parse. How about
the SVG style representation from this aspect? Note that we might want
to store the style strings in a separate field per feature even if the
data source has no built in style support.
3. Will this change affect the OGR Support Classes described in
http://www.gdal.org/ogr/ogr_feature_style.html
4. Can someone consider which drivers have built in style support and
what are their requirements to incorporate? The current approach seems
to be a mapinfo-ish implementation but in the meantime there might be
other drivers have been added to the pool with different requirements.
5. How about the compatibility issues with the existing applications?
Would it be easy to migrate their existing scripts. For example if the
application use the WHERE OGR_STYLE LIKE 'BRUSH' according to
http://www.gdal.org/rfc6_sqlgeom.html ?

Further issues:

6. Can we support the dataset/layer level default styles as described
in the OGR Feature Style specification but haven't been implemented
yet?


Best regards,

Tamas


2008/4/17, Ari Jolma <ari.jolma at tkk.fi>:
> People,
>
>  As discussed in the OSGeo-Discuss list, there might be an interest, need,
> etc. to rethink feature styles. My suggestion would be to look into the SVG
> specification and refer to it as much as possible. Also something meta to
> that would be useful, i.e., saying that this feature is to be rendered using
> this symbol, and the symbol would be presented as a SVG snippet. I'd also
> like to render raster cells using symbols, the best known example being
> perhaps the flow direction arrow of raster DEMs.
>
>  The issue of rules - which symbols to use and tieing symbols and their
> properties into feature attributes - is perhaps unavoidable. It could be
> handled using the OGC symbology encoding spec (which also uses SVG styles),
> but does the whole thing get too big or out of scope for GDAL? One easily
> gets carried away. For example once we have SVG style and the geometry
> available, we could spit out SVG paths... which brings up the idea of having
> line simplification in OGR, etc...
>
>  If thought sensible in the first place I could try writing down this as a
> RFC.
>
>  Regards,
>
>  Ari
>
>  --
>  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
>
>
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>