An exciting new year is ahead for OpenDroneMap! 
I’m opening this thread to ask a simple question:
What would you like to see next?
In short, what’s important/valuable to you that is currently missing?
This feedback will help guide development decisions going forward in the year.
I was recently taking a look at the GCP interface. And I had some trouble understanding how to use it properly. I think it could maybe use a look-over by someone who has good UI/UX experience? Or usability feedback from a variety of people trying to work with it for the first time?
Hi, new on this forum but not new to the ODM.
3.And option to correct distored images based on camera and lense level (camera calibration). Ref, this one on github https://github.com/dakotabenjamin/CameraCalibration
4. Lever arm adjustment. This is more as an extended feature of nr 2. Apply an relative XYZ offset between the camera and the GNSS antenna that is fixed for the entire job. Ref. this description https://community.emlid.com/t/does-reach-need-to-be-level/6221/4?u=tb_rtk
Had to split my post as new users cant have more then 2 links i a post 
Hi Piero - my number 1 request is georeferencing point clouds before making meshes, ie:
(but I am also maybe missing some documentation which says how to do that already)
depth filtering (found in some commercial packages) - sort of like ‘confidence thresholding’ for MVE in: https://github.com/OpenDroneMap/ODM/pull/921
general point cloud/depth map alignment improvements, I’m sorry I don’t have an exact recommendation - point density of smvs with geometric quality of MVE? (yes, asking for all the things - I want to see branches on trees!).
I second @TB_RTK ’s number 2 - being able to provide a list of camera centres which over-ride exif would be awesome. I’m not sure it’s ODM’s job to add lever arms, but really, I guess it could. It’s cheap math compared to everything else going on.
native compilation fixes for more modern ubuntu (opencv 3+?)
MOAR TIME for me to play with and test ODM things instead of chasing money 
Hi, new I. The forum. I would like to see a quality report of the project. Thank you
Hello pierotofy,
i am new to the forum but would like to add that i agree with the others in updating the GCP tool.
i would also like to see the projections reviewed. in particular this setting. proj (PROJ4 string).
living Australia output to UTM North 55 is what i have been getting yet it should be MGA94 Zone 55.
other than a few minor settings i really appreciate being able to use it. Thanks a lot.
(Good news: the Southern Hemisphere issues are being fixed: https://github.com/OpenDroneMap/ODM/pull/936)
I’d like to have an option to add a custom base layer (something other than Google Satellite) for the ‘View Map’ screen, and also turn off the background base layer.
Thanks a lot smathermather-cm. Sorry i was not aware of this.
Definetly true NDVI based on Micasense or Sequoia.
Thats really missing for all us in agriculture or forestry.
Together with ardupilot that would complete the sequence.
Pierro,
From my view the following would be great (in no particular order!);
1.Improved GCP interface which offers the nearest images to the GCP initially, then refines the location once enough have been marked to centre in on approx location. I’d prefer it in the workflow rather than as a plugin, ie calc sparse point cloud, then mark GCPs, and optomise sparse point cloud and continue processing. This is perhaps quite an ask!
2. Use EPSG codes rather than proj4 strings, as few people use proj4 in the real world.
3. Accuracy report
4. Ability to load autocad dwgs as an overlay in WebODM
5. Ability to use WebODM to view other drone data (raster/point cloud/etc) even if processing has not taken place, ie upload data processed elsewhere, or previously saved and removed from WebODM.
6. Timeline view for a project with multiple tasks, perhaps tabbed, so progression can be shown.
Embed Camera calibration in the work flow:
As a start, allow one to specify the location of a camera calibration file and, if present, undistort the images prior to beginning other steps.
A tool to extract the camera calibration. It could be from images of a checkerboard pattern, or even a method like the one proposed at this link which describes (at a high level) a strategy for automatically extracting the calibration.
Finally, I second the wishes of others to improve the GCP interface. In addition to making it easier to find/match GCPs, there should be an interface to specify known lengths/heights of objects in the scene.
I would like to see the volume measurement expanded to include different ways to measure an object based on the terrain around it, e.g. Setting a base surface that is flat but at any orientation (to also measure things on hillsides).
hi @PAHDrone - MGA55 is a specific Australian coordinate system - switching to automagically using UTM south is a decent approach by default for ODM; I wonder if a future request might be:
‘allow input of an EPSG code or proj string to define desired output projection’?
Hello adamsteer,
yes i think and EPSG would be fairly straight forward. all of the GIS software i use recognise and EPSG code.
i assume by proj string you mean well known text. (WKT)
ESRI WKT for EPSG 28355 is
PROJCS[“GDA94_MGA_zone_55”,GEOGCS[“GCS_GDA_1994”,DATUM[“D_GDA_1994”,SPHEROID[“GRS_1980”,6378137.0,298.257222101]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER[“false_easting”,500000.0],PARAMETER[“false_northing”,10000000.0],PARAMETER[“central_meridian”,147.0],PARAMETER[“scale_factor”,0.9996],PARAMETER[“latitude_of_origin”,0.0],UNIT[“Meter”,1.0]]
a tad long winded so an EPSG would be much more preferable.
is there much use for a ‘plant’ grid? if so then maybe a proj string may be useful that way you can define your own CRS.
grah! there is already —proj in opendronemap options to accept proj4 strings, for example:
+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs is the proj4 declaration of EPSG:28355. it’s a bit more elegant, and Proj4 strings also allow non-EPSG spatial reference systems to be used. So maybe the addition here is an —epsg equivalent to —proj - or perhaps an —out_crs which can be either EPSG code or proj4 string?
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)
you may already be aware of this http://www.epsg.org/ this is what we go by.
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!
hope this helps.