Norman Vine | 2 Dec 03:56 2005

FW: SCAR Antarctic PS projection issue in proj


> -----Original Message-----
> From: Mark Fahnestock
> Sent: Thursday, December 01, 2005 5:13 PM
> To: norman vine
> Subject: SCAR Antarctic PS projection issue in proj
> 
> 
> Hi Norman,
> 
> Here is the detail on the issue I talked to you about regarding  
> setting up a WCS for the SCAR projection - this projection has an  
> EPSG identifier, but is not making it in to proj:
> 
> This projection is in the EPSG database, but doesn't survive some  
> translation stage that generates the epsg file in /usr/local/share/proj
> 
> 
> EPSG:3031 is the SCAR Antarctic Polar Stereographic Projection - lat0  
> -90  lon0 0 lat_ts -71  ellipsoid WGS84 datum WGS84  Units meters -  
> note that the scale factor is 1.0, because lat_ts is set.  I believe  
> that for PS projections, the scale factor is used (or is different  
> than 1.0) only when the latitude of true scale is not used.
> 
> the older instances of proj I have on my systems do not have this  
> entry at all, but this entry (see below) leads me to think that the  
> translation may be fixable.  Note that the <3031. is missing because  
> of the error.  I don't know if this is the only affected file, or if  
> there would be others that would need to contain this entry.
> 
(Continue reading)

Oscar van Vlijmen | 2 Dec 23:28 2005
Picon

Re: FW: SCAR Antarctic PS projection issue in proj


> From: "Norman Vine" <nhv-cape.com>
>> -----Original Message-----
>> From: Mark Fahnestock
>> Here is the detail on the issue I talked to you about regarding
>> setting up a WCS for the SCAR projection - this projection has an
>> EPSG identifier, but is not making it in to proj:
>> This projection is in the EPSG database, but doesn't survive some
>> translation stage that generates the epsg file in /usr/local/share/proj

There are 53 such instances.
How come? No method available to support the projections in question?

# Unable to translate coordinate system into PROJ.4 format.

# Hartebeesthoek94 / Lo15
# Hartebeesthoek94 / Lo17
# Hartebeesthoek94 / Lo19
# Hartebeesthoek94 / Lo21
# Hartebeesthoek94 / Lo23
# Hartebeesthoek94 / Lo25
# Hartebeesthoek94 / Lo27
# Hartebeesthoek94 / Lo29
# Hartebeesthoek94 / Lo31
# Hartebeesthoek94 / Lo33
# Scoresbysund 1952 / Greenland zone 5 east
# Scoresbysund 1952 / Greenland zone 6 east
# Ammassalik 1958 / Greenland zone 7 east
# Qornoq 1927 / Greenland zone 1 east
# Qornoq 1927 / Greenland zone 2 east
(Continue reading)

Martin Vermeer | 3 Dec 17:59 2005
Picon
Picon

Re: FW: SCAR Antarctic PS projection issue in proj

On Thu, Dec 01, 2005 at 09:56:46PM -0500, Norman Vine wrote:
> 
> > -----Original Message-----
> > From: Mark Fahnestock
> > Sent: Thursday, December 01, 2005 5:13 PM
> > To: norman vine
> > Subject: SCAR Antarctic PS projection issue in proj
> > 
> > 
> > Hi Norman,
> > 
> > Here is the detail on the issue I talked to you about regarding  
> > setting up a WCS for the SCAR projection - this projection has an  
> > EPSG identifier, but is not making it in to proj:
> > 
> > This projection is in the EPSG database, but doesn't survive some  
> > translation stage that generates the epsg file in /usr/local/share/proj
> > 
> > 
> > EPSG:3031 is the SCAR Antarctic Polar Stereographic Projection - lat0  
> > -90  lon0 0 lat_ts -71  ellipsoid WGS84 datum WGS84  Units meters -  
> > note that the scale factor is 1.0, because lat_ts is set.  I believe  
> > that for PS projections, the scale factor is used (or is different  
> > than 1.0) only when the latitude of true scale is not used.
> > 
> > # WGS 84 / Antarctic Polar Stereographic
> > # Unable to translate coordinate system into PROJ.4 format.
> > #
> > # WGS 84 / Australian Antarctic Polar Stereographic
> > # Unable to translate coordinate system into PROJ.4 format.
(Continue reading)

