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 Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

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 Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

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 Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Confirming what Peter has said. The internal side is always meter. 

You can use the Linear convert for the values to get the ones TBC uses.

Here is a demo of a project in meters and how to get the appropriate values in US Survey Foot. 

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Peter,

thanks for asking and your proposal!

I had tried picking on 2d and 3D views and until now, picking on the point cloud, but I now tried also picking a previous created line just in case, and unfortunately, I still get always the Z coordinate from the CoordinateEdit control in Metres while XY in the current units.

Thanks.

Fernando

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

Original Message:
Sent: 06-05-2024 13:12
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Original Message:
Sent: 6/5/2024 1:12:00 PM
From: Fernando Calvo
Subject: RE: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

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

Original Message:
Sent: 06-05-2024 08:03
From: Ronny Schneider
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

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

Original Message:
Sent: 06-04-2024 09:21
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 09:08
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

------------------------------
Peter Kistler

Original Message:
Sent: 06-04-2024 07:29
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Do you look at the values in the object watcher? Here you'll get all 3 values always as metres. I's impossible that you get X/Y here in project units, but Z in metres.

If you write them into a simple NumberEdit all 3 willl show up with their value as Meters and you will have to manually convert them, as you showed you do for the z-value. As an example, if you'd just write your Coordinatepicker.X into that Elevation NumberEdit you'll need to do a manual conversion.

Or do you mean the coordinate picker when you write that you get x and y in project units? That would be correct, since the Edit converts it automatically for you. That's why you see it properly in project units without manual conversion. In the background it's still metres as well.

In regard to the coordinates you usually just don't realize that you work with metres, since you just add the point to a linestring or a new point or DTM..... And since internally everything is saved as Metres anyway you won't have to do any conversion. The conversion is only necessary if you present values to or take inputs from the user in the UI, or an output file.

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

Original Message:
Sent: 06-05-2024 23:30
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks for asking and your proposal!

I had tried picking on 2d and 3D views and until now, picking on the point cloud, but I now tried also picking a previous created line just in case, and unfortunately, I still get always the Z coordinate from the CoordinateEdit control in Metres while XY in the current units.

Thanks.

Fernando

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

Original Message:
Sent: 06-05-2024 13:12
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Original Message:
Sent: 6/5/2024 1:12:00 PM
From: Fernando Calvo
Subject: RE: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

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

Original Message:
Sent: 06-05-2024 08:03
From: Ronny Schneider
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

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

Original Message:
Sent: 06-04-2024 09:21
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 09:08
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

------------------------------
Peter Kistler

Original Message:
Sent: 06-04-2024 07:29
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi Ronny,

thanks so much for your efforts and recommendations and sorry for the confusion.

Please find attached a video, as it´s easier to show this way what I mean and what I was able to clarify through your, Peter´s and Bryce´s feedbacks and recommendations, so thanks a lot for that ! ;-)

Regards,

Fernando

Do you look at the values in the object watcher? Here you'll get all 3 values always as metres. I's impossible that you get X/Y here in project units, but Z in metres.

If you write them into a simple NumberEdit all 3 willl show up with their value as Meters and you will have to manually convert them, as you showed you do for the z-value. As an example, if you'd just write your Coordinatepicker.X into that Elevation NumberEdit you'll need to do a manual conversion.

Or do you mean the coordinate picker when you write that you get x and y in project units? That would be correct, since the Edit converts it automatically for you. That's why you see it properly in project units without manual conversion. In the background it's still metres as well.

In regard to the coordinates you usually just don't realize that you work with metres, since you just add the point to a linestring or a new point or DTM..... And since internally everything is saved as Metres anyway you won't have to do any conversion. The conversion is only necessary if you present values to or take inputs from the user in the UI, or an output file.

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

Original Message:
Sent: 06-05-2024 23:30
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks for asking and your proposal!

I had tried picking on 2d and 3D views and until now, picking on the point cloud, but I now tried also picking a previous created line just in case, and unfortunately, I still get always the Z coordinate from the CoordinateEdit control in Metres while XY in the current units.

