richsmith / sexytopo Goto Github PK

It can be useful to keep the data but not use it, so commenting out a leg or splay would be useful.

I use it to store my calibration checks, a real enhancement would be to be able to identify them as calibration checks, currently I write this as a comment in Pockettopo, hence the request to add comments to splays

Currently things like station labels are hard to read at different (very new) phone resolutions because they are set in pixels. These should scale more intelligently.

Dev Notes

Look into setting the size of things using something other than pixels, or doing the scaling in code.

It would be nice if Sexytopo gave some audio feedback on successful readings. By default this could be a soft tone for each splay and a more significant audio report on each new station. This should all be configurable in Settings (e.g. updates Never, Every Reading, or New Stations Only, and sounds Beep or Voice Feedback.)

I've started a feature branch for adding SVG sketch export. Ideally this will allow direct vector export at map-scale, layer compatible with Adobe Illustrator and Inkscape, with appropriate metadata so that Walls and Compass can roundtrip morph them along with loop closure.

If you're willing to consider accepting this feature, I'd like to use this ticket for discussing further design and implementation.

Initial working but "not ready for primetime" branch is at: https://github.com/riggsd/sexytopo/tree/svg-export

Low priority enhancement
A dark theme should be an option, to replace the current light theme. And like Google maps, there should be the option for it to automatically switch, in response to changing light levels (although head lamps could make this problematic).

Where a cross-section has been added it would be good to have an "arrow" (maybe a line with arrow or u-shaped line) drawn across a station at the angle of the cross-section with a direction.

The export pdf are useful, however, -layout local refers to a configuration layout called local, that does not exist in the file, so it will not run. Remove this part is the easiest solution, or add in a layout local a suggestion would be

layout local
debug off
map-header 0 0 off
#symbol-hide group cave-centreline
endlayout

The export map should also probably be commented out, as they do not work until something is drawn. Usually the first thing a surveyor wants to check is the skeleton view, best created using

export model -fmt survex -o NAMEth.3d

I personally like adding th to the name of my files produced by Therion so I know which program has created them, so if a bug occurs I can work out where.

This is easy to do and a quick win to overcome a tedious manual task, especially for cross section that are not labelled, would need a screen to ask about naming conventions, using the topParser method would be a good start

Sexytopo doesn't really have a format per se for sketches - it just holds the data in memory as native Android objects and saves it as .json.

With regard to SexyTopo's native save/load format:

Currently survey data is persisted and read in an extremely basic Survex-compatible format. It uses the Survex .svx extension, and consists of absolutely nothing except the raw survey data in Survex default "data normal" format.

1   2   3.77    299.23  18.23
2   -   5.00    0.00    0.00
2   3   10.00   90.00   0.00
3   4   15.00   180.00  45.00

I've got a local branch which implements magnetic declination calculation and correction. This requires persisting and loading the declination value associated with a given survey.

Additionally, there will be more metadata associated with a given survey as the software grows. Examples include the name of the cave, the survey date, perhaps the survey team, etc.

I have implemented a slightly more thorough Survex export/import based upon the following format:

*title TestSurvey
*date 2016.01.21
*declination 14.48 degrees

1   2   3.77    299.23  18.23
2   -   5.00    0.00    0.00
2   3   10.00   90.00   0.00
3   4   15.00   180.00  45.00

The parser makes it easy to add support for new Survex commands as features warrant them.

The real question, however, is whether a subset of the Survex format is desired as the native SexyTopo format, or whether a SexyTopo-specific format is preferred. My opinion is that the world doesn't need Yet Another Cave Survey Format, and I do like the Survex format (as well as the similar but changed-for-absolutely-no-reason Therion centerline version) but the decision isn't mine to make.

On every connection or data pull from device.
Password dialog for bluetooth pin is shown.

Tesed on:
DistoX2 (V2.4)

OnePlus X

• Bluetooth: v4.0, A2DP
• OS Android: v5.1.1 (Lollipop)

Samsung S7710 Galaxy Xcover2

• Bluetooth: v4.0, A2DP
• OS Android: v4.1.2 (Jelly Bean)

It's not too late to add the "script" onto the technology, and it would avoid the competition with applications like topodroid. Also it would be a lot easier for get other contributors because you don't have the heavyweight load of the android dev. environment and compiler.

An example of Webgl for caves (which works best on the phone) is here:
http://goatchurchprime.github.io/groundwindow/groundwindow.html#caves/expoloser.js

The recommendation is to make it work through the lower-level canvas than using the svg engine because it has much better performance even for very large numbers of elements.
http://smus.com/canvas-vs-svg-performance/

Admittedly this is a recent development that makes it possible
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

Pockettopo uses a light grey line, this is very useful

Recent code drop included a app/build.gradle with a lower versioncode than what was used before. This essentially prevents upgrades:

versionCode 1
versionName "1.0"

The last VC I am aware was 9. version 1.0.9.