Maciek Sieczka | 3 Dec 20:53 2005
Picon

GRS80 vs GRS80 +towgs84=0,0,0

Hi,

I've encountered one small thing using cs2cs I don't understand. There
is a difference in results when converting between WGS84 and GRS80 based
systems - when the towgs84=0,0,0 is given for GRS80 and when it is not:

cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0

17d01'0.0E 51d07'0.0N
361227.112181   362969.278159 0.000063

But, if I don't specify the +towgs84=0,0,0 in the target coordinate
system, I obtain a slightly different result:

cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
+lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80

17d01'0.0E 51d07'0.0N
361227.112178   362969.278057 0.000000

The difference is less than 1 mm, but anyway - why? I thought that no
matter if I specify the towgs84=0,0,0 for GRS80 or not I would obtain
the same results. 

Maciek

--------------------
Historia, która przeros³a fikcjê. Chcesz poznaæ rozwi±zanie jednej z najwiêkszych tajemnic II
wojny ¶wiatowej? 
(Continue reading)

Frank Warmerdam | 3 Dec 21:43 2005
Picon

Re: GRS80 vs GRS80 +towgs84=0,0,0

On 12/3/05, Maciek Sieczka <werchowyna <at> epf.pl> wrote:
> Hi,
>
> I've encountered one small thing using cs2cs I don't understand. There
> is a difference in results when converting between WGS84 and GRS80 based
> systems - when the towgs84=0,0,0 is given for GRS80 and when it is not:
>
> cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
> lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0
>
> 17d01'0.0E 51d07'0.0N
> 361227.112181   362969.278159 0.000063
>
> But, if I don't specify the +towgs84=0,0,0 in the target coordinate
> system, I obtain a slightly different result:
>
> cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
> +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80
>
> 17d01'0.0E 51d07'0.0N
> 361227.112178   362969.278057 0.000000
>
> The difference is less than 1 mm, but anyway - why? I thought that no
> matter if I specify the towgs84=0,0,0 for GRS80 or not I would obtain
> the same results.

Maciek,

In the case you specify the +towgs84, no ellipsoid conversion
is done.  In the case without +towgs84, an ellipsoid conversion
(Continue reading)

Maciek Sieczka | 3 Dec 22:00 2005
Picon

Re: GRS80 vs GRS80 +towgs84=0,0,0

> Maciek,
> 
> In the case you specify the +towgs84, no ellipsoid conversion
> is done.  In the case without +towgs84, an ellipsoid conversion
> is done.  The WGS84 and GRS80 are essentially the same
> but there is a small difference.
> 
>     WGS84 a=6378137.0      rf=298.257223563 WGS 84
>     GRS80 a=6378137.0      rf=298.257222101 GRS 1980(IUGG, 1980)

So the formaly "right" approach is not to use any +towgs84= for GRS80,
is it?

Maciek

Best regards,
Maciek

--------------------
Historia, która przeros³a fikcjê. Chcesz poznaæ rozwi±zanie jednej z najwiêkszych tajemnic II
wojny ¶wiatowej? 
Przeczytaj BURSZTYNOW¡ KOMNATÊ, Catherine Scott-Clark, Adrian Levy
http://www.rebis.com.pl/rebis/strony/pokaz_ksiazke.html?id=32787

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

(Continue reading)

Martin Vermeer | 3 Dec 22:14 2005
Picon
Picon

Re: GRS80 vs GRS80 +towgs84=0,0,0

On Sat, Dec 03, 2005 at 08:53:46PM +0100, Maciek Sieczka wrote:
> Hi,
> 
> I've encountered one small thing using cs2cs I don't understand. There
> is a difference in results when converting between WGS84 and GRS80 based
> systems - when the towgs84=0,0,0 is given for GRS80 and when it is not:
> 
> cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
> lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +towgs84=0,0,0
> 
> 17d01'0.0E 51d07'0.0N
> 361227.112181   362969.278159 0.000063
> 
> But, if I don't specify the +towgs84=0,0,0 in the target coordinate
> system, I obtain a slightly different result:
> 
> cs2cs -f "%.6f" +proj=latlong +ellps=WGS84 +to +proj=tmerc +lat_0=0
> +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80
> 
> 17d01'0.0E 51d07'0.0N
> 361227.112178   362969.278057 0.000000
> 
> The difference is less than 1 mm, but anyway - why? I thought that no
> matter if I specify the towgs84=0,0,0 for GRS80 or not I would obtain
> the same results. 
> 
> Maciek

