Non-Projected Co-ordinate systems support /export error

Olly Betts olly at
Tue Oct 31 19:26:42 GMT 2017

On Tue, Oct 31, 2017 at 01:50:15PM +1100, Robert Jones wrote:
> I'm trying to integrate my existing georeferenced entrance/surface survey
> data workflow with Survex. The surface survey data I have is in GDA94.
> Getting this into Survex is ok, but I'm having trouble getting sane data
> out again, and I can't choose the same unprojected CRS to export in - it
> appears to require a projected CRS such as UTM.
> But I get a 'Coordinate system unsuitable for output' error with:
> *cs out custom "+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs"

Currently the output coordinate system needs to be in metres.

To remove this requirement, we'd need to have such a coordinate system
as an intermediate system to perform the loop closure in anyway, we'd
need to extend the 3D format to support coordinates which aren't in
fractions of a metre, and aven would need to reproject coordinates into
such a system for display.  That seems a lot of work for unclear

> Second, and larger problem is that when I do a KML export in GDA94/UTM55

You can't "do a KML export in GDA94/UTM55" - KML always uses decimal
degrees in WGS84 for its coordinates.

> as above the co-ordinates are garbage:
> <Placemark><Point><coordinates>147.00000000,-90.00000000,51871.97</coordinates></Point><name>test.entrance</name><styleUrl>#ent</styleUrl></Placemark>

With 1.2.32 I get this, which looks plausible:


> I tried various combinations of EPSG codes, custom PROJ strings and the
> built in reference systems but I get the same problem. GPX behaviour is the
> same. JSON doesn't appear georeferenced.

Like KML, GPX always uses WGS84.

JSON is for use with a webgl canvas javascript thing, and uses an
arbitrary coordinate origin at the centre of the survey data.

> - Is there any reason unprojected CRS' aren't supported for export? in this
> case I want to pull the data back into QGIS in the native CRS and let it
> handle the projection. Using the projected data works but it's another
> re-projection step/potential source of error and seems (naively perhaps)
> unnecessary.

Note that neither KML nor GPX are going to help achieve this anyway, as
both require reprojecting to WGS84.

If you're concerned that reprojection is introducing errors, probably
the simplest answer is to sanity check by taking the coordinates of
a few fixed points which you get out of the end of your process and
converting them back to their original coordinate system.

And at least both Survex and QGIS use the same library to reproject
coordinates (PROJ.4), so if the answers don't agree, it's either a
problem in that or how it is being used.

> Survex version is release build of 1.2.27 running on OSX.

You probably want to update - 1.2.32 fixed a bug which negated Z in
several formats, including KML and GPX:

  + In export formats which include 3 dimensions (DXF, PLT, GPX, KML, JSON,
    POS), the value in the Z dimension was negated.  Bug introduced by fixes
    for export of rotated plans and tilted elevations in 1.2.27.  Reported by
    Erin Lynch in #89.

Also, 1.2.30 extended KML export:

  + Export to KML now supports exporting passages, walls and cross-sections.
    Addresses the remainder of ticket #4.

Unfortunately you'll have to build your own to get newer than 1.2.27 on
OS X (the Mac I used to borrow to build releases on got stolen).

It'd be good to have Survex installable on OS X via homebrew (like
therion is), but that really needs someone familiar with homebrew to
help make it happen.


More information about the Survex mailing list