Points list

Adam

Well-Known Member
5PLS
I have never used Carlson's f2f but I think understand what you are trying to do now. What if you were to set your point names to ea1, ea2 etc.? Then you could use this export format:

Name
N
E
H
Name

If you set the point name to ea1, ea2 automatically becomes the next default point name.

Say for instance I were locating the center of creek, I would identify this as ck1. I would not want it to change the number automatically. I would change it to ck2 when I came to another creek. I use point numbers traceable to the operator, example Ap1 is my initials plus a number. My employees use their initials so point numbers do not get accidentally used twice by different people. I don't think that would help me Matt, thanks though. Currently I am using description because I can type in ck1 for example. The drawback is a lot of jfield features are code oriented. I have used the code and description both for a while but got tired of punching in the same thing twice.
 

Matt Johnson

Well-Known Member
5PLS
Ok I understand. It should be pretty simple to add a "none" delimiter in the J-Field export options and that would solve your problem like you said. I'll see if that can be done.
 

Shawn Billings

Shawn Billings
5PLS
I've been thinking about this, since this morning's conference call.

I believe that Codes would be the best way for Adam to simulate Carlson. My thought is this. Build a code in J-Field for each Carlson field to finish action code.

Here I've made a Code, called ea. I've set up two attributes for this code: Line Number and Action. Line Number will be attached to the Code to produce the Carlson field-to-finish action code ea1 (in this example). During collection, you can change this attribute to 2, 3, 4, etc. which will produce ea2, ea3, ea4. This will require a slight change to our exporting which I'll describe in more detail in a moment. The action will also export. In this example I've set up action code "PC" which will begin a curve in Carlson field-to-finish. This Action could be any action you might desire (PT, CLO, JPN, JOG, etc.) Once you enter the action item in the attribute, the attribute library stores this item until you delete it from the library. So you don't have to type any of them more than once. Once you type it in, you can just recall it from the attribute selection screen. This should prove to be very fast. Pick the code from your code list, pick the line number from the Line Number attribute list, pick an action from the Action attribute list. If you don't want an Action, select <EMPTY> from the Action attribute list.

00341_Code_Attributes_20151111-15.24.31.png



On the Collect Action screen, setup white boxes for Code (see box "ea") and Attributes (see box 1, PC). Also setup white box for description. In this case the description can be used for text entry to further describe the point being collected (if necessary). Notice I have prefaced the Description with a "/". The default nature of this character prevents text to the right from being processed in Field to Finish.

00341_3_COLLECT_20151111-15.21.47.png



At Export, I would have my .txt set up to export as follows:

00341_Export_File_Format_20151111-15.22.25.png


The export will need one addition, a Separator 3. A point exported with the above Code (ea) and Attributes (1, PC) would export like this:
L042,5000.0000000000,5000.0000000000,100.0000000000,ea 1 PC /Desc

This almost produces the desired result, except that we don't want the space between "ea" and "1". We do need the comma delimiter, and we do need the space delimiter, but we need a third delimiter, None, between the Code and Attribute 1, which in my example is the line number, which would produce "ea1". This would result in an export of:

L042,5000.0000000000,5000.0000000000,100.0000000000,ea1 PC /Desc

I still maintain that the J-Field line work using Tags and Codes is more efficient than Carlson's Field to Finish, but I understand the desire to maintain consistency across platforms. It's possible that you could still use J-Field's line work with Tags and Codes and still use this scheme to work with Carlson. Adam, what do you think?
 

Jim Frame

Well-Known Member
Not to discourage innovative solutions, but what's wrong with putting the F2F codes in the description as we've always done?
 

Shawn Billings

Shawn Billings
5PLS
I'm not settled that what I've outlined is the best solution. Just rolling it around. The problem with the description field is that, outside of our memory cells, there isn't much automation that can be done to insure consistent coding. By creating codes in J-Field and then selecting the code from the code list, there is no chance of inadvertently mis-typing something (ae instead of ea). Also, with attributes, you can have a lot of predefined action codes ready to select for the same reason. No need to type "RECT", it can just be snagged from the attribute library. Otherwise, you'll need to manually type them in the description field as well.

