Trimble Business Center

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?



------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

Interesting Question. If you set the new code via the properties pane it will completely overwrite the whole code.

Since you're in Australia you probably have access to UPG's ANZ-Toolbox. That contains a "Find and Replace Points" what supposedly can replace featurecodes as well. The question would be if it really only replaces the feature name and would keep the attributes untouched. BUT, I just tested it and the version that came with TBC5.70.1 doesn't replace feature codes at all. Have to check with UPG if that is a bug.

I'll have a look later if that can easily be done with a macro.

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

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

Managed to bodge a quick macro together. It should work for multi-codes as well.
Save before you use it, haven't done in depth testing yet. Let me know if you find a bug or strange behavior.
I would not recommend to actually rename/replace feature codes. It will do it and the attributes won't get lost, but i.e. a SU code doesn't have the same attributes as EU. You'll end up with a mixed up attributes list.

Unzip the attached file somewhere into "C:\ProgramData\Trimble\MacroCommands" and restart TBC.

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

Original Message:
Sent: 08-02-2022 23:26
From: Ronny Schneider
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Interesting Question. If you set the new code via the properties pane it will completely overwrite the whole code.

Since you're in Australia you probably have access to UPG's ANZ-Toolbox. That contains a "Find and Replace Points" what supposedly can replace featurecodes as well. The question would be if it really only replaces the feature name and would keep the attributes untouched. BUT, I just tested it and the version that came with TBC5.70.1 doesn't replace feature codes at all. Have to check with UPG if that is a bug.

I'll have a look later if that can easily be done with a macro.

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

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

Hi Ronny,

Thanks for this, but it doesn't help. Yes, the ANZ offers a function similar to your macro. Searching the codes with the missing string numbers it selects all the codes. There are 195 points selected, but they should be on 20 different strings.

I tested it today in the field with Trimble Access by changing the string number and here the attributes are retained. I would expect TBC to do the same as Trimble Access.

------------------------------
Heinz Lichtenberg
------------------------------

Original Message:
Sent: 08-03-2022 03:15
From: Ronny Schneider
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Managed to bodge a quick macro together. It should work for multi-codes as well.
Save before you use it, haven't done in depth testing yet. Let me know if you find a bug or strange behavior.
I would not recommend to actually rename/replace feature codes. It will do it and the attributes won't get lost, but i.e. a SU code doesn't have the same attributes as EU. You'll end up with a mixed up attributes list.

Unzip the attached file somewhere into "C:\ProgramData\Trimble\MacroCommands" and restart TBC.

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

Original Message:
Sent: 08-02-2022 23:26
From: Ronny Schneider
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Interesting Question. If you set the new code via the properties pane it will completely overwrite the whole code.

Since you're in Australia you probably have access to UPG's ANZ-Toolbox. That contains a "Find and Replace Points" what supposedly can replace featurecodes as well. The question would be if it really only replaces the feature name and would keep the attributes untouched. BUT, I just tested it and the version that came with TBC5.70.1 doesn't replace feature codes at all. Have to check with UPG if that is a bug.

I'll have a look later if that can easily be done with a macro.

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

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

If you use polygon select you can relative easy select the points that should end up as one linestring, add a number to it with search and replace so that all of them have different numbers and re-process the codes. Shouldn't take much longer than 10 minutes to do that.

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

Original Message:
Sent: 08-04-2022 21:07
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Hi Ronny,

Thanks for this, but it doesn't help. Yes, the ANZ offers a function similar to your macro. Searching the codes with the missing string numbers it selects all the codes. There are 195 points selected, but they should be on 20 different strings.

I tested it today in the field with Trimble Access by changing the string number and here the attributes are retained. I would expect TBC to do the same as Trimble Access.

------------------------------
Heinz Lichtenberg

Original Message:
Sent: 08-03-2022 03:15
From: Ronny Schneider
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Managed to bodge a quick macro together. It should work for multi-codes as well.
Save before you use it, haven't done in depth testing yet. Let me know if you find a bug or strange behavior.
I would not recommend to actually rename/replace feature codes. It will do it and the attributes won't get lost, but i.e. a SU code doesn't have the same attributes as EU. You'll end up with a mixed up attributes list.

