lack of support for South African projections

[proj4-bot]

Reported by gfleming on 17 Oct 2008 08:59 UTC
South African Coordinate System zone xx (EPSG odd numbers from 22275 - 22293)

and

Hartebeesthoek94/ Loxx (EPSG 2046 - 2055)

are not supported / do not have standard definitions in proj4. South Africa users of proj4, QGIS, PostGIS and others are thus crippled.

Attached are the WKT and PROJ4 definitions as csvs from PostGIS spatial_ref_sys.

SA Hartebeesthoek datum.csv:

4148 is fine - that's the fundamental GEOGCS. The rest have default, invalid proj4 definitions, except for 2054 (the last one) where I have attempted a proj4 definition but I dont think its quite right - it doesn't work.

SA Cape datum.csv:

The proj4 definitions for the SA Cape datum projections are INCOMPLETE. They only include the datum specs, not the projection or central meridian or other parameters.

Apparently the problem is that proj4 does not support 'transverse_mercator_south_orientated'?

Migrated-From: https://trac.osgeo.org/proj/ticket/18

[proj4-bot]

Comment by neteler on 2 Jun 2009 21:05 UTC
A similar problem was reported today http://lists.osgeo.org/pipermail/grass-windows/2009-June/001814.html with EPSG codes 4293 29371 29373 29375 29377 29379 29381 29383.

Testing in GRASS:

for i in 4293 29371 29373 29375 29377 29379 29381 29383 ; do g.proj -c epsg=$i location=epsg$i ; done
WARNING: Datum <Schwarzeck> not recognised by GRASS and no parameters found
Location epsg4293 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29371 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29373 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29375 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29377 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29379 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29381 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29383 created!

But the definition seems to be known by GeoTIFF:
http://geotiff.maptools.org/proj_list/transverse_mercator_south_oriented.html

and is also listed in this file
http://www.gdal.org/ogr/ogr__srs__api_8h-source.html

The Schwarzeck datum is described here: http://www.mme.gov.na/gsn/nam-map-system.htm:

  The transformation from the Schwarzeck datum into WGS 84 implies X, Y and Z shifts but no rotation. DMA  NIMA and Prof. Charles Merry from the University of Cape Town do give shift values, from which the latter ones are the more accurate:

Bessel Spheroid:

a = 6377397.1550 &German legal; meter
b = 6356078.96325 German legal meter
a = 6377483.865 intern. meter
b = 6356165.383 intern. meter
f = 1/299.1528128 (no changes due to length unit)
  = 0.003342773182
X, Y, Z shifts in meter
DMA ; NIMA 616 ( 20) 97 ( 20) -251 ( 20)
C. Merry (UCT) 616.80 103.30 -256.90

On the Maps in the LO system you will find the positive X axis to the south and the positive Y-axis to the west. This is a left-handed Cartesian co-ordinate system, whilst the computer thinks in a right-handed system. For the display of gridded data just use the normal co-ordinate system but be careful with the grids origin. Some software allows taking care of this by giving a negative central scale factor. 

[proj4-bot]

Comment by craigleat on 31 Jan 2010 19:45 UTC
Lack of support for TMSO is affecting users of proj, gdal, ogr, grass, qgis and possibly other projects. A wiki page is available for discussion and co-ordination of efforts. It is hoped that this will lead to a satisfactory implementation in the near future.

http://trac.osgeo.org/proj/wiki/TMSO

[proj4-bot]

Comment by warmerdam on 1 Mar 2010 04:46 UTC
I have implemented preliminary support for a +axis switch to control axis orientation in PROJ.4 trunk (3405bf70 (SVN rev1825)).

[proj4-bot]

Comment by warmerdam on 1 Mar 2010 21:07 UTC
According to the EPSG guidance notes on transverse mercator south orientated the false easting and false northing effectively become a false westing and false southing however this is not reflected in the current approach to support TMSO.

However, EPSG PCSs using TMSO (2046-2055, 22275-22293, and 29371-29385) all seem to use a false easting and northing of zero so the issue does not have an effect. If there is an issue we need to ensure that TMSO translation to proj=tmerc for proj.4 also negate the fe/fn values which it does not do now.

[proj4-bot]

Comment by craigleat on 2 Mar 2010 09:41 UTC
Replying to warmerdam:

However, EPSG PCSs using TMSO (2046-2055, 22275-22293, and 29371-29385) all seem to use a false easting and northing of zero so the issue does not have an effect. If there is an issue we need to ensure that TMSO translation to proj=tmerc for proj.4 also negate the fe/fn values which it does not do now.

In my experience it is only land surveyors and engineers that use non zero false westings and southings. I have a number of dwg/dxf files using these offsets. Currently I translate (shift) the data inside the CAD app to remove the offsets and then export to a GIS format. For me it would be useful to have correct signs applied to the fw/fs values.

[proj4-bot]

Comment by warmerdam on 31 Jul 2010 14:43 UTC
In 195e3f3e (SVN rev1874) I have incorporated definitions for TMSO projections in the epsg init file, after completion of TMSO support in GDAL's PROJ.4 translator.

This ticket remains open only in the hopes of addressing the sign of false easting/northing issue.

[proj4-bot]

