Working with
QGIS Desktop 3.4.12 with GRASS 7.6.1 (Long Term Support)
The following process:
- New Project > CRS = WGS84
- Add 2 x shapefile WGS84 layers (From http://www.naturalearthdata.com/downloads/50m-cultural-vectors/)
- Add Oranjemund town layout - Schwarzeck / Lo22/17
results in proper view of information (North South orientation), however, the process (different order of actions):
- New Project > CRS = WGS84
- Add Oranjemund town layout - Schwarzeck / Lo22/17
- Add 2 x shapefiles in WGS 84
results in all three data sets to be displayed upside down (South North). The only difference between the two processes, is the sequence in which data sets are loaded.
Thus, in order to have data sets in Schwarzeck / Lo22/17 on their own would require one to first load a WGS84 data set, and only then the Schwarzeck / Lo22/17 data set, in order to ensure proper display.
This should not be an issue, surely.
Could someone with background to these projections explain what the user needs to do to ensure that data sets in Schwarzeck projection behave consistently and as expected on their own, and not be dependent on a Geographic Coordinate System like WGS84 ?
EDIT:
After the suggestion by csr that this is a bug, the notification received a very flippant response : Not bug, user has to do workaround. This is a contradiction in terms, but hey, we live in a world of fuzzy logic.
The workaround suggested in response of the bug notification: "Just use a north-oriented projection instead, or manually rotate the map frame if you want north-up!" therefore, reducing this to an apparent user preference instead of incorrect behavior by QGIS.
Tentative Proper Workaround:
Create user projection that excludes the +axis parameter from the proj4 string.
Follow the discussion of the "SOUTH ORIENTATED TRANSVERSE MERCATOR (TMSO)" at https://github.com/OSGeo/PROJ/wiki/TMSO
To illustrate, three re-projections of world WGS data
- Proj Projection = Standard Schwartzeck EPSG:29371 ---> Re-projected WGS84 data upside down
- Proj Projection = Amended Schwartzeck ---> Re-projected WGS84 data CORRECT (EPSG:29371 minus "+axis" parameter)
- Proj Projection = User Schwartzeck and ellipsoid param ---> Re-projected WGS84 data CORRECT (EPSG:29371 minus "+axis" minus "+ellps" parameters)
OR edit standard EPSG:29371 to state "+axis=enu" as if it is a north-oriented projection.
General Comment
The small community that make use of the "SOUTH ORIENTATED TRANSVERSE MERCATOR (TMSO)" are used to having the eastings positive to the west and the northings positive to the south, thus, a double mirror, or a 180 degree rotation of the CAD Cartesian coordinate system, (Usually by only changing the sings of the coordinates) in order for the data to project the "right way up".
It is therefore a given that CAD files in Cartesian need to be treated accordingly. So when coordinates for setting out of infrastructure is taken from the CAD drawing, the text listing of coordinates need to negate the CAD Cartesian coordinate.
What is interesting is that this phenomena corresponds with EPSG:29371 standard Schwartzeck (when used in QGIs with a WGS layer present and first layer)
It is, however, not the case when adjusting the EPSG:29371 to exclude the "+axis" parameter, or even excluding "+ellps".
Comparing this to other TMSO's it is interesting to note that there are three listed EPSG's for South Africa based on WGS84 ellipsoid
- Hartebeesthoek94_Lo19 EPSG:102482 +proj=tmerc +lat_0=0 +lon_0=19 +k=-1 +x_0=0 +y_0=0 +ellps=WGS84 +units=m +no_defs
- South African CRS : HBK_NO_19
+proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs - Hartebeesthoek94 / Lo19 +proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Notice that No 1 (EPSG:102482) has "k" as negative in order to adjust for south-orientation, however, not valid for QGIS because "k" now has to be positive.
Then the other two are similar except for the difference in +axis parameter. Guess which projection works, yes, the one with +axis = enu, and not the +axis = wsu (which is supposed to be the correct setting according to https://github.com/OSGeo/PROJ/wiki/TMSO).
It is evident from the above that the "+axis = wsu" parameter has to be used with a "south orientated" ellipsoid. Both WSG84 ellipsoid as well as bess_nam ellipsoid seem to be "north oriented", so when QGIS adjusts for "+axis = wsu", the ellipsoid causes the projection to be upside down, because, the same ellipsoid using "+axis = enu", re-projects ellipsoid data correctly.
Final Solution ?
For CAD based data sets, one has to invert the data (by rotating 180 degrees about 0,0 in CAD) and then it can be used as normal with EPSG:29371 edited to "+axis = enu". All other data sets in other projections can then be successfully re-projected to "edited EPSG:29371" and be compatible.