QGIS » QGIS Application

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

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.

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?

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.

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.

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

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.

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?

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

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.