Trimble Business Center

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Hi Martin,

Absolutely agree that TA and TBC should produce the same result, and that TBC is correct. In your case, perhaps a solution would be to code it like this, which is a little simpler, and gives the same (correct) result in TA and TBC

Best regards,

Nick.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

thanks martin, i am pretty sure my technique will work. i did not actually do it in the field yet, and could not get the emulator running for some reason(i am away and maybe it is picking up a change in my zone or something, or something else got messed up with that finicky thing), but i did key in some points and it shows that it works in access anyways. 

it would take a bit of fancy button pushing to hop in and out of multicodes in measure codes. exit multicode, increase or decrease the string number, then back into multicodes and select the two needed. or you could just run in measure mode and manually increase the string number by one as you go up the parking lot and then decrease by one as you go the other way, with the two codes for almost all shots but the outsides. 

it might be that you are right and using "join to" command from the cad toolbar only on the return up the parking lot would be faster for a lot of stalls. i guess my initial reaction was that it was a lot of point numbers to type in, but if you select them from the map, it might go well. sometimes we also run with very large point numbers and the join command will not work with a date range type of number: ie 231129000. Or I remember having issues there in the past.

my only other thought is that my way will almost certainly produce a continuous string closing around the perimeter, with segments for each stall, i am not exactly sure what kind of line is created with the join command, is it connected to the longer line string or not? but this could always be exploded if needed. and not sure what your end goal is.

 

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Ian,

thanks! Now, I fully understand what you suggested and yes, it will work.

Just some questions:

How did you define the WL1, WL2, ... codes in your FXL file? As a line feature? If they are defined as line feature, then all the lines will be line strings

and I need to have a polygon feature on the perimeter (I also use some attributes for the polygons) and the individual dividing line on particular parking lots as lines.

Do you also use stringing codes functionality?

Martin

thanks martin, i am pretty sure my technique will work. i did not actually do it in the field yet, and could not get the emulator running for some reason(i am away and maybe it is picking up a change in my zone or something, or something else got messed up with that finicky thing), but i did key in some points and it shows that it works in access anyways. 

it would take a bit of fancy button pushing to hop in and out of multicodes in measure codes. exit multicode, increase or decrease the string number, then back into multicodes and select the two needed. or you could just run in measure mode and manually increase the string number by one as you go up the parking lot and then decrease by one as you go the other way, with the two codes for almost all shots but the outsides. 

it might be that you are right and using "join to" command from the cad toolbar only on the return up the parking lot would be faster for a lot of stalls. i guess my initial reaction was that it was a lot of point numbers to type in, but if you select them from the map, it might go well. sometimes we also run with very large point numbers and the join command will not work with a date range type of number: ie 231129000. Or I remember having issues there in the past.

my only other thought is that my way will almost certainly produce a continuous string closing around the perimeter, with segments for each stall, i am not exactly sure what kind of line is created with the join command, is it connected to the longer line string or not? but this could always be exploded if needed. and not sure what your end goal is.

 

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Ian,

thanks! Now, I fully understand what you suggested and yes, it will work.

Just some questions:

How did you define the WL1, WL2, ... codes in your FXL file? As a line feature? If they are defined as line feature, then all the lines will be line strings

and I need to have a polygon feature on the perimeter (I also use some attributes for the polygons) and the individual dividing line on particular parking lots as lines.

Do you also use stringing codes functionality?

Martin

thanks martin, i am pretty sure my technique will work. i did not actually do it in the field yet, and could not get the emulator running for some reason(i am away and maybe it is picking up a change in my zone or something, or something else got messed up with that finicky thing), but i did key in some points and it shows that it works in access anyways. 

it would take a bit of fancy button pushing to hop in and out of multicodes in measure codes. exit multicode, increase or decrease the string number, then back into multicodes and select the two needed. or you could just run in measure mode and manually increase the string number by one as you go up the parking lot and then decrease by one as you go the other way, with the two codes for almost all shots but the outsides. 

it might be that you are right and using "join to" command from the cad toolbar only on the return up the parking lot would be faster for a lot of stalls. i guess my initial reaction was that it was a lot of point numbers to type in, but if you select them from the map, it might go well. sometimes we also run with very large point numbers and the join command will not work with a date range type of number: ie 231129000. Or I remember having issues there in the past.

my only other thought is that my way will almost certainly produce a continuous string closing around the perimeter, with segments for each stall, i am not exactly sure what kind of line is created with the join command, is it connected to the longer line string or not? but this could always be exploded if needed. and not sure what your end goal is.

 

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Many thanks Ian,

Yes, you understand my last question correctly. Thanks for your tips.

My explanation regarding to measuring of a parking area with dividing lines for every single parking lot:

I had/have no desire to walk with my R12i/TSC7 rover in zig-zag  manner  to struggle between parked cars. It is far more easier

to observe end points of the dividing lines on one side and then, when walking back to the start point by measuring the opposite

end points of the single dividing lines. Therefore I used the command control code JOIN TO SPECIFIC POINT (JTSP), since I see the

opposite end point on the map and I can either type in its number manually as the last parameter of its code field (which I did) or tap it from the map (I will try it next time).

A formal question:

Is it possible to create Measure Code forms in Trimble Access without joining to a GNSS receiver 

(simply in the office with TSC7/5 in hand)?

Till now, I always was outside, connected the R12i rover, started an RTK style measurement and then defined the Measure Codes buttons.

