Latest Contributions by CodyBenkelman

Lance  Sorry I didn't respond soonr.  The single best resource for these questions about "What is recommended?" is our Imagery Workflows site at http://esriurl.com/ImageryWorkflows.  Specific sections I would recommend are the overview topic of Image Management starting at https://doc.arcgis.com/en/imagery/workflows/best-practices/what-are-best-practices.htm (continue with the rest of the section on Image Management) and a specific discussion of the multi-year case in  https://doc.arcgis.com/en/imagery/workflows/resources/managing-preprocessed-orthophotos.htm  Regarding that post that you found from 2016 - and I regret that I did not discuss this more deeply at that time.  My caution about the 'pitfalls' focuses on which raster type is used when adding a mosaic dataset (MD) as input to another mosaic dataset.   Briefly: I recommend *against* using the default "Raster Dataset" raster type which is recommended in the post you reference  Creating a mosaic dataset containing raster data from multiple dates  If you have 3 input MDs and use that raster type, your master MD will only have 3 records.  That may seem convenient and in some limited cases I'd say "Yes go ahead" but it can lead to performannce problems if you have 8 or 10 or more MDs and especially if you 'nest' them further in another layer of hierarchy because you've embedded database tables as single records inside other tables. What I *do* recommend in most cases is to use the Table raster type.  In my last statement, if you have 3 MDs with 100 records each as source data, your master MD will have all 300 records.  This avoids performance problems but it does (generally) require the additional step of defining one or more custom fields e.g. "Year" or "Date" as you note, and I also recommend adding a field (we typically call it "Dataset_ID") into each source MD so that the master MD will clearly show the source MD for each of the 300 records.  Hoping to avoid confusion, I should note that some of our documentation refers to the master MD as a "Derived" mosaic dataset - but this name is simply a convention, not a formally defined term. You also asked "How is there an advantage when you would need to filter the data to render each year individually?"  If you only have a small number of image collections (years or separate projects) this is not a major concern, but if you share each as a separate image service, those services will consume resources on the server even if nobody is using them.  If many collections are shared in a single image service, your use of server resources is more efficient (better performance).  The Landsat service is a good example - millions of individual records and it performs very well.   But yes, you do have to provide users with the ability to select images by date (or other attributes as necessary) - see the Time Selector tool in the Landsat Explorer app. Last, re: the Esri video in your 2nd reference, I do not agree that you need to create a new GDB for every MD.  I've never attempted nor felt a need for hundreds of MDs - and there probably is some reasonable limit - but multiple MDs in a single geodatabase should not be a problem. Cody B.   ... View more

Hi Eisele sorry for the delay in responding.  Your account administrator should have received an email explaining this - I believe it was in June. At the next release of Drone2Map (early November) we'll have two license levels, Standard and Advanced.  Current users were given early licenses to Drone2Map Advanced to support beta testing of the new version.  In the currently released version, there is only one license level for Drone2Map. Cody B.  ... View more

Julie there are a few separate issues here.  FIrst, I agree with Gordon.  Incorrect Z values in drone GPS data is a well known problem - I've documented altitude errors up to 100 m for some very common drones.  If you do not use 3D control points, your output Z values will never be accurate.  (Having said that, the DSM and DTM from the same project should be self-consistent, so even if not absolutely accurate, the relative accuracy should be good, with a critical dependence on content).   I think the more important issue is that what you're seeking to do is really not possible with optical imagery.  Images cannot penetrate through canopy the way lidar can, so you're not going to get valid ground samples under the vegetation to create a DTM.  In addition, the DTM created in this manner is an *estimate* of the bare ground, and created in a fully automatic manner.  Without editing, it's not going to successfully eliminate thick vegetation canopy.  This DTM is really intended to be an elevation base for orthorectification of imagery, but not of the quality needed for hydrographic analysis or detailed canopy height measurements you're seeking to make.   If you want to proceed with using drone imagery to do this work, it will be more complicated but you can get a good estimate of the vegetation height (presuming this is your full study site.  If this is just a small sample and the full project is 100x or 1000x this area, this will not be feasible). I wouldn't use the auto generated DTM at all since it won't adequately remove the low, dense vegetation.  You'll have to manually create a DTM.  If you can make a copy of the DSM, and draw polygons around the open 'pits' to mark areas to *retain*, then zero out the rest of the DSM and then interpolate to fill the erased areas, you'll get a pretty good estimate of the DTM (although this would not reveal any hidden stream/drainage channels that may well be there).   Also note I'm assuming those 'pits' are the true ground and the vegetation between them that's ~1-2 meters tall should be included in your vegetation height output...?   If you have ArcGIS Pro and the Image Analyst extension, this DEM editing can be done with the pixel editor.  If you don't have Image Analyst but you do have Pro, you could do this editing with the point cloud.   Let us know if that manual editing is feasible and we can advise further. Cody B ... View more