Thanks.

Fernando

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

Original Message:
Sent: 06-05-2024 13:12
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Original Message:
Sent: 6/5/2024 1:12:00 PM
From: Fernando Calvo
Subject: RE: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

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

Original Message:
Sent: 06-05-2024 08:03
From: Ronny Schneider
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

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

Original Message:
Sent: 06-04-2024 09:21
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 09:08
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

------------------------------
Peter Kistler

Original Message:
Sent: 06-04-2024 07:29
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

Hi again,

additionally, as I´m calculating a lot of heights, etc based on the picked Z values and showing them in different kind of field such us NumericEdits but also as Labels, etc, knowing now that conversion issue, I will rather change all those fields to DistanceEdits as they will be automatically converted and many TBC functions need those heights also in Metres and not in the current units, so I´ll try to unify...however there are dozens of controls to be changed and hundreds of lines where their value is used, so a sensible and time consuming task, but absolutely necessary.

Thanks again.

Regards,

Fernando

Hi Ronny,

thanks so much for your efforts and recommendations and sorry for the confusion.

Please find attached a video, as it´s easier to show this way what I mean and what I was able to clarify through your, Peter´s and Bryce´s feedbacks and recommendations, so thanks a lot for that ! ;-)

Regards,

Fernando

Do you look at the values in the object watcher? Here you'll get all 3 values always as metres. I's impossible that you get X/Y here in project units, but Z in metres.

If you write them into a simple NumberEdit all 3 willl show up with their value as Meters and you will have to manually convert them, as you showed you do for the z-value. As an example, if you'd just write your Coordinatepicker.X into that Elevation NumberEdit you'll need to do a manual conversion.

Or do you mean the coordinate picker when you write that you get x and y in project units? That would be correct, since the Edit converts it automatically for you. That's why you see it properly in project units without manual conversion. In the background it's still metres as well.

In regard to the coordinates you usually just don't realize that you work with metres, since you just add the point to a linestring or a new point or DTM..... And since internally everything is saved as Metres anyway you won't have to do any conversion. The conversion is only necessary if you present values to or take inputs from the user in the UI, or an output file.

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

Original Message:
Sent: 06-05-2024 23:30
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks for asking and your proposal!

I had tried picking on 2d and 3D views and until now, picking on the point cloud, but I now tried also picking a previous created line just in case, and unfortunately, I still get always the Z coordinate from the CoordinateEdit control in Metres while XY in the current units.

Thanks.

Fernando

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

Original Message:
Sent: 06-05-2024 13:12
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Original Message:
Sent: 6/5/2024 1:12:00 PM
From: Fernando Calvo
Subject: RE: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Ronny,

thanks  a lot for your comments and recommendations !

I´ll have a look again to check why I´m getting other values than in your test, however I´m simply reading the XYZ given back from the control as follows:

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

Original Message:
Sent: 06-05-2024 08:03
From: Ronny Schneider
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

I can't confirm what you're seeing with the CoordinateEdit control.

Simple test, I have a line, in a basic metric project, with a node at 1,1,1.

If I snap to that node while using my point macro the object watcher shows the following.

And if I switch the project to US survey foot, the object watcher looks exactly the same

while the coordinate picker shows the foot values.

The issue with your macro is, as Peter pointed out, that you're using the NumericEdit to show the Z-Value. As he wrote, is that one unitless and always shows whatever value you give it in your macro. It doesn't do any unit conversions before it shows it to the user in the UI. Since the CoordinateEdit in the background always uses metres you're always writing pure metres into that box.

The CoordinateEdit, DistanceEdit, ElevationEdit do the appropriate conversion for you, before showing the value on the screen, that's the beauty of those.

The best would be if you'd just change those NumericEdits to Wpf:ElevationEdit. And you're good to go without manual conversions. You'd only have to change the target for the elevation to self.numRefLevelZ.Elevation

in OnLoad you can i.e. set the CoordinateEdit to show the elevation as well.

        self.coordpick1.ShowElevationIf3D = True

