Comments (19)
Comment by neteler on 2 Jun 2009 21:05 UTC
A similar problem was reported today http://lists.osgeo.org/pipermail/grass-windows/2009-June/001814.html with EPSG codes 4293 29371 29373 29375 29377 29379 29381 29383.
Testing in GRASS:
for i in 4293 29371 29373 29375 29377 29379 29381 29383 ; do g.proj -c epsg=$i location=epsg$i ; done
WARNING: Datum <Schwarzeck> not recognised by GRASS and no parameters found
Location epsg4293 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29371 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29373 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29375 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29377 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29379 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29381 created!
ERROR 6: No translation for Transverse_Mercator_South_Orientated to PROJ.4 format is known.
Location epsg29383 created!
But the definition seems to be known by GeoTIFF:
http://geotiff.maptools.org/proj_list/transverse_mercator_south_oriented.html
and is also listed in this file
http://www.gdal.org/ogr/ogr__srs__api_8h-source.html
The Schwarzeck datum is described here: http://www.mme.gov.na/gsn/nam-map-system.htm:
The transformation from the Schwarzeck datum into WGS 84 implies X, Y and Z shifts but no rotation. DMA NIMA and Prof. Charles Merry from the University of Cape Town do give shift values, from which the latter ones are the more accurate:
Bessel Spheroid:
a = 6377397.1550 &German legal; meter
b = 6356078.96325 German legal meter
a = 6377483.865 intern. meter
b = 6356165.383 intern. meter
f = 1/299.1528128 (no changes due to length unit)
= 0.003342773182
X, Y, Z shifts in meter
DMA ; NIMA 616 ( 20) 97 ( 20) -251 ( 20)
C. Merry (UCT) 616.80 103.30 -256.90
On the Maps in the LO system you will find the positive X axis to the south and the positive Y-axis to the west. This is a left-handed Cartesian co-ordinate system, whilst the computer thinks in a right-handed system. For the display of gridded data just use the normal co-ordinate system but be careful with the grids origin. Some software allows taking care of this by giving a negative central scale factor.
from proj.
Comment by craigleat on 31 Jan 2010 19:45 UTC
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
from proj.
Comment by warmerdam on 1 Mar 2010 04:46 UTC
I have implemented preliminary support for a +axis switch to control axis orientation in PROJ.4 trunk (3405bf70 (SVN rev1825)).
from proj.
Comment by warmerdam on 1 Mar 2010 21:07 UTC
According to the EPSG guidance notes on transverse mercator south orientated the false easting and false northing effectively become a false westing and false southing however this is not reflected in the current approach to support TMSO.
However, EPSG PCSs using TMSO (2046-2055, 22275-22293, and 29371-29385) all seem to use a false easting and northing of zero so the issue does not have an effect. If there is an issue we need to ensure that TMSO translation to proj=tmerc for proj.4 also negate the fe/fn values which it does not do now.
from proj.
Comment by craigleat on 2 Mar 2010 09:41 UTC
Replying to warmerdam:
However, EPSG PCSs using TMSO (2046-2055, 22275-22293, and 29371-29385) all seem to use a false easting and northing of zero so the issue does not have an effect. If there is an issue we need to ensure that TMSO translation to proj=tmerc for proj.4 also negate the fe/fn values which it does not do now.
In my experience it is only land surveyors and engineers that use non zero false westings and southings. I have a number of dwg/dxf files using these offsets. Currently I translate (shift) the data inside the CAD app to remove the offsets and then export to a GIS format. For me it would be useful to have correct signs applied to the fw/fs values.
from proj.
Comment by warmerdam on 31 Jul 2010 14:43 UTC
In 195e3f3e (SVN rev1874) I have incorporated definitions for TMSO projections in the epsg init file, after completion of TMSO support in GDAL's PROJ.4 translator.
This ticket remains open only in the hopes of addressing the sign of false easting/northing issue.
from proj.
Comment by cyberworldukltd on 2 Feb 2012 06:52 UTC
According to the EPSG guidance notes on transverse mercator south orientated the false easting and false northing effectively become a false westing and false southing however this is not reflected in the current approach to support TMSO.
Thanks
CW-Mobile Phone Accessories
iPhone 4 Case & Covers
from proj.
Comment by gfleming on 31 Aug 2013 14:46 UTC
I concur that proj4 has implemented TMSO incorrectly. Now that the full series of south facing CRSs have been released by the EPSG [and are available in QGIS 2, ArcGIS 10.2 and possibly others, I have had occasion to test them using real south-facing coordinates.
In the current implementation only the y value is being negated whereas both coordinates must be negated AND swap axes such that x => -y and y => -x.
Refer to the attached 'south-oriented_TM_coords.csv'. To get it to draw correctly in QGIS 2.0 in EPSG:22287 CRS you have to swap the X and Y column headers. It is in north west Lesotho.
1 odd numbers in 22293 and all numbers in 2055
from proj.
Comment by warmerdam on 31 Aug 2013 15:18 UTC
Gavin,
Could you give me a couple points in EPSG:22287 and what they ought to be in WGS84?
from proj.
Comment by gfleming on 1 Sep 2013 15:33 UTC
I think the issue might just be the predefined proj4 EPSG strings and not how proj4 implements them.
If north-facing coordinates are defined by +axis=enu then the official South African TMSO CRS ("LO") should simply be +axis=swu and not +axis=wsu. I'm struggling to test this in QGIS now because of http://hub.qgis.org/issues/8487. If this is the case then all that needs to be changed is the +axis flag in all the "LO" definitions (odd numbers in 22293 and all numbers in 2055)
from proj.
Comment by warmerdam on 3 Sep 2013 02:01 UTC
Gavin,
I have reviewed the EPSG 22287 description as reported in the Galdos produced EPSG registry web site. Unfortunately, it seems impossible to get a direct url to a report due to loads of javascript bullshit (I fondly remember when the web was html documents with urls!). However, I have attached an html capture of the report page which unfortunately Trac won't render nicely.
The gist of it is that EPSG claims EPSG 22287 is supposed to be westing for the first coordinate axis, and southing for the second. I believe that the PROJ.4 definitions is created based on that. Of course, it isn't uncommon for folks not to necessarily honour the EPSG axis orders (ie. for EPSG:4326) but I'm not sure how I can know when I should or shouldn't do so. If you can give me a strong assurance that the order should be reversed for essentially all gis use of 22287 and similar PCS codes the I can introduce an override though I just hate doing that.
I do agree that the issue is likely around creation of the PROJ.4 init strings from EPSG's dictionary rather than being breakage in the core PROJ.4 engine.
from proj.
Comment by gfleming on 3 Sep 2013 11:30 UTC
Frank
As per http://trac.osgeo.org/proj/wiki/TMSO
The Y-axis lies on the equator and increases positively in a westerly direction while the X-axis lies on the central meridian and increases positively in a southerly direction.
and other discussion and references on that page, incl http://www.dwa.gov.za/iwqs/gauss/node7.html#SECTION00025000000000000000, I guess it depends on how the coordinates are ordered in the original geometry. I've attached test_TMSO_axis orientation.csv above to do some testing. What I call 2050_reversed should actually be 2050 according to the EPSG. But according to South African convention as I am familiar with it, what I call 2050 is how we work with TMSO. i.e. we reverse the EPSG axis ordering convention. But I will do a snap survey to confirm this before we jump to conclusions. And we should probably check how ESRI and others handle it so it's consistent.
from proj.
Comment by gfleming on 29 Sep 2013 12:39 UTC
Replying to warmerdam:
The gist of it is that EPSG claims EPSG 22287 is supposed to be westing for the first coordinate axis, and southing for the second. I believe that the PROJ.4 definitions is created based on that. Of course, it isn't uncommon for folks not to necessarily honour the EPSG axis orders (ie. for EPSG:4326) but I'm not sure how I can know when I should or shouldn't do so. If you can give me a strong assurance that the order should be reversed for essentially all gis use of 22287 and similar PCS codes the I can introduce an override though I just hate doing that.
Based on feedback from the community in SA I think we can lay this to rest: EPSG and proj.4 do define and implement the SA south-facing CRS correctly. Surveyors do use +axis=wsu. GIS practitioners just need to remember to ensure that the coordinate order matches; as you say, some people don't honour EPSG axis orders and use x,y when they should be using y,x (since the South African surveyors' westing is y and southing is x).
from proj.
Attachment added by gfleming on 17 Oct 2008 09:00 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/SA Cape datum.csv
from proj.
Attachment added by gfleming on 17 Oct 2008 09:00 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/SA Hartebeesthoek datum.csv
from proj.
Attachment added by gfleming on 30 Aug 2013 04:39 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/south-oriented_TM_coords.csv
from proj.
Attachment added by gfleming on 1 Sep 2013 06:28 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/south-oriented_TM_coords_projected_to_4326.csv
from proj.
Attachment added by warmerdam on 3 Sep 2013 01:56 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/22287.html
from proj.
Attachment added by gfleming on 3 Sep 2013 11:08 UTC
https://trac.osgeo.org/proj/attachment/ticket/18/test_TMSO_axis orientation.csv
from proj.
Related Issues (20)
- Proj4 export from a bound CRS object fails
- Interrupted Mollweide gives wrong result on inverse projections of some lat/lons. HOT 5
- .github/workflows/docker.yml to push only proj-docs for master pushes
- Project build failed on windows10 vs2017 HOT 1
- "proj_grid_info" C API function fails with grid "test_gridshift_projected.tif" HOT 4
- HEPOS GGRS87 shift grid HOT 2
- "No inverse method available" HOT 7
- Different (~100m) results from transforming WGS84 -> Belgian lambert 72 depending on definition used HOT 6
- General grid shift issue HOT 4
- Wrong transformation from vertical with geoid model to "vertical offset" HOT 1
- Doc Helmert: rotation matrix HOT 2
- Google marks proj.org as potentially hacked, recommends against visiting it HOT 11
- Help with compiling PROJ 5.1.0 with JNI on windows HOT 2
- I'm cross-compiling, tried 9.3.1, 9.3.0, 9.0.0, and sqlite cross-compilation and local compilation all failed, don't know why the build failed HOT 3
- Error with sqlite link in cross-compilation HOT 3
- Error initializing invproj 9.1.1 with epsg PROJ_USE_PROJ4_INIT_RULES=YES HOT 1
- multi-grid GTG with overlapping grids and nodata HOT 6
- Make output or error message
- ReadTheDocs Deprecation: Removal of Sphinx context injection at build time
- Proj paramater string with "significant" or "junk" parameters returns incorrect transformation results for EPSG:4326 to some projected coordinate systems HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proj.