OGR SFS Specification and style of point features problem

[nil5-ksa@…]

I have found the bug in MapInfo driver for OGR.

There is follow MIF file:

--top of MIF file
Version 300
Charset "WindowsCyrillic"
Delimiter ","
CoordSys Earth Projection 1, 0
Columns 2
  ID Integer
  Code Char(8)
Data

Point 36.145654 54.531409
    Symbol (45,0,10,"MapInfo Weather",0,0)
--end of MIF file

So, I have follow style string (by calling OGRFeature::getStyleString()):

SYMBOL(a:0,c:#000000,s:10pt,id:"mapinfo-sym-45.ogr-sym-8").

There is no information about font name in that style string. And there is no 
ability to get the information, so that information is lost!

 I have developed a patch (for OGR 1.2.3), which helps to get that
 information. But it's implemented only for MapInfo files. (MIF/MID and
TAB).
 And I tested it only for MapInfo files. But I think, that it does not have
 effect for other formats (bad effect, of course :)  ).
 I suggest, it is nesessary to change OGR Simple Feature Style Specification
 by adding new parameter in Symbol Tool parameter set. Parameter
 'font name' ("f").

Patch is attached.

[nil5-ksa@…]

patch for this bug report

[warmerdam]

Same patch uncompressed for easy viewing.

[warmerdam]

Sergey,

I also need the proposed update to the specification document. 

[warmerdam]

ksa wrote:
> Frank, I don't get your email with asking for some clarifications... sorry.
> Could you send me your email again?
> 
> And I will submit my suggestions via bugzilla.
> 
> Sergey Karin


Sergey,

I am embarrassed to admit I can't find the email.  I am starting to wonder
if I just thought about sending it.   In any event, the gist of it was
that your changes look pretty good, but that I would like you to write up
the proposed change to the specification document. 

You change adds fonts for point symbols, right?  Previously symbol ids
were relatively abstract things.  Is there some standard way that the
symbol id would now be used to select the symbol from the indicated font
definition? 

Is the font to be interpreted similarly to the font attributeof the label 
object?  

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

[Daniel Morissette]

Frank, Sergey, I'm not sure that font names belong in symbols. I know that
MapInfo and a few other packages do that, but the StyleStrings tries to be
generic and avoid implementaation-specific things like that. (Wheteer that's
good or bad I don't know)

To be consistent with the way other symbol types work, pershaps we should encode
the font name as part of the symbol name, e.g. 

SYMBOL(a:0,c:#000000,s:10pt,id:"fontsym-Wingding-45.ogr-sym-8").

Sorry for not responding to your posts on the list earlier... I just didn't have
a nice solution to the problem (and still don't)... so this one slept in my
Inbox until today.

[nil5-ksa@…]

Daniel, I think that including font name into StyleString will not lead to loss 
of its universality. StyleString was developed as a set of optional parameters. 
In other words, if there is no given parameter, it will not be included into 
StyleString. If in source package font name not belong in symbol, the font name 
will not be included in StyleString. Only and all... 
But if in source package (in our case MapInfo) font name belong in symbol, so 
the font name will be (and *should be*) included in StyleString.
I'm not sure that we should edcode the font name as part of "id" parameter ( 
i.e. SYMBOL(a:0,c:#000000,s:10pt,id:"fontsym-Wingding-45.ogr-sym-8") ). I think 
it should be: SYMBOL(a:0,c:#000000,s:10pt,id:"mapinfo-sym-45.ogr-sym-8", 
f:"Wingdings").

I always considered and I think that absolutely universal systems with minimal 
set of parameters do not happen. We should give to the user an opportunity to 
decide what given parameter is and how to use that.

[Daniel Morissette]

In what you write the id still poses a problem in my opinion.

How about?

SYMBOL(a:0,c:#000000,s:10pt,id:"font-sym-45.ogr-sym-8", f:"Wingdings")

We would document that font ids that start with "font-sym-" are followed by the
id of the character in that font.

[warmerdam]

I like this font-sym- convention, does this work for your Sergey?  
If so, would you like to update the patch accordingly?

And thanks for your input Daniel.  I was really wanting us to think about
the proposed change holistically before committing to it. 

I am willing to write up the changes to the specification for this change
if we agree to this approach.

[nil5-ksa@…]

Okay, I agree with you. I will develop new path for font-sym- convention. 

But there is a new problem :).
After implementing this patch reading styleStrings from MapInfo files (sorry, 
simply I work with this package very much. but work with another packages is 
still ahead...) will work very good. 
But what about writing (in MIF/MID)? At this time *ALL* styleStrings are 
lost... In MIF-file only default StyleString is writing...
Or this is another problem and it must be discuss in another BUG#? What do you 
think?

[nil5-ksa@…]

About putch for reading.
Result StyleString will look like this:
SYMBOL(a:0,c:#000000,s:10pt,id:"font-sym-45.ogr-sym-8", f:"Wingdings")

Are you agree with me?

[warmerdam]

Sergey, 

This is indeed another problem, and there may well be a bug report open about
it already.  For now it is just a difficiency of the library, but it would
be very nice to implement style support for MIF.  It's just the writing of
style info for MIF that is broken right?  Writing styles for tabs does work?

And yes, your current proposed form looks fine to me.  If you attach 
appropriate patches I will apply them in GDAL/OGR and the upstream MITAB library
assuming Daniel has no objections. 

[Daniel Morissette]

No objections. 

I also agree that the problem with StyleStrings being lost when writing to MIF
format should be a separate bug. You might want to file that in the MITAB
bugzilla directly (http://maptools.org/bugzilla/) but unfortunately I'm not
always as quick to respond to bugs in MITAB/OGR as Frank is.

[nil5-ksa@…]

new patch for reading stylestrings from mapInfo files

[nil5-ksa@…]

Holidays... it is fine... :)  
  
okay. So, I just create new patch for reading.   
  
Daniel, I'm ready to create patch for writing styles into MIF file. Or you  
want to create it?   
  
P.S. About #683. Yes. it's just a test and can be closed.  

[warmerdam]

I have applied the changes to ogr_featurestyle.h and ogrfeaturestyle.cpp
in the GDAL CVS tree. They will need to be moved up to MITAB before the 
MITAB driver changes are integrated and then migrated down to GDAL. 

[Daniel Morissette]

I'll update ogr_featurestyle.h and ogrfeaturestyle.cpp in the MITAB CVS now.

[Daniel Morissette]

I have updated ogr_featurestyle.h and ogrfeaturestyle.cpp in the MITAB CVS, this
will be part of the 1.4.0 release, the rest of the changes will have to be done
in MITAB after the 1.4 release.

[Jukka Rahkonen]

Parameter "f" is supported in OGR_STYLES ​http://www.gdal.org/ogr_feature_style.html.

Could it be that all the work despite closing this ticket was done ten years ago?

[Jukka Rahkonen]

Obviously fixed 10 years ago.