Section of a map missing despite lots of photo points

Thankyou for the response. Is this a new feature of your platform? I've been using the Mavic Air to process maps for that same field multiple times since the start of the year, and your service has always produced the maps OK.

I actually triggered another job at 0.25 quality (so free), and that's come back with some of the missing area filled in ( https://www.mapsmadeeasy.com/maps/public/45137eddbb344ae4a2c2ff0f84f78412 ), but then other parts missing. Same files, different results.

Should I expect to get different results if I uses the old workflow?

Thanks,

Miles

To add to that, i've done a trial upload of just the photos from the region my paid-for run failed to process.

https://www.mapsmadeeasy.com/maps/public/704db75031ee4c24ba6101e0d7d0bde1

It's worked perfectly, and the main area reports 13+ points of overlap. Aside from the fact I used a smaller part of the data set, everything else is the same.

This would seem to indicate there was an error in the initial job run, rather than something fundamentally unmappable about that area?

As explained above, the issue was in your source imagery and the amount of smear that was created during data collection due to the camera's small lens and limited light. It may have worked before with more light but it was too dark or the content of what you were trying to map was too dark for the given light. It is important to keep an eye on that ground smear number. It is there for a reason. 

Both workflows provide the same processing. The main difference is the uploader and the processing options which can affect processing duration.

It having streaky data makes it hard to match adjacent areas on non-streaky data. 

I understand the explanation, but do not understand why those very same images can be turned into a extremely good map, when I upload them on their own?

As above, I have multiple subsequent test runs using just the images from the 'bad' data set (i.e. dropping most of the pictures from the east & south that rendered well). Each 'sub-map' has produced great images and reports a 13+ blue overlap. ( https://www.mapsmadeeasy.com/maps/public/456219fc07ec48708e7f321a66d3d866 and https://www.mapsmadeeasy.com/maps/public/704db75031ee4c24ba6101e0d7d0bde1 )

Evidently, your algorithms were perfectly capable of producing a very good map of those areas using that data. It is only when I those exact same data points alongside other photos taken on the same flight, that it completely omitted them leaving a significant chunk missing of the map. If it was due to blur (vs e.g. some other kind of temporary failure in the processing), then it's a very odd manifestation.

I'm not so bothered about the points spent on that one failed map, but I still have points to use, and would like to continue using this service. It doesn't feel like a good solution to split my maps up into multiple sub-maps just because your process seems to cope with those, as that fundamentally lots of little maps are no good to me. 

Can you offer any explanation as to why your processing managed to cope with the 'small' data set of 158 images, yet failed to render most of that area completely when those same 158 images were uploaded with another @~150?

I'd love to keep using your service and recommending it to others, but I hope you can understand why i'm concerned about a map getting to the 'paid points' level and suddenly being returned with something unusable... Are you sure there wasn't some other kind of issue, or is your algorithm really sensitive enough to completely ignore large chunks of data that it'd happily normally process, just because they're submitted alongside a larger set of data?

It is likely matching the streaky data areas and then matching the non-streaky data areas but is unable to match the streaky areas with the non-streaky areas. 

Also, downscaling by .25 is a completely different thing. That is basically blurring all of it and making it all equally burry, except in the areas where your motion blur was more than the size of the downscaling (4X). 

If you upload data that doesn't have motion blur values of up to 13X GSD it won't happen like this.

High motion blur data is bad. 

Hello,

Your point about 0.25 downscaling makes sense to an extent, but the first of those links wasn't downscaled at all, yet worked OK. The 2nd was, because I didn't want to pay for another failed map.

I'd delicately suggest we end this discussion as a "feature request"; even if you cannot get a perfect map, a slightly distorted/blurred one will still be usable (indeed, the sub-maps i've done look superb in quality) as is vastly preferable, whereas completely ommitting large central areas with high overlap coverage renders entire runs (and points spent) as a waste.

In the meantime, a side-install of WebODM i've done has managed to render the full map (albeit not quite at the quality you can, at your best). This allays my worries about the immediate task, if not the future doubts I'll have before submitting a points-paid size job with you in the future, which is a shame.

Thanks,

Miles

We have to make some assumptions about the quality of the images that are provided for us to process. This is why we have our Data Collection guidelines which you agree that your images are compliant with at the time of upload.

From https://www.mapsmadeeasy.com/data_collection:

"Exposure Time vs Speed - Try to keep your ground smear below the GSD value. 15 m/s flight at 1/1000s exposure will allow 1.5 cm GSD."

This is there to say that we cannot reliably process streaky images. If these guidelines had been followed I am sure your may would have turned out fine. 3-13X GSD is not OK when you agree that your data is within 1X GSD. This makes our assumptions fail.

We understand that in northern latitudes at this time of year it can be hard to get good lighting. This is where having a camera with bigger optics comes into play: they collect more light and have shorter exposure times. This leads to less motion blur.