[GRASS-dev] 6.4.0 blocker bugs

[Maciej Sieczka]

W dniu 16.05.2010 21:18, Paul Kelly pisze:
> On Sat, 15 May 2010, Markus Neteler wrote:
>> On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka
>> <msieczka at sieczka.org> wrote:

>>> OK now, so this was actually a revert of a massive update which
>>> broke things.

>> Right - personally, I find it to be a major problem that we are out
>> of synch with GDAL now.

> I agree it's rather unfortunate. But I think we would be getting a
> lot more complaints and bug reports if we had kept in-sync; the way
> GDAL now handles datum transformation parameters by forcing a default
> choice just isn't very desirable for the case of a user setting up a
> new location. Having a potentially non-optimal choice being
> automatically made for them could come back to haunt them in the
> future, perhaps even years into the future.

>>> Anyway, my point is that gcs.csv as it is now in all GRASS SVN
>>> branches lacks towgs84 definition for Pulkovo 1942(58) datum,
>>> which results in locations created from EPSG codes [4] lacking it
>>> too. The towgs84 should be as in [5].
>>>
>>> @Markus, Paul
>>>
>>> Do I simply modify gcs.csv alone or should this be a somewhat
>>> bigger change?

> 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'.

> In 7.x I hope to change things around so we can try to work with
> GDAL's new way of doing things, rather than trying to work around
> it.
>
> 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. All I know is that "Pulkovo 1942 (58)" equal
"33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84" is the official solution
for Poland.

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org