[Plugin] Coords Text Tag from Datum

[Gaieus]

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).

---

[TIG]

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...

[Gaieus]

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.

---

[TIG]

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...

[Gaieus]

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?

[TIG]

@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 >>> ','...

[Gaieus]

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.

[TIG]

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...

[Gaieus]

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?

[TIG]

@gaieus said:

Thank you very much, TIG! Works perfectly now. And even has Lat/Long options (I did not notice before)!

Did you get somehow to learn what caused that inch issue?

NO!
It was simply easier to remove the option

The XY as 'Lat/Long' takes the existing Geo-referenced Lat/Long AND a Z as customized relative to the origin.
Irrespective of the d.p. value entered it will always return the Lat/Long angles to 6 d.p. The N/E and S/W angles are 'suffixed' appropriately. Note that when entering Lat/Long in the 'Add-by-Dialog' option you need to enter -ve values for any S/W values...

Hope it proves useful...

Please feedback if you'd like anything tweaking...

[Gaieus]

Yes, I realized how the LatLong thing works (and since I am in the positive quarter for both values, do not have to hassle with the negative input either).

[dedmin]

Could be made something that puts the material of the clicked face - aka material label?

[ubi904]

It's a great plugin ,

the only one problem is, that the user have to select manualy all the points and mark them, and only these, manually marked points will be exported, so a complet surface or more surfece's can not be exported to other program, which needs txt file as input (Surfer, Vertical Mapper etc.)

[Gaieus]

@ubi904 said:

the only one problem is, that the user have to select manualy all the points and mark them, and only these, manually marked points will be exported, so a complet surface or more surfece's can not be exported to other program, which needs txt file as input (Surfer, Vertical Mapper etc.)

TIG, we have been communicating with ubi over the Hungarian forum about this.

I have been thinking about an easy (at least for me, a lay person, "seemingly" easy) solution/modification;

what if tags could be added to the vertices of a whole selection? Say there is a terrain imported / exploded from GE and one turns on hidden geometry to be able to select all - then run the plugin and each vertex would be tagged - then could be exported to a csv file?

(Or a simple vertex export - like a reverse Cloud.rb á la Didier?)

[ubi904]

@ubi904 said:

It's a great plugin ,

the only one problem is, that the user have to select manualy all the points and mark them, and only these, manually marked points will be exported, so a complet surface or more surfece's can not be exported to other program, which needs txt file as input (Surfer, Vertical Mapper etc.)

As I see, it has some limitations, even I can click on many point's, so I get a lot of points marked, above "X" point it can not be export to CSV, it make's nothing, the csv file will not be generated.

[TIG]

@gaieus said:

...(Or a simple vertex export - like a reverse Cloud.rb á la Didier?)

An export_vertices ruby is quite straight forward - I'll make you one...

[Gaieus]

[TIG]

It's here http://forums.sketchucation.com/viewtopic.php?p=298614#p298614
exportvertices2csv.rb .............

[George]

Hello TIG,

I’m working with Coords Text Tag from Datum v1.6 20101120

Gaieus suggested the plugin as a means of creating guide points at specified locations in a geo-located model using Latitude and Longitude as input data via ‘Add Coord by Dialog’.

The plugin works as expected with length units ... inches, feet, meters and so on.
However, entering LL data via ‘Add Coord by Dialog’ yields odd results.

These are the settings:

This is the location of the model:

When I click the Add Coords-Tag tool on the Origin, the coord-tag is correct:

Then I try entering the exact model location in ‘Add Coord by Dialog’:

The result is consistently a coord-tag with Latitude way off to the south, near the Equator:

I tried unloading all plugins and the extensions in the Preferences-Extensions panel so this was the only plugin loaded when SU starts.
The results were the same.

I'm at a loss to figure out what's wrong.
Am I entering the data improperly?

Thanks,

-Geo

[TIG]

I just tried exactly what you did and it worked fine for me ???
Try with LL+Z ?
Can you post your exact steps to get to the problem...............