2

Working with

QGIS Desktop 3.4.12 with GRASS 7.6.1 (Long Term Support)

The following process:

  1. New Project > CRS = WGS84
  2. Add 2 x shapefile WGS84 layers (From http://www.naturalearthdata.com/downloads/50m-cultural-vectors/)
  3. Add Oranjemund town layout - Schwarzeck / Lo22/17

results in proper view of information (North South orientation), however, the process (different order of actions):

  1. New Project > CRS = WGS84
  2. Add Oranjemund town layout - Schwarzeck / Lo22/17
  3. 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 ?

Correct Display

Upside Down Display

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

  1. Proj Projection = Standard Schwartzeck EPSG:29371 ---> Re-projected WGS84 data upside down
  2. Proj Projection = Amended Schwartzeck ---> Re-projected WGS84 data CORRECT (EPSG:29371 minus "+axis" parameter)
  3. 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.

Standard Schwartzeck Projection EPSG:29371

Edited Schwartzeck Projection EPSG:29371 (without +axis)

User Projection -Schwartzeck Projection minus +axis minus +ellps

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

  1. 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
  2. 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
  3. 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.

3
  • Do you have a link to your EPSG::29377 data?
    – nmtoken
    Oct 24, 2019 at 14:17
  • This has to be a bug. You can make a bug report here: github.com/qgis/QGIS/issues
    – csk
    Oct 24, 2019 at 14:25
  • The answer would be to ensure that the client (e.g. QGIS) is axes aware when making on-the-fly CRS transformations, so EPSG::4326 is lat/long and epsg::29377 is westing/southing. If the data is not in that format and the client is axes aware, or if the data is in that format, and the client is not axes aware, then you will have problems.
    – nmtoken
    Oct 24, 2019 at 16:16

2 Answers 2

1

Thanks for all the responses.

The best practical answer is to implement the following in order to have "normal behavior" in QGIS.

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 with "with EPSG:29371 edited to "+axis = enu" and be correctly re-projected. (Such as using Google Earth kml's directly into Schwartzeck project without further workarounds)

1

It seem that when you add the first layer on an empty project QGIS automatically set the project CRS to this first layer CRS regardless of what it was before (I don't know if that's a bug or not....).

So if your first layer is in WGS84 the project stay in WGS84 and all subsequent layer are "on the fly" re projected to the project CRS (so again WGS84, north up)

When you add your Oranjemund town layout layer first the project CRS is automatically set to Schwarzeck / Lo22/17 (look the CRS indication in the bottom right corner of the QGIS window changing after you add the layer) and all other layer you add after that are "on the fly" reprojected to the project CRS (now Schwarzeck / Lo22/17) and are also displayed in a south-up way.

The best way to ensure that you got the display you want is to set the project CRS after adding your layer.

EDIT :

I guess it all come down to different interpretation, visibly QGIS developer think that QGIS data frame is a "regular" cartesian coordinate system with the X axis as horizontal with more positive value on the right and the Y axis as vertical with more positive value up. So when using a south up projection the south end at the top and the north at the bottom to reflect that the projection has positive value for the south. To be honest I find this 'the right way" because it's what is the norm when plotting value in cartesian coordinate (or at least the most commun use even if it's not a strict norm), if they where to set a behavior where the reference frame rotate to always have the north up (or to always display what people are used to to see) they will run in problem with lots of projection and have to revert to arbitrary choice that wont please everyone.

Anyway there are numerous way to display the data in the most pleasing way for you, like using another CRS for display purpose (you could choose different CRS for data frame (project CRS) and for any map element in your print layout) or rotating the display to your preferred amount.

EDIT 2:

What I mean is that the QGIS display is "fixed" to '+' is to the up (vertical axis) and right (horizontal axis) and all data are plotted this way regardless of projection or any other convention : QGIS is just looking at coordinate value and plot (+,+) value in the up and right corner and (-,-) value on the bottom and left corner.

So in your case QGIS is not looking at where north is or if this specific projection should be displayed differently, as Data on Schwartzeck projection have coordinate set to "the more south you are the more positive the Y coordinate is" it is displayed inverted to the usual cartographic convention (so south up and not the usual north up) but consistant to the usual cartesian plane convention (positive coordinate are up, negative are down)used by QGIS. (I don't take side on if this is good or not just explaining why it's displayed this way in QGIS data frame).

Anyway this is just QGIS data frame display, if you want to produce any document (map, layout to contractor...) you will have to choose a CRS, a scale and a rotation for your print layout that suit the purpose of your map, the data you are mapping and the size of your paper (by default these are set as project CRS, a scale that allow to show the same extend as data frame and 0° rotation but you don't have to choose the default if that's not what you want)

4
  • - the "on the fly" idea is fine, but on its own, the Schwarzeck should be able to have correct north-south orientation. The issue is that Schwarzeck seems to rely on WGS84 to "know" which side is up. Note: layer with Schwarzeck on its own is also upside down.
    – Jaco V
    Oct 24, 2019 at 15:19
  • @Jaco the Schwarzeck is a South-up projection, so when on his own the "normal" orientation is south-up (and the unit is "German legal metre" : 1.0000135965m) this is a rather unusualy oriented projection but if you look at the link you provide (epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::29377) you will read : METHOD["Transverse Mercator (South Orientated)" ; AXIS["westing (Y)",west ; AXIS["southing (X)",south...
    – J.R
    Oct 25, 2019 at 8:22
  • although the epsg reports it as "south up" as "normal", we do not walk upside down over here. Our layouts to contractors, our maps to tourists, our reference to "up", all are north based. So it would be incorrect to assume that the epgs should be "South orientated". As per my answer, in order to work "as normal", the +axis parameter needs to pretend the projection is north oriented (enu not wsu). We can then use data from any of the recognized sources and produce maps and other information with north pointing upwards, as is usual for this part of the globe for centuries.
    – Jaco V
    Oct 25, 2019 at 9:36
  • Kindly note arbitrary ≠ convention. Cartesian system describes same space as polar system, so the various projections. Same space. By convention, geodetic system "N" vs "S", Cartesian "+" vs "-" for "vertical". Presenting a graph in the 3rd quadrant Cartesian, is same as presenting graph in 1st quadrant - only coord signs differ. Your suggestion - projections used in the south must be turned 180 degrees - why? What happens near or over the equator? The difference in projection lies solely with coord values. Convention - map "up" north ↑, convention - even in southern hemisphere!
    – Jaco V
    Oct 25, 2019 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.