[Plugin] Coords Text Tag from Datum
-
Hi TIG:
1- Running SU8, PC, XP. My VCB doesn't display anything
2- I already have models to which I have used #heightool.rb (and labels).
Could one of the following be done?
Change heighttool.rb so it uses the same model tag variable (converts the old tag to the new).
or
Combines both into one ruby with the option to display the Z value only in the labels? (converts any existing heightool tag to a coordinate tag).Regards, John
-
Here's v1.2 http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
It totally revised and updated with many more options and settings.
Please read the note in the linked post... -
Here's v1.3 http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
An additional option to Export all of the Coords-Tags to a CSV file is added.
See the notes in the linked post... -
Excellent, TIG. This works quite nicely. I'll bet Bob will be pleased.
-
Thanks TIG again; this CPoint enhancement is very essential for me!
(Now if I could also add CPoints/Coord-tags by inputting into a box the XYZ values...)
-
@gaieus said:
Thanks TIG again; this CPoint enhancement is very essential for me!
(Now if I could also add CPoints/Coord-tags by inputting into a box the XYZ values...)OK, OK...
What format would the input be would you want it to reflect your current Coords-Tag Settings ? -
Dear TIG,
I have just noticed this post. Many thanks for all you efforts, and the continuing development of this plugin.
I will look at it more detail when I get home.
Kind regards,
Bob -
@tig said:
What format would the input be would you want it to reflect your current Coords-Tag Settings ?
Well, when I have already set the co-ordinates (say for example) X=1000, Y=1000, Z=1000, I then wish to place guide points (maybe with an option to receive a tag - or a tag with the option to add a CPoint)) to say (again, with the above example) at 2000/2000/2000 which in this case would of course be only at 1000/1000/1000 relative to the model origin.
To make the example clear; when we have the chance to dig "cleanly", we generally work in a 10m x 10m (or 5mx5m or whatever) grid system (where we keep section walls between these rectangular pits). This grid system is set up according to our national orthographic grid system so whenever I find a Roman coin (again, for instance), we take the exact location with those surveying tools.
Now when I set up an excavation with a grid plugin (there are lots of fine ones) and I want to quickly display the (already) known location of this coin, I could then have an input box to enter the xyz co-ordinates (maybe a yes/no for an additional CPoint) rather than trying to guess where it is.
In other words; what the plugin already does just vice-versa.
And of course, I am already very grateful and would not "urge" you in any way...
-
Here's v1.4 http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
It fixes a glitch with incorrect reading of the Datum.
It also adds two new tools:
Import Coords-Tag from CSV [optional units and optional cpoint]
Add Coords-Tag by Dialog [input XYZ and optional cpoint, using current units' settings]
Please read the notes on the download page as linked... -
Hi TIG and many thanks again but what I would need is not exactly this.
First of all, the add coord tag by input seems to add the tags in inches (2.54x farther than needed).
The other thing is that these points are now added relative to the current origin (that would also be cool in fact but then I could simply use 0/0/0 as my origin). What I would need is to add the coords according to the modified origin co-ordinates. So if I am 800 kilometres away from our national origin (that is somewhere in Slovenia, Austria or Italy AFAIK
), and add a coord at 800.000.125 - or 800,000,125 on my Hungarian keyboard system (i.e. only 125 centimetres from my model origin), it would be just 125 cms from my origin.
-
Wait a minute, something else is also wrong here. My model origin is not at 100/100/100 but all negative; -100/-100/-100!
I tried again and indeed it sets it to negative!
-
Some correction/modification...
It only works in inches if I set the coords in model-units. Although I have centimetres in my template, it doesn't seem to recognise it.
Then if I set the units to centimetres, it will correctly add the coords - except it swaps my origin from + to - (see screenshot) and does not add the coord tag where I wish (so what is written above is still valid).
-
I'm sure this is 'fixable'...
Let's say you set your Coords-Tag Datum of X=100m, Y=100m, Z=0m.
This then interprets the SKP origin SKP[0,0,0] as CT[100m,100m,0m] which is the text shown in the Coords-Tag that is placed at the SKP[0,0,0] ?
If you add a Coords-Tag manually at SKP[1m,1m,1m] its displays CT[101m,101m,1m] in the Tag.
If you want to Add a Coords-Tag via the dialog at say CT[102m,101m,1m] you enter those values three, and it then places a new Coords-Tag in the model at SKP[2m,1m,1m] - because its SKP[X,Y,Z] = CT[typedX - datumX, typedY - datummY, typedZ - datumZ].
I fear I might have got my +datum/-datum calculations in a twist - I'll revisit the code and issue an update... 
-
Hm. Very interesting. If I set the origin to -100/-100/-100, the plugin puts the origin in correctly at 100/100/100 and works as intended (i.e. a point at 200/200/200 is at 100/100/100 from the model origin). So maybe yes, you twisted something...
Yet the centimetres need to be set otherwise it works in inches.
-
Here's v1.5 http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
The balls up in the datum v. tag's values is now fixed
The Coords-Tag values correctly show the value relative to the set Datum - irrespective of the method used to input them - i.e. manual-pick/add-by-dialog/imported-CSV...
Gaieus - the XY/Z units should be either the SKP's current-units or the XY/Z units you choose [or XY Lat/Long?] - please try and report back...
-
Yes, this is it, thanks!
Two more things: when I do not set the units (just leave it on "model units"), it still calculates in inches. I can live with this of course as that's just two clicks and I do not produce hundreds of models like this. So if you have anything better to do, leave it (although users may get confused if this is not working so for the time being, if it is too much to fix, I'd suggest simply deleting that option and force the user to select something).
The other is just cosmetics; the tags are displayed in the "English" way; 100.00 while our decimal separator is the comma: 100,00 (and the dialog actually displays it that way - I guess automatically). But if it is more than a line in the code to adjust (if possible at all), please, disregard it as I really do not care too much.
And did I say thanks?
-
@gaieus said:
Yes, this is it, thanks!
Two more things: when I do not set the units (just leave it on "model units"), it still calculates in inches. I can live with this of course as that's just two clicks and I do not produce hundreds of models like this. So if you have anything better to do, leave it (although users may get confused if this is not working so for the time being, if it is too much to fix, I'd suggest simply deleting that option and force the user to select something).
The other is just cosmetics; the tags are displayed in the "English" way; 100.00 while our decimal separator is the comma: 100,00 (and the dialog actually displays it that way - I guess automatically). But if it is more than a line in the code to adjust (if possible at all), please, disregard it as I really do not care too much.
And did I say thanks?
I don't understand the display in inches part - it I select Model-Units the values display in the current model units and accuracy e.g. ~915 [mm].
I think I will remove the Model-Units option and default to 'm' for everyone. You can then set the units as you wish and they are remembered with the model.
Ruby automatically does the 1.234 method [when you want 1,234] but I can add a 'Decimal-Separator' option './,' that will sort that.
A CSV file always exports with '.' as the separator as that is the way Ruby does it: I ca'tn change to ',' as it's a CommaSepeartedVariable file...
If you have a set of XYZ values in a file with ',' as decimal-point, I suggest that you edit using a Find/Replace and make ','>>>'.' and then say the XYZ separating character of tab/space >>> ','... -
I think there is some issue with the separators here. See what happens if I chose model-units. In the dialog, I get the comma (as expected from the system). But then when I place the tag, both the decimal and the list (?) separators are commas.
Now when I put a tag at 200 all, in the dialog, I have dot as decimal separator (as opposed to my system) and it's actually at 200x2.54=508 (i.e. it must be using inches). The tag is at 408 cm from the origin (along the axes) so that 100 all origin is counted correctly.
Now if I set cm as unit, I still get the add dialog with dots but now the tags have dots, too, and the tag is placed correctly to its place.
You may not experience any issues because your system is English but something may be messed up for us, puny non-English with these separators.So maybe there is something more with those separators than just cosmetics?
Sorry to be a pain in the neck - as I said, it would not be much of a work for me to always set the unit - just showing that something may be working wrongly.
-
Here's v1.6 http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
You can now choose between '.' and ',' as your decimal-separator [i.e. 1.234 OR 1,234].
Note: if DecSep==',' then the XYZ_separator=';' rather than ','- so it's 'XYZ: 1.234, 5.678, 9.012' OR 'XYZ: 1,234; 5,678; 9,012'...
The default XY/Z units is now 'm', and you must choose these units - the 'model-units' are no longer accepted as a default...
- so it's 'XYZ: 1.234, 5.678, 9.012' OR 'XYZ: 1,234; 5,678; 9,012'...
-
Thank you very much, TIG! Works perfectly now. And even has LatLong options (I did not notice before)!
Did you get somehow to learn what caused that inch issue?
Advertisement