[Proj] proj.4 BNF

[Roger Oberholtzer]

On Oct 21, 2008, at 8:36 PM, Gerald I. Evenden wrote:

> On Monday 20 October 2008 11:05:41 pm support.mn at elisanet.fi wrote:
>> The problem using + alone as a staement separator is obvious,
>> since it can be mixed with positive number sign. One way is to forbid
>> to use "+" as a positive number sgn. But then it would trop all
>> future expressions also. Maybe best is to agree, that if "+" is
>> used as statement separator (and continuation mark) it should
>> be preceded by <SEP>, which is usually the case.
>>
>> So it would be more like:
>>
>>
>> <SEP> ::= (<SPACE>  | <TAB> | <EOL>) {<SEP>}
>>
>> <continuation> ::= <SEP> "+"
>>
>>
>> That would require some white space before + and would make it
>> most clear?
>>
>> ----
>>
>> Janne.
>
> I should stay out of this thread other than to discourage it because  
> it is making a grand mountain out of a
> mole hill.
>
> Regarding the "+": it has nothing to do as a separator and if  
> bothering to use BNF, use something like:
>
> <proj_key>::= "+"<id> | <id>
>
> where id is your typical identifier definition.  Treating "+" as a  
> delimiter only confuses the issue.  In fact, treating
> it like white space could cause a failure---"+proj=poly+ellps=intl"  
> would fail becaue the second + would be
> treated as part of the projection name and there is no projection  
> called "+ellps=intl",
>
> <proJ_option> ::= <proj_key> | <proj_key>"="<proj_value>
>
> <proj_option_list> ::=  <proj_option> |  
> <proj_option_list><white_space><proj_option>
>
> <white_space> ::= <white_space_char> | <white_space><white_space_char>
>
> <white_space_char> ::= " " | <tab> | <new_line>
>
> I do not think the above (given it's possible BNF warts and  
> incompleteness> is really necessary as it is a
> common scenario for keyword control entry.  Users may get confused  
> as to what and how of the <proj_key>s
> but I do not think entering the values is that confusing because it  
> is virtually identical to entering runline
> control options.
>
> Alas.
>
> As a final note: it we really want to get serious about BNF and such  
> descriptions of control entry then we may
> have to install a lexical analyzer designed with programs lex or  
> flex and possibly a parsing machine designed
> with yacc or bison.  Do programmers, installers of libproj4 want to  
> get involved with these beasts?

Not really. I think it would lead to more complex syntax over time,  
because these systems would allow it. Having said that, in a large  
syntax (which this is not), simply making the spec helps identify  
weaknesses in the syntax. Even if the spec is never used beyond a  
paper and pencil proof that the syntax is consistent, the spec could  
be useful. But I see no need to implement it in the programs.

On the other hand, I think it would be great if one could enter a  
series of strings, as is done today, and then, based on how everything  
ultimately gets parsed, list it back with all settings expanded. It  
often seems to be to be a little too "blackboxish". Documenting what  
one's strings really parse into is not really possible, making any  
serious regression testing across releases next to impossible. ESRI,  
for example, list the settings that it decides to use based on  
whatever the user specified, like a code or whatever. The analysis  
lists what all the important settings wind up being. More than once  
this has helped to clarify some seemingly odd thing to me.

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Kapellgränd 7
P.O. Box 4205
SE-102 65 Stockholm, Sweden

Office: Int +46 8-615 60 20
Mobile: Int +46 70-815 1696

And remember:

It is RSofT and there is always something under construction.
It is like talking about large city with all constructions finished.
Not impossible, but very unlikely.