martin. you had a question about making measure code forms.
you can make them in the feature definition manager(new group) but it is not as intuitive as it could be because it is not in tiles. i have not tried in a bit and i thought i heard something about some improvements there. not sure.
also you can use the emulator on a pc to make them and then you would have to copy over some files. there was another thread talking about this and i have not done it. maybe it is just the config file that contains most of the access settings and shortcuts, but i remember something about an mcd file that might contain it. maybe someone else can help here.
pretty sure the easiest instrument to use on the emulator is the "manual" total station. this instrument is a default where you enter the angles and distances manually. so, likewise if you create a "manual" total station in your controller then fake a station setup then you can get to the measure codes screen.
for the trimble team i would like to point out that having the ability to do stuff like this and change regular settings of total stations and rtk without being hooked on an instrument would really help. often i think of changes i want to make, but because i am not in a survey i can not initiate these changes. a master settings page could solve these problems.
Original Message:
Sent: 11-30-2023 08:59
From: Martin Kalafut
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
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
------------------------------
Martin Kalafut
Original Message:
Sent: 11-30-2023 07:25
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
ya i have WL as a line code.
so you could use how i have it setup and have your first code be the polygon code and the second code be a line code. that would omit the 'close' control code that i have. i think. i was talking more about how the polyline would exist in cad or tbc when you use the join command. i will look at some point, i just forget at the moment if join creates a simple "line" or a continues the polyline in a T shape.
i'm not sure about your last question, do i use stringing codes functionality? do you mean line control codes? if so, then yes i use both line control codes and also use the line string identifiers ie WL1 WL2... to control lines. i think i used to be in your opinion and uses control codes more, but i have since learned the power of using strings. particularly when doing topo in cross sections when you want to run two strings of the same code(this is powerful). it is also way less walking if you walk in cross sections rather than always following your string. it means walking up a road once in a zig zag instead of maybe 10-12 times in strings. i hope this makes sense a bit, and i am following what you are asking. we also have clients that require a new string per line.
Original Message:
Sent: 11/30/2023 4:52:00 AM
From: Martin Kalafut
Subject: RE: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
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
------------------------------
Martin Kalafut
Original Message:
Sent: 11-29-2023 18:57
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
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.
Original Message:
Sent: 11/28/2023 5:43:00 PM
From: Martin Kalafut
Subject: RE: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
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.
------------------------------
ian bissonnette
Original Message:
Sent: 11-27-2023 11:00
From: Martin Kalafut
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
Robert,
could you publish how? Thanks.
Martin
------------------------------
Martin Kalafut
Original Message:
Sent: 11-27-2023 10:34
From: Robert Hoy
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
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.
------------------------------
Robert Hoy
Original Message:
Sent: 11-25-2023 14:33
From: Martin Kalafut
Subject: Different behaviour of coded line work in TBC v2023.10 and Trimble Access v2023.10 which use the SAME FXL library
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):
![](https://higherlogicdownload.s3.amazonaws.com/TRIMBLE/MessageImages/62674e38e2cc480994f125458bdff8cf.png)
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):
![](https://higherlogicdownload.s3.amazonaws.com/TRIMBLE/MessageImages/151cfaa44c404bc19e2b482d36f04d38.png)
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)
![](https://higherlogicdownload.s3.amazonaws.com/TRIMBLE/MessageImages/2c114b2d126f45f0848731b3720ee7db.png)
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):
![](https://higherlogicdownload.s3.amazonaws.com/TRIMBLE/MessageImages/d6aa00bb1b2b41c2aabd6ed4b4e6eda0.png)
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
------------------------------