State Plane Zones in Emlid Flow?

Based on a recommendation I read in this community, I decided to put a point down using OPUS and see if I can replicate nearby city monument coordinates. I performed 3 base observations over a few weeks, 8/6/5 hours, to see how they performed and they are all within 12 millimeters of each other horizontally.

I then placed my base over the same point I took observations from, averaged the three points and entered those coordinates as my base. I went to 3 monuments our city has placed out, configured Emlid Flow to transform to NAD83(2011) / Texas North Central ftUS + NAVD88 ftUS (EPSG 6584 + EPSG 6360.)

I am off almost the exact same distance, in the exact same directions at each monument, both Northings and Eastings. 3.47 feet E as an example.

Is there a different coordinate system I should choose in Emlid Flow than EPSG 6584?

Or is their data off and I picked a dandy 1st project? They list: NAD83/NAVD88 as the coordinate system. Texas North Central (4202).

Northing: 7098857.211
Easting: 2528659.057

Lat: 33 07 47.76134
Lon: 96 40 14.21816

Converting state plane to Lat/Long and vice versa on Earthpoint and via NCAT, I can’t get the coordinates they are listing for this monument to reconcile. NCAT and Earthpoint agree when I use the monument Lat/Lon - they both produce the same Eastings and Northings.

I am probably answering my own question, but is there something I am missing, like the use of combined scale factor? When presented with Texas North Central 4202, that doesn’t have an EPSG code from what I can tell, what adjustments should I make, if any, when configuring Emlid Flow?

Thank you for participating in my struggle to learn accuracy!

The 4202 is a FIPS code based an ESRI projection on NAD27 datum so it’s not surprising it doesn’t fit. You could do a base shift?

1 Like

I have not looked and I’ll take your work on the ESRI FIPS code and the NAD27 relation, but 4202 here is the NGS assigned number for Texas North Central NAD83 State Plane Coordinate System.

We see the same thing here in Central zone with 4203. Some surveyors use it and some surveyors use the standard EPSG code but they are not the same.

1 Like

I see your dilemma with the lat/long coordinates not matching the state plane coordinates listed when converting between them with normal geodetic software. I even tried looking to see if they applied the DOT scale conversion for Collin County, but that didn’t work either. I’m not sure what is going on there.

What happens if you do an OPUS on one of the city marks? Do you get the same values the city has listed?

Or set your base up on a one of the city marks using there numbers or as MichaelL suggested: use a base shift, and then and tie into other city marks? Does the city at least check relative to itself?

Wish I could have been more help… Best of Luck!

What about the datasheets for the points you’re verifying ?

Can you upload so we can actually see what the city cords are in ?

Are they in the NGS database ?

I found this and it appears to be the same coordinate the OP posted:
https://www.cityofallen.org/1050/Geodetic-Monumentation

Click on Monument #5 in the above link to see the datasheet. I also checked the NGS website for their control monument and Shared Opus and found no monuments that are shared between agencies. It looks the monument is purely a city control point - best I can tell.

2 Likes

@michaelL , that is what I suspected with values being off by a precise amount. I’ll try the base shift when the weather improves to see what it renders. Won’t that data still be off since we’re working in different coordinate systems?

@snillor999 , an OPUS observation is something I may try after the base shift. These locations aren’t great for setting up a tripod and taking long observations.

@EBE111057 , the link above is correct. Monument 5 is the one in question. NGS seems like a goose chase around me. I need to find a set of monuments to validate my processes - any thoughts on the best way to do that?

I see in QGIS the ESRI IDs, there are 6 of them listed for FIPS (Federal Information Processing Standards) 4202. I am guessing a surveyor would plug one in to ESRI ArcGIS and transform the data I came up with in EPSG 6584 to the appropriate projection, but so far, after importing both data sets I don’t get the points to do that in QGIS.

For some reason I can’t access the points, I’m on my mobile so that could be the case .

I’ll check on my W machine when I get back in office.

One thing you might ask yourself, did the city actually create the passive control , did a government agency (state Geodetic Survey) or was it contracted by a surveying firm… How was it established ? By GNSS or by standard terrestrial traverse.

We’ve been in this situation before, city wanted additional control for photogrammetry and provided us with their control marks information.

The control was established by terrestrial traverse methods down through the years… on NAD27. They wanted all additional control referenced to their system. We told them in our proposal NAD83/NAVD88.
We ended up re-surveying all their control in addition to the new control. The old city control was pretty accurate considering the old methodology.

Only if there is a scale factor. Otherwise everything should be in relative accuracy to the base.

Use NGS Data Explorer

It appears there’s not much new GNSS control, looks like a few old classical triangulation stations, they may still be there to verify your cords. Looks like there’s a lot of “leveling line” of vertical stations nearby. But you’ll have to look at the data to make sure they’re in NAD83/NAVD88 or whatever system you decide to use. They are the “black dots” see legend on website, click stations to view data sheets. Most of the passive leveling stations don’t have accurate horizontal positions.

It looks like the city data isn’t in NGS database

2 Likes

Hi Jeff,

Reading throughout this thread, I assumed that the base shift indeed looked the most suitable option to adjust your coordinates and check these benchmarks. Just in case, this guide may help you learn how to do that.

Furthermore, I’ve researched a bit and have found that this FIPS 4202 refers to ESRI:102738 system, which is deprecated. It’s also not supported by Emlid Flow, so we’ll go back once again to the base shift.

Haven’t you tried this feature yet?

1 Like

The issue seems to stem from an XY datum shift. I am guessing Nad83 (1986 original realization) versus NAD83 (2011) Epoch 2010.00. See this example of Texas North Zone (4201): NAD83 / Texas North (ftUS) - EPSG:2275 which is the original Nad83 and NAD83(2011) / Texas North (ftUS) - EPSG:6582, which is the 2011 realization in USFT. The datum shift would be a bit over a meter. You would want EPSG code 6582 versus 2275. They are both FIPS code 4201 but different realizations of Nad 83.