Voting on RFC 9.

[Frank Warmerdam]

On 1/31/06, Steve Lime <steve.lime at dnr.state.mn.us> wrote:
> As usual I write before I think about things. The main parser is setup to return an int, not a string, it's there for logical expression evaluation. I need to do more reading to see if one can have multiple parsers in one application (I'm sure you can)and what the ramifications of that are. Probably need a another lexer state... *yuck*
>
> Needless to say this is not trivial so the item tag becomes a reasonable start, but it does nothing to help with bug 1634. I'm afraid fixing the data in the source data or via SQL on the way out is the best solution at the moment.

Steve,

Might it make sense to provide an attribute on the
style object (or label object?) which is essentially the
item tag, and could then be used to apply normal
item format processing to labels?   Presumably in
this context the default escaping would be none, not
HTML.

While not as "composable" as allowing string processing
expressions to be applied, it would allow consistant
formatting rules.

By the way, I found RFC 9 a bit brief in describing what
the various attributes do.  In particular, I was interested
in the "format" attribute.  When I first saw it, I hoped it
would be a "C" style format string, allowing tight control
of stuff like leading zeros, width and precision.   Any chance
we could have a "cformat" attribute?

Also, the RFC doesn't describe the precision attribute.  Was
this always there?

Sorry for just getting interested now.  My interest has been
sparked by Tamas wanting to fix some of his formatting
issues down in OGR.  After I told him it was a MapServer
issue, I thought I ought to investigate how MapServer handles
these things. :-)

I have come to the impression that how numbers are returned
from different data providers is rather adhoc.  The shape/dbf
code in mapxbase seems to return the literal representation
of numbers from the .dbf file.  OGR uses GetAsStringValue()
which tries to format as per width and precision but in some
cases this makes numbers like "        1.000000000", when
the width and precision values in the format don't make much sense.
I suspect the RDBMSes use whatever conversion to char is
applied by the database.

Are there places other than labelling and query formatting that
we would want to control attribute formatting?  Perhaps we should
be able to apply per attribute formatting overrides in "item tag"
form right in the LAYER declarations?   Get them at the source,
as it were.

Finally, it is possible to have two lexers and two parsers in the
same app, but you may have to do quite a bit of fiddling to ensure
they are named differently.   I see FDO has three such parsers, but
as part of the build has to run little scripts to post-process the
parser generator output.  I think this is mainly to rename stuff
though I'm not absolutely sure.

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