TBC Macros and Extensions

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Please look at the Linear class in the Trimble.Sdk.Units assembly. 

It should have a Convert method that does what you are looking for. 

NOTE:

You need to pass a CultureInfo to the constructor. I would advise to use the static System.Globalization.CultureInfo.CurrentCulture 

Hope this helps.

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi Fernando,

yes TBC computes internally everything in Meters. I have never checked the conversions values though. I always just used the internally provided methods.

So, if there is an error in the conversion factors then most users will not stumble over it. TBC would always use the same, maybe wrong, conversion factor to convert inputs i.e. from feet to internal meters and back. The user would never see the wrong? meter value.

In order to make my macros more compatible for feet users I've written me a few functions to populate a drop down box, and use the internal methods to convert output values.

Have a look at i.e. SCR_PerpDistToDTM from my repository https://github.com/RonnySchneider/SCR_Macros_Public

but in short, as it is shown in the Trimble sample macros

from Trimble.Vce.Interfaces.Units import LinearType                # get the units for linear distance        self.lunits = self.currentProject.Units.Linear        self.lfp = self.lunits.Properties.Copy() # create a copy in order to set the decimals and enable/disable the suffix        self.lfp.AddSuffix = False # disable suffix, we need to set it manually, it would always add the current projects units

Once you have the self.lfp (linear format properties) you can change it to add a unit suffix or set the decimal number to something different than is set for project. I have macro where I let the user selct how many decimals the output should have.

self.lfp.NumberOfDecimals = int(self.textdecimals.Value)

if you need a string, i.e. for a text object in the worldview or to the write into a CSV file you can use

        self.lfp.AddSuffix = self.addunitsuffix.IsChecked        return self.lunits.Format(LinearType.Meter, v, self.lfp, LinearType(self.outputunitenum)) # in this example the outputunitenum is derived from a combobox

or, as Bryce suggested, you use the Convert method to get a value as double

self.lunits.Convert(station1.Value, LinearType.Display)

you could stack both methods as well

self.lunits.Format(self.lunits.Convert(station1.Value, LinearType.Display), self.lfp)

works the same for i.e. volumes

        # get the units for volumes        self.vunits = self.currentProject.Units.Volume        self.vfp = self.vunits.Properties.Copy()       # create the result strings - back in project dimensions       solutionelevation = self.lunits.Format(solmeter[0], self.lfp)       solutionvolume = self.vunits.Format(solmeter[1], self.vfp)

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi Fernando,

yes TBC computes internally everything in Meters. I have never checked the conversions values though. I always just used the internally provided methods.

So, if there is an error in the conversion factors then most users will not stumble over it. TBC would always use the same, maybe wrong, conversion factor to convert inputs i.e. from feet to internal meters and back. The user would never see the wrong? meter value.

In order to make my macros more compatible for feet users I've written me a few functions to populate a drop down box, and use the internal methods to convert output values.

Have a look at i.e. SCR_PerpDistToDTM from my repository https://github.com/RonnySchneider/SCR_Macros_Public

but in short, as it is shown in the Trimble sample macros

from Trimble.Vce.Interfaces.Units import LinearType                # get the units for linear distance        self.lunits = self.currentProject.Units.Linear        self.lfp = self.lunits.Properties.Copy() # create a copy in order to set the decimals and enable/disable the suffix        self.lfp.AddSuffix = False # disable suffix, we need to set it manually, it would always add the current projects units

Once you have the self.lfp (linear format properties) you can change it to add a unit suffix or set the decimal number to something different than is set for project. I have macro where I let the user selct how many decimals the output should have.

self.lfp.NumberOfDecimals = int(self.textdecimals.Value)

if you need a string, i.e. for a text object in the worldview or to the write into a CSV file you can use

        self.lfp.AddSuffix = self.addunitsuffix.IsChecked        return self.lunits.Format(LinearType.Meter, v, self.lfp, LinearType(self.outputunitenum)) # in this example the outputunitenum is derived from a combobox

or, as Bryce suggested, you use the Convert method to get a value as double

self.lunits.Convert(station1.Value, LinearType.Display)

you could stack both methods as well

self.lunits.Format(self.lunits.Convert(station1.Value, LinearType.Display), self.lfp)

works the same for i.e. volumes

        # get the units for volumes        self.vunits = self.currentProject.Units.Volume        self.vfp = self.vunits.Properties.Copy()       # create the result strings - back in project dimensions       solutionelevation = self.lunits.Format(solmeter[0], self.lfp)       solutionvolume = self.vunits.Format(solmeter[1], self.vfp)

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi again,

