Topic for discussion: incompatible change of -subtype option for line symbols Working on 2D export and 3D reconstruction we came to incredible obstacles caused by the -subtype syntax: it currently applies to an arbitrary subpath of the line. Proposed new behaviour is to allow only one global -subtype specification for the whole line. Would it cause big troubles to split lines in every point where subtype is changing in your existing data? Martin
Topic for discussion: incompatible change of -subtype option for line symbols
Working on 2D export and 3D reconstruction we came to incredible obstacles caused by the -subtype syntax: it currently applies to an arbitrary subpath of the line. Proposed new behaviour is to allow only one global -subtype specification for the whole line.
Would it cause big troubles to split lines in every point where subtype is changing in your existing data?
Hi, I didn't know about this possibility (-subtype for subpath of line) so I use separate lines for each -subtype. No problem for me. Lada Blazek -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz
+++ Martin Budaj [04-04-21 13:04 +0200]:
Topic for discussion: incompatible change of -subtype option for line symbols
Working on 2D export and 3D reconstruction we came to incredible obstacles caused by the -subtype syntax: it currently applies to an arbitrary subpath of the line. Proposed new behaviour is to allow only one global -subtype specification for the whole line.
Would it cause big troubles to split lines in every point where subtype is changing in your existing data?
I suspect that using xtherion one normally selects whole paths to apply type/subtype to. I don't think I have any lines which partly have one subtype and partly not. But so far I actaully have only 2 scraps so it doesn't matter anyway for me. I suppose I may have 'invisible' as part of a line... I do thing that the list of linetype/subtypes could be improved. I wanted to have a 'presumed' <something> where 'presumed' wasn't a valid subtype for it. This seemed a bit arbitrary - why can I have a presumed wall but not a presumed rock-edge (Something like that - I forget exactly what it was). It seems to me that nearly everything could be 'presumed' or 'invisible', and also perhaps that some subtype should be main types. We could usefully review the list to see if it still makes sense. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
I do thing that the list of linetype/subtypes could be improved. I wanted to have a 'presumed' <something> where 'presumed' wasn't a valid subtype for it. This seemed a bit arbitrary - why can I have a presumed wall but not a presumed rock-edge (Something like that - I forget exactly what it was). It seems to me that nearly everything could be 'presumed' or 'invisible', and also perhaps that some subtype should be main types. We could usefully review the list to see if it still makes sense.
Presumed = presumed. It means that I presume continuation but I don't know what's the type of continuation. Simply I presume that it is "wall". If you know that it is rock-border, why you need presumed rock-border? Lada -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz
+++ Ladislav Bla?ek [04-04-22 17:52 +0200]:
I do thing that the list of linetype/subtypes could be improved. I wanted to have a 'presumed' <something> where 'presumed' wasn't a valid subtype for it. This seemed a bit arbitrary - why can I have a presumed wall but not a presumed rock-edge (Something like that - I forget exactly what it was). It seems to me that nearly everything could be 'presumed' or 'invisible', and also perhaps that some subtype should be main types. We could usefully review the list to see if it still makes sense.
Presumed = presumed. It means that I presume continuation but I don't know what's the type of continuation. Simply I presume that it is "wall". If you know that it is rock-border, why you need presumed rock-border?
Because I am looking over an edge and I can see one side of a big rock, but not the other. The passage shape makes me think that this is a rock not a wall so the part I can see is 'rock border', but the part where it goes out of sight would be drawn as 'presumed rock border' - ie "- - -" with correct line thickness. Or I can see along a passage and one side is wall, the other is a big boulder. I cannot see beyond so both sides need to be drawn as 'presumed continuation', but it looks wrong if the rock side suddenly changes line thickness to be a wall at the point it becomes presumed. (this would be the case if I followed your suggestion above). Also what about the situation where the wall is made of blocks - so now it is 'wall, subtype blocks', but I also want to make it 'presumed' at the point I cannot see. I don't think we can have two subtypes, but there should be a way to draw this...(this illustrates what I mean about reviewing walltypes and subtypes. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
I do thing that the list of linetype/subtypes could be improved.
I agree at this point. -subtype option comes from times, when we had intention to make things universal and complex (and complicated :) . I'm not sure, but my feeling is that option -subtype should be removed at all. The reason is simple. If you do not specify the subtype, some subtype is assumed as default anyway. So it is just complicating things. I think, having types: wall wall-blocks wall-sand wall-debris would be better, than specifying all the time the subtype. What do you think? S.
+++ Stacho Mudrak [04-04-23 09:50 +0200]:
I do thing that the list of linetype/subtypes could be improved.
I agree at this point.
-subtype option comes from times, when we had intention to make things universal and complex (and complicated :) . I'm not sure, but my feeling is that option -subtype should be removed at all. The reason is simple. If you do not specify the subtype, some subtype is assumed as default anyway. So it is just complicating things.
I think, having types:
wall wall-blocks wall-sand wall-debris
would be better, than specifying all the time the subtype. What do you think?
I am inclinded to agree, although I'm not sure I have used it in enough detail to be confident. There are two main thing to consider - what the line represents and 'modifiers' to how that line appears or is used. So above is a list of what the line represents, but things like 'invisbile', 'presumed', and maybe others are modifiers (or 'subtypes' if you like). These things are orthogonal. A good look at the full list thinking in this way, and considered how you want real surveys to look/be drawn would be a good way to rationalise the list. So, yes I think I agree that wall and wall-blocks should both be types, but wall-blocks-presumed possibly shouldn't be. Theother thing to consider is the interface. Exactly how we specify the data is probably a bit arbitrary, but if the new version produces a very long drop-down list that is inconvenient to use then maybe the interface needs to change (so you still select wall, then blocks) or maybe it is not actually worth changing the spec. That is some things to think about really, rather than an actual opinion on what is best. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
I agree with Wookey that "...very long drop-down list is inconvenient to use...". I think that much more better are two list - one for line type, second for subtype. So I am for GUI change but not for syntax change. Lada B. -- ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned! Pripojeni na cisle 971 200 111 z cele CR, v Praze navic na cisle 971 200 555. Uzivatelske jmeno "post.cz", heslo "post.cz". http://www.post.cz
So, yes I think I agree that wall and wall-blocks should both be types, but wall-blocks-presumed possibly shouldn't be.
OK, but I've never seen in any cave symbol list "presumed wall probably formed by blocks" :))), but I've seen many times "presumed wall" or something simmilar - so I think wall-presumed will be enought. And in any case - for each combination of type/subtype - you need a separate symbol. Therefore I think we need only types... Another point - wall-invisible or wall -subtype invisible is completely not realistic. Therefore it should be probably renamed to outline or something like this...
Theother thing to consider is the interface. Exactly how we specify the data is probably a bit arbitrary,
Yes, I've intention to change it in any case - the combobox is not very lucky solution. S.
Yes, I've intention to change it in any case - the combobox is not very lucky solution.
What about tree structure of the menu... - wall - normal - debris - sand - ... - rock - border - edge - ... L.B. -- Surfujete pres VOLNY? Tak proc jeste nejste ve VOLNY klubu? Nyni exkluzivne pro cleny klubu soutez o skvele ceny. http://klub.volny.cz
participants (4)
-
Ladislav Blažek -
Martin Budaj -
Stacho Mudrak -
Wookey