Unzip the attached file somewhere into "C:\ProgramData\Trimble\MacroCommands" and restart TBC.

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

Original Message:
Sent: 08-02-2022 23:26
From: Ronny Schneider
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Interesting Question. If you set the new code via the properties pane it will completely overwrite the whole code.

Since you're in Australia you probably have access to UPG's ANZ-Toolbox. That contains a "Find and Replace Points" what supposedly can replace featurecodes as well. The question would be if it really only replaces the feature name and would keep the attributes untouched. BUT, I just tested it and the version that came with TBC5.70.1 doesn't replace feature codes at all. Have to check with UPG if that is a bug.

I'll have a look later if that can easily be done with a macro.

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

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

seems like a pop up with an option to 'save existing attributes otherwise data will be lost' would make sense for this application.

one solution might be to add a beginning line control code to each new string. i have a feeling this would not remove the attribute since the base code is staying the same, but it would have to be tested. example: UG would change to UG B. where UG is underground gas and B is begin new string in our FXL file.
of course this would not work if the field crew was collecting two features at the same time with the same code, but i doubt that is the case if they were not coding correctly to begin with. 

can i make two comments here about the feature code processing where i see other problems. 
1. if i change point numbers in order to fix a feature string problem(a zig zag field error, or sometimes a sting is started in the middle in one direction and then goes again from the middle in the other direction) then the software does not recognize that the numbers have been changed and the feature line stays the same. it should follow the increase in point numbers, but get stuck by the number that was collected in the field.

2. if i collect an offset shot using an offset line control code for only one point along a string it will not offset the line to that one point. it works if all codes have offsets for a string. and a work around is to add an offset code of 0 for the code before and after the one in question, but this is cumbersome. example: UG V -1.5 where UG is underground gas and V is vertical offset of -1.5. this code would not work on a string of 1 UG                    2 UG V -1.5                        3 UG.                
but it will work on a string of: 1 UG  V 0                  2 UG V -1.5                            3 UG V 0
1 2 3 being the point numbers.

------------------------------
ian bissonnette
------------------------------

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

Just a comment on your first comment:

The order of the points used when processing a feature is by the order that they were collected (database order), not by point number.  At least for Trimble Access job/JobXML files.  This holds true when viewing linework either in Trimble Access or Trimble Business Center.  I find this a lot more consistent and robust than processing by sorted point number -- it's resistant to point name sequencing changing in Trimble Access that can happen when switching between measurement methods (e.g. rapid vs topo), and in cases where alphanumeric point names are used there are discrepancies between different software what the sort order is for alphanumeric names, which can obviously change how the linework is formed.

That said I would like to see an option in TBC to control the order of points used for feature processing, right now it uses different methods depending on the file type imported (e.g. for a CSV it will sort by point name, for Access Job/JobXML it uses the order stored in the file), which can get confusing if you use a CSV from Access and expect it to look the same as if you imported the same points from a JobXML...

-- Andrew

------------------------------
Andrew Klingenberg
------------------------------

Original Message:
Sent: 08-03-2022 08:18
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

seems like a pop up with an option to 'save existing attributes otherwise data will be lost' would make sense for this application.

one solution might be to add a beginning line control code to each new string. i have a feeling this would not remove the attribute since the base code is staying the same, but it would have to be tested. example: UG would change to UG B. where UG is underground gas and B is begin new string in our FXL file.
of course this would not work if the field crew was collecting two features at the same time with the same code, but i doubt that is the case if they were not coding correctly to begin with. 

can i make two comments here about the feature code processing where i see other problems. 
1. if i change point numbers in order to fix a feature string problem(a zig zag field error, or sometimes a sting is started in the middle in one direction and then goes again from the middle in the other direction) then the software does not recognize that the numbers have been changed and the feature line stays the same. it should follow the increase in point numbers, but get stuck by the number that was collected in the field.

