US Foot unit option for Arbitrary Coordinate System

PIX4Dmapper PIX4Dmapper Feature Request
1

Hello,

Please consider adding the US Foot Unit to the drop down for Arbitrary Coordinate System selection during project setup.  Currently, only having Metric and International Foot makes life difficult for those of us leveraging PPK and localized coordinate systems in US. 

I realize you offer US Foot for “published” state plane coordinate systems, but for my typical Klau PPK workflows, it would be terrific to specify US Foot Unit at project set up prior to processing in Pix4D.

Thank you very much.

1 Like
2

Hi Michael,

Any feedback about your experience or information about features you would like to see in a future release is much appreciated. Thank you!

I understand that it would be crucial to have an option of US foot unit for Arbitrary Coordinate System selection during project setup. Although this suggestion is already passed on to our Development Team - the confirmation you can find in the related community post US Survey Foot. I will share your interest with the developer’s team once again so that they consider to implement this feature with a higher priority in the future. However, I cannot provide you with any time frame of the implementation.

Best regards,

3

Michael,

Are you using GCPs?  We don’t use arbitrary coordinate systems very often but we always use GCPs and tie the data to a few of them throughout the project. We also use checkpoints to verify the data.  We fly RTK / PPK for everything.  I’ve not noticed any issues with our resulting data fitting any of the other data produced by conventional GPS equipment localized to the site coordinates.  I’m somewhat new to this so I may be overlooking something.  

Sincerely,

Eric Wischropp (Our pix4d account is registered to my coworker so his name shows up instead of mine) 

4

It is crucial for US projects with localized coordinate systems to be able to use US Survey Foot in the Arbitrary coordinate system. Our projects are very difficult when utilizing PPK workflows and trying to apply a localized site calibration.

HIGH PRIORITY!

5

What difficulties are you encountering?  I’m not seeing this on my end but perhaps I’m not flying large enough sites that the difference between US feet and international feet causes an issue.  The largest site i’ve flown to an arbitrary 5000,5000 N & E values was around 400 acres.  We have a couple of workflows for this situation and they both work very well with most checkpoints coming in less than .1 foot.  Bob Parker is our account holder but this is actually Eric Wischropp.  You are welcome email me directly at eric@lasergps.com.

Sincerely,

Eric Wischropp

6

You’re not seeing any issues within Pix4D because everything is fine, looks good, and checks out within the Pix4D platform. However when you export the ortho or other product to another GIS application it applies that international foot and that’s when you’ll see the shifts. You should see issues on a 400 acre site. We’ve seen shifts of 20+ feet on a 550 acre site.

7

We do export to Carlson Civil as well as Autocad Civil software.  I import both surveyor provided checkpoint data as well as CAD plans directly over the orthomosaic image.  I also compare contour data created in pix4d against the checkpoints to be sure they are consistent. I don’t use any GIS software regularly though. I work with surveyors that are creating ALTA surveys as well as topo data for site design and no issues have been encountered. We just haven’t seen issues like what you’re describing.  Are you seeing 20 horizontal shifts or vertical ones?  Are you using GCPs for control?  What type of drone GPS are you using?  I’m confident you can get this worked out with a little more info.  I have lots of survey and engineering customers using the same workflows that I use and if it wasn’t working for them,  I’d be the first to know about it.  We shoot for <1" horizontal and <2" vertical error values when the map data is compared to independently surveyed points and it’s extremely rare to have an issue.  If my error values are > .5’  I KNOW there is a mistake somewhere.  I’ve seen .5’ error on a localized site when the surveyor forgot to provide the localization data.  This example was to modified state plane coordinates.  After repeated inquiry,  they remembered that they in fact did localize the site and when provided with that info,  the error value was <.1’ as expected.  I’ve also found errors in my GPS rover equipment.  We use tilt compensated GPS receivers and one shot didn’t have the compensation active when it was measured.  I easily found the bad checkpoint and verified the error in the data collector so that point was disregarded.  What I’m trying to get at is that it’s possible to produce very accurate and repeatable results even on arbitrary coordinate systems.  Some of my customers only work on arbitrary 5000, 5000 coordinates and never work in state plane coordinates.  

8

Can you add support for US Feet?

9

Mr. Carlson is correct. This is very problematic. It isn’t that Pix4d is designating arbitrary systems as International Feet, it is they don’t provide enough specificity in regards to the unit Feet. Feet by itself is interpretted by most Civil/Surveyor software platforms as International Feet. So when you export an file that has sufficient metadata to described the unit of its contents, the program used for import will read Feet as International Feet.

When using a Pix4d project that has an assigned NAD83 type state plane projection, these are understood to be based almost always as US Survey Feet. I believe maybe one state in our 50 states uses International Feet, all others US Survey Feet.

You end up with a scaling issue based around the origin. So for those who are using arbitrary system with a 5000, 5000 range coordinate you won’t detect this because the scale factor is so minimal.

But if you are using a larger coordinate pair, like what state plane looks like in California, 2 million, 5 million or so, you end up with a 12 foot scale shift.

I just experienced the same on a project that we inheritted that has coordinates that look like NAD27, but since we inherited the project and their wasn’t a written control statement to clarify, we moved forward as if this was an assumed system. Now using arbitrary in Pix4d, I can’t get the point cloud to give with any other Civil/Survey software without doing some type of major trickery. There are solutions, but none of them are “correct”.

This is an oversight by Pix4d and it should be corrected. Based on my experience most sophisticated mapping software understand the importance in defining the type of foot unit used, and I am surprised to see that Pix4d doesn’t.

1 Like
10

Eric,

All of your points would come in within a foot because the conversion between international feet and us survey feet is small - us survey ft * 1.000002 = international feet. In your example: 5000 * 1.000002 = 5000.1. So the most error you would see would be a 1/10th of a foot. As the coordinate system gets larger, the error does as well.

11

I can’t believe that this hasn’t been added as a feature yet. There should be a dropdown for the arbitrary system as well as the GCP coordinate system with both units of measurement. My current workaround is to convert the GCPs that I use to tie in the project to international feet, process, and then convert back to US survey feet in something like Global Mapper. I have had no deviations down to the thousandths using this methodology. I hope this helps.