Non-Projected Co-ordinate systems support /export error

[Robert Jones]

Thanks Olly,

I can live with UTM projection. Thanks for explaining. I'm coming from a
position of  'minimising the number of unnecessary re-projections is good
practise', rather than having a specific need, and this appears to be
largely necessary for the reasons you've given.

As for the versioning, yes I saw the item in the CHANGELOG but didn't twig
that the latest OSX build on the website was outdated.

I've managed to produce a functional but incomplete  HEAD build on OSX
after installing a few additional dependencies and commenting out a few
items in the build that are breaking. I'm happy to write a homebrew script
and submit it to one of the GIS/science cask repositories if we can resolve
these. Perhaps you have some thoughts.


1- unifont.hex - Currently manually downloading this from
http://unifoundry.com/pub/unifont-10.0.06/font-builds/unifont-10.0.06.hex.gz
and symlinking in ./lib prior to build

2- Additional doc dependency on docbook2x - Once installed I get an XML
parse error:

/bin/sh /Users/rob/Code/GIS/survex/missing docbook2man ./man_cad3d.sgml
./man_cad3d.sgml:1: parser error : SystemLiteral " or ' expected
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
[                                                        ^
...
           ^
unable to parse ./man_cad3d.sgml

There's an option in docbook2man to specify SGML over XML input but
enabling this seems to trigger an unmet dependency:
/usr/local/Cellar/docbook2x/0.8.8/bin/sgml2xml-isoent: cannot find
sx(sgml2xml)
I'm unclear on what 'sgml2xml' is or where it should be obtained from. It's
not included in docbook2x or documented.

3-Icons
There are a few lines in buildmacosx.sh that pull in various icons:
lib/icons/*.iconset.zip
However the build is not generating any *.iconset.zip.
I can produce a functional build, and Aven appears to have an icon, minus
this step.

4-PROJ dependencies/packaging
The buildmacosx.sh script pulls some projection data out of the locally
downloaded PROJ and copies it into the build. I am able to dynamically link
against the homebrew supplied PROJ package, so is this step necessary? That
said, it may be more appropriate to keep the static linking or at least
offer it as an option - I've had more changes to upstream dependencies
breaking builds in homebrew than I care to remember, and it's not
previously made pinning dependency versions easy.

Regards,

Rob






On 1 November 2017 at 06:26, Olly Betts <olly at survex.com> wrote:

> 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
> benefits.
>
> > 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:
>
> <Placemark><Point><coordinates>148.19353998,-37.
> 44455004,290.00</coordinates></Point><name>test.entrance</
> name><styleUrl>#ent</styleUrl></Placemark>
>
> > 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.
>
> Cheers,
>     Olly
>