The DistoX view with pairing and connection information is an inspired, informative and effective approach.
However once the Table, Plan or Elevation views are activated by the user, there seems to be no way of going back to the DistoX view mid-session. Taking a punt that connection issues will occur from time to time, it would seem reasonable that the user be able to view the bluetooth and connection status and log. That would save all sorts of pain and uncertainty that i have experienced with both PocketTopo and TopoDROID.

When 3 readings are taken and become a leg, if you try to edit them, it appears as a single reading, also on the export only 1 reading is exported.
This should not happen, as it is also possible to take 1 reading and make it into a leg, it is important to be able to distinguish the difference, is it is likely that the multiple reading leg is less likely a blunder than the single reading, survex is in the process of taking account of this, I believe.
It is also important as at times, say for avens, the user might have overriden a set of legs that did not become a leg automatically, these are more varied and by just having the export, this cannot be ascertained.
The DistoX also records its rotation when taking a reading, this would be useful to be stored, as a leg with 3 readings with the same orientation is not as likely to be correct as a leg with at least 2 orientations. (I wonder if this should be a different issue)

Add who was surveying, doing what and what instruments used, auto date. What cave it is in, maybe country, and area Units of instruments, Calibration information about instruments, especially tapes, if a tape is 40cm shorter this is going to effect the drawing. Tapes can be longer and holding the end on is easier than the correct zero (Survex uses the number you read for a 0 length as its datum, so 20 would have the end missing -20 would be longer than it should be) This should also contain a declination box, that is only used to align the drawing screen. Personally I'm not familiar with this as mostly I survey in places where the compass north is very close to grid north, however I have heard that for surveying in places where it is more than 20 degrees out this is useful. (Bruce on the Therion mailing list would be a good person to ask)

You can put in a second survey (faded) in the background of the current survey.

How about allowing this to be a bitmap image as well?

Then this would allow ST to work off a historical survey and continue onwards, or from a aerial photo surrounding a cave entrance (when starting off), or be used to trace up old surveys (and replace tunnel and therion).

The bitmap should preferably be in geotiff format so that it comes with the correct scale and coordinate system. This way it would have the convenience of qgis and there would be no need to develop user interface features for georeferencing.

Enhancement...

Currently you have the cross section as perpendicular to the last leg. If it is a station with a single leg, that is the only real automatic option. However. when there are 2 legs, the most common definition and the one that gets it right most often is the perpendicular bisector of the legs. This is what pockettopo, Therion and I believe Survex all use, so it would make sense to use the same as the programme they are likely to be exported to.

I really like the lines showing where the cross sections are, a real nifty feature would be to allow the user to set the direction. Guess some thought would have to be put into how the direction is exported, but I and others have used the direction you are facing in bracket after the station number, when doing this on paper surveying, so maybe this could be adapted

Pitch lines with whiskers, fat lines for walls, dotted for estimated walls, invisible lines to surround areas of sand in the middle of a chamber. (There are only 8 line types in tunnel)

This can be done with a fixed set of colour conventions for the line types.

Needs to be added.

Either the app from Google Play or Fdroid when opening it, it doesn't work and show an error saying "Unfortunately, Sexytopo has stopped".

My phone is a Nexus 5 from Google and runs Android 6.0.1.

Best regards,
Alejandro

Probably quite involved :/

The cross section do not appear on the drawing canvas if they are too far off the edge, this can be solved by expanding the area by using numbers in the Drawing Area menu in Xtherion

It would be useful if there was a line joining it to the correct station, also there are no stations in or splays in the import (maybe this should be split into more than one issue)

There's a few places in the code where I was lazy and put the strings directly into the source code. These need to be hunted down and put in the XML file. At some point we'll want to add translations and this is a prerequisite.

This might be superseded by being able to rotate the diagram, but yesterday I found it better to draw the extended elevation in landscape and the plan in portrait, there is plenty of room on the icon bar to add this, so no need to go through the menu.

It would be very useful if a top import (and maybe an export) was available, lots of people converting from PocketTopo do not have a txt version as they where not needed.

Here is the format

PocketTopoFileFormat.txt

Program doesn't properly request permissions (in modern versions of Android) so always ends up falling back to internal storage.

Nice-to-have. Think this would be satisfying to use, plus easy to do.

Dev Notes

This probably involves updating SexyTopoActivity to implement some sort of gesture dection.

It would be useful to add a comment to a splay, ie to say this splay points to a bone, I'm not sure this can be done from the drawing menu, its just to difficult to select the splay.

Hello Rich, and many thanks for your efforts !
I have an issue re-reading data from a saved file in sexytopo, and it seems to be related to the (french) local (if such a notion exists in Android) of my phone, as it says (in a toast) "Error:invalid double:2,50". Please note the comma, as used in France for floating point (even called "nombre à virgule", virgule being comma in French) instead of the anglo-saxon dot.
So it seems that the routine that save the data uses the locale and the one that reads them back just ignores the local.

The pinch to zoom works even in drawing mode, so why can't you use the two finger detection here to drag as well as zoom at the same time. Google maps has it, so it can't be that awful an interface

This is a good idea from PocketTopo. It uses purple.

It looks like you just pushed the "app" folder into the repo and not the root porject. You most likely have ../build.gradle and ../settings.gradle whcih should be published as well.