just for general info, when using the Convert function and giving i.e. 1 m and 1 m² to convert, I get following values (so their internal conversion factor):

• From Metres to Intl. Feet: 3.280839895013123
• From Metres to US Survey Feet: 3.2808333333333328
• From Square Metres to Square Feet: 10.763910416709722

So still a slightly different to other "official" values, but probably differences below 1 Square Centimeter or so, I have to check it, but I´ll use from now the Convert function to keep consistency in results given by TBC itself.

Thanks again.

Regards,

Fernando

------------------------------
Fernando Calvo
calvo@calvo-geospatial.com

Original Message:
Sent: 04-23-2024 15:27
From: Ronny Schneider
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

yes TBC computes internally everything in Meters. I have never checked the conversions values though. I always just used the internally provided methods.

So, if there is an error in the conversion factors then most users will not stumble over it. TBC would always use the same, maybe wrong, conversion factor to convert inputs i.e. from feet to internal meters and back. The user would never see the wrong? meter value.

In order to make my macros more compatible for feet users I've written me a few functions to populate a drop down box, and use the internal methods to convert output values.

Have a look at i.e. SCR_PerpDistToDTM from my repository https://github.com/RonnySchneider/SCR_Macros_Public

but in short, as it is shown in the Trimble sample macros

from Trimble.Vce.Interfaces.Units import LinearType                # get the units for linear distance        self.lunits = self.currentProject.Units.Linear        self.lfp = self.lunits.Properties.Copy() # create a copy in order to set the decimals and enable/disable the suffix        self.lfp.AddSuffix = False # disable suffix, we need to set it manually, it would always add the current projects units

Once you have the self.lfp (linear format properties) you can change it to add a unit suffix or set the decimal number to something different than is set for project. I have macro where I let the user selct how many decimals the output should have.

self.lfp.NumberOfDecimals = int(self.textdecimals.Value)

if you need a string, i.e. for a text object in the worldview or to the write into a CSV file you can use

        self.lfp.AddSuffix = self.addunitsuffix.IsChecked        return self.lunits.Format(LinearType.Meter, v, self.lfp, LinearType(self.outputunitenum)) # in this example the outputunitenum is derived from a combobox

or, as Bryce suggested, you use the Convert method to get a value as double

self.lunits.Convert(station1.Value, LinearType.Display)

you could stack both methods as well

self.lunits.Format(self.lunits.Convert(station1.Value, LinearType.Display), self.lfp)

works the same for i.e. volumes

        # get the units for volumes        self.vunits = self.currentProject.Units.Volume        self.vfp = self.vunits.Properties.Copy()       # create the result strings - back in project dimensions       solutionelevation = self.lunits.Format(solmeter[0], self.lfp)       solutionvolume = self.vunits.Format(solmeter[1], self.vfp)

------------------------------
Ronny Schneider

Original Message:
Sent: 04-23-2024 08:40
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

------------------------------
Fernando Calvo
calvo@calvo-geospatial.com
------------------------------

Hey Fernando,

