I map at a unique location. The 180 meridian or The Dateline where latitude coordinates change from negative to positive and drones go fly away if mission not well planned.
I have dataset spread over across the dateline along the both sides from it. When I process it, it seems those image files, that lay to the west from the dateline get processed by ODM with CRS EPSG:32701 - WGS 84 / UTM zone 60S and those to the east from the dateline get EPSG:32701 - WGS 84 / UTM zone 1S in the result orthophoto. Those two halves don’t stitch and ODM throw error that “something is wrong with your dataset or it was incorrectly collected” sending me to read manuals…
I can stitch those halves separately with no problem. I am not sure why but I suspect those two chunks don’t stitch because of different CRS they get processed with?
Will applying GCP with the same CRS for both sides of the world help to get one piece orthophoto under the same CRS?
Is there any way to enforce specific CRS for the whole project before start processing the images?
It looks like it picks one CRS from each side of the date line, but I am not 100% sure… when I try to process them all together it fails, when I process them separately, I get them in different CRS.
I am uploading the images at the moment will share a link once they’re there.
After some investigation done how the data was collected and processed I found out that two halves one from one side of the date line and other half from another side were not correctly collected. The drone took off from different elevation on the mountain, so datasets were not matching with the altitude. Even though both chunks were taken at the same altitude, the take off ground elevation was different. The altitude difference was about 100 m… after re-collecting data from both sides of the dateline from the same elevation on the slope and altitude. Everything finally stitched well.
So the problem was actually in the ways how data was collected, not how software processed it.
But if I process those datasets separately they still get different CRS even though they’re literally from the same location on earth but from different sides from the dateline.
If I process them in one whole piece, the final orthophoto gets WGS 84 / UTM zone 1S if separately
Eastern one gets WGS 84 / UTM zone 60S and Western WGS 84 / UTM zone 1S
So my problem sort of resolved itself after I re-taken data properly along the dateline.
I can tell that 50m difference in flight heights still work if I fly two overlapping datasets from the same spot, but 100 m difference seems doesn’t work. Still two datasets match on the edges elevation wise. I even able to merge their point clouds manually
It’s different story if I fly those datasets at the same height, but from different ground elevations… in that cases obvious error strikes and processing stops.
When I process them separately and try to merge their point clouds… one point cloud visually above or bellow another one… I don’t think it’s a big problem that need to be addressed, maybe just worth to be mentioned, that in order to get overlapping datasets processed together, they need to be taken from the same take off elevation on the ground. If we use UAV for that.
