grah! not sure what that is for, sounds like you are frustrated. it sounds to me like we both live in two different GIS worlds. lets see if we can come together.
proj4 suggests you need to know all the CRS details and transformation details so you can type them in. nothing wrong with this if you use proj4. i don’t know anybody in my GIS groups that use it or have even heard of it. (maybe naive!)
therefore your suggestion is good but i think maybe needs to be rearranged slightly.
an EPSG for the base data (maybe given or read from data),
an output EPSG (-out_crs --> -epsg_out),
and a transformation drop down list (similar to -proj (+to…) --> -trans)
examples
GDA94 to GDA2020 (1)
GDA94 to WGS 84 (1)
ITRF97 to GDA94 (2)
ITRF2014 to GDA2020 (1)
AGD66 to GDA94 (1)
not sure what is in the background coding of ODM but my guess is proj4 so it would mean dong some tricky converting epsg strings to proj4 strings. this would make it simpler for some people but would it be worth it? maybe we need to spend a lot more time trying to understand proj4. not a bad thing!
Hiya - only frustrated at myself, I seem to suggest features which already exist a lot
I should have made that clearer.
I agree - adding an option for —out_crs (not necessarily named that) using EPSG codes is likely a valuable thing for people who don’t want to use proj.
I think that for most folks, yes, EPSG codes are the mainstay/shortcut. Proj exposes the fundamental stuff if you want to do something exotic (including compound CRS and all the transforms you suggest).
from my PoV, I think we can leave all the other datum shifts to post-ODM tasking, although maybe there’s a webODM option there…
I’ll have some time to tinker with ODM again soon, I’ve already done some work around aligning output with other data in EPSG:28355, let’s see if I get closer a priori using the —proj option.
I’d like to see the ODM split/merge added to WebODM.
Although it seems that split/merge is an interim “fix” for processing large datasets (but would help me with a large-ish machine), I assume that the final goal (single job over multiple nodes) is some time off due to complexity (though I’d vote +10 to that!!!). And quite frankly, I’d sooner use my time getting better results than trying to run the split/merge pipeline manually (and why I had no issue paying for the excellent installer).
I’m not sure if this is implemented in other software platforms but it is an issue I’ve been running into lately. We are using a DIY RTK system based on RTKLIB and it is set to log points at defined intervals. The rover is mounted to the aircraft and stores its positioning information independent of the flight controller. It would be great if we could get some sort of option to import the GPS track from the rover and use it for placing cameras instead of the exif data in the images.
Any chance of producing a Plant Health map as is available in Drone Deploy. Their notes on the matter are below:-
“However, the standard plant health layer for all customers only reflects the VARI algorithm, which is designed for data captured with standard Red, Green, Blue cameras”
I find this useful for some Archaeological survey situations.
JohnRich
Another thing I recently thought of that would be kind of useful is the option to turn on the display of a northing arrow and scale when looking at orthophotos and 3D point clouds. This would make it a bit easier to identify orientation of a dataset and presumably would be quite simple to add to the web interface.
Maybe it’s not possible, but I’d like to see multithreaded volume and contour calculations. Currently these are limited to one core, which can take a long time to compute. In the case of volume measurements, these timeout after 60 seconds and so is limited to smaller volume calculation sizes.
Yet another improvement to make, the GCP interface does not allow for importing of coordinates with EPSG codes. This is just one of those small things that really simplifies the data workflow since we don’t have to generate a proj.4 formatted string for every project. WebODM already imports EPSG codes when processing images, but the GCP interface falls just short of it.
@RyanF, I sort of already solved this. I’m not familiar with Python (I’m a Perl guy) but I’m happy to contribute the code to ODM (maybe somebody can convert it?) You can see how I did it here: https://dashboard.aerosurvey.co.nz/login.cgi?Demo=1
Check out “Poets Park Flats (GCP)”. A user uploads their photos, the GPS EXIF tags are pulled out automatically as each file is saved and stored in the DB. Then they’re all scattered out onto a Google Map for the user to click, assign GCPs to them, and saved to the DB with photo IDs, Pixel IDs, lat/long, alt, and WGS84. Then the GCP file is created when the job is triggered and injected automatically into ODM. You can do the whole thing with just clicking if you wanted to.
Your interface looks great compared to some of the stuff in ODM. I especially like how you show the camera trigger locations over the map before processing. I wish I knew more about Python so I could contribute to the project but that’s unfortunately outside my area of expertise. I’m more of an Arduino kind of guy, so unless ODM suddenly becomes capable of running on a small IC chip I probably won’t be of much help
I have been doing what I can to upload test datasets for others to experiment with, so I guess that’s my small contribution to the project.
It would be useful to have a “time taken” or “run time” feature so that users (esp. those with large projects they don’t want to constantly keep tabs on) can know how long their project took to run. Just a helpful planning and assessment feature I think.
A more easy to use GCP interface so that the user can upload all the images then specify gcp’s and register each one of them in one or two images. Then the process should continue automatically for all photos of the mission and generate the appropriate file for import to webodm. I think @ITWarrior has created something similar but in a different programming language if i understood correctly.
Sincerely,
A new webodm member
Christos
hell of a opensource project. i would like to see the possibility of adding vari algorithms that already exist in the grass package, directly on webodm instead of having to process, open qgis, process again, save output.
Longtitude-Latitude coordinates system support for using gcp in the model would be an extremely useful improvement. Many engineers cannot use webodm because of this shortage.
