[GRASS-dev] 6.4.0 blocker bugs

[Paul Kelly]

On Mon, 17 May 2010, Maciej Sieczka wrote:

>> GRASS already has the correct parameters for Poland. The problem is
>> that it doesn't recognise the datum name "Pulkovo_1942_58"; it is
>> looking for "Pulkovo_1942". I would recommend the patch below for
>> working around this problem.
>
>> Index: lib/proj/convert.c
>> ===================================================================
>> --- lib/proj/convert.c (revision 42262) +++ lib/proj/convert.c
>> (working copy) @@ -744,6 +744,8 @@ "Militar_Geographische_Institut",
>> "Potsdam_Datum_83", "Deutsches_Hauptdreiecksnetz", +
>> "Pulkovo_1942_58", + "Pulkovo_1942", NULL };
>
> Does the trick for location wizard at GRASS startup (e.g. for epsg 2174
> a nice selection GUI pops up) and the resulting PROJ_INFO as well as
> `g.proj -p' output are OK, but `g.proj -p epsg=2174' on the command line
> still fails to include the towgs84 parameter set at all, so does `g.proj
> -c epsg=2174'.

It does include the datum though (there is a line "datum: S-42"), which 
means that the default GRASS parameters for S-42 (over the whole region it 
is used in) will be used where necessary (e.g. in g.proj -jf epsg=2174). I 
think this is the best we can hope for for now; in GRASS versions 
6.2.1 and earlier g.proj when used on the command-line used to 
interactively prompt for the user to select a datum transformation if the 
datum was not fully specified, but this behaviour had to be removed when 
we were working towards removing all command-line interaction from modules 
so they could be used in scripts with no side-effects. Since GRASS 6.2.2 
if you want g.proj to give you a choice of datum transformation parameters 
(when one is available), you have to add "datumtrans=-1" to the 
command-line; this is what the location creation GUIs do to determine the 
available sets of datum transformation parameters.

>> Does this sound acceptable for now - in particular are there any
>> differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
>>  worrying about?
>
> I don't know.

OK well I will guess that any differences are not relevant for us here, 
and will see about adding the equivalence of Pulkovo_1942_58 and 
Pulkovo_1942 to SVN.

Paul