I would guess this relates to the notorious "GRS80 vs WGS84
flattening" bug.
(Continue reading)

Jan Hartmann | 1 Dec 19:23 2005
Picon
Picon

Re: Meaning of 7-parameter transformation rotations

Frank Warmerdam wrote:
> On 11/30/05, Clifford J Mugnier <cjmce <at> lsu.edu> wrote:
> 
>>
>>
>>
>>Gentlemen:
>>
>>Note that the SENSE of the rotations have two common usages.  The American
>>Standard versus the European Standard differ!  To transform in the same
>>direction, the signs are OPPOSITE from one "standard" to another.
>>Generally speaking, a 7-parameter  transformation, whether it is a
>>Bursa-Wolfe or a Molodensky, MUST have a "test point" provided so that the
>>user knows which sense the rotations need for the desired transformation
>>direction.
>>
>>The Americans, Australians, and Luxemborgs use one SENSE, the Europeans use
>>the other.  In regard to the rest of the world, it depends on which
>>brand-name of GPS Geodetic Processing software was used to derive the
>>parameters from some collection of data points.  See my monthly column for
>>such important minutiae for country to country considerations.
>>
>>Be careful of 'dem signs!  :-)
> 
> 
> Cliff,
> 
> Your point is quite correct.  I believe that PROJ
> is using the European definition so that we can directly
> apply the numbers from EPSG.
(Continue reading)

Antonin Orlik | 2 Dec 23:13 2005
Picon

Coordinates transformation - Proj4, GDAL, OGR, PostGIS, MapServer

Dear developers,

I'm not sure who is responsible for the problem that I'm going to describe. This problem is very serious for me and for a lot of other people who are trying to use Open Source GIS software (especially in the Czech republic).

1.
Library PROJ.4 has (next to the "proj" program) also program "cs2cs" ("The new cs2cs program performs a similar function to the proj program, but transforming from any one coordinate system to another. The new pj_transform() is used to access the extended coordinate system to coordinate system transformation with datum shifting."). This program is a great thing, but unfortunately it looks like just a few GIS programs are using cs2cs instead of the proj program. For example, there is no problem with the coordinate transformation used in the PostGIS (which probably uses cs2cs). However,  the utilities of the GDAL and the OGR library, which are a base for a lot of other applications (MapServer, QGIS and so on), are probably using the proj program for coordinate transformations. This fact makes quite a big position shift after the coordinate transformation between coordinate systems based on diferent ellipsoids (proj program cannot make datum shifting). Finally, it is not possible to transform data correctly or to display more datasets based on different ellipsoids in a detailed view by the way of on-the-fly projection (the shift between elipsoids is often bigger than 100 meters).

Does somebody have any ideas? Is possible to make changes in the GDAL and OGR source codes and use the cs2cs instead of the proj program?


