QGIS 3 and Southern Hemisphere, Transverse Mercator Projection - Schwarzeck - Upside Down display #32391
Comments
JacoV69
added
the
Bug
|
@JacoV69 I would appreciate if the infos about the issue can be reported directly here rather than posting a SE post. Thanks! |
|
Is this even a bug? From my interpretation of the stackexchange question it's all working as designed, and showing that projection in its correct orientation. If you want to convert that projection to a north-up orientation, you'd need to rotate the map frame manually |
|
Dear Nyall
Thank you for your response.
As indicated, the Schwarzeck on its own displays upside down. This is
not as designed.
The workaround is to first load a WGS84 layer and only thereafter load
the Schwarzeck projection.
You can easily reproduce the error. Any OSM data from Namibia
reprojected to a relevant Schwarzeck projection will initially seem to
display correctly. However, when this layer is loaded into a new
project on its own it displays upside down.
This is surely not as designed.
Trust you find the above satisfactory.
Kind Regards
Kobus vd Merwe
…On 10/25/19, Nyall Dawson ***@***.***> wrote:
Is this even a bug? From my interpretation of the stackexchange question
it's all working as designed, and showing that projection in its correct
orientation. If you want to convert that projection to a north-up
orientation, you'd need to rotate the map frame manually
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
|
I believe it IS as designed. The existing answer on stackexchange already explains why the project CRS differs depending on the order in which layers are loaded. epsg 29377 is south-oriented, hence the "upside down" appearance of the map. Just use a north-oriented projection instead, or manually rotate the map frame if you want north-up! Just to further reinforce that qgis is correctly handling this situation, here's a screenshot showing a north arrow set to "true north" correctly orienting with a map set to epsg 29377:
|
|
Dear Nyall
Thank you for your response.
It is difficult to understand how something behaves as designed and
simultaneously also need a workaround.
It should never be an option to make use of a different projection
just because the required projection is not working out.
Why? Because we live in the real world.
There are many instances where a whole project is done from legacy
projected data and the "just use a north-oriented projection" would
never be accurate to interact with this legacy data.
Your response for a workaround is presumably due to the Schwarzeck not
being a major projection and only used by few practitioners in a
remote minuscule country. Not good enough.
Having compared a user based proj4 setup for Schwartzeck with the
official setup, it is realized that the additional "+axis" parameter
is added, which is supposed to notify that the projection is south
based.
This "+axis" parameter seems not to be supported by QGIS, thus,
results in an error. This is then the reason for the upside-down
display.
A very logical approach by elimination reveals
Proj Projection = Standard Schwartzeck ---> Re-projected WGS84
data upside down
Proj Projection = Amended Schwartzeck ---> Re-projected WGS84
data CORRECT
Proj Projection = User Schwartzeck and ellipsoid param --->
Re-projected WGS84 data CORRECT
Conclusion:
QGIS is has a problem with handling the +axis parameter
Workaround:
NOT the idiotic idea of making use of some north-oriented
projection with wrong projection settings
BUT !!! to exclude the +axis parameter altogether, because QGIS
cannot handle +axis parameter correctly
Bug Fix Suggestion
Improve code for handling +axis parameter, taking due cognizance of
ellipsoid parameters of Bessel-Namibia which seems to reverse the
adjustment QGIS makes for the +axis parameter.
It is unfortunate that fuzzy logic should dictate the response for
something that is clearly not correctly implemented, by suggesting
that inappropriate projections be used in order to set the north-south
orientation, IGNORING the balance of the projection parameters
yielding incorrect data.
I have now comprehensively commented and demonstrated that there is an
error. It is easy to reproduce the error on any installation of QGIS
3.x, which you have not done.
Not anticipating any positive response from you, I conclude thus.
Kind Regards
Kobus vd Merwe
…On 10/25/19, Nyall Dawson ***@***.***> wrote:
@JacoV69
I believe it IS as designed. The existing answer on stackexchange already
explains why the project CRS differs depending on the order in which layers
are loaded. epsg 29377 is south-oriented, hence the "upside down" appearance
of the map. Just use a north-oriented projection instead, or manually rotate
the map frame if you want north-up!
Just to further reinforce that qgis is correctly handling this situation,
here's a screenshot showing a north arrow set to "true north" correctly
orienting with a map set to epsg 29377:
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
|
This is not a bug and everything works correctly and is by design. South African and Namibian 'LO' CRSs are upside down and back to front. I proposed this a while ago to make it more intuitive: #19599 In the meantime if you want north up, just project your canvas to another CRS. You could make Namibian equivalents of the ZANGI ones we added to QGIS in 2013. The 'north-up' versions of the LO CRSs are not standard therefore are not in the EPSG database nor in any GIS software so you have to create your own custom ones. |
|
Dear Gavin
Thank you for your reply below.
Could you kindly refer me to an objective source that states that the
SOUTH ORIENTATED TRANSVERSE MERCATOR (TMSO) are "upside down and back
to front". Remember, QGIS is not an objective source.
It would be helpful if you could also provide any map since inception
(circa 1833) of the TMSO that indicates or is orientated "upside down
and back to front" for the two countries mentioned.
There is repetitive statements coming from the QGIS side which are
"just so" statements. The entire body of knowledge of TMSO survey for
the two countries (and believe me that Namibia has many archived maps
with the Schwarzeck projection) would need to be upset in order to
justify the QGIS statement "upside down and back to front". It is
simply not a viable statement as it is proven wrong by all the maps
dating back to the 19th century.
The Clarke 1880 ellipsoid used with Transverse Mercator is a case in
point. Actually, "In South Africa the Gauss Conform Projection
(modification of the Mercator projection) is used ", whereas "Gauss
Conform Projection" is the " Gauss–Krüger" projection. Later (early
1990's) South Africa moved to the WGS84 ellipsoid.
The initial "Cape Datum" was established in 1833. Since then, all the
maps produced to today have been produced with "North Up". Kindly
refer to http://www.ngi.gov.za/index.php/technical-information/geodesy-and-gps/datum-s-and-coordinate-systems
Historically, the maps used in SADC (Southern Africa Development
Community) region are British, Portuguese and German based and all
follow the same basic conventions as set out in the link referenced
above.
You will not find any official map from these territories that has a
reference other than "North Up".
It is incomprehensible that the QGIS statements are contrary to the
established convention and the established official data supplied.
Repeating these statements many times would not change the conventions
established more than a century ago.
If you are not interested in implementing the projections correctly,
then at least have the integrity to qualify that you are not fully
supporting the TMSO's. There is a workable workaround that circumvent
the shortcomings of the design.
I trust that the objective references to the use of TMSO's in SADC
will not in the future be nullified in order to satisfy subjective
claims.
I further trust that you would acknowledge the authority of the
references supplied and conclude positively on the matter. Otherwise
it might be construed as jest and revile.
Kind Regards
Kobus vd Merwe
…On 10/29/19, Gavin Fleming ***@***.***> wrote:
This is not a bug and everything works correctly and is by design.
South African and Namibian 'LO' CRSs **are** upside down and back to front.
I proposed this a while ago to make it more intuitive:
#19599
In the meantime if you want north up, just project your canvas to another
CRS. You could make Namibian equivalents of the ZANGI ones we added to QGIS
in 2013.
The 'north-up' versions of the LO CRSs are **not** standard therefore are
not in the EPSG database nor in any GIS software so you have to create your
own custom ones.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
|
I would tend to agree with @JacoV69. The axis order and orientation of the EPSG code doesn't necessarily constrain how we might decide to represent them (carto)graphically. They are just a rule to be able to transmit coordinates in a unambiguous way. For example, if we use a projected Northing-Easting system (contrary to the usual Easting-Northing order), we wouldn't want to represent the Northing along the horizontal axis of the screen and the Easting along the vertical axis of the screen. So for TMSO West - South, we might represent it with increasing westing from left to right of the screen, and increasing southing from top to bottom of the screen, while still being conformant to TMSO if we display the correct coordinates. |
|
The EPSG guidance note 7-2 https://www.iogp.org/wp-content/uploads/2019/09/373-07-02.pdf paragraph "3.2.3.3 Transverse Mercator (South Orientated)" has a diagram that is compatible with the traditionnal cartographic conventions, that is horizontal axis with longitudes/eastings increasing from left to right, and vertical axis with latitudes/northings increasing from bottom to top |
|
Hi @JacoV69, there's nothing contrary to convention here, nor to authorities such as NGI. I think you have the wrong end of the stick. I'm just explaining why TMSO coordinates defined properly in, say, EPSG 29375 will draw upside down and back to front (if your canvas is in 29375, so will everything else draw upside down and back to front, but everythign will be perfectly overlaid). Never mind the projection or software, if you draw an SO coordinate on a NO set of axes, it will draw upside down and back to front. Basic maths. If you want it to draw north up on NO axes, you have to swap coordinates and change signs, which is what GIS people in SA and Namibia have done since the dawn of GIS, because all GIS software uses a standard NO (x,y) set of axes. OR you can flip the axes in the GIS to get north-up. Which is what effectively happens if you project your QGIS canvas, from, say EPSG 29375 (Schwarzek LO 22/15) to 32733 (UTM33S), or what would happen if #19599 were implemented. Again, I emphasise there is no bug here and no-one is trying to be difficult. I'm happy to have a call or screenshare to demonstrate (I'm in Joburg) |
|
Dear Gavin
Thank you again for your email and responses.
So it is then obvious that since the dawn of GIS systems, we had to
negate the coordinates for proper "North Up" orientation, because we
work that way (north up) before the dawn of GIS, without having to
negate coordinates.
(Definition : negate coordinates, or similar wording, means that
coordinates have to be rotated about the origin of the projection for
a total of 180 degrees, or the double flip about horizontal and
vertical axis, or just to change the sign of coordinates by
multiplying the coord by -1).
So, what is the logical design? Do the orientation for the client
when you implement the projection without the client having to negate
the coordinates. Because negating the coordinates since the dawn of
GIS is exactly the workaround for the GIS work to be compatible with
the convention.
As per http://www.dwa.gov.za/iwqs/gauss/node7.html (supposedly an
"official and expert" site) "... ARC/INFO GIS absobloominglutely
insists ...", it is evident that since the dawn of GIS there was
frustration on this issue, as it was necessary to make a workaround,
precisely because the GIS systems were not designed to handle the
south oriented projections "in accordance with convention" "out of the
box".
This is precisely the reason for the introduction of the +axis
parameter for proj4 format, as per
https://github.com/OSGeo/PROJ/wiki/TMSO. Whereas it is intimated that
"+axis = wsu" is suggested to take the burden off the user for
negating the coordinates (or workaround).
As you are based in RSA, you might be familiar with "Civil Designer"
software. There implementation of the south orientated projects are
correct as long as you stay within the programme. Reading to and
writing from, as well as displaying the data, does not require
adjustment of any kind, unless (again) data is ported to AutoCad, or
other "north biased software".
So, after the merry-go-round, you confirm that the user has to adapt
to the circumstance as the design does not allow "out of box"
solution.
The proper design for a GIS would be to implement the projections
without the need for the user to compensate or workaround.
Conversely, if the design of the GIS does not cater for the above, and
continues to rely on the user to make
adjustments/workarounds/compensate, then the design is not proper.
So, call it a term that is palatable, but for QGIS to claim "proper
design" the current design has to be adjusted. It is obviously also
the prerogative not to implement a design that removes the burden for
adjustment from the user, but then the claim cannot be made for
"proper design".
I truly hope this puts raising this issue to bed. What is done about
it is on the side of the QGIS developers and the user can only hope
that objectivity and user oriented solutions would be implemented.
Kind Regards
Kobus vd Merwe
…On 10/29/19, Gavin Fleming ***@***.***> wrote:
Hi @JacoV69, there's nothing contrary to convention here, nor to authorities
such as NGI. I think you have the wrong end of the stick. I'm just
explaining why TMSO coordinates defined properly in, say, EPSG 29375 will
draw upside down and back to front (if your canvas is in 29375, so will
everything else draw upside down and back to front, but everythign will be
perfectly overlaid).
Never mind the projection or software, if you draw an SO coordinate on a NO
set of axes, it will draw upside down and back to front. Basic maths. If you
want it to draw north up on NO axes, you have to swap coordinates and change
signs, which is what GIS people in SA and Namibia have done since the dawn
of GIS, because all GIS software uses a standard NO (x,y) set of axes. OR
you can flip the axes in the GIS to get north-up. Which is what effectively
happens if you project your QGIS canvas, from, say EPSG 29375 (Schwarzek LO
22/15) to 32733 (UTM33S), or what would happen if
#19599 were implemented.
Again, I emphasise there is no bug here and no-one is trying to be
difficult. I'm happy to have a call or screenshare to demonstrate (I'm in
Joburg)
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
|
@JacoV69 since only a small proportion of global users have this issue (i.e. just SA and Namibia afaik) it hasn't been high on anyone's priority list to develop. The current solution is hardly a workaround - you just set your canvas to a NO CRS and that's that. If it's important to you, you are welcome to provide a patch for #19599 or fund a QGIS developer to do so. That's how the FOSS community works - by community participation and contributions. |
|
Dear Gavin
Thank you for the mail below and acknowledging the issue that QGIS
does not properly cater for our situation.
Setting an "NO CRS" remains a workaround for display issues ONLY, as
it does not treat the coordinates correctly. Thus any utilization of
coordinates still requires negation of coordinates.
So, "NO CRS" does not solve the issue. The better workaround as was
my answer to my own question, make use of custom projection and negate
coordinates when utilizing coordinates outside of QGIS.
The reason why "NO CRS" is not a good workaround is that a mixture of
projections would be distorted, either the other data or the TMSO
data.
Therefore, "NO CRS" should not be suggested at all.
As for user group being small and therefore requires funding to
develop the proper implementation is a consequence of the lack of
support. There is not "nice to have" funding on this side, especially
without an indication of typical costs involved.
Hope one day the interest in the subject is higher.
Kind Regards
Kobus
…On 10/30/19, Gavin Fleming ***@***.***> wrote:
@JacoV69 since only a small proportion of global users have this issue (i.e.
just SA and Namibia afaik) it hasn't been high on anyone's priority list to
develop. The current solution is hardly a workaround - you just set your
canvas to a NO CRS and that's that.
If it's important to you, you are welcome to provide a patch for
#19599 or fund a QGIS developer to do so.
That's how the FOSS community works - by community participation and
contributions.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
|
Hi @JacoV69 I'm afraid you are wrong in several areas.
|
|
Dear Gavin
This is a blast!
1 : I do know how to set NO CRS (although I am working on QGIS 3.4
LTS, the setting is still "no projection / unknown earth projection")
The point that is missed here. You can only work on map sets that are
of the same original projection. OBVIOUSLY, adding WGS84 shape files
with Schwarzeck coordinates will not render the two sets together and
the WGS84 would be distorted.
The elaborate pictures in the original post clearly illustrates this issue.
2 : I did not intimate that the QGIS community is small, but that the
request community (those benefiting from proper implementation) is
small.
3 I know, the quote from 1997 is in relation to ArcGis functionality.
4 Yeah, anything is for sale.
So nothing I got wrong. Quite the contrary, my initial raising of the
issue stated all that has been confirmed, albeit the long way around
as focus is not always on the issue, but most often about the
messenger of the issue.
There is thus no need to do a screen cast, the workaround stays the
workaround and the functionality would most probably lack for the
foreseeable future.
Kind Regards
Kobus vd Merwe
…On 10/30/19, Gavin Fleming ***@***.***> wrote:
Hi @JacoV69
I'm afraid you are wrong in several areas.
1. You do not need to change any coordinates and a canvas NO CRS will solve
the issue. I would appreciate an opportunity to understand your situation
and help you via a screenshare session (just fill in a contact form on
kartoza.com and I'll get back to you).
[This](https://gist.github.com/gubuntu/6403425) might also help.
2. It's not the QGIS community that is small, it is that we are the only two
countries in the world using TMSO afaik.
3. There is no other mainstream GIS package to my knowledge that does what
you want. CAD, yes, but not GIS.
4. A FOSS community like this is the opposite of a proprietary behemoth - if
you want new funcitonality it can be implemented in a quick turnaround -
someone just needs to put up the time / money.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#32391 (comment)
|
nyalldawson
added
the
Projections/Transformations
|
Where do we stand with this report? |
|
There has been no movement as far as I could assess. Users have two workarounds
Draw back - depending from where data is sourced, user has to assign one of the two workarounds. Specifically draw back when working with both workarounds due to historical reasons. The only solution offered was add-on at development cost. Kind Regards |
|
Hi. This topic came to my desk recently from several ways. First in the Czech Republic (using southing-westing EPSG:5513), that I tried to fix in OSGeo/PROJ#4084 . @rouault halted it thinking what we should solve the problem completely in PROJ. I have the impression that the "upside-down" effect cannot be fixed in PROJ, but has to be done in the application side (if you consider it is a bug). In South Africa they also use westing-sourthing CRSs. (Just a comment: westing-southing are only the projected systems. those geographic systems are northing-easting, lat-lon).
As you can see he is rotating the view. In other "traditional printed maps" north is also at the top: https://itoldya420.getarchive.net/amp/media/sa-topographic-sheet-3418abandad-1ed-1942-113679 It is true that there is a workaround, rotating the view in the status bar. I do not know if that option was there in 2019 when @JacoV69 created the ticket. At least now it is clear to me how it is used in South Africa and how I can rotate it in QGIS. |
Description of problem at
https://gis.stackexchange.com/questions/339685/qgis-3-and-southern-hemisphere-transverse-mercator-projection-schwarzeck/339691#339691
Report of bug proposed by csk
The text was updated successfully, but these errors were encountered: