Opened 8 weeks ago
Last modified 4 weeks ago
#138 new enhancement
File location of stations in 3d file
Reported by: | Andrew | Owned by: | Olly Betts |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Other | Version: | |
Keywords: | 3d | Cc: |
Description
When importing the 3d file into (Q)GIS it would be very useful to have the location of the file that stations , and possibly other features, are created.
After some experimenting with QGIS, I believe the most useful format would be relative to the svx file that is processed to produce the 3d. When importing the 3d file to GIS the root of the svx file can be added to the layer.
The reason to have the file location in the 3d file is that the station could then be selected and an action choice of opening the original data file could be included, making GIS a very useful front end for projects.
Some thought should probably be given to compatibility with Therion drawing files (th2) These do not necessarily have to have a one to one relation with the survey trip. Although most UK cavers do have this direct relationship it is not what the main Therion page recommends so likely to be different else where. I would suggest a place holder could be added to the 3d file to allow Therion to support file location of a survey station within a th2 file as well as the th file.
Change History (3)
comment:1 Changed 5 weeks ago by
Summary: | File locatoin of stations in 3d file → File location of stations in 3d file |
---|
comment:2 Changed 5 weeks ago by
I see no reason to have column numbers, line numbers are a nice touch but as you say need to be carefully considered against the bloat the could cause. The file name is perfectly adequate.
I'm trying to use GIS as a front end for data and project editing and powerful viewer, so far the trials are looking good. Only showing one location for a station is not ideal, but probably a reasonable thing to do. I'm struggling to think how a station can be in more than one place if it is not equated or fixed. Am I missing something. Can a station have multiple fixes? There obviously are lots of cases of multiple equates, but it would be relatively easy for an experienced surveyor to work out which files the station is in from the adjacent stations. When is a 3d format change likely to happen?
comment:3 Changed 4 weeks ago by
I see no reason to have column numbers
Yes - column numbers are useful in the error reporting machinery, but mostly because they allow highlighting part of the relevant line in the data to help explain the issue better. For going from a view of the processed data to the raw survey data it seems good enough to just know the line number.
I'm struggling to think how a station can be in more than one place if it is not equated or fixed. Am I missing something.
Simplest example:
1 2 3.45 067 +08 2 3 9.87 065 -04
Here station 2 is used in both lines (and obviously this is very common because it happens for any station which isn't a dead-end). The needn't be adjacent lines, but if you only care about the filename then it's most likely all the mentions would be in the same file.
Can a station have multiple fixes? There obviously are lots of cases of multiple equates, but it would be relatively easy for an experienced surveyor to work out which files the station is in from the adjacent stations.
A station can be fixed multiple times (the useful case is fixes with errors specified, e.g. you might have multiple GPS fixes for an entrance; you can re-fix exactly provided the coordinates exactly match but that seems like unhelpful duplication of data).
The common exception to all the mentions being in the same file would indeed be an exported point which is then equated in a different file to join surveys (probably one which includes the files they are exported by).
When is a 3d format change likely to happen?
I'd hope next year (2025).
Internally cavern does track a file+line location for each station for reporting diagnostic messages. If it's a station used in
*fix
then this will be the location of such a*fix
, otherwise if it's a station used in*equate
then it's the location of such a*equate
. Otherwise it's the first place it was used.Probably that location is a reasonable one to link to, but exporting it in the 3d file would need to wait for a 3d format revision.
Are you just suggesting storing the filename, or filename and line number?
Just filename could be easily done without a lot of bloat I think (because many stations are usually defined in each file), but if we're storing linenumbers and perhaps column numbers for everything we need to take care how it's encoded.