Markus wrote:
> > I am concerned that r39638 will break scripts expecting the old behavior.
> > (m.proj output delim)
>
> I consider the old behaviour as broken.
I would say inconsistent with the rest of grass and awkward, but not
actually broken. It does not report incorrect results (but 3rd column of
cs2cs must be watched & interpreted carefully)
> > e.g. v.in.gpsbabel et al.
>
> Could you specify et al.? I would update those.
grep says v.out.gpsbabel and d.out.gpsdrive; but really what I was think-
ing about was the fact that m.proj is primarily meant as middleware for
scripts, so will especially be found in any number of end-user scripts.
> > please revert.
>
> For 6.4 we can revert but for newer versions it does not
> make sense. Sounds ok?
for gr7 I believe Martin has already enhanced it to respect fs=,
but there remains the inconsistency of DDDdMM'SSSS.SSS" output
format. Note that the input fs= is not necessarily what you want the
output fs= to be -- often it probably isn't.
For 6.5 we must consider if it is broken enough that dropping backwards
compatibility (and associated loss of trust that incurs) is outweighed by
the improvement. Which is another way of reminding ourselves (me
included) to start shifting to trunk for our main day to day working
version.
It is not so hard to parse in python, but at some point it is easier to
drop the cs2cs wrapper and rewrite the thing in C using libproj, as it
was in GRASS 5. I expect scalability for massive datasets will be the
determining factor in that decision, one way or the other. (currently
I don't know how real the non-C penalty actually is)
regards,
Hamish
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
