[Proj] proj.4 BNF

Richard didier didier.richard at ign.fr
Thu Oct 23 03:48:48 EDT 2008 

Le Mercredi 22 Octobre 2008 23:32, support.mn at elisanet.fi a écrit :
> 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.
>

There is no problem at all handling +title in catalogue. I have submitted a 
ticket to prevent some parsing error when the string after +title= contains 
keywords. See http://trac.osgeo.org/proj/ticket/17 for better explanations.

Regards,

didier

> 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
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj

-- 
Didier RICHARD, chef du pôle technique Géoportail pour l'IGN
Institut Geographique National           tel: +33/0 1.43.98.83.23
2/4 Avenue Pasteur                       fax: +33/0 1.43.98.80.88
F-94165 St-Mande Cedex                e-mail: Didier.Richard at ign.fr

More information about the Proj mailing list