Opened 8 years ago

Closed 3 years ago

#18 closed defect (fixed)

lack of support for South African projections

Reported by: gfleming Owned by: warmerdam
Priority: critical Milestone:
Component: default Version: unspecified
Keywords: tmso Cc: neteler, craigleat

Description

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 csv’s 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 don’t think it’s 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'?

Attachments (6)

SA Cape datum.csv (8.8 KB) - added by gfleming 8 years ago.
SA Hartebeesthoek datum.csv (7.0 KB) - added by gfleming 8 years ago.
south-oriented_TM_coords.csv (760 bytes) - added by gfleming 3 years ago.
south-oriented_TM_coords_projected_to_4326.csv (2.5 KB) - added by gfleming 3 years ago.
tab-delimited file with WKT points in 4326, correct 22287 and current proj4 incorrect 22287
22287.html (18.9 KB) - added by warmerdam 3 years ago.
Galdos/EPSG Registry Report on 22287 (as html)
test_TMSO_axis orientation.csv (723 bytes) - added by gfleming 3 years ago.
load this in QGIS with polygon of South Africa, label with crs field, enable on the fly CRS, set to 4326. Cycle layer CRS definition between 4326,2050,'reversed 2050' and custom SACRS_NO ('north-oriented 2050')

Download all attachments as: .zip

Change History (19)

Changed 8 years ago by gfleming

Changed 8 years ago by gfleming

comment:1 Changed 8 years ago by neteler

  • Cc neteler added

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. 

comment:2 Changed 7 years ago by craigleat

  • Cc craigleat added

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

comment:3 Changed 7 years ago by warmerdam

  • Status changed from new to assigned

I have implemented preliminary support for a +axis switch to control axis orientation in PROJ.4 trunk (r1825).

comment:4 follow-up: Changed 7 years ago by warmerdam

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.

comment:5 in reply to: ↑ 4 Changed 7 years ago by craigleat

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.

comment:6 Changed 6 years ago by warmerdam

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

comment:7 Changed 5 years ago by cyberworldukltd

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

Changed 3 years ago by gfleming

comment:8 Changed 3 years ago by gfleming

  • Priority changed from major to critical

I concur that proj4 has implemented TMSO incorrectly. Now that the full series of south facing CRSs have been released by the EPSG [1] 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 [22275 22293] and all numbers in [2046 2055]

comment:9 Changed 3 years ago by warmerdam

  • Keywords tmso added

Gavin,

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

Changed 3 years ago by gfleming

tab-delimited file with WKT points in 4326, correct 22287 and current proj4 incorrect 22287

comment:10 Changed 3 years ago by gfleming

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 [22275 22293] and all numbers in [2046 2055])

Changed 3 years ago by warmerdam

Galdos/EPSG Registry Report on 22287 (as html)

comment:11 follow-up: Changed 3 years ago by warmerdam

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.

Changed 3 years ago by gfleming

load this in QGIS with polygon of South Africa, label with crs field, enable on the fly CRS, set to 4326. Cycle layer CRS definition between 4326,2050,'reversed 2050' and custom SACRS_NO ('north-oriented 2050')

comment:12 Changed 3 years ago by gfleming

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.

comment:13 in reply to: ↑ 11 Changed 3 years ago by gfleming

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.