Martin

Ian,

thanks! Now, I fully understand what you suggested and yes, it will work.

Just some questions:

How did you define the WL1, WL2, ... codes in your FXL file? As a line feature? If they are defined as line feature, then all the lines will be line strings

and I need to have a polygon feature on the perimeter (I also use some attributes for the polygons) and the individual dividing line on particular parking lots as lines.

Do you also use stringing codes functionality?

Martin

thanks martin, i am pretty sure my technique will work. i did not actually do it in the field yet, and could not get the emulator running for some reason(i am away and maybe it is picking up a change in my zone or something, or something else got messed up with that finicky thing), but i did key in some points and it shows that it works in access anyways. 

it would take a bit of fancy button pushing to hop in and out of multicodes in measure codes. exit multicode, increase or decrease the string number, then back into multicodes and select the two needed. or you could just run in measure mode and manually increase the string number by one as you go up the parking lot and then decrease by one as you go the other way, with the two codes for almost all shots but the outsides. 

it might be that you are right and using "join to" command from the cad toolbar only on the return up the parking lot would be faster for a lot of stalls. i guess my initial reaction was that it was a lot of point numbers to type in, but if you select them from the map, it might go well. sometimes we also run with very large point numbers and the join command will not work with a date range type of number: ie 231129000. Or I remember having issues there in the past.

my only other thought is that my way will almost certainly produce a continuous string closing around the perimeter, with segments for each stall, i am not exactly sure what kind of line is created with the join command, is it connected to the longer line string or not? but this could always be exploded if needed. and not sure what your end goal is.

 

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

------------------------------
Martin Kalafut

Original Message:
Sent: 11-28-2023 09:13
From: ian bissonnette
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

------------------------------
Martin Kalafut
------------------------------

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

------------------------------
Martin Kalafut

Original Message:
Sent: 11-28-2023 09:13
From: ian bissonnette
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

------------------------------
Martin Kalafut
------------------------------

Hi Martin,

Just wanted to be clear you would like to put a polyline starting at 74-83 and then have just linework that goes from 83 to 76, 82 to 77, 81 to 78 while only using Trimble Access and not processing through Trimble Business Center? Thanks....

Hello Ian,

thank you for your considering about my problem.

However, I think your approach is usable only in such cases, when only a few parking lots come into account.

Here is why:

A)

Imagine that there are many hundreds of parking lots (in my case, more than 1000 in front of a big mall).

To code the dividing lines (between parking lots) with the codes LI1, LI2, LI3, ... etc is not practically feasible. 

B)

I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.

C)

I am afraid, when connecting the line between the codes LI (points 75 and 79), it will NOT run exactly through the points  76, 77, 78

since they have different codes in your example.

So, the approach suggested by Nick is quite elegant alternative (as an emergency solution is mine, described in my reply to Nick which involves the use of TBC).

So, as a summary I can conclude as follows:

• the problem described in my very first email in this communication should answer either TA development or FDM development or both
• evidently, there is a difference (different logic) when processing line control codes between TA and TBC when using the IGN (IGNORE) line control code where TBC handles it correctly, while TA not

As I already stated in my previous email, I need to OMIT the use of TBC in this process (just do the line code work in TA, then export the coded data to SHP format from TA and send the exported SHP data by email from the field).

At this point, I cannot believe that TA will process the field coded data correctly (when I will use the IGNORE line control code), so I have to use TBC as a control tool. 

I believe that the coding problem is in TA software.

Martin

------------------------------
Martin Kalafut

Original Message:
Sent: 11-28-2023 09:13
From: ian bissonnette
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library

i think this is one way how to do it. might take a bit of planning or going back into the codes to fix them up. but it only uses one line code multiple times and the close comand. 

Robert,

could you publish how? Thanks.

Martin

I can only comment that it seems the line coding can be done a bit simpler than you are doing it.  Without needing to recall point names or ignore codes, etc.

Hello,

I encountered a strange thing (problem) regarding the use of the same FXL library used in TBC and TA.

I created a FXL library using latest Feature Definition Manager (FDM):

Here is an overview of the used codes in the FXL library and displayed in the pictures below:

PP - polygon feature definition (code) for an area feature (parking area as a whole)

LI - line feature definition (code) for a line dividing parking lots each other

ST - line control code for the start of a line joining sequence 

IGN - ignores any joining operation

JTSP - joins to specified point name

In TA the coded line work looks as follows (it is NOT as expected, it is wrong):

I downloaded the TA JXL file into a TBC project, where I processed the feature codes and the results looks like this (this is as expected, this is correct)   

When I remove the control code IGN from the points 81, 82 and 83 in TA 2023.10, then TA joins

the point 81 with 78, 82 with 77 and 83 with 76 (creates the required lines between them),

however, when I process it in TBC (with removed IGN control code on points 81, 82 and 83), although even TBC also creates

the required lines, there (in TBC) is also created a whole undesirable line between the points 78-81-82-83-76 (see picture below):

The line overlaps polygon line in the section between points 81-82-83 and is absolutely undesirable,

although the logic in TBC is OK when it creates this undesirable line taking the coding without IGN line control code into account.

Where is the problem in Trimble Access 2023.10 logic that performs NO required joining between the points pairs 81-78, 82-77 and 83-76

when using IGN control code as described above?

Martin Kalafut

------------------------------
Martin Kalafut
------------------------------