Bug report #1176

Transverse mercator south orientated projections not supported

Added by Neil Robinson - about 12 years ago. Updated over 10 years ago.

Status:Closed
Priority:Low
Assignee:Magnus Homann
Category:Projection Support
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:invalid
Crashes QGIS or corrupts data: Copied to github as #:11236

Description

I need to project maps in South Africa, where we use the Hartebeesthoek projections. These are based on transverse mercator south orientated.

These projections are not supported, making it impossible for me to carry out any measurements etc. This effectively makes the application useless in most cases where such projections are needed.

It appears to be related to the fact that proj4 lacks support for south orientated projections.

Is there some way around this? Is there a solution using PostGIS, perhaps? If so, it should be highlighted for new users, with clear instructions on how to implement it.

Lastly there are quite a number of South orientated coordinate reference systems included with the QGIS database and it certainly does support them.

Regards

Tim

SA_Hartebeesthoek_datum.csv Magnifier (7.04 KB) Gavin Fleming, 2008-10-17 02:27 AM

SA_Cape_datum.csv Magnifier (8.76 KB) Gavin Fleming, 2008-10-17 02:28 AM

History

#1 Updated by Tim Sutton about 12 years ago

  • Status changed from Open to Closed
  • Resolution set to invalid

Hi

You can define custom projection definitions using the tool provided under the tools menu. Also your terminology is I think incorrect - Hartebeeshoek is a datum describing the spheroid. AFAIK Surveys and Mapping began phasing out the use of the Hartebeeshoek datum around 9 years ago, in favour of the WGS84 datum.

Regards

Tim

#2 Updated by Neil Robinson - about 12 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (invalid)

One can define custom projections, and I tried, but proj4 does not support transverse mercator south orientated projections. There is no +proj attribute that describes that projection.
I don't dispute that other south orientated projections are supported, but those projections unfortunately don't help me at all.

Essentially, the bug is that I cannot use this projection with qgis:
Hartebeesthoek94 / Lo29

Or any of these, with the exception of EPSG:4148, which is the Hartebeesthoek datum describing the spheroid that you mention.

I'm leaving priority as minor, since this problem won't affect many of your users, but from my perspective it is pretty much a show-stopper.

#3 Updated by Tim Sutton about 12 years ago

Hi

Thanks for the update. I see on http://spatialreference.org/ref/epsg/2053/ that even there your CRS is not supported:

Input Coordinates: 29, -27.55
Output Coordinates: An error occurred.

The problem lies in proj4 and you should take it up with them. Short of rewriting our whole on the fly projection subsystem, I don't have any ready answers for on on how we might deal with this.

One thing I wanted to mention is that proj also lets you describe a datum using your own ellipsoid etc settings rather than using a named datum. Have you tried this approach?

Regards

Tim

#4 Updated by Neil Robinson - about 12 years ago

I've been communicating with Gerald Evenden who has a lot to do with the proj4 library.

Via command-line, I can get the correct projections with this sample input (filename proj2):
26.67029 -30.69927

where first column is longitude and second column latitude

and this command and output
$ proj +proj=tmerc +ellps=WGS84 +lon_0=27 -m -1 proj2
31587.18 3397679.73

The -m flag doesn't work when defining a custom projection in qgis. Is there some other way to get the -m behaviour when defining custom projections?

From the proj man file:

-m mult
The cartesian data may be scaled by the
mult parameter. When processing data in
a forward projection mode the cartesian
output values are multiplied by mult oth‐
erwise the input cartesian values are
divided by mult before inverse projec‐
tion. If the first two characters of
mult are 1/ or 1: then the reciprocal
value of mult is employed.

#5 Updated by Neil Robinson - about 12 years ago

command and output line should read:
$ proj +proj=tmerc +ellps=WGS84 +lon_0=27 -m -1 proj2
31587.18 3397679.73

Where'd tht line-break go?

#6 Updated by Magnus Homann about 12 years ago

  • Status changed from Feedback to Open

You are right, the '-m' parameter does not work. It does however work in the "test" box in the custom CRS dialog. There is hope. :-)

See also #1352.

#7 Updated by Gavin Fleming about 12 years ago

See also proj4 ticket #3921 and PostGIS ticket 61

I'm not sure -m is the approach - we're not trying to switch coordinate signs here.

The Hartebeesthoek datum references the WGS84 ellipsoid. There is no transformation between them so they can be used interchangeably in practice - they differ in name only, but Hartebeesthoek is the South African standard and has been since 1999.

Interest only: The old datum, which still applies to much data, is the Cape datum (Clarke 1880 MODIFIED). There is no accurate direct transformation between Cape and Hartebeesthoek - instead a localised, controlpoint-based transformation needs to be applied.

See http://w3sli.wcape.gov.za/SURVEYS/MAPPING/wgs84.htm for details about the Hartebeesthoek datum.

From my other tickets:

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.

#8 Updated by Magnus Homann about 12 years ago

Well, in that case it's not much we can do? We rely on proj4 and GDAL/OGR to perform the string parsing and projection logic. Both must have support for any new '+proj' or '+datum'. When that is the case, we can add support for it in Qgis.

#9 Updated by Frank Warmerdam - about 12 years ago

I would like to suggest that we add axis orientation control to PROJ.4 init strings and handle them appropriately in the OGRSpatialReference class rather than doing anything special in QGIS. I'll point to:

http://trac.osgeo.org/proj/ticket/18

and

http://trac.osgeo.org/gdal/ticket/2590

#10 Updated by Neil Robinson - about 12 years ago

I'm not sure what the right approach to fixing this in qgis is, but using the command-line tools cs2cs and proj, I get the correct results for the projections with the -m flag. As warmerdam suggests, it appears that axis orientation control would solve this.

I came to this conclusion after extensive experimentation and discussion with Gerald Evenden via the proj4 mailing list.

This post and this post seem most relevant.

#11 Updated by garyrsa - about 11 years ago

Replying to [comment:10 halfhaggis]:

I'm not sure what the right approach to fixing this in qgis is, but using the command-line tools cs2cs and proj, I get the correct results for the projections with the -m flag. As warmerdam suggests, it appears that axis orientation control would solve this.

I came to this conclusion after extensive experimentation and discussion with Gerald Evenden via the proj4 mailing list.

This post and this post seem most relevant.

The following proj definition would also sort the problem.In fact it works with the test option in "customs srs". But once stored as a custom srs it provides the wrong signs (negative)
+proj=tmerc +ellps=WGS84 +lon_0=19 +to_meter=-1.

While axis control would be the ideal solution a simple but adequate fix would be to allow the -1 in the m or to-meter parameters. Or am I missing something?

#12 Updated by craigleat - over 10 years ago

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

#13 Updated by Frank Warmerdam - over 10 years ago

I would note that south oriented tm is now supported by PROJ trunk and the support will appear in PROJ 4.8.0. I think this ticket ought to be closed as this is not at all a QGIS specific problem, unless you want to track the updated of the qgis srs dictiontary to support sotm.

#14 Updated by Paolo Cavallini over 10 years ago

  • Status changed from Open to Closed
  • Resolution set to invalid

Also available in: Atom PDF