Wondering if there are plans to support the PROJ Local Orthographic projection in the custom projection settings? Looks promising to use for quickly setting up a ground-scaled projection for small site localization. My understanding is this also results in an ERSI compatible WKT for a 2D site calibration.
1 Like
Hi @summitbri,
Orthographic map projection is commonly known as the “view from space” projection, which is why it is more common to use it for inset and/or pictorial views of the Earth from space.
This map projection is also aphylactic, meaning neither conformal (angles are preserved) nor equal-area (area is preserved). This makes it unsuitable for surveying and navigation.
Could you please share with me where you found the info regarding the compatibility with ESRI WKTs?
1 Like
Sorry for the delay. The intent of this projection is for localized engineering surveys that take into account ground scaling.
Here’s the documentation links:
Orthographic — PROJ 9.5.0 documentation
This projection method corresponds to EPSG:9840 (or EPSG:1130 with k_0 or alpha ).
Also here’s an example for SFO airport:
EPSG:10622 NAD83(2011) / San Francisco SFO-B18 (ftUS) – Spatial Reference
Let me know your thoughts!
What is happening that a localization is not covering? Are your base coordinates not true? Is your GIS/CAD software not in, or close to the natural projection? Just trying to understand the use case.
1 Like
Many of the post-processing software packages requires a projection, either a prj string or epsg, to manipulate the points and vectors. Also would be nice to embed the prj in deliverables that are in arbitrary survey coordinates, but end customer wishes to pull them into GIS and they end up in the middle of the ocean.
I may not be understanding what your are trying to do but it sounds interesting. To me it sounds like the base Survey geographic data may have the arbitrary datum. The point of the localization is to apply a geographic value to a project/site grid point. This alleviates an arbitrary grid coordinate system issue but does not resolve an arbitrary “i’m here or uncorrected averaged” point. You should be able to extract surface data from those geographic observations and import them directly into and geospatial software. Then you just bring in the Emlid projected data and rectify it. As @ruth.bongon mentioned the projection is unsuitable for Surveying. IMO the data should be processed natively preserving its integrity & backup and then be transformed or rectified to the needs of the proceeding parts of the workflow. What GIS software is being used?
Correct, the base survey data is in arbitrary ground-scaled coordinates. And the survey data is being processed natively, then ‘backed into’ GIS. Many of the libraries such as GDAL and PDAL require an EPSG or a prj string. For example, to convert points in say a geopkg format to DXF uses a tool called org2ogr in GDAL. It doesn’t work without a projection.
Regarding the observations… For a local 5000,5000 system for example, is the recommended workflow to simply manually define a new transverse mercator projection, using the local combined scale factor, lat/lon of the local point of origin and 5000,5000 false easting and northing (assuming all are in meters)?
Ok, that makes sense then. Ideally you would have a point with a known LLH or corrections from an RTK network and then localize the arbitrary ground coordinates.
In flow you would select the CRS your base (wgs84/utm) or network (?) is providing corrections in or choose a Global CS, select the units you want your data to be measured by and your vertical datum or just leave it ellipsoid.
What level of global accuracy do you need? You may be able to define a base point using your GIS software and enter those coordinates to the base instead of doing a single average. I have had projects where they just wanted a close map that represented well in GIS or Google Earth so I just picked something I could define within 30cm and used those coordinates for my base. Or if you have an official benchmark within a reasonable distance you can setup your base there and traverse to the site.
This is something that has plagued construction in the US. Contractors have a bad habit of doing a single-average and some of the equipment just immediately grabs a geographic coordinate as soon as it initializes which could be 20ft off from a corrected coordinate. Then we get supplemental data or try to do drone work and have the same issues.
2 Likes
We almost always have the base on a known point, or if we not, we do a static observation with an OPUS solution, then PPK the other points. These points are usually state plane coordinates that then need to be manually scaled to ground. I guess this is the real question I’m seeking to answer: is there a way to simply enter a known scale factor into the rover and collect ground-scaled observations on site since we know the combined scale factor at the known point?
Where we are Land Surveying is done in grid and Engineers are always the ones to mess it up by scaling to surface. Unless you’re doing 5,000ac tracts or 10 mile roadways there’s no reason to use surface coordinates for construction but that’s just my own experience. Hardly any of the technologies we use on sites can even comprehend a surface scaling which is one of the major reasons the construction industry adopted site localizations/calibrations for machine control. We get CAD in surface and a Survey & control in grid so we always bring the Engineered data back to grid and all of the machine control, mobile devices and software solutions can actually show up where they are on the planet instead of 300ft east and 1200ft north.
I would think you could just use the geographic point values but I don’t know how you would get linework out. If we need surface values we have a grid CAD and then just transform it in one of our software solutions, typically Civil 3D. I am not familiar with non-projected CRS’s for Surveying but I think you can choose such instead of a projection in Flow? Maybe that would give you a surface export?
@ruth.bongon Is something like that possible?
1 Like
Most of our jobs are 5000-10,000’ elevation where the grid vs ground becomes noticeable quickly. Thanks for your suggestions. We have a working repeatable process to get from grid to ground, was just thinking there might be an easier way here!
Grid to Surface is the horizontal and doesn’t involve elevation. What is your typical grid to surface scale factor? Ours is 0.999998 but our grid coordinates are 10M N and 3M E so it adds up.
In our area ground coordinates are the local arbitrary coordinates, grid is the true projection and surface is the projection scaled so there is terminology that can cause misunderstandings, even regionally. Saying that, to me it sounds like you’re talking about horizontal to slope (ground) distances at that point.
1 Like
The elevation factor has a large impact on the combined factor. This is from a project I’m working on this week, ellipsoid height is around 2400m. Difference between ground and grid is more than 4/10th per thousand feet.
Zone
CO C-0502
Northing
417,177.694 (m)
1,368,690.483 (usft)
1,368,693.221 (ift)
Easting
860,484.423 (m)
2,823,105.977 (usft)
2,823,111.623 (ift)
Convergence (dms)
-00 23 30.17
Scale factor
0.99994592
Combined factor
0.99956817
2 Likes
Ok, yeah Colorado makes a difference. Do you always use a combined scale factor? I guess you are dealing with very large areas? Typically the surface scale factor is often used in a local context (like a small survey), while the combined scale factor is more common in large-scale projects, like regional or national surveying, where multiple distortions need to be corrected simultaneously. I’m really glad I don’t have to transform your coordinates.
1 Like
Our projects are typically 20 to 500 acres (UAV data) and always scaled with the combined factor. Right now, a mile long stretch of river.
Most of our civil jobs are surveyed in modified state plane, meaning the point of origin (centroid) is an actual state plane grid point, then everything scaled from there. The scaled coordinates are often truncated by subtracting the millions so they aren’t confused with grid. CDOT takes this approach. I’m not sure how they connect adjoining survey limits though!
2 Likes
Very interesting, thank you.
Hi @michaelL ,
I am not familiar with non-projected CRS’s for Surveying but I think you can choose such instead of a projection in Flow? Maybe that would give you a surface export?
Yes, you also have the option to export only the Global coordinates. Otherwise, you can just set your project in Global CS, so you do not need to use the custom CSV export.
@summitbri, currently, it’s not possible to apply a combined scale factor in Emlid Flow. We’re collecting such requests for consideration, and I’ll add yours as +1.
1 Like