US Survey Foot vs. International Foot Issue...Again

8804

Sorry...have to fire a shot off the bow here...
I have mentioned this to Adam in multiple conversations, but just wanted to reiterate the seriousness of this issue.
This is not an issue for many users...only six states use International foot...but for those of us bordering on states with two definitions of the foot...this is a HUGE issue.
I am in Charlotte NC and on a daily basis I work in NC (US Survey Foot) then at any given day I will switch to SC (International Foot)
In the current version of J-Field you can create a new project and specify units...this gives the impression that you are setting the units for the project...beware! Not so...
Units are set in the General Group - Advanced Settings

This is the scenario I just ran into this morning:
Worked in NC yesterday...going to SC today to do some LAYOUT on an ongoing project...
I open the SC project (originally setup in International Foot) and import some points...just as I was finishing the import I noticed the import units option and the red flag goes up...DANG I FORGOT AGAIN...
Sure enough...went to the edit project properties...it had reverted to US Survey foot...
I'm aware of how to set it correct...went to setup - general group edit - changed the units back...
Changing the units like this applies a scale to the points all the way from the origin of the system 0,0
On this particular site the shift was 4.59'
No Warning...it just straight up changes coordinates on all your design points...IF I WAS NOT CONSTANTLY WATCHING THIS...(INTRODUCE UNAWARE FIELD CREW)...THIS WOULD HAVE BEEN STAKED INCORRECTLY...EVEN THOUGH I CHANGE BACK THE UNITS.
I don't know anyone who would be OK with a 4.59' shift on any layout project.
This would never get caught...until that call from the contractor happens!

PROJECT UNITS MUST BE LINKED TO THE PROJECT...PERIOD!

I'm sold on Javad equipment for sure...BUT:
THIS EQUIPMENT WILL NEVER BE IN THE HANDS OF MY FIELD CREWS UNTIL THIS ISSUE IS 100% RESOLVED...
I need to be able to open a project...and the units be set across the board...it needs to be OUT of the general group settings...and maintained in the Project specific settings...
 
Ahhh...more issue...

So I just went to re-import those points for today...
Project settings and general group settings are set correctly to International foot.

I went to import the file and the units were still reverting to the last used setting of US Survey foot...
Teeny tiny "i" in the upper right hand corner of the screen...can equal 4.58' on the ground.

So that adds yet another level of being able to mess that up...
 

James Suttles

Active Member
Yep, If you work in NC and then go to SC, you got to be on your game, or you will miss that small setting in your settings. Too bad the units are not specific to the project, then once you set it, you can forget it.
 

Adam

Well-Known Member
5PLS
Personally, I think it should be tied to the coordinate system somehow. When the system is selected it would default to the foot used for that system. I don't know how much work that would take to implement. They added the option to select the units under project so users could see it but it is still applied globally.
 

Matt Johnson

Well-Known Member
5PLS
Changing the units like this applies a scale to the points all the way from the origin of the system 0,0
On this particular site the shift was 4.59'
No Warning...it just straight up changes coordinates on all your design points...
Design points are stored in the project’s database file with their native coordinate system and units as was selected when they were imported. Changing the coordinate system or units projects them from the native coordinate system to the current coordinate system.
 
I like Adam’s idea because it would work for local site coordinate systems also.

So if I am working in SC and create a scaled to ground system the units for the project are defined as you choose the “underlying coordinate system.”

You could change it if you wanted...There would always be an exception to the rule, But this would help for sure when opening and closing existing files.
 

Terry Becker

President
Simple rule works for us. Our office computers don't care international or us ft. But in the field always set collector to us survey ft. Regardless stay in one or the other for all crews.
 
Big red flag there brother...
That’s exactly how this can create those large busts on the ground.

Scenario:
I’m a Carlson user...I do a job in SC...for a NC based design engineering firm. If I have some Topo data all collected in US feet...cause it’s “all the same in the office”...then I do my mapping, surface, all the works. Cause I’m such a tech savvy surveyor I’ll share a land xml file with the engineer containing point and surface data...he’s stoked I’m stoked...on to design.
Enter EIT cad tech...he opens Civil 3D...starts his SC project and imports all my xml data. Then he notices a shift...no clue...silly surveyors they don’t know what they’re doing...so he slides all the line work over so he doesn’t have to figure out why the tin won’t line up...
DONE...4-5’ shift on the ground. This could cause a building in a setback...curb returns won’t lineup...loss of a parking space...you name it...I’ve seen the issue come up more with Civil 3D than with any other program.

I’ve coached design firms and construction companies through the correction of this issue. And it is equally spread between office software and field software.

My conclusion over the years is that units must be correct in every nook and cranny of the project or it can pop and cause grief.

Prior to being a Javad user I had templates set up for TBC in my office computer that would totally filter out this issue. You could collect data in any coordinate system and upon import it would say “do you want to use the data collected coordinate system” ...select NO and it’s back to 100% correct units for that system.
Since Javad I have shifted to Star*Net. Again I have templates that set the units. .ngs Gfile vector data are metric so the issue does have an “office” buffer to catch any bad data collected units.

Been working for years with my workflow to snuff this issue...now it’s back...and that’s the point of this thread.

Let’s bury the project units so they can be fixed by a template OR as Adam suggests set them to default to the units for the SPCS for each state according to their legislation. (For the ones that don’t specify...give em US survey feet...just cause this is America!)
 
Top