Cross-sections in extended elevations are currently handled wrong (they're the same plane as the elevation, when they should be at right-angles). This should be corrected.

Dev Notes

Cross-section creation should be delegated to PlanView and ElevationView (Template Method strategy) so the X-section creation code can be split.
Context Menu creation should be delegated to child view as well and EE menu should be modified so vertical and horizontal sections are available.
Sketch data X-section format needs to be modified to include X-section type. May have saving implications.

This could be a longer term thing to add but would be nice to be able to rotate the view using e.g. two fingers rotation a la Google Maps.

Adding this would also let us look into rotating the view automatically.

Dev Notes

Would have to add gesture detection (we already handle pinch-to-zoom so something similar, hopefully). Would also have to modify the survey to view translation code and several random things like graph paper drawing. Could be a big job.

Personally I think that this would be better named as Convert to Leg.

When this is done it reverts to the toporobot numbering system 1.1 not the next counting number which would seem more sensible

Instead highlight errors and allow the user to correct them

Needs to be some way of flagging a survey changed but not saved

It would be useful to be able to add notes to splays and legs. My main use of this is to label the first splay with what the station is so people can find it on a return trip. Bit can also say what the splay points to, or occasionally use it on a leg, it is a good place to comment about a QM.

A real advancement would be to allow a photo tag to be added, then you could photo the station or the QM

I wrote some comments on some stations, however, in the Therion export and now the original files the comments have been replaced by the 3 readings that where taken, it would appear to have overwritten the original comments.

I have had three crashes that left me with no data. It's a great app but not stable enough!

Notes made of letters can be added to any place on the survey.

Why not have special codewords that are plotted as symbols?

One way would allow for typing up unicode, where we know what the unicode symbol for a stal-curtain is.

Or they could be codewords with a dot in front of them, eg: ".stream" which gets rendered as a stream arrow.

These should have the ability to set the rotation, eg encode in ".stream90" for one that is at 90 degrees.

But if you had a rotation attribute on the general note itself you could stick labels at different angles.

This would be the prequel to inputting cave symbols through a more madphilfriendly interface.

Hmm how do I set something as an enhancement?

Currently you can reverse a leg from the plot screens, although this is a good place, it is often easier to do it in the data screen, would it be possible to add this as an option, please?

Also instead of having to pick select mode, could a context menu not be brought up with a long click on move mode? This would make it far easier for the user.

It would be nice to have a log accessible somewhere from within SexyTopo where you could read log updates such as errors or basic program operations.

Dev Notes

Some work has already been done on this, with a custom logging class. It needs to be checked that logging is actually going through this class, then some way of viewing this in the GUI needs to be coded up.

GUI options are a separate Activity or a dialog box. Doesn't need to be fancy, just a list of time-stamped log entries.

Need to check only the last e.g. 500 messages are stored.

Currently all splays get "ironed out" in the same direction as the centreline in an extended elevation. They probably shouldn't do. Figure out what they should do and modify the projection code.

When editing a station labelled as a - if you select the bottom one to try to make it into a number, to make it into a leg, the first in the list of - is edited, not the one highlighted or active station.
One significance of this is that you cannot override a splay to become a leg. This can be important to show Avens etc.
Sexytopo 1.0.11

All data collected and created with ST should be exported.
However text point entries in drawings is not exported to Therion format. Not sure how this would be done, as I assume there is no direct equivalent in xvi format (I don't know). The text entity could be parsed direct to a scrap (with point label) in the Therion th2 file, but this would be a bit messy. Firstly all the labels would be in one arbitrary scrap, which may have no relation to the way the survey/drawing author wants to set things out, and it may confuse inexperienced Therion users.
But mainly I don't like the 'raw survey notes in scrap' idea because it blurs the line between survey notes and subsequent drawing or data edits (which is one reason why I believe TopoDROID is flawed). The ideal would be to export the ST drawing text entities into xvi format and have it parse to Therion (and other export formats).

As stated previously a survey program should record what a survey actual does.

So if a person reads a backwards leg it should be recorded as a backwards leg eg

5 4 10.34 115 +11

However Sexytopo is just changing the measurements and recording

4 5 10.34 295 -11

This causes 2 problems
If you do not know where the station was read from, you might not be able to go back and check for thinks like magnetic interference or know that it was taken away from the interference, something like a anchor in the wall.
It breaks clino calibration, lets take an extreme example, but one I have seen.

On the above data, if the Clino was reading 4 degrees (something I have seen) under the true reading when the survey program corrects the reading it will then use

5 4 10.34 115 +15 (+11+4)

4 5 10.34 295 -7 ((-11+4)

So the way SexyTopo records the data doubles the error for reversed legs when clino correction is applied.

There are probably lots of other reasons not to change the readings, but the above are the main 2.

Oh and I have just noticed, it does not actually change the sign of the clino reading, so the reversal of a leg is actually wrong, so the elevation plot becomes wrong

Hi @richsmith , I'm a graphic designer, after I review your project, I'm interested in your project and I want to contribute by creating a logo/icon for your project. What do you think?