The other possibility is to build a description library that stores words that are typed in a dictionary that can be auto-completed. But I think that may not be as efficient in the case of F2F codes as simply grabbing the appropriate code from a list. What do you think Jim? How would you like to see the description field in J-Field used for F2F? Would you make any changes?
 

Adam

Well-Known Member
5PLS
I've been thinking about this, since this morning's conference call.

I believe that Codes would be the best way for Adam to simulate Carlson. My thought is this. Build a code in J-Field for each Carlson field to finish action code.

Here I've made a Code, called ea. I've set up two attributes for this code: Line Number and Action. Line Number will be attached to the Code to produce the Carlson field-to-finish action code ea1 (in this example). During collection, you can change this attribute to 2, 3, 4, etc. which will produce ea2, ea3, ea4. This will require a slight change to our exporting which I'll describe in more detail in a moment. The action will also export. In this example I've set up action code "PC" which will begin a curve in Carlson field-to-finish. This Action could be any action you might desire (PT, CLO, JPN, JOG, etc.) Once you enter the action item in the attribute, the attribute library stores this item until you delete it from the library. So you don't have to type any of them more than once. Once you type it in, you can just recall it from the attribute selection screen. This should prove to be very fast. Pick the code from your code list, pick the line number from the Line Number attribute list, pick an action from the Action attribute list. If you don't want an Action, select <EMPTY> from the Action attribute list.

View attachment 3429


On the Collect Action screen, setup white boxes for Code (see box "ea") and Attributes (see box 1, PC). Also setup white box for description. In this case the description can be used for text entry to further describe the point being collected (if necessary). Notice I have prefaced the Description with a "/". The default nature of this character prevents text to the right from being processed in Field to Finish.

View attachment 3430


At Export, I would have my .txt set up to export as follows:

View attachment 3431

The export will need one addition, a Separator 3. A point exported with the above Code (ea) and Attributes (1, PC) would export like this:
L042,5000.0000000000,5000.0000000000,100.0000000000,ea 1 PC /Desc

This almost produces the desired result, except that we don't want the space between "ea" and "1". We do need the comma delimiter, and we do need the space delimiter, but we need a third delimiter, None, between the Code and Attribute 1, which in my example is the line number, which would produce "ea1". This would result in an export of:

L042,5000.0000000000,5000.0000000000,100.0000000000,ea1 PC /Desc

I still maintain that the J-Field line work using Tags and Codes is more efficient than Carlson's Field to Finish, but I understand the desire to maintain consistency across platforms. It's possible that you could still use J-Field's line work with Tags and Codes and still use this scheme to work with Carlson. Adam, what do you think?

Thanks for working on this Shawn. I think that using codes would work okay if I could edit the code without it saving it as a new code and without leaving the action screen. I agree with Jim.
 

Adam

Well-Known Member
5PLS
It not a big deal to me about the action codes , pc, pt etc. These are easy enough to punch oin and I have truncated a lot of them to single letter e=end, b=beg, etc.
 

Adam

Well-Known Member
5PLS
II think being able to edit the code once it is selected would be the easiest on the user. Maybe press and hold to recall the code list and tap once to edit it?
 

Adam

Well-Known Member
5PLS
I would put a number and action code ,if needed, with it. The code wouldnt get changed just additional info appended to it. By the way, Shawn I collect and draw everything in the field but have found that exporting a drawing from the field doesn't work because when the data gets adjusted the points move so your linework ends don't match up with the adjusted points. I completely redraw everything in the office software with f2f after the adjustment and then the linework mathes the points.
 

Matt Johnson

Well-Known Member
5PLS
I would put a number and action code ,if needed, with it. The code wouldnt get changed just additional info appended to it. By the way, Shawn I collect and draw everything in the field but have found that exporting a drawing from the field doesn't work because when the data gets adjusted the points move so your linework ends don't match up with the adjusted points. I completely redraw everything in the office software with f2f after the adjustment and then the linework mathes the points.

You would just need to export the dwg file again if you adjust the points. In J-Field the linework moves with the points.
 

Adam

