Transverse mercator south orientated projections not supported

[halfhaggis]

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

[timlinux]

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

[halfhaggis]

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.

[timlinux]

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

[halfhaggis]

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.

[halfhaggis]

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?

[homann]

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.

[gfleming]

See also ​proj4 ticket #18 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.

[homann]

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.

[warmerdam]

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

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

[garyrsa]

Replying to 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?

[craigleat]

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

[warmerdam]

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.