Comment by cyberworldukltd on 2 Feb 2012 06:52 UTC
According to the EPSG guidance notes on transverse mercator south orientated the false easting and false northing effectively become a false westing and false southing however this is not reflected in the current approach to support TMSO.

Thanks
CW-Mobile Phone Accessories
iPhone 4 Case & Covers

[proj4-bot]

Comment by gfleming on 31 Aug 2013 14:46 UTC
I concur that proj4 has implemented TMSO incorrectly. Now that the full series of south facing CRSs have been released by the EPSG [and are available in QGIS 2, ArcGIS 10.2 and possibly others, I have had occasion to test them using real south-facing coordinates.

In the current implementation only the y value is being negated whereas both coordinates must be negated AND swap axes such that x => -y and y => -x.

Refer to the attached 'south-oriented_TM_coords.csv'. To get it to draw correctly in QGIS 2.0 in EPSG:22287 CRS you have to swap the X and Y column headers. It is in north west Lesotho.

1 odd numbers in 22293 and all numbers in 2055

[proj4-bot]

Comment by warmerdam on 31 Aug 2013 15:18 UTC
Gavin,

Could you give me a couple points in EPSG:22287 and what they ought to be in WGS84?

[proj4-bot]

Comment by gfleming on 1 Sep 2013 15:33 UTC
I think the issue might just be the predefined proj4 EPSG strings and not how proj4 implements them.

If north-facing coordinates are defined by +axis=enu then the official South African TMSO CRS ("LO") should simply be +axis=swu and not +axis=wsu. I'm struggling to test this in QGIS now because of http://hub.qgis.org/issues/8487. If this is the case then all that needs to be changed is the +axis flag in all the "LO" definitions (odd numbers in 22293 and all numbers in 2055)

[proj4-bot]

Comment by warmerdam on 3 Sep 2013 02:01 UTC
Gavin,

I have reviewed the EPSG 22287 description as reported in the Galdos produced EPSG registry web site. Unfortunately, it seems impossible to get a direct url to a report due to loads of javascript bullshit (I fondly remember when the web was html documents with urls!). However, I have attached an html capture of the report page which unfortunately Trac won't render nicely.

The gist of it is that EPSG claims EPSG 22287 is supposed to be westing for the first coordinate axis, and southing for the second. I believe that the PROJ.4 definitions is created based on that. Of course, it isn't uncommon for folks not to necessarily honour the EPSG axis orders (ie. for EPSG:4326) but I'm not sure how I can know when I should or shouldn't do so. If you can give me a strong assurance that the order should be reversed for essentially all gis use of 22287 and similar PCS codes the I can introduce an override though I just hate doing that.

I do agree that the issue is likely around creation of the PROJ.4 init strings from EPSG's dictionary rather than being breakage in the core PROJ.4 engine.

[proj4-bot]

Comment by gfleming on 3 Sep 2013 11:30 UTC
Frank

As per http://trac.osgeo.org/proj/wiki/TMSO

 The Y-axis lies on the equator and increases positively in a westerly direction while the X-axis lies on the central meridian and increases positively in a southerly direction.

and other discussion and references on that page, incl http://www.dwa.gov.za/iwqs/gauss/node7.html#SECTION00025000000000000000, I guess it depends on how the coordinates are ordered in the original geometry. I've attached test_TMSO_axis orientation.csv above to do some testing. What I call 2050_reversed should actually be 2050 according to the EPSG. But according to South African convention as I am familiar with it, what I call 2050 is how we work with TMSO. i.e. we reverse the EPSG axis ordering convention. But I will do a snap survey to confirm this before we jump to conclusions. And we should probably check how ESRI and others handle it so it's consistent.

[proj4-bot]

Comment by gfleming on 29 Sep 2013 12:39 UTC
Replying to warmerdam:

The gist of it is that EPSG claims EPSG 22287 is supposed to be westing for the first coordinate axis, and southing for the second. I believe that the PROJ.4 definitions is created based on that. Of course, it isn't uncommon for folks not to necessarily honour the EPSG axis orders (ie. for EPSG:4326) but I'm not sure how I can know when I should or shouldn't do so. If you can give me a strong assurance that the order should be reversed for essentially all gis use of 22287 and similar PCS codes the I can introduce an override though I just hate doing that.

Based on feedback from the community in SA I think we can lay this to rest: EPSG and proj.4 do define and implement the SA south-facing CRS correctly. Surveyors do use +axis=wsu. GIS practitioners just need to remember to ensure that the coordinate order matches; as you say, some people don't honour EPSG axis orders and use x,y when they should be using y,x (since the South African surveyors' westing is y and southing is x).

[proj4-bot]

Attachment added by gfleming on 17 Oct 2008 09:00 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/SA Cape datum.csv

[proj4-bot]

Attachment added by gfleming on 17 Oct 2008 09:00 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/SA Hartebeesthoek datum.csv

[proj4-bot]

Attachment added by gfleming on 30 Aug 2013 04:39 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/south-oriented_TM_coords.csv

[proj4-bot]

Attachment added by gfleming on 1 Sep 2013 06:28 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/south-oriented_TM_coords_projected_to_4326.csv

[proj4-bot]

Attachment added by warmerdam on 3 Sep 2013 01:56 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/22287.html

[proj4-bot]

Attachment added by gfleming on 3 Sep 2013 11:08 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/test_TMSO_axis orientation.csv