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?
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
Many thanks Nick!
I will use it as you suggested. Basically, I had a solution for it, although it is NOT what I want. My solution was to use only LI code for line strings as follows:
So, I abandoned the polygon (area feature) code PP and used only line feature code (LI), where the CLO control code means CLOSE to the first point of the sequence.
It works as expected both in TA and TBC. The "problem" is that I have to perform some additional actions in TBC after Feature Code Processing, since by using my approach I get
only line strings (no polygons) and I need an area (polygon) as a result. It practically means I have to use the ANZ command Convert To Polygon,
after selecting the lines between points 74-75-76-77-78-79-80 -81-82-82-74 and this is also not desired (the additional work).
Basically, my idea is to omit TBC for this purpose and perform it in real time in TA only, then export the coded line work within TA to SHP with correct topology (no overlapping line/s)
and send the results by email from the field to the customer. Customer requires NO overlapping line/s.
So again - thank you!
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.
could you publish how? Thanks.
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.
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:
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.
I always try to keep the MEASURE CODE buttons defined in TA during RTK measurements in the field in a minimum count.
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:
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.
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?
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.