Just to expand a few cents ... The lines / points / areas concepts and parameters available through a GUI at F2 with drop-down choices for drawing the scraps - that's great, we understood and used that. That is not the issue. However, the windows presented at F1 and F3 require the new user 1: to learn / understand writing a language - the commands and parameters - from scratch. 2: to learn / understand in which screen each command / parameters and definitions and extra code should go. The new user is expecting to get hands-on with drawing up within a few minutes, not having to copy/paste and write code before getting any sensible output. The GUI for the F3 screen could, for example, present the user with drop-down boxes for setting up all the required outputs and customising layout etc etc. The new user is a caver who wants to produce a survey, then more complicated surveys/maps then a geographical area with surveys/maps - obviously this takes time to learn but the learning process is hampered by having to (unnecessarily) learn the language syntax and the parameters. He/she knows what output scale to use, what symbol set to use, what size printout/pdf is expected etc but having to find the code to porgramme the application is frustrating. None of the above comments stops more advanced users (big project coordinators) from "getting under the bonnet". [My background: 40 years of surveying and drawing surveys through sin / cos tables to Survex / DistoX / Therion etc. Organising and coordinating the Matienzo Caves expeditions to Cantabria. Here, new passage is being found in known or new sites all the time. Much surveying is required which needs organising from single cave surveys through to showing centre lines/surveys over the whole permit area (and beyond!) on contoured maps, Google Earth etc. (Many years ago, I wrote a cave survey programme for the Archimedes which processed survey data and showed the centre line growing on-screen - but we then had to switch to PCs. There are currently more than 3600 entrances (including many digs) and more than 325km of passage. Most surveys are now drawn up in Corel Draw, some in Inkscape, and Footleg is producing a 54km cave network survey in Tunnel.] Anything to encourage cavers to produce a final output, ie a friendly front end to Therion, would be superb. Juan Corrin
On 13.3.2012, at 11:47, Juan Corrin wrote:
Anything to encourage cavers to produce a final output, ie a friendly front end to Therion, would be superb. One tip only. Open TherionBook on chapter Layout and use it as "popup" window. It is my way too. Or print it on piece of paper. It is nice idea to have it in F3 window directly. But by my (and not only my) experience each user will develop several "layout_index" files which he/she may include to F3 window. Probably to share this files with explanation comments could be usefull too.
2+2+2+2 cents (NZ) together Martin s.
+++ Juan Corrin [2012-03-13 06:47 -0400]:
Anything to encourage cavers to produce a final output, ie a friendly front end to Therion, would be superb.
I don't think anyone would argue that xtherion is the best possible embodiment of a therion GUI. It was originally a proof-of-concept to see if a GUI to generate the highly co-ordinate intensive parts of the data could work. And it's clearly a huge improvement on having to work out the co-ords by hand and type them in :-) Unfortunately it has been rather too successful and has developed for many years now rather than being replaced by something less crufty, and also dealing with the rest of the problem (layout files, centreline data, etc). We keep hoping someone with the relevant expertise will get enthused and write some suitable software... The catch here is that it's much easier to add a bit more to the existing xtherion, further entrenching its model and tcl/tk, than to do it right (or at least hopefully better) by using a more flexible toolkit and rewriting the whole thing in the light of what we learnt first time round. Your points are well made Juan, and I don't think anyone really disagrees. Making more of the survex functionality available from the GUI would be nice too, for essentially the same reasons: at least for basic cases it's just easier to use and to get started. It's not easier for the software authors though and that's actually the rate-limiting resource here. Surveyors may not like having crufty interfaces and loads of stuff they don't care about exposed, but they can deal with that by simple application of time and effort. Being able to write GUIs is a different skillset and people with skills, motivation and time are thin on the ground. So maybe Andrew and I should start teaching Qt courses instead of Therion courses to solve this problem in the longer term :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
So maybe Andrew and I should start teaching Qt courses instead of Therion courses to solve this problem in the longer term.
Possibly - otherwise our caver-surveyors are going to drown in a sea of -name, symbol-hide and metapost jargon - and won't produce the surveys anyway :-(
On 13.3.2012, at 16:31, Wookey wrote:
So maybe Andrew and I should start teaching Qt courses instead of Therion courses to solve this problem in the longer term :-)
We had an idea, several years before. Our friend, young caver, studied the informatics. So the idea was he could do the new GUI for therion as his thesis. But no chance. Is creating the new GUI for therion enough for thesis? Try to find someone. ;o) Martin s.
Juan and others So I think we generally agree that an improved interface would be nice to have. And our experience to date is that it is unlikely to happen anytime soon.
However, the windows presented at F1 (text editor) and F3 (compiler) require the new user 1: to learn / understand writing a language - the commands and parameters - from scratch. 2: to learn / understand in which screen each command / parameters and definitions and extra code should go.
The new user is expecting to get hands-on with drawing up within a few minutes, not having to copy/paste and write code before getting any sensible output. The GUI for the F3 screen could, for example, present the user with drop-down boxes for setting up all the required outputs and customising layout etc etc.
I have never expected or achieved this (as a new user) with any cave centerline application let alone a drawing application, so Therion is not alone in this, but I would agree it requires more determination than most. Obtaining outputs with your own data in a few minutes is however a reasonable expectation to aspire to. We could do better with sample datasets, the existing ones demonstrate a variety of features but they are not documented usefully, so most people will miss the significance or reasons for what is being demonstrated. It would be rash of me to offer to document them, but perhaps one distant day.
There are currently more than 3600 entrances (including many digs) and more than 325km of passage. Most surveys are now drawn up in Corel Draw, some in Inkscape, and Footleg is >producing a 54km cave network survey in Tunnel.]
Anything to encourage cavers to produce a final output, ie a friendly front end to Therion, would be superb.
I see your problem now I think, as I have perhaps a similar (but much smaller) headache with a ~30km (so far) project with a few dozen caves and entrances covering 60km2. My issue with Therion is more of a documentation and organizational guidance problem. In the absence of a super-interface it seems that good guidance and templates for organizing data would be the next best thing, and could even inform the design brief for a future interface. I see the current Therion as experimental and perhaps half way towards having a well developed and complete feature set, so again, a super-interface is competing for developers time against developing and fixing some core functionality that is especially needed for larger projects. While there is a lot of good information in the wiki, much of it is not "what you need to know, when and where you need it." I have started putting some of my ideas in the wiki, but they are a long way off being useful or complete as far as organization goes. And I still do not have good feel for how to manage multiple output options for multiple caves in a modest system, let alone anything over say 20km. I know a lot of you people are dealing with much larger systems and so probably have a better grasp on it than I, even if you are not exclusively using Therion. Still, perhaps I will get around to making an effort adding some more thoughts and samples on organization to the wiki, in the hope that someone will point out where I am making it too complicated for myself. Bruce
As others have said, I think there is a lot of room for improvement in tooling that is more end-user friendly yet can still leverage the power of Therion in the background to compile maps, stats, etc. I've built some software for a specialized survey project I've been working on to ease managing the data, redefining symbols, etc. I have a web interface to import and manage survey data, it is all stored in a SQL database. I then create th and th2 files programmatically when I wish to compile a PDF map. There are some advantages to this approach as I can do things like easily generate my own KML files using some symbology I've developed, easily query the database to do shortest path searches between two survey stations, or make changes to my Therion input file structure that I'd otherwise have to manually edit hundreds of .th and .th2 files to achieve. Unfortunately my program has been specialized for a very specific survey project, and does not have the right features to serve as a general purpose data management tool and is not available for general release. But the lesson I've learned is that there is a lot of power behind being able to access and modify the data in more advanced ways then simply editing text files, also that to implement an easy, powerful and flexible GUI to do this is not a quick project :P Carl On Mar 14, 2012, at 4:23 AM, Bruce wrote:
Juan and others So I think we generally agree that an improved interface would be nice to have. And our experience to date is that it is unlikely to happen anytime soon.
However, the windows presented at F1 (text editor) and F3 (compiler) require the new user 1: to learn / understand writing a language - the commands and parameters - from scratch. 2: to learn / understand in which screen each command / parameters and definitions and extra code should go.
The new user is expecting to get hands-on with drawing up within a few minutes, not having to copy/paste and write code before getting any sensible output. The GUI for the F3 screen could, for example, present the user with drop-down boxes for setting up all the required outputs and customising layout etc etc.
I have never expected or achieved this (as a new user) with any cave centerline application let alone a drawing application, so Therion is not alone in this, but I would agree it requires more determination than most. Obtaining outputs with your own data in a few minutes is however a reasonable expectation to aspire to. We could do better with sample datasets, the existing ones demonstrate a variety of features but they are not documented usefully, so most people will miss the significance or reasons for what is being demonstrated. It would be rash of me to offer to document them, but perhaps one distant day…
There are currently more than 3600 entrances (including many digs) and more than 325km of passage. Most surveys are now drawn up in Corel Draw, some in Inkscape, and Footleg is >producing a 54km cave network survey in Tunnel.]
Anything to encourage cavers to produce a final output, ie a friendly front end to Therion, would be superb.
I see your problem now I think, as I have perhaps a similar (but much smaller) headache with a ~30km (so far) project with a few dozen caves and entrances covering 60km2. My issue with Therion is more of a documentation and organizational guidance problem. In the absence of a super-interface it seems that good guidance and templates for organizing data would be the next best thing, and could even inform the design brief for a future interface. I see the current Therion as experimental and perhaps half way towards having a well developed and complete feature set, so again, a super-interface is competing for developers time against developing and fixing some core functionality that is especially needed for larger projects.
While there is a lot of good information in the wiki, much of it is not “what you need to know, when and where you need it.” I have started putting some of my ideas in the wiki, but they are a long way off being useful or complete as far as organization goes. And I still do not have good feel for how to manage multiple output options for multiple caves in a modest system, let alone anything over say 20km. I know a lot of you people are dealing with much larger systems and so probably have a better grasp on it than I, even if you are not exclusively using Therion. Still, perhaps I will get around to making an effort adding some more thoughts and samples on organization to the wiki, in the hope that someone will point out where I am making it too complicated for myself. Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
On 16.3.2012, at 20:57, Carl Magnuson wrote:
being able to access and modify the data in more advanced ways then simply editing text files
Hi Carl, it is your way how to use therion. But there are many others they need something else. Not "such complicated" as SQL and so on. There were many projects in history to put all data about caves, cave systems, karst areas to a database. But as I know, no one is widely used. And no one is really universal. Everywhere and everytime one find exception from primary analyse and what to do? Change structure of all databases filled with data with new version? I think if data will be in plain text format as simple as possible such data are very easy to interprete and to generate. And to edit too. Not for hundreds of files of course. Is your project presented somewhere on net? m.s.
what about a hyperlink point ? point x y link -url "..." to point to external resources from the pdf maps. marco
what about a hyperlink point ?
point x y link -url "..."
to point to external resources from the pdf maps.
Thanks Marco Users of our maps have been asking for this over here. Needs to be able to point to absolute and relative paths as well as urls. Perhaps -link or -url is just another property of point label, line label and point remark? After all, a point link is going to need similar properties to labels (-align -text -scale, so -link or -url is just one more). It would be nice if the link had an indicator that is visible on screen, but not visible in the printed pdf. Or maybe it is another property? -underline [on off] #default on for links and default off otherwise?? Bruce
Perhaps -link or -url could be a property of almost any point entity? There would need to be some way of visually distinguishing them other than the change in cursor while hovering, a light background shading perhaps? Also map-image x y nw "filename" -link "linkaddress" would be useful. Bruce
i was considering linking to reports, publications, photoes, videos from the maps. this would link these other resources to the map, allowing the user to jump from the map to a report or a video and so on. i would rather have iconic refs in the pdf (the "usual" file, picture, video icons). links could be turned off (to preapare maps for publications, with a symbol-hide command. not sure whether link should be a property of label/remark i use these for the lettering (eg. pit depths). maybe there are uses i do not foresee. yes urls should be absolute or relative. i do not now how pdf handles urls. probably the smart people at adobe already thought about this issue. marco ----- Original Message ----- From: Bruce <bruce@tomo.co.nz> To: 'List for Therion users' <therion@speleo.sk> Cc: Sent: Tuesday, March 20, 2012 3:18 AM Subject: Re: [Therion] hyperlink point
what about a hyperlink point ?
point x y link -url "..."
to point to external resources from the pdf maps.
Thanks Marco Users of our maps have been asking for this over here. Needs to be able to point to absolute and relative paths as well as urls. Perhaps -link or -url is just another property of point label, line label and point remark? After all, a point link is going to need similar properties to labels (-align -text -scale, so -link or -url is just one more). It would be nice if the link had an indicator that is visible on screen, but not visible in the printed pdf. Or maybe it is another property? -underline [on off] #default on for links and default off otherwise?? Bruce _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
i was considering linking to reports, publications, photoes, videos from the maps. this would link these other resources to the map, allowing the user to jump from the map to a report or a video and so on. My thought as well.
i would rather have iconic refs in the pdf (the "usual" file, picture, video icons). These would be OK, or even quite nice, when viewed electronically, but redundant or even untidy once the map is printed.
links could be turned off (to prepare maps for publications, with a symbol-hide command. They could, but it means you have to create two maps, one for electronic viewing and one for paper viewing. Seems like needless duplication of authors effort and maintaining separate versions of what are otherwise identical files.
not sure whether link should be a property of label/remark i use these for the lettering (eg. pit depths). maybe there are uses i do not foresee. The label or symbol for a large stalagmite could double as a hyperlink to it's photograph (although admittedly there needs to be a cue to the links existence). I think in many applications a hyperlink is just another property to add to existing entities range of properties, like colour, size, text etc.
What do others think? I guess it come down to what is expedient to code and what functionality the pdf format provides. Bruce
From: bruce@tomo.co.nz To: therion@speleo.sk Date: Tue, 20 Mar 2012 22:14:38 +1300 Subject: Re: [Therion] hyperlink point
i was considering linking to reports, publications, photoes, videos from the maps. this would link these other resources to the map, allowing the user to jump from the map to a report or a video and so on. My thought as well.
I had also had thought about this. In my survey-databases I use url to reports of the trips we made to make the surveys, or reports of the digging and further exploration.
i would rather have iconic refs in the pdf (the "usual" file, picture, video icons). These would be OK, or even quite nice, when viewed electronically, but redundant or even untidy once the map is printed.
Isn't it possible to create automatically both maps: the one with the url-links, the other without. In case there are no links you have twice the same.
links could be turned off (to prepare maps for publications, with a symbol-hide command. They could, but it means you have to create two maps, one for electronic viewing and one for paper viewing. Seems like needless duplication of authors effort and maintaining separate versions of what are otherwise identical files.
Bruce
Guido
links could be turned off (to prepare maps for publications, with a symbol-hide command). They could, but it means you have to create two maps, one for electronic viewing and one for paper viewing. Seems like needless duplication of authors effort and maintaining separate versions of what are otherwise identical files.
Isn't it possible to create automatically both maps: the one with the url-links, the other without.
True, I guess there is no effort to create them, just twice the files to manage later on. Sometimes there will be good reasons to have multiple files, other times less, is more. Not an issue for a one or two cave system, but it all adds up for multi-cave systems where maps an atlas' are produced at multiple scales (parts-of-cave, cave, groups of caves, whole system). It makes sense to me that the pdf outputs should be as flexible as possible if the map author wants them to be. Just putting ideas out there, I'll be happy however hyperlink functionality is implemented. Stacho and Martin have made pretty good choices so far :) Bruce
On 20/03/12 08:17, Marco Corvi wrote:
i would rather have iconic refs in the pdf (the "usual" file, picture, video icons).
Might be worth allowing direction as well, which would require an icon which showed direction. So for a photo, it could show the position of the shot and the way the camera was pointing. Could lead to all sort of virtual trips from the pdf!! Andrew
I agree with you that for dealing with this general purpose data, it is very difficult to create a database model which can capture all the information needed without being overly complex, a plain text format is much easier to get started with and can still be very expressive. The downside is that all the data is "trapped" in a sense - you lose the power to query and manipulate it like you can with a database. For my survey the database I've created and software to interface with it works much easier then having to manage text files, however it is clear that there is a whole slew of complications with handling survey data in the general case. My project isn't available online - It is not a traditional cave survey as it is not of a cave! It is a survey of active and abandoned electric/gas/drainage/sewage/etc. tunnels using in person survey data, historical data, construction data, etc. Therion is used for map production, loop closure, and to generate a SQL export which is then read back into my database for absolute coordinates, measurement errors, etc. We are just past 20 miles surveyed so far, though because it contains locations and access to active utility tunnels I'm not able to release it for safety concerns. Carl On Mar 17, 2012, at 3:46 AM, Martin Sluka wrote:
On 16.3.2012, at 20:57, Carl Magnuson wrote:
being able to access and modify the data in more advanced ways then simply editing text files
Hi Carl,
it is your way how to use therion. But there are many others they need something else. Not "such complicated" as SQL and so on. There were many projects in history to put all data about caves, cave systems, karst areas to a database. But as I know, no one is widely used. And no one is really universal. Everywhere and everytime one find exception from primary analyse and what to do? Change structure of all databases filled with data with new version?
I think if data will be in plain text format as simple as possible such data are very easy to interprete and to generate. And to edit too. Not for hundreds of files of course.
Is your project presented somewhere on net?
m.s.
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
participants (8)
-
Andrew Atkinson -
Bruce -
Carl Magnuson -
GuidoNTS Verhoeven -
Juan Corrin -
Marco Corvi -
Martin Sluka -
Wookey