2.
(probably to Frank Warmerdam)
In the Czech Republic we are using a strange coordinate system known as "krovak" (S-JTSK). This system has a strange axis orientation that is very hard to apply in the computer world, so nobody is using this axis orientation in GIS. Instead everybody is using switched axis ( X = -y, Y = -x ). If somebody would like to use proj.4 library, they have to use a patch for proj.4 library ( http://mpa.itc.it/radim/jtsk/PJ_krovak.c.patch ). For a lot of people it is very hard to apply this patch because they are just users who want to use an open source GIS software that uses proj.4 library. I can remember that this problem was discused by Radim Blazek and Frank Warmerdam but no successfull result were found... I think.

Is there any possibility to include this patch into an official version of proj.4 library? Or in the case that you want to keep this a "well-defined" krovak system, is possible to make a new definition of krovak with a different EPSG code (and keep the old one (esri:102065) in case there is an individual person who is using this definition)?


These two problems are major for a lot of people that I know and these are two of the main reasons why they are not going to use open source GIS software (and that is pity of course)...


Thank you for feedback.

Best regards,
Antonin Orlik

-- Ing. Antonin Orlik Institute of Geoinformatics VSB-Technical University of Ostrava 17.listopadu 15/2172 708 33 Ostrava-Poruba E-mail: antonin.orlik.hgf <at> vsb.cz Office: J 327 Tel: +420 59 732 3337 Mobile: +420 604 333 744 ICQ: 54928537
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Oscar van Vlijmen | 3 Dec 23:45 2005
Picon

Re: FW: SCAR Antarctic PS projection issue in proj


>>> -----Original Message-----
>>> From: Mark Fahnestock
....
>>> Here is the detail on the issue I talked to you about regarding
>>> setting up a WCS for the SCAR projection - this projection has an
>>> EPSG identifier, but is not making it in to proj:
....
>>> # WGS 84 / Antarctic Polar Stereographic
>>> # Unable to translate coordinate system into PROJ.4 format.
>>> #
>>> # WGS 84 / Australian Antarctic Polar Stereographic
>>> # Unable to translate coordinate system into PROJ.4 format.

> From: Martin Vermeer <martin.vermeer-hut.fi>
> Googling I found the following old (2002) message by Frank Warmerdam:
> "Generally this happens when there is more than one approximation available
> for
> a datum (to WGS84) in the EPSG tables, as the auto-translation code can't
> decide which to use.  I also doubt that the EPSG to PROJ.4 stuff properly
> accounts for non-greenwich prime meridians.

Let's see how this theory relates to the actual data in the EPSG database.
I used the SQL version 6.7. There is a version 6.8, but at the moment
epsg.org is not connected.
What has the EPSG database to say about: WGS 84 / Antarctic Polar
Stereographic?
(Some not so relevant info not copied here):

>From the coordinate reference system table:

coord_ref_sys_code: 3031
coord_ref_sys_name: WGS 84 / Antarctic Polar Stereographic
area_of_use_code: 1031
coord_ref_sys_kind: projected
coord_sys_code: 4490
datum_code: Null
source_geogcrs_code: 4326
projection_conv_code: 19992
crs_scope: Antarctic Digital Database and small scale (<1:1,000,000) studies
and topographic mapping.

Following the coord_sys_code entry:

coord_sys_code: 4490
coord_sys_name: Cartesian 2D CS for APS. Axes: E,N. Orientations: E along 90
deg East, N along 0 deg meridians. UoM: m.
coord_sys_type: Cartesian
dimension: 2
remarks: Used for South Pole tangential and secant projections.

It's a derived CRS, namely from the CRS mentioned in the field
source_geogcrs_code.
This brings us after a couple of related tables to the basis, which is not
very interesting.
Let's see what the primary coordinate operation is, mentioned in the
original field projection_conv_code.

coord_op_code: 19992
coord_op_name: Antarctic Polar Stereographic
coord_op_type: conversion
source_crs_code: Null
target_crs_code: Null
coord_tfm_version: 
coord_op_variant: Null
area_of_use_code: 1031
coord_op_scope: 1: Antarctic Digital Database and small scale (<1:1,000,000)
studies and topographic mapping. 2: Medium scale studies and topographic
mapping south of 80 deg S.
coord_op_accuracy: 0
coord_op_method_code: 9829
remarks: Special studies may use a different projection using an alternative
longitude of origin. See for example projection code 19993.

The coordinate operation method is:

coord_op_method_code: 9829
coord_op_method_name: Polar Stereographic (variant B)
reverse_op: 1
formula: (see EPSG guidance note #7.2)
example: (see EPSG guidance note #7.2)

The projection parameters can be found in the table
"coordoperationparamvalue" under coord_op_code: 19992
This gives:

False easting: 0
False northing: 0
Latitude of standard parallel: -71
Longitude of origin: 0

In conclusion, my theory is that the projection method is unambiguously
clear, but that either "Polar Stereographic (variant B)" is not supported by
PROJ.4 or that it was somehow not possible to construct relevant PROJ.4
arguments for any PROJ.4 method (stere perhaps) on the fly.

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


Gmane