What would you like to see next?

#21

Hiya - only frustrated at myself, I seem to suggest features which already exist a lot :thinking:
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.

#22

Simplier interface to publish data to others :

  • One interface with gpc, nodes, administration, diagnostic …
  • Sharing project to others give link with only dataset and not complete interface
2 Likes
#23

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).

4 Likes
#24

This definitely a goal and on the road-map. Glad to hear it’s a broader need.

1 Like
#25

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.

2 Likes
Pause and limit tasks
#26

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

4 Likes
#27

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.

3 Likes
#28

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.

1 Like
#29

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.

1 Like
#30

@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.

1 Like
#31

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 :wink:

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.

1 Like
#32

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.

2 Likes
#33

Or perhaps a step further, the ability to trigger a command or webhook so that a completed or failed job fires off an email or other notification.

1 Like
#34

Both useful and slightly different use cases, but both great feature requests.

#35

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

2 Likes
#36

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.

thanks

carlos

3 Likes