I've been watching this thread. I'm not sure exactly what macros you're developing but just thought I'd throw some general best-practice advice into the mix (as someone who's been writing spatially orientated software for a quite a while)...

For all internal calculation and computations use SI units (meters, radians etc...) exclusively. Only convert into region specific units at the UI level (where a user is going to see something rendered in a CAD UI or a Report or whatever). If you start mucking about with non-SI units (feet, pounds) in your model/functional layer you're opening yourself up for a world of pain in the future. I'm not saying that's what you're doing, just recommending it as something to avoid.

For example in the ANZToolbox everything is done in metric units but when we come to display things at UI level code like this is invoked (this is C# but should map pretty well onto Python):

Hope this helps,

ANZ Toolbox Dev Team.

Hi again,

just for general info, when using the Convert function and giving i.e. 1 m and 1 m² to convert, I get following values (so their internal conversion factor):

• From Metres to Intl. Feet: 3.280839895013123
• From Metres to US Survey Feet: 3.2808333333333328
• From Square Metres to Square Feet: 10.763910416709722

So still a slightly different to other "official" values, but probably differences below 1 Square Centimeter or so, I have to check it, but I´ll use from now the Convert function to keep consistency in results given by TBC itself.

Thanks again.

Regards,

Fernando

Hi Fernando,

yes TBC computes internally everything in Meters. I have never checked the conversions values though. I always just used the internally provided methods.

So, if there is an error in the conversion factors then most users will not stumble over it. TBC would always use the same, maybe wrong, conversion factor to convert inputs i.e. from feet to internal meters and back. The user would never see the wrong? meter value.

In order to make my macros more compatible for feet users I've written me a few functions to populate a drop down box, and use the internal methods to convert output values.

Have a look at i.e. SCR_PerpDistToDTM from my repository https://github.com/RonnySchneider/SCR_Macros_Public

but in short, as it is shown in the Trimble sample macros

from Trimble.Vce.Interfaces.Units import LinearType                # get the units for linear distance        self.lunits = self.currentProject.Units.Linear        self.lfp = self.lunits.Properties.Copy() # create a copy in order to set the decimals and enable/disable the suffix        self.lfp.AddSuffix = False # disable suffix, we need to set it manually, it would always add the current projects units

Once you have the self.lfp (linear format properties) you can change it to add a unit suffix or set the decimal number to something different than is set for project. I have macro where I let the user selct how many decimals the output should have.

self.lfp.NumberOfDecimals = int(self.textdecimals.Value)

if you need a string, i.e. for a text object in the worldview or to the write into a CSV file you can use

        self.lfp.AddSuffix = self.addunitsuffix.IsChecked        return self.lunits.Format(LinearType.Meter, v, self.lfp, LinearType(self.outputunitenum)) # in this example the outputunitenum is derived from a combobox

or, as Bryce suggested, you use the Convert method to get a value as double

self.lunits.Convert(station1.Value, LinearType.Display)

you could stack both methods as well

self.lunits.Format(self.lunits.Convert(station1.Value, LinearType.Display), self.lfp)

works the same for i.e. volumes

        # get the units for volumes        self.vunits = self.currentProject.Units.Volume        self.vfp = self.vunits.Properties.Copy()       # create the result strings - back in project dimensions       solutionelevation = self.lunits.Format(solmeter[0], self.lfp)       solutionvolume = self.vunits.Format(solmeter[1], self.vfp)

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando

Hi Fernando,

Hopefully I can shed some light on this since I'm the one that wrote the units classes.  Here's the history (may be a bit boring) The conversion factors used by TBC were used in Terramodel which was developed before everything was available on the internet. I had recently graduated from Georgia Tech and still had access to the library. I spent a day researching / hunting "official" conversion factors. What I found was the "ASTM Metric Practice Guide" (see attached picture). It's old, older than me. Within the book it lists the exact (denoted by an asterisks, *) conversion factors to convert between "foot" and "meter". These are the values used by TBC today. These conversion factors were also the same values in the textbook I used in the surveying classes I took at university.

International: 1 Foot = .3048 (based on 1 inch = 25.4mm)

US Survey: 1 Foot = 12 / 39.37 (based on 1 meter = 39.37 inches)

All units within TBC that have a length component (Area, Volume, Velocity, etc.) will use the appropriate Linear unit for convention. If you have your Linear set to "International Foot", the SquareFoot Area unit will compute the conversion factor using the International Foot to Meter conversion factor. (It does some caching behind the scenes to make it faster). If you change the "Foot Conversion" factor in Project Settings, it will recompute all the affected composite conversion factors.

Now there may be higher "accuracy" values available today but using those values in existing / defined measurements would be extremely dangerous. I can see all the lawyers getting very rich from all the lawsuits as a result.

Hi,

so far I see the area and length values got back from function such us:

###################################

polyRoom = lRoom.ComputePolySeg()
polyRoom.Area( dArea, ptCentroid, sideDirection)

dLength = polyRoom.Length()

###################################

are always in Metres independently on the current unit settings inside TBC, correct?

As I´m also doing right now my own conversions from metres to Feet and US Survey Feet, as well as SquareMetres to SquareFeet and USSurveySquareFeet for my macros, I realized that TBC is using a different conversion factor than the "official" ones that I found on the internet. I obviously tried first to find existing functions inside the SDK to convert between those units but without success or the ones that I found that could sound to do that, didn´t work.

So, I found on the internet the following conversion factors:

• Metres to International Feet: 3,280839895
• Metres to US Survey Feet: 3,28083343833312
• Square Metres to International Square Feet: 10,76391042
• Square Metres to US Survey Square Feet: 10,7638673611

While if I create some lengths and areas inside TBC and show first the values in Metres and Square Metres and then change the units, I get the following factors comparing both shown values:

• Metres to International Feet: 3,28085 instead of  3,280839895 as above
• Square Metres to International Square Feet: 10,7639 instead of 10,76391042 as above

Could anyone clarify this please? if there is any internal function to convert those values using the same conversion factors as TBC does, even better obviously.

Thanks.

Regards,

Fernando