No matter what I try, I can’t get my GPC text file to show the points on the ODM GPC interface map. When I planned my mission using DroneDeploy app, the coordinate system indicates: NAD83 (CSRS) or UTM zone 10 or EPSG: 3157. Using the EPSG format, ODM just rejects the file. I had more luck using: WGS84 UTM 10N as the first line in the text file, this is accepted by ODM but does not show the coordinates on the map. ODM documentation says creating the text file is VERY EASY, then goes on to say there must be 6 columns, but I have seen others using just 4 columns: Label, Longitude, Latitude, Elevation. I have spent hours searching for the answer, but I am coming up short. HELP!
Thank you for your help, I tried the Proj.4 string you suggested, and also tried the EPSG:4616, but GCP’s are still not showing on the map. I am starting over with a new map with new coordinates and I will post the file here. There doesn’t seem to be any consistency in the format, I see different people doing it different ways, but none are working for me.
The format is actually quite consistent, but I’ll give you that how people post about it on the forum may not be. When you get to the point where you want to share your attempt, we can help you get it over the line.
OK, really struggling here. My initial GCP file loads in the maps window OK, and the GCP points are in the right places. The exported GCP file looks good. However, when I run the 2D map with GCP file in ODM, the map goes haywire.
I wonder why the truncating is occurring? Anyone else getting this? Why would I be the only one? I am not sure how to copy the coordinates because they aren’t apparent when establishing the 3 photos per point. Also, this seems like a lot of manual work, there has to be a better way! Does this have something to do with the Proj+4 string that was recommended?
Looking into it, but its been a busy day. I haven’t used the Ground Control Point Interface (GCPI) in WebODM in quite sometime, so it’s a bit of a re-learning curve.
It seems that the control point input with the Proj.4 string produces truncated Long Lat coordinates in the GCP.txt file while the control point input file with the EPSG:xxxx code seems to yield UTM coordinates in the GCP.txt. Could this be a bug? Both control input files show the control points correctly in the map window. Maybe try the EPSG code?
I havent checked for this issue in GCP_Pro yet. GCPI and GCP_Pro have different input formats. Sorry if i’m confusing…just trying to help.
Thanks Mike, anything that you learn I’d be eager to know. I have tried the ESPG code for my area, but the ODM GCP tool rejects it. The GCP interface certainly has other bugs in it. One thing that I was made aware of from Rich Charpentier (YouTuber), is the erroneous yellow control point in the map that first needs to be deleted… or does it? What I am learning is that OpenSource software, whilst amazing, has bugs that need to be overcome. Anyhow, please share anything that you know, it is much appreciated.
How the code is licensed has little to do with bugs. Let me show you what I’ve seen in software with all rights reserved… .
But, as the PM on the GCP editor many years ago now, it’s bugs are mine. We had a painfully small budget for that project and it shows. If you need a better editor, you can purchase GCPEditor Pro for a relatively nominal price: https://uav4geo.com/software/gcpeditorpro
Thank you! That is the answer that I need. As for the tool you made for ODM, even if it is buggy, it opened my eyes and started my journey to using GCP’s, made me understand a little bit more on this mapping journey, so thank you! I will go ahead and buy that tool now.
Unfortunately, it seems that the intention is to leave the free editor with errors in order to sell the not-so-free one?
In my opinion, we need a free and good (at the same time) GCP editor.
It doesn’t really have to do with the open source. Without going any further, the pro editor also has the code published. Even though it’s a challenge that you wouldn’t want to take on compiling it yourself, and even though it’s not fully-free licensed, it’s open source.
The truth is that software development needs to be paid for to ensure its continuity. That is not easy in any free project. In this case, I consider it even more difficult, since uav4geo has already developed and sells a limited license version and a funding campaign for the development of a free editor could go against their interests.
I think this is worth discussing. Free software is hard to fund, so if I remember correctly, the editor was an experiment in keeping the code readable, the functionality free for any who choose to compile it themselves, but to constrain redistribution.
But it may come at the cost of competing with the time and energy for a fully FOSS core version, as you suggest. It is useful to hear this perspective as there hasn’t been a lot of discussion on the forum regarding the editor.