2. if i collect an offset shot using an offset line control code for only one point along a string it will not offset the line to that one point. it works if all codes have offsets for a string. and a work around is to add an offset code of 0 for the code before and after the one in question, but this is cumbersome. example: UG V -1.5 where UG is underground gas and V is vertical offset of -1.5. this code would not work on a string of 1 UG                    2 UG V -1.5                        3 UG.                
but it will work on a string of: 1 UG  V 0                  2 UG V -1.5                            3 UG V 0
1 2 3 being the point numbers.

------------------------------
ian bissonnette

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

Original Message:
Sent: 8/3/2022 12:40:00 PM
From: Andrew Klingenberg
Subject: RE: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Just a comment on your first comment:

The order of the points used when processing a feature is by the order that they were collected (database order), not by point number.  At least for Trimble Access job/JobXML files.  This holds true when viewing linework either in Trimble Access or Trimble Business Center.  I find this a lot more consistent and robust than processing by sorted point number -- it's resistant to point name sequencing changing in Trimble Access that can happen when switching between measurement methods (e.g. rapid vs topo), and in cases where alphanumeric point names are used there are discrepancies between different software what the sort order is for alphanumeric names, which can obviously change how the linework is formed.

That said I would like to see an option in TBC to control the order of points used for feature processing, right now it uses different methods depending on the file type imported (e.g. for a CSV it will sort by point name, for Access Job/JobXML it uses the order stored in the file), which can get confusing if you use a CSV from Access and expect it to look the same as if you imported the same points from a JobXML...

-- Andrew

------------------------------
Andrew Klingenberg
------------------------------

Original Message:
Sent: 08-03-2022 08:18
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

seems like a pop up with an option to 'save existing attributes otherwise data will be lost' would make sense for this application.

one solution might be to add a beginning line control code to each new string. i have a feeling this would not remove the attribute since the base code is staying the same, but it would have to be tested. example: UG would change to UG B. where UG is underground gas and B is begin new string in our FXL file.
of course this would not work if the field crew was collecting two features at the same time with the same code, but i doubt that is the case if they were not coding correctly to begin with. 

can i make two comments here about the feature code processing where i see other problems. 
1. if i change point numbers in order to fix a feature string problem(a zig zag field error, or sometimes a sting is started in the middle in one direction and then goes again from the middle in the other direction) then the software does not recognize that the numbers have been changed and the feature line stays the same. it should follow the increase in point numbers, but get stuck by the number that was collected in the field.

2. if i collect an offset shot using an offset line control code for only one point along a string it will not offset the line to that one point. it works if all codes have offsets for a string. and a work around is to add an offset code of 0 for the code before and after the one in question, but this is cumbersome. example: UG V -1.5 where UG is underground gas and V is vertical offset of -1.5. this code would not work on a string of 1 UG                    2 UG V -1.5                        3 UG.                
but it will work on a string of: 1 UG  V 0                  2 UG V -1.5                            3 UG V 0
1 2 3 being the point numbers.

------------------------------
ian bissonnette

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

I don't know of an easy way to change it in TBC (or Access) short of getting creative with the JoinTo line control code (which we do but it can get messy).  To me it would be easiest if TBC would just default to using the order of the points as they appear in whatever file is imported (e.g. CSV), then you could just shuffle the lines in the CSV rather than re-numbering the points (which also paints you into a corner if you have to insert additional points in a line and there isn't room for them in the existing point number sequence).  Minimal changes to the existing data that way.  Works great in Bentley software, which always respects file order.

Another future idea could be to have a linestring editor that shows a list of points used in a line sequence, and then move/insert/delete points as needed.  Doesn't quite map back to the feature coding though (if that matters).  Bentley has this option as well.  (Not that I'm promoting Bentley software, we're actually moving away from it for survey data).

Agree that there needs to be better ways to manipulate this.  We've had lots of cases where additional data is gathered that needs spliced into existing linework, or things are just out of order.

------------------------------
Andrew Klingenberg
------------------------------

Original Message:
Sent: 08-03-2022 12:25
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

good to know why it does it that way, i see now why csv exports from access are sorted how they are sorted. but this leaves no option to change the sequence of a line string, unless you know of an easy way to force it in tbc. 

