[GRASS-dev] 6.4.0 blocker bugs

[Maciej Sieczka]

W dniu 20.05.2010 17:48, Paul Kelly pisze:
> On Wed, 19 May 2010, Paul Kelly wrote:
>> On Mon, 17 May 2010, Maciej Sieczka wrote:

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

> Actually it is a bit more complicated than this. According to the EPSG
> database, Pulkovo_1942 is used in the following countries:
> Armenia; Azerbaijan; Belarus; Estonia; Georgia; Kazakhstan; Kyrgyzstan;
> Latvia; Lithuania; Moldova; Russian Federation; Tajikistan;
> Turkmenistan; Ukraine; Uzbekistan.
> and Pulkovo_1942_58 is used in the following countries:
> Albania; Bulgaria; Czech Republic; Germany (former DDR); Hungary;
> Poland; Romania; Slovakia.
>
> So it seems to me that we should have two separate datum entries in
> GRASS, and that it is arguably a bug treating them both as one.
>
> I would appreciate some suggestions on what the GRASS abbreviation for
> Pulkovo 1942 (58) should be; for Pulkovo 1942 it is S-42 - which IMHO is
> not nice as it has a capital letter in it, but of course we can't change
> it without breaking existing locations.

Hi,

Another solution is available now. In GDAL stable branch r19810 
https://svn.osgeo.org/gdal/branches/1.7/gdal/data/gcs.override.csv, 
overrides for problematic Polish CRSes [1] were added [2]. After copying 
it over $GISBASE/etc/ogr_csv/gcs.override.csv, the wxGUI location wizard 
behaves OK when using Polish EPSG codes [1]. Same as g.proj does, e.g. 
instead of a warning and a lacking towgs84:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2174
UWAGA:Datum <Pulkovo_1942_58> not recognised by GRASS and no parameters
       found
+proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 
+x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 +to_meter=1
---

it returns a correct string:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2174
+proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 
+x_0=3703000 +y_0=5627000 +no_defs +a=6378245 +rf=298.3 
+towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +to_meter=1
---

Can I upload the new gcs.override.csv to GRASS SVN? Mind it also 
overrides the current GRASS ETRS89 definition, as per datum.table:

---
# Datum parameters for/from European Terrestrial Reference System ETRS89
etrs89   "European_Terrestrial_Reference_System_1989"   grs80       dx=0 
        dy=0       dz=0
---

with:

---
# Backported from 1.8dev (see ticket #3579)
4258,ETRS89,6258,European Terrestrial Reference System 
1989,6258,9122,7019,8901,1,0,6422,9603,0,0,0,,,,
---

thus, e.g. EPSG 2180 would no longer be:

--
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2180
+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 
+no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1
---

but:

---
GRASS 6.5.svn (test):~ > g.proj -jf epsg=2180
+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 
+no_defs +a=6378137 +rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +to_meter=1
---

I guess it doesn't hurt; does it?

[1] 3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328 4179

[2] http://trac.osgeo.org/gdal/ticket/3579#comment:7

Best,
Maciek

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