Load style table directly from .ofs file

[nsands]

It may be useful to have a method that loads a style table directly from a .ofs file. Currently the method to load a style table from a text file does not recognise the .ofs format headers (first 1 or two lines) of an .ofs file and treats them as if they were style definitions.

The existing method OGR_STBL_LoadStyleTable() could be modified to ignore those lines (and to ignore any lines starting with a '#' perhaps also?). Alteratively, a separate method could be created for this slightly different behaviour.

See email discussion on this issue below.

---

Nik,

This is a good idea. The doc you specified needs a correction. The version string and style field lines are supposed to be commented out with a #.

The OGRStyleTable class has methods to save and load style tables. They assume neither empty lines nor comments. There is one method to Print that saves the styletable into a file in the .ofs format. We can implement a method that loads a styletable from such file. Do you have any other suggestions?

I suggest you create a ticket on this at http://trac.osgeo.org/gdal/#BugTracking

On Wed, Jul 30, 2014 at 10:17 AM, Nik Sands <nixanz@…> wrote: Hi Devs,

I'm just planning to convert my own 'in-house' drawing styles management to using the styles management built into OGR. The documentation at ​http://www.gdal.org/ogr_feature_style.html suggests that styles can be in a '.ofs' file to be automatically associated with a data source of the same name as the .ofs file.

But how about if the .ofs file is a stand-alone file passed directly to OGR_STBL_LoadStyleTable()? Eg, OGR_STBL_LoadStyleTable(table, "/path/to/styles.ofs")

In this case the first two calls to 'OGR_STBL_GetNextStyle(table)' will return the 'styles':

OFS-Version : 1.0 2014-07-30 14:38:36.392 Maps n Trax[47458:60b] StyleField : "style"

Which are of course not styles at all, but part of the .ofs specification.

From this, I assume that files passed into OGR_STBL_LoadStyleTable() should in fact NOT be .ofs files, but merely plain text files with raw style strings only (and no .ofs specifications).

Is this correct?

Would there be any advantage on getting OGR_STBL_LoadStyleTable() to ignore the first line or two if it is an .ofs file and those two lines match the spec?

Cheers, Nik.

OFS-Version: 1.0 StyleField: "style"

DefaultStyle: SYMBOL(c:#000000,id:"ogr-sym-3",s:5pt); PEN(c:#000000,w:2pt); BRUSH(fc:#80808080); LABEL(c:#000000,s:14pt,t:{title})

locality: LABEL(c:#000000,s:24pt,t:{title}) town: SYMBOL(c:#800000,id:"ogr-sym-3",s:10pt); LABEL(c:#800000,s:24pt,t:{title}) city: SYMBOL(c:#800000,id:"ogr-sym-3",s:15pt); LABEL(c:#800000,s:24pt,t:{title}) region: PEN(c:#000000,w:2pt); BRUSH(fc:#80808080); LABEL(c:#000000,s:28pt,t:{title}) country: PEN(c:#000000,w:2pt); BRUSH(fc:#80808080); LABEL(c:#000000,s:32pt,t:{title})

vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title}) vegetation_medium: BRUSH(fc:#80C080); LABEL(c:#004000,s:18pt,t:{title}) vegetation_high: BRUSH(fc:#008000); LABEL(c:#004000,s:18pt,t:{title}) water: SYMBOL(c:#000080,id:"ogr-sym-3",s:2pt); PEN(c:#000080,w:2pt,p:"18pt 8pt"); BRUSH(fc:#8080C0); LABEL(c:#000080,s:18pt,t:{title}) contour: PEN(c:#808080,w:1pt); LABEL(c:#808080,s:12pt,t:{elevation})

road_unsealed: PEN(c:#A08080,w:2pt,p:"10pt 6pt"); LABEL(c:#000000,s:18pt,t:{title}) road_minor: PEN(c:#A08080,w:2pt); LABEL(c:#000000,s:18pt,t:{title}) road_medium: PEN(c:#A00000,w:4pt); LABEL(c:#000000,s:18pt,t:{title}) road_major: PEN(c:#A00000,w:6pt); LABEL(c:#000000,s:18pt,t:{title})

route: PEN(c:#000000,w:2pt,p:"2pt 4pt"); LABEL(c:#000000,s:18pt,t:{title}) track: PEN(c:#000000,w:2pt,p:"10pt 6pt"); LABEL(c:#000000,s:18pt,t:{title}) rail: PEN(c:#000000,w:4pt,p:"2pt 5pt"); LABEL(c:#000000,s:18pt,t:{title}) cable: PEN(c:#000000,w:2pt,p:"1pt 6pt"); LABEL(c:#000000,s:18pt,t:{title}) ferry: PEN(c:#000080,w:2pt,p:"18pt 8pt"); LABEL(c:#000080,s:18pt,t:{title})

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.