I only use the NumericEdit to request scale values, decimal places or increment numbers. For all the other values I try to use the appropriate control that does the conversion for me. I've got a few old macros where I did it manually, but I'll see that I'll change them if I have time.

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

Original Message:
Sent: 06-04-2024 09:21
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Peter,

thanks so much for your reply and feedback !

Yes, I use the ElevationEdit in some masks, however I was reading the Z coordinate from the CoordinateEdit control in some others, so:

ctrl = self.coordCtlLevel
coord1 = ctrl.Coordinate

dZ = coord1.Z

and was surprised that the ctrl.Coordinate.Z is always given back in Metres while the X and Y in the current units settings.

I´ve been adding now the conversion for distances and picked Z values and it´s working fine so far, however I´ll recheck if using an ElevationEdit would be a better approach.

Thanks again.

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 09:08
From: Peter Kistler
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando,

The internal value is always meters for any distance value.

The problem might be the control you are using.  The NumericEdit control should be used for unitless numbers.  There is an ElevationEdit control which should be used for retrieve elevation / Z values. It uses meters internally but will display the value in the user's preferred units.

Peter

------------------------------
Peter Kistler

Original Message:
Sent: 06-04-2024 07:29
From: Fernando Calvo
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Bryce,

thanks so much for your quick reply !

Sure, I mean when using an own macro and picking a point from a CoordinateEdit control, not using a standard TBC mask where you pick a point, as it probably gets its conversions before showing the Z coordinate.

For example, if I pick a point somewhere using the standard TBC point info function:

However, if picking from an own macro via CoordinateEdit control as follows:

and after picking reading the XYZ of the picked point:

def coordCtlRefPoint_ValueChanged(self, sender, e):

      ctrl = self.coordCtlRefPoint

      coord1 = ctrl.Coordinate

      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 

      dConvLinear = self.lunits.Convert(1, LinearType.Display) 

       dZ = coord1.Z    # in Metres

       dZ = dZ * dConvLinear   # units conversion for Z (in case)

       self.numRefLevelZ.Value = Math.Round(dZ,3)

And then I get the expected Z coordinate fitting the current units settings:

Thanks a lot for your support !

Regards,

Fernando

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

Original Message:
Sent: 06-04-2024 06:59
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

Hi Fernando, 
Can you please give steps to reproduce the issue you are seeing? 

I did a simple test and did verify the Z value (elevation) can be read when the units are set to US Survey Foot. 

There is something I am missing in what you are doing, so please let me know what to do to reproduce the issue you believe you are seeing. 

Thanks!

------------------------------
Bryce Haire

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

Hi Bryce,

coming back to this topic, I realized that the Wpf:CoordinateEdit reads the Easting and Northing fine (depening on the units set for lenghts) when picking any point, however the Z coordinate is read always in Metres. Could you confirm this please?

It´s a bit confusing as when reading the coordinates of a picked point from that CoordinateEdit control, we can use the XY but need to convert all the time from Metres to i.e. US Survey Feet to get the proper Z coordinate, but afterwards, if needing to create i.e. an horizontal cutting plane at a specific Z coordinate, we need to convert back from Feet to Metres.

Wouldn´t make rather sense to read X, Y and Z from a CoordinateEdit control either all in Metres or all in the corresponding current units? 

Thanks.

Regards,

Fernando

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

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

Hi Bryce,

thanks again for this answer too !

As previously mentioned in my reply to Ronny, I´m already using that class but didn´t find the Convert method, or so far I remember something with "...ToFeet()" or similar but it didn´t work, and therefore I decided to make the conversions myself as it was pretty simple applying a conversion factor.

I´ll have a look at it and try to use the same conversion as TBC internally as it makes sense to avoid confusion when getting minor differences if using the internal TBC conversion factor or a slightly different one as "official" but giving at the end some decimals differences.

Thanks.

Regards,

Fernando

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

Original Message:
Sent: 04-23-2024 13:47
From: Bryce Haire
Subject: Unit conversion inside TBC - Conversion factors used different than "official ones"

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.

------------------------------
Bryce Haire

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

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