i guess this is my biggest wish for tbc. if we can manipulate everything that is whited out, sure, show a warning, but there are times when things need to be changed. 

Ian Bissonnette

HBH Land Surveying

3750 1st Avenue

PO Box 536

Smithers, BC

V0J 2N0

250.847.3808

Original Message:
Sent: 8/3/2022 12:40:00 PM
From: Andrew Klingenberg
Subject: RE: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Just a comment on your first comment:

The order of the points used when processing a feature is by the order that they were collected (database order), not by point number.  At least for Trimble Access job/JobXML files.  This holds true when viewing linework either in Trimble Access or Trimble Business Center.  I find this a lot more consistent and robust than processing by sorted point number -- it's resistant to point name sequencing changing in Trimble Access that can happen when switching between measurement methods (e.g. rapid vs topo), and in cases where alphanumeric point names are used there are discrepancies between different software what the sort order is for alphanumeric names, which can obviously change how the linework is formed.

That said I would like to see an option in TBC to control the order of points used for feature processing, right now it uses different methods depending on the file type imported (e.g. for a CSV it will sort by point name, for Access Job/JobXML it uses the order stored in the file), which can get confusing if you use a CSV from Access and expect it to look the same as if you imported the same points from a JobXML...

-- Andrew

------------------------------
Andrew Klingenberg

Original Message:
Sent: 08-03-2022 08:18
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

seems like a pop up with an option to 'save existing attributes otherwise data will be lost' would make sense for this application.

one solution might be to add a beginning line control code to each new string. i have a feeling this would not remove the attribute since the base code is staying the same, but it would have to be tested. example: UG would change to UG B. where UG is underground gas and B is begin new string in our FXL file.
of course this would not work if the field crew was collecting two features at the same time with the same code, but i doubt that is the case if they were not coding correctly to begin with. 

can i make two comments here about the feature code processing where i see other problems. 
1. if i change point numbers in order to fix a feature string problem(a zig zag field error, or sometimes a sting is started in the middle in one direction and then goes again from the middle in the other direction) then the software does not recognize that the numbers have been changed and the feature line stays the same. it should follow the increase in point numbers, but get stuck by the number that was collected in the field.

2. if i collect an offset shot using an offset line control code for only one point along a string it will not offset the line to that one point. it works if all codes have offsets for a string. and a work around is to add an offset code of 0 for the code before and after the one in question, but this is cumbersome. example: UG V -1.5 where UG is underground gas and V is vertical offset of -1.5. this code would not work on a string of 1 UG                    2 UG V -1.5                        3 UG.                
but it will work on a string of: 1 UG  V 0                  2 UG V -1.5                            3 UG V 0
1 2 3 being the point numbers.

------------------------------
ian bissonnette

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------

good points. we too sometimes have to be creative with begin/end/connect commands to make things work.
i don t use civil 3d. but i have heard that it has it s own number system for each point number(not exactly sure how it works). but from what you are saying andrew, it would be great if in the tbc point list there was a column with the sequence of observations, i guess these already exist as the rtk or total station observations and these could be manipulated to fix the sequence of linestrings where needed.


Original Message:
Sent: 8/3/2022 6:14:00 PM
From: Andrew Klingenberg
Subject: RE: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I don't know of an easy way to change it in TBC (or Access) short of getting creative with the JoinTo line control code (which we do but it can get messy).  To me it would be easiest if TBC would just default to using the order of the points as they appear in whatever file is imported (e.g. CSV), then you could just shuffle the lines in the CSV rather than re-numbering the points (which also paints you into a corner if you have to insert additional points in a line and there isn't room for them in the existing point number sequence).  Minimal changes to the existing data that way.  Works great in Bentley software, which always respects file order.

Another future idea could be to have a linestring editor that shows a list of points used in a line sequence, and then move/insert/delete points as needed.  Doesn't quite map back to the feature coding though (if that matters).  Bentley has this option as well.  (Not that I'm promoting Bentley software, we're actually moving away from it for survey data).

