[GRASS-dev] 6.4.0 blocker bugs
msieczka at sieczka.org
Sun May 16 17:17:41 EDT 2010
Thanks for looking into this. I'll get back to you, hopefully this week.
W dniu 16.05.2010 21:18, Paul Kelly pisze:
> Hi Maciej, Markus,
> On Sat, 15 May 2010, Markus Neteler wrote:
>> On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka <msieczka at sieczka.org>
>>> OK now, so this was actually a revert of a massive update which broke
>> 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  lacking it too. The towgs84 should
>>> be as in .
>>> @Markus, Paul
>>> Do I simply modify gcs.csv alone or should this be a somewhat bigger
> 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. 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?
> Index: lib/proj/convert.c
> --- lib/proj/convert.c (revision 42262)
> +++ lib/proj/convert.c (working copy)
> @@ -744,6 +744,8 @@
> + "Pulkovo_1942_58",
> + "Pulkovo_1942",
More information about the grass-dev