[Proj] proj.4 BNF

support.mn at elisanet.fi support.mn at elisanet.fi
Wed Oct 22 17:32:02 EDT 2008 

My concern  is originated from those initialization files proj.4 has. Here
is some examples:

----------------file 1-------------
# Kalianpur 1962
<4145> +proj=longlat +a=6377301.243 +b=6356100.230165384 +no_defs  <>
# Kalianpur 1975
<4146> +proj=longlat +a=6377299.151 +b=6356098.145120132 +towgs84=295,736,257,0,0,0,0 +no_defs  <>
# Hanoi 1972
<4147> +proj=longlat +ellps=krass +towgs84=-17.51,-108.32,-62.39,0,0,0,0 +no_defs  <>
# Hartebeesthoek94
<4148> +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs  <>
# CH1903
<4149> +proj=longlat +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +no_defs  <>
-------------------------------

----------------file 2-------------
# W [HIVA67]
<IGN63> +title=IGN 1963 (Hiva Oa, Tahuata, Mohotani) +proj=geocent +towgs84=410.7210,55.0490,80.7460,-2.5779,-2.3514,-0.6664,17.331100 +a=6378388.0000 +rf=297.0000000000000 +units=m +no_defs <>
--------------------------------

and how to parse those. "+" is used as separator and I am assuming that the reason is the
"+title=something with white spaces in it". That should pass the scanner somehow.

The second file will never pass? The only way to get that to pass, is to use

<white_space> "+"

as the separator, since <white_space> alone is used also in the title key value.

The file 2 will split as:

+title=IGN
1963
(Hiva Oa,
Tahuata, Mohotani)
+proj=geocent
+towgs84=410.7210,55.0490,80.7460,-2.5779,-
etc....

when is should be:

+title=IGN 1963 (Hiva Oa, Tahuata, Mohotani)
+proj=geocent
+towgs84=410.7210,55.0490,80.7460,-2.5779,-
etc....

If I would use  <proj_key>::= "+"<id> | <id>, that would not work, since
there is no way to know if "Tahuata" is key word or not using just a
dump scanner. And since all the proj.4 identifiers are not known
(and continue to change) listing them will also not work and is not
rational.. since that would require to edit the list all the time there
comes some new key wods.

The only way is to use <white_space>"+" or <white_space> as
separators. Since that way one does not need to know all the key
words and the scanner gets smaller and will work for ever.

Regards: Janne.

------------------------------

 
"Gerald I. Evenden" <geraldi.evenden at gmail.com> kirjoitti: 
> 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?
> 
> > -----------------------------------------
> >
> > support.mn at elisanet.fi kirjoitti:
> > > Frank Warmerdam <warmerdam at pobox.com> kirjoitti:
> > > > support.mn at elisanet.fi wrote:
> > > > > Maybe should define the correct BNF (BackusNaur Form) for proj4?
> > > > >
> > > > > http://en.wikipedia.org/wiki/Backus-Naur_form
> > > > >
> > > > > That would help people to write correct proj.4 inits. I am still
> > > > > wondering that if sombody enters wrong proj.4 attributes, the library
> > > > > takes them in, but does
> > > > > something else and never informs the user that something he was
> > > > > entering was totally ignored. Not a very nice situation.
> > > > >
> > > > > There might be some kind of a stand alone pre scanner, that could be
> > > > > called on demand and that checked the user entry and gave full
> > > > > information about typos. errors and similar matters. It could be
> > > > > bypassed by those who do not need it. But I don't see why anybody
> > > > > wanted to bypass checking of his input.
> > > >
> > > > Janne,
> > > >
> > > > While this seems like a reasonable idea, I am doubtful that it will
> > > > occur due to the challenges in implementing and keeping it up to date.
> > >
> > > Well, I can start with it. Here is an example, maybe full of errors, but
> > > something to start with.
> > >
> > > ------------------
> > >
> > > <proj.4 definition> ::= <statement list>
> > >
> > > <statement list> ::= <statement> {<SEP> <statement list> }
> > >
> > > <statement> ::= <empty> | <comment line> | <assignment statement> |
> > > <identifier>
> > >
> > > <empty ::=
> > >
> > > <comment line> ::= # <anything but EOL> <EOL>
> > >
> > > <assignment statement> ::= <identifier> = <right side>
> > >
> > > <right side> ::= <identifier> | <identifier list> | <number> | <number
> > > list>
> > >
> > > ........
> > >
> > > <EOL> ::= <CR> <LF> | <CR> | <LF>
> > >
> > > <SEP> ::= <SPACE>  | <TAB> | <EOL> | "+"
> > >
> > > <SPACE>  :: = " "
> > >
> > > <TAB>  ::= chr(09)
> > >
> > >
> > > etc. etc.
> > >
> > >
> > >
> > > regards: Janne.
> >
> > _______________________________________________
> > Proj mailing list
> > Proj at lists.maptools.org
> > http://lists.maptools.org/mailman/listinfo/proj
> 
> 
> 
> -- 
> The whole religious complexion of the modern world is due
> to the absence from Jerusalem of a lunatic asylum.
> -- Havelock Ellis (1859-1939) British psychologist
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>

More information about the Proj mailing list