Agree that there needs to be better ways to manipulate this.  We've had lots of cases where additional data is gathered that needs spliced into existing linework, or things are just out of order.

------------------------------
Andrew Klingenberg
------------------------------

Original Message:
Sent: 08-03-2022 12:25
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

good to know why it does it that way, i see now why csv exports from access are sorted how they are sorted. but this leaves no option to change the sequence of a line string, unless you know of an easy way to force it in tbc. 

i guess this is my biggest wish for tbc. if we can manipulate everything that is whited out, sure, show a warning, but there are times when things need to be changed. 

Ian Bissonnette

HBH Land Surveying

3750 1st Avenue

PO Box 536

Smithers, BC

V0J 2N0

250.847.3808

Original Message:
Sent: 8/3/2022 12:40:00 PM
From: Andrew Klingenberg
Subject: RE: Feature Code Attributes being lost by changing a string number for a feature code in TBC

Just a comment on your first comment:

The order of the points used when processing a feature is by the order that they were collected (database order), not by point number.  At least for Trimble Access job/JobXML files.  This holds true when viewing linework either in Trimble Access or Trimble Business Center.  I find this a lot more consistent and robust than processing by sorted point number -- it's resistant to point name sequencing changing in Trimble Access that can happen when switching between measurement methods (e.g. rapid vs topo), and in cases where alphanumeric point names are used there are discrepancies between different software what the sort order is for alphanumeric names, which can obviously change how the linework is formed.

That said I would like to see an option in TBC to control the order of points used for feature processing, right now it uses different methods depending on the file type imported (e.g. for a CSV it will sort by point name, for Access Job/JobXML it uses the order stored in the file), which can get confusing if you use a CSV from Access and expect it to look the same as if you imported the same points from a JobXML...

-- Andrew

------------------------------
Andrew Klingenberg

Original Message:
Sent: 08-03-2022 08:18
From: ian bissonnette
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

seems like a pop up with an option to 'save existing attributes otherwise data will be lost' would make sense for this application.

one solution might be to add a beginning line control code to each new string. i have a feeling this would not remove the attribute since the base code is staying the same, but it would have to be tested. example: UG would change to UG B. where UG is underground gas and B is begin new string in our FXL file.
of course this would not work if the field crew was collecting two features at the same time with the same code, but i doubt that is the case if they were not coding correctly to begin with. 

can i make two comments here about the feature code processing where i see other problems. 
1. if i change point numbers in order to fix a feature string problem(a zig zag field error, or sometimes a sting is started in the middle in one direction and then goes again from the middle in the other direction) then the software does not recognize that the numbers have been changed and the feature line stays the same. it should follow the increase in point numbers, but get stuck by the number that was collected in the field.

2. if i collect an offset shot using an offset line control code for only one point along a string it will not offset the line to that one point. it works if all codes have offsets for a string. and a work around is to add an offset code of 0 for the code before and after the one in question, but this is cumbersome. example: UG V -1.5 where UG is underground gas and V is vertical offset of -1.5. this code would not work on a string of 1 UG                    2 UG V -1.5                        3 UG.                
but it will work on a string of: 1 UG  V 0                  2 UG V -1.5                            3 UG V 0
1 2 3 being the point numbers.

------------------------------
ian bissonnette

Original Message:
Sent: 08-02-2022 17:37
From: Heinz Lichtenberg
Subject: Feature Code Attributes being lost by changing a string number for a feature code in TBC

I have to work on a project where Feature Codes for a line feature were used without a string number. Now every time the different .job files are reprocessed the lines for the features go all over the place. Now after I added or changed a string number the lines came up the way I wanted to. But when I looked at a single point all the attributes where gone. Most important the attributes contain an individual depth information, which I require. 
I could go back to a previous version of the TBC project. So I still have the information I need. I tested it for a single point. If I add a string number to the Feature Code the attributes are lost. And I have about 1,000 points in the project. See screen snippets below.

How can I retain the attribute information and change the string number of a Line Feature Code? Any work around?

------------------------------
Heinz Lichtenberg
Cairns / Australia
------------------------------