Well-Known Member
5PLS
I am referring to a least squares adjustment in Survnet, where GPS data gets adjusted along with total station data. I wasn't referring to the adjustment the LS does with dpos.
 

Shawn Billings

Shawn Billings
5PLS
Yeah. That makes sense Adam. I can see that. Sometime I'd like to get you on RAMS and look at my LS and I will show you what I have in mind so that you can see it in action.
 

Adam

Well-Known Member
5PLS
I've been thinking about this, since this morning's conference call.

I believe that Codes would be the best way for Adam to simulate Carlson. My thought is this. Build a code in J-Field for each Carlson field to finish action code.

Here I've made a Code, called ea. I've set up two attributes for this code: Line Number and Action. Line Number will be attached to the Code to produce the Carlson field-to-finish action code ea1 (in this example). During collection, you can change this attribute to 2, 3, 4, etc. which will produce ea2, ea3, ea4. This will require a slight change to our exporting which I'll describe in more detail in a moment. The action will also export. In this example I've set up action code "PC" which will begin a curve in Carlson field-to-finish. This Action could be any action you might desire (PT, CLO, JPN, JOG, etc.) Once you enter the action item in the attribute, the attribute library stores this item until you delete it from the library. So you don't have to type any of them more than once. Once you type it in, you can just recall it from the attribute selection screen. This should prove to be very fast. Pick the code from your code list, pick the line number from the Line Number attribute list, pick an action from the Action attribute list. If you don't want an Action, select <EMPTY> from the Action attribute list.

View attachment 3429


On the Collect Action screen, setup white boxes for Code (see box "ea") and Attributes (see box 1, PC). Also setup white box for description. In this case the description can be used for text entry to further describe the point being collected (if necessary). Notice I have prefaced the Description with a "/". The default nature of this character prevents text to the right from being processed in Field to Finish.

View attachment 3430


At Export, I would have my .txt set up to export as follows:

View attachment 3431

The export will need one addition, a Separator 3. A point exported with the above Code (ea) and Attributes (1, PC) would export like this:
L042,5000.0000000000,5000.0000000000,100.0000000000,ea 1 PC /Desc

This almost produces the desired result, except that we don't want the space between "ea" and "1". We do need the comma delimiter, and we do need the space delimiter, but we need a third delimiter, None, between the Code and Attribute 1, which in my example is the line number, which would produce "ea1". This would result in an export of:

L042,5000.0000000000,5000.0000000000,100.0000000000,ea1 PC /Desc

I still maintain that the J-Field line work using Tags and Codes is more efficient than Carlson's Field to Finish, but I understand the desire to maintain consistency across platforms. It's possible that you could still use J-Field's line work with Tags and Codes and still use this scheme to work with Carlson. Adam, what do you think?

Shawn, one other thing that would be useful but isn't a must have, would be for the line number string to default to the first unused string for that specific code. This is handy on bigger jobs when where there is a lot of linestrings being used. Otherwise I think you would have to search the points list at the beginning of the day to see what was the last one used for each code.
 

Jim Frame

Well-Known Member
What do you think Jim? How would you like to see the description field in J-Field used for F2F? Would you make any changes?

My F2F experience is limited to SurvCE, where I use the description to encode the instructions (and I use F2F heavily). So far I haven't used the T-LS for description-intensive topo -- it's been mostly control, and the bits of topo I've done have mostly had repetitive descriptions, so I haven't had to think about a better way of doing things. I'm not making use of codes at all yet -- I couldn't even tell you how they differ from descriptions, that's how ignorant I am in that regard. In summary, I'm not the guy to ask about this! (At least not yet.)
 

Shawn Billings

Shawn Billings
5PLS
In the procedure I am thinking about, J-Field codes would not be different from description. The code and its attributes would export as the description. The codes would be used to shortcut manual entry by making selections from populated code/attribute libraries instead of manually typing the description.
 

Matt Johnson

Well-Known Member
5PLS
Ok I understand. It should be pretty simple to add a "none" delimiter in the J-Field export options and that would solve your problem like you said. I'll see if that can be done.

This has been added to the development version and will be available soon to try:

EXPORT-CSV-SEPARATOR_20151112-11.45.50.png
 
Top