I was wondering if anyone was having trouble enabling NAVD88 (Geoid 18) for the vertical datum when the coordinate system “NAD83(2011) / Florida East (ftUS)”.
The only vertical datum options offered in the flow app for this coordinate system are those shown in the screenshot below.
I’ve seen some other posts on this forum “claiming” that the option in the flow app titled “NAVD88 height (ftUS)” is the Geoid 18 option (the current geoid for NAD83 CONUS).
However, when I select “NAVD88 height (ftUS)” as the VD option, the flow app prompts me to download the us_noaa_g2012bu0.tif file, which I believe is the Geoid 12B raster, that is not the Geoid 18 raster.
Then there is another NAVD88(Geoid12B) height (ftUS), which likewise prompts you to download us_noaa_g2012bu0.tif, the same raster as the aforementioned.
The geoid 18 raster should be the us_noaa_g2018u0.tif file, should it not?
I am not an expert in this stuff, but if Emlid or someone else could assist me in pointing out how to enable the NAVD88 datum with geoid 18, while using the CS “NAD83(2011) / Florida East (ftUS)”, I would appreciate it.
Maybe the code in the app needs to be updated to download the geoid 18 raster, or maybe I am just wrong.
I’m just demoing Emlid rovers, so this is new for me but do a search for Florida East in the list and you’ll see a few. The one that says USA EPSG: 6437 will let you pick Geiod 18. I am in Fl West and have the same issue. Availability of Vertical datum depends on picking the correct horizontal.
I’ve seen 6360 in every other app, but those usually give me the option to choose the geoid as well. I was just showing what Emlid Flow presents as options after choosing one of the available Florida coordinate systems. If 5703 is only for Mexico, why is it an available option, and why is the tif US_NOAA_G2018U0?
Thanks Michael. I agree with you EPSG 6360 is GEIOD18.
When I select EPSG 6360 in the flow app, the below screenshot shows the TIF raster the flow app is prompting me to download upon the initial selection of EPSG 6360.
My question is, is this TIF image it prompting me to download for EPSG 6360 the correct raster for GEOID18?
I would have thought that the app would prompt me to download us_noaa_g2018u0.tif for GEOID 18, not the “us_noaa_g2012bu0.tif” (GEOID12B), as is shown in the screen shot below.
If I am wrong about the rasters images let me know.
Is there anyway EMLID could confirm is the geoid raster being used for EPSG 6360 in the flow app is the correct raster as of this date and time on 8/20/2024 1:30 PM EST ?
Thanks Scott. I believe EPSG 6437 has a unit of measurement in meters.
I would really like to stay in survey feet with EPSG 6438. All I would like EMLID to do is ensure that the tif raster image that Flow prompts the user to download upon initializing the VD for NAVD 88 is geoid 18 tif, and not the geoid 12b tif.
Geoid 18 supposedly should give us more accurate orthometric height calculations with RTK NTRIP via FDOT’s base station network.
Not that geoid12b is way off or something, used it for years, but the experts at NOAA have given us geoid 18 so I would like to use it in Flow.
I would also love if EMLID could allow us to upload custom geoid files like the FDOT’s allegedly better version of geoid 18 for Florida, which is a .bin file.
Not a surveyor (I’m an engineer), so all of this ESPG/geoid stuff is new to me from getting into drone photogrammetry. I work in CEI piloting rovers for FDOT construction projects. From what I’ve seen, using the metric EPGS hasn’t had an effect, the software does the conversion, though that could be incorrect, just my observation. I’m in Florida West which is 6442 metric / 6443 survey ft.
I discussed this with the developers. This specific horizontal CS, NAD83(2011) / Florida East (ftUS) (EPSG:6438), is from our legacy registry. And when you chose NADV88 height (ftUS) (EPSG:6360), you were prompted to download us_noaa_g2012bu0.tif.
And I agree that this can be quite misleading to everybody. But what happens is that even though we show that the download of us_noaa_g2012bu0.tif, all the other geoids are downloaded as well, including the one you need, us_noaa_g2018u0.tif. So, under the hood, we’ll still use the newest which is geoid18.
On the other hand, the new registry has the metric version of NAD83(2011) / Florida East (EPSG:6437), then the list of available geoids will be like this:
Yes, this definitely leads to uncertainty and guessing. We have NO idea what is going on under the hood.
But at least Emlid added the choice of setting units in case a meter geoid showed the correct latest version which i did notice. Would be nice to be able to plug in your own downloaded geoids like FieldGenius allows that way no confusion.
I understand that this can indeed be confusing. This only happens when you choose a CS from the legacy registry. The new registry doesn’t have a CS in USft, so I advise using the metric ones and then just setting the project units to meters, which should be less confusing.
Would be nice to be able to plug in your own downloaded geoids like FieldGenius allows that way no confusion.
We’re collecting such cases for consideration, and I’ll add yours and Mike’s as +2.
I ended up at running the metric version of our datum but set the project units to feet and it worked fine. They assured me 5703 and 6360 are identical. It was cool to get to do some actual Surveying and localize to the Surveyors control network before flight but boy was it hot!
