Let jednoho dne, let dalšího dne - obrázky nejsou zarovnány.

Question

<\/HEAD>Letěli jsme dvě oblasti během dvou dnů.... zpracovali jsme snímky samostatně pomocí D2M. Přidali jsme ortofoto v Pro \/Desktop a v D2M a je tam brutální nesoulad. Ví někdo, co by to mohlo způsobit? A jak to opravit? <\/P> <\/P> Jeden den je levá polovina... další let je pravá polovina. proč se stopy nespojují? <\/P> <\/P> <\/P> Je zvláštní, že nesoulad roste čím blíže ke středu ortofota (dále od okrajů)<\/P> U okrajů je odchylka stopy asi 1,9 až 2,1 m ve středu téměř 3,4 m.<\/P> <\/P> Děkuji<\/P><\/BODY><\/HTML>

MervynLotter · Answer

Hi Michael (not sure why I called you Robert in my last post)

There is not much that I can add other than suggesting the GCP approach may be your best approach. If accessing surveyed GCP is problematic, you could use Collector and Esri have a new template on AGOL that allows you to create a feature layer using one of their templates designed for capturing GCPs for D2M. Collector can also be set to average GPS collections under settings.

If you are keen, go to your Content/Create/Feature Layer/ then search for "drone". You can then create a feature layer that will assist in capturing of GCPs.

If you use the georeference option, depending on where you are located, you may have access to high resolution aerial imagery on AGOL that can be used you to correct both images as neither are correctly, or adequately, georeferenced using the raw image GPS coordinates.

MichaelRobb · Answer

Hi Mervyn,

This is the response I was expecting.

Just making sure it inst something else, as in settings in D2M or..

So the cause is due to different flight days or just the fact that each flight taken has the open window of the accuracy (e.g. 5m HDOP) error to create the shift - GPS image tile reference.  There is some math involved knowing sampling would increase accuracy (reduce the HDOP) to some log factor - maybe 2.1 meter. and yes, all image tiles are tied to the GPS as this is the reference.

Do you feel this statement is valid in understanding what is causing this shift?

To validate one could, strap on a better gps device with RTX OmniStar satellite correction and run different flights and if the above hypothesis is correct, would drastically reduce or even eliminate the shifts seen above.

Unfortunately, do not have the funds to do such an experiment.

I was not aware that Pro allows you to correct / rubbersheet to another image.  (sounds like a poor mans fix but the option is there) - like you said, you need a valid reference image.  And I am not sure how well that would work for tying a shift as seen in the attachment when that occurs at one end of the flight... what about the tail end that has no image to reference to? (it stays out of whack?)

With that being said, what can be done with avoiding or correcting after the images have been collected?

1.   Create ground control points (surveyed) and rubber sheet the image?

2.   Create ground control points (surveyed) and use in the D2M software - manage GCPs.

3.   Increase accuracy of GPS Device (better device)

4.   For elevation correction (one can reference a known accurate DEM) to correct altitude - doesn't help with shift though.

5.  ?

MervynLotter · Answer

Hi Robert

Unless your drone imagery is captured using a real-time deferential GPS, or you are not using any Ground Control Points (GCPs), this alignment problem will continue to occur. I have also experienced it and there may be many reasons for the variation you observed. All relate to accuracy of GPS points captured.

To correct it, you could either make use of the same GCPs in both D2M projects. Or you can now correct the imagery in ArcGIS Pro using the Imagery/Georeference tools. Select which imagery is more accurate then align with the "Add control points". Perhaps the "Auto Georeference" tool will work but I have not yet tried it for correcting this alignment problem.

I am not sure why the alignment problem is not at a fixed distance throughout the two products.