[Proj] Proj.4 definition grammar checker, was: Re: Problem with program on Windows
support.mn at elisanet.fi
support.mn at elisanet.fi
Mon Aug 15 12:02:12 EST 2011
Here is how you can make a simple Proj.4 definition grammar
checker in a easy way:
1) First you check the syntax that it is formally correct, which is very
simple since there are only very few types of statements. Here you
can also check that given numbers are formally ok and that they do
not exceed known limits and similar matters.
2) During the syntax check you first figure out what is the current
projection .. there are about 150 or so in Proj.4. Then you just
consult the projection allowable parameter table where all possible
parameters are given for that particular projection and check that the
user is using it as it should be used ... some parameters might be
required, some optional and many illegal.
3) You could later add more and more detailed checking around this
simple code. I would estimate that the preliminary version would not
be very much more than 1000 lines of code. It would be based around
a simple recursive descent parser and a projection allowable parameter
table (with one row for each projection - about 150 rows and maybe
about 50 columns for different parameters) .... or somthing similar.
It is easy to implement and would remove most of the "beginner"
errors and greatly improve the quality of the data. At least it would
greatly help me for example since even I don't know what is required,
allowed or illegal with all projections. (So better let the computer
to take care of that). The table could also be used by an other small
program which would automatically list out all the current projections
and how to use their parameters. That printout would then be the
current definition of the Proj.4 projection-datum definition language.
Thomas Knudsen [knudsen.thomas at gmail.com] kirjoitti:
> I somewhat kind of doubt it since, as Frank says, the syntax for some of the
> more esoteric projections may be non trivial. And under all circumstances
> there will be a lot of special cases (e.g. the zone specifier for utm). For
> each individual projection I agree that it may not be a big thing to
> implement syntax checking - but there is a lot of projections, and one would
> need to understand the specifics of all of them. Actually, as far as I can
> see, this amounts to writing "a significant fraction of N" syntax checkers
> for the N projections in the library.
> If you can see simpler ways to do it, I think you should flesh it out in
> code and post a patch: Others may want to join the effort once you have
> actually shown how easy it is.
More information about the Proj