Latest Contributions by JoelCusick

This would be an excellent enhancement.   ... View more

mfarfad, Did you solve this, or get assistance?  I get this occassionally, with features with exact same geometries, same time stamp from GNSS stored in the feature service.   I would think, if the first second you press a button "seals" the time of storage, and inputting, say a project input, photo, you have stored a unique feature on device.   I use AutoSend OFF, and return to the office from the field and when in WIFI, Submit my features.   This process should never duplicate positions.    This issue may be because you are set to autosend on, but to have duplicate geometries, same time stamp, I am also stumped. My tests using Android v. 13, Samsung Tab3, Trimble R1/R12i with mock location on, NTRIP connection via TMM (latest version) and Internal provider set in QC. ... View more

Segmenting line features in FM would be huge.  Yes, Terrasync can do this with two taps (option/segment).  It would make sense if QC could do this too, as mentioned, carrying forward into the next segment previous attribution, allowing change on one or more.   Couldn't this be simple, building into the interface, knowledge in FM that its a line, and provide a segment button (not sync).  Fundamental to GIS linework is changes at vertices and no better way to directly observe changes when mapping in the field (Field Maps) right? ... View more

Colin, correct me if I'm wrong, but the basic premise is Field Maps must have a basemap in order for any data collection to occur in the field, with or without realtime access to a NTRIP stream.  NTRIP is second-by-second realtime positions being stored in the map.   Intermittent cellular broadband connectivity is the achilles heel in field collection.  Therefore, going into the field without an offline map ahead of time and losing NTRIP also means losing the map.  Data collection ceases.  Going into the field with an offline map allows Greg to continue to store positions offline (but without the precision of NTRIP, and the resultant storage of positions in two different datums...an issue that can only be corrected in a post-process environment).  No offline map = No data being collected when internet in the field breaks down. ... View more

Like PhilippNagel1, we also work across large geographic regions, and depending on the locality have either WAAS (SBAS) augmentation with submeter, but obviously in ITRF2014, while in other locations, Single Base RTK solutions based on NAD83 2011 (epoch 2010) solutions.   Hence this datum switch is now, maintained on each device by each user creating two location profiles, both of which are of course dependent on the map coordinate system (which can come in two "types" - WGS84 and NAD83 (2011).  Right there we have a 4-way permutation, rife with errors for field personnel.   So, controlling at least a portion of the location profile (incoming datum stream) is crucial, and could eliminate the number one error in mobile GIS - Datum mismatch. ... View more

May I suggest the ultimate way to solve this dilemma.  Its called Whack a Mole.  Unless you occupy survey control,that is in the datum of which you seek to be tied too, you will chase this till the cows come home.   Surveyors, the expert measurement experts will tell a GIS guy/gal - to Check in.  This means to see how close your system, software, incoming augmentation and all the datum gates in Pro/ArcGIS/Map/FS/Location Profile/Quality of GPS take into effect have on becoming "accurate".   Check into a Control point using a nearby benchmark using OPUS shared (google) or NGS Explorer (google). Find a point that is reporting its coordinates in, I'm guessing with your situation as NAD83 (2011). Setup on that point with your system, do what you think is best and see how close you get too that point using best practices. Look up the specs of the device.  If it says 20cm, subfoot, you should get there. If your not, then one of the datum gates you selected is wrong.  Or more. Good Luck. ... View more

Kyle, Okay - You have got me hooked. You state in original thread (last sentence of first paragraph). "All of my GIS map documents and data are in NAD83(1986)." What is the source of these original map documents and data.  Lets start there.  Deployment of modern GPS receivers, bound to latest reference frame of WGS84, when selecting "correct realtime" in PFO means you are assuming latest reference frame which starts the game of shifts.  Lets start over.  What is your data really "in" that you need to get back too. Thanks, Joel ... View more

Kyle, Your not kidding it gets thick.  Frances gives the guidance, while I'll take a stab at your original workflow, ie., using a Geo7x and Post Processing against a CORS station.  This is my expertise and have what I think is a workflow that won't get you to 1986 (original NAD83), but holding a CORS published position through a workflow when collecting a position with that bomber system you have. Assumptions:  You are using TerraSync.   You are using either Trimble Pathfinder office 5.4 or higher.  Ideally, today, your using both TS and PFO at the 5.86/5.85 or 5.9 version.  This ensures the differential correction wizard is optimized.   Finally, you are using a CORS station, not a UNAVCO or local base station.   Okay, Step 3 above has to be explained further, and I'll take an opposite tact, that holding "NAD83" is paramont to getting data into NAD83 (and the highest form).   I worked with Trimble years ago on this issue of the "Use reference position from base provider" vs "Use reference position from base files".  Trimble has not corrected this error and continues to propogate a NON published position, hindcasting to a version of non-NAD83 that, when converting to NAD83 from that version is going to be wrong.  This has to be understood that the former "provider" is NOT the published position of a CORS station, but a calculated shift that frankly should never be used and was intended by Trimble to be a stop gap shifter when in 2002, CORS96 datum moved to a new reference frame.   NGS would state - always use the published position for a CORS.  I agree, and hence, when using that Geo7x, the best thing you can do (the right thing) is to use the modern, published position of that ARP for that antenna certified by NGS.  That position is what differential correction means to "hold" the CORS and calculate your rover "difference" from the coordinates you stored in TerraSync and what the CORS stored and differentially held during that same epoch at the base.  You should always use the latter "Use reference position from Base File".  Today, that is NAD83 (2011) epoch 2010.  You get that coordinate from the seeded RINEX file that CORS so elegantly stores in all the RINEX header of the zip file you are retrieving from CORS.  Run the PFO wizard, stalling at the confirmation step, and call up the CORS station, Position and Velocity page, and open the ARP coordiantes for that station. Scroll to NAD83 (2011) and compare the coordinates in the confirmation box and CORS  YOu will see nearly exact coordinates.  (Any difference is usually out to the 5th decimal seconds, way under the resolution of your gps).  Proceed thru differential, and today, your COR file is now "In" NAD83 (2011) Epoch 2010.0.   By doing this, you skip around what Frances says your in "1997".  Your COR file is now at today's epoch (the day you collected the data) and are now holding NAD83 (2011) at Epoch 2010.  You do have 9 years between your time of collection, but that is the premise of NAD83 (holding at an epoch). I know, this doesn't get you to NAD83 (1986), but you have to exclusively use "Use reference position from base file" to use the Published coordinate of a CORS.  That is the key to start putting GPS data collected today into the most current form of NAD83.  This is a serious Datum Gate many users are skipping by, and Trimble has not corrected this naming convention and shifting what you should be doing.  Since this issue started in 2002, we are now 2 reference frames past that construct, and, now in ITRF14.  Here is a link to the coordinates for a CORS in AK.  Do this for your CORS you are using.  YOu don't see ITRF97 do you?? https://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=tsea&option=Coordinates Once you do these steps, then Use HTDP tool.  I would take the top choice, hindcasting your coordinate back to 1986.  This would be as close to assigning a "plain vanilla" NAD83.  Then, shift that coordinate from NAD83 to WGS84 using a bookeeping Molendensky transform like WGS_1984_To_NAD_1983_1.   Joel ... View more

Hi Keith, Bookkeeping transformations (ones with null values for parameters) are used quite often. We did not have HARN up here, but for states with HARN, there is extra pain involved.  From doing this type of work your doing, here are some suggestions after being in the trenches so often its hard to count. 1) Ignore accuracies (the way ESRI puts a transformation on top.  Often, concatenated transforms are put on top, and I try to tell people to NOT do double transforms unless you have thoroughly solved one at a time.  keep to single transforms, and carefully jump from one to another.  Its insanely complex when combining transforms in one step.   1a) Get comfortable with the Data Frame shifts on fly and effect with data assigned diff. projections.  That can really sting when your shifting data say in ArcCatalog, and the dataframe is shifting too. 2) Get onto a survey control (modern NAD83 (2011).  Conduct tests - if your using GPS - on a BULLSEYE, because eventually once you figure out what is "moving", your going to have the real question... Which one do I use.   Finally, find a surveyor near you who knows all about HARN.  He/she will have sage advice.  Your down in the weeds man, where GIS is just mapping, what Surveyors would call "guessing".   Joel ... View more

I fear to tread on this topic, but its my understanding from sitting in so many NGS presentations on this topic, the phrase above :"geoid12b should be used with NAD83 (2011)" should be better written as "geoid12b must be used with NAD83 (2011)".  The Datum Tag and Epoch of NAD83 2011 (Epoch 2010.0) is tied too the Orthometric H using Geoid12A/12B.  I'm not a surveyor, but I heard these two MUST be associated with each other.  That is, of course if the data stored in this table was derived from say an OPUS solution, or post Processed with or RTN streamed from a service bound to NAD83 (2011).  Again, not a surveyor,  nor am I a geodesist. I'm merely a biologist by training who tries to tie all my federal data to NSRF. Joel ... View more

John, I'm pretty familiar with PFO/TBC and have both down cold depending on what you want your final export to be "in".  Then there is the issue of what is your input datum, and how you are correcting the data.  Your screen shots from PFO are absolutely correct.  TBC also has the same exact ones.  But, and I'll emphasize again is there is no way around testing on control set to the output you want to be "in".  I've trained hundreds, and every student by the 3rd day doesn't get "it" until they plop their data onto a point in ArcMap and they are 1.5 meters away, while the other students are 10cm away. Your getting bit by thee most common confusion in GIS today.  Thank god we got Melita, but you can imagine her inbox from all over the world.  Your original question is very specific to handling in TBC, PFO.   So, I don't even want to guess why you want to be in "WGS84".  If your in State Plane, your an obvious US citizen, so most common is you want to be in NAD83, and since your using top dollar GPS devices, you most specifically want to be "in" NAD83 (2011) Epoch 2010.0.  Thats what you get when you run OPUS or PFO with a CORS base station and you use the reference from Base file.  You have with each software, 2 datum gates you must pass thru, and thirdly ask what you are setting in ArcMap.  So that is a 3x3 matrix or 9 possible combinations.  You can't do this correctly without TRUTH.  You must calibrate your GPS work, and Accuracy means doing the right thing with datum.  You can't evaluate Accuracy without comparing to TRUTH, and its so darn easy these days to set a nail, occupy with a GPS running 2 hours and comparing. Oh, and your last comment on KMZ production.  Nothing in Google Earth ever is to be trusted.  I wouldn't export data from 2,000$ software just to be compliant with GE.  Export to NAD83 (2011) and let others suffer with any supposed shifts in GE.  Just some thoughts. Joel ... View more

May I make a suggestion for times like these.  Much like our tidal flats up here in Alaska, the more you struggle the deeper you get sucked into a place that is very hard to climb out of.   Here is the way out.  Occupy a high quality survey control. You mentioned TBC - you likely have survey grade GPS so, drop a nail outside your door, occupy for 2 or 4 hours, run OPUS and when you have that sheet, occupy the same point with any GPS.  In ArcGIS, start a fresh dataframe in your reference frame.  Add to that frame an unadulterated coordinate from OPUS( you have lat/long in both reference frames and utm/state plane in NAD83 (2011). Then drop your exported data into that frame.  Quietly test your on-the-fly transformations.  You will know very quickly what is biting you and what is not.   Joel ... View more

Henry, May I chime in on the first layer of the onion that I see in this original question.  I'm experienced in Trimble workflows including Pathfinder Office and have fought my way out of the datum tidal flats more than i can mention.  So, if its not too late, or too far back, I have two comments on the precise terms you use when you wrote what your doing in PFO. If PFO output (the shapefiles you mention are considered "truth"), then I have a suggestion to do the right thing when it comes to "holding" a CORS solution. Then, when you get your PFO shapefile, you know you did everything you could prior to the loading into arcGIS.   True accuracy is assessed only when you occupy truth better than your system.  That is a modern OPUS observed benchmark.  Try to find one nearby using NGS explorer or OPUS shared solutions.  you'll see the NAD83 2011 coordinate (assume you are trying to "get there" is posted.  Thats truth. second level of truth is your Correction settings.  At PFO v. 5.2, pick the closest CORS station.  Next, when stepping thru the wizard your two radio button choices in the Diff Wizard will allow you to either "hold what Trimble has produced - thats the "Use position from base provider" or "Use position from base files".  The former is NOT a published CORS coordinate, and I never use.  The second option "base files" is the actual NAD83 (2011) coordinate for the Rinex file embedded by NGS.  Use that option at all times. Then, that COR file at the conclusion of Differential correction is in NAD83 (2011).  On export, you do not shift. You use a Trimble "bookkeeping" shifter (NAD83 (CONUS) which does nothing.  Define your shapefile with the correct PRJ (provided by ESRI with the datum tag 2011 and your exported shape is in the highest quality form.  I never use ESRI to shift data coming from PFO. Why?  Because you can harvest data directly from CORS published position  - thats the best approach in my view.   So, this is going to have different results (likely about 90cm) depending on where you are in your world, relative to the WGS84 output you were exporting before, but your ready to load with no shifting in GIS. Good luck. Hope this helped, or thoroughly confused you.  Just know, Trimble has a mistake in the CBS list which is often overlooked and one path down PFO will lead you to holding NOT the IGS08 position for a CORS, but in reality, ITRF00 (1997) position. ... View more

Hi Melita, Could we start a new Thread on 10.5 forward with Vertical?  There isn't clear directions (maybe i'm just dumb) on 10.5 Desktop / 10.6 Desktop and ArcGIS Pro on what the Coordinate system package does.  Its just a minor thing, but I'm reading the extra install package is only vertical related, providing transformation capacity.  So, even the name "ArcGIS Coordinate Systems Data is not precise.  Should this be renamed "ArcGIS Vertical Coordinate Systems Package" or something like that. In any case, were getting a bit lost, or can you direct to a place in support that specifically speaks to what the package does, how to install, etc. thanks. joel ... View more

Melita - I heard your scream from up here!   Intersection between CAD and GIS will continue to mature regardless of how things were done in the past.  The author missed the GNSS(RTK) solution that has been sitting between AEC and GIS for years, allowing us to actually live on GRID and GROUND in the field.  Geodesy inside ESRI is our friend here, not our enemy. Joel ... View more