|
POST
|
Lance - always happy to help, and I know it can be challenging to find the best advice. In some cases our recommendations change over the years as the software matures, and in other cases it's a gray area for what is "best". One additional point I should have added is that our Imagery Workflows site provides examples of scripts for automating the creation and maintenance of mosaic datasets. In any configuration with more than a handful of mosaics and a dozen image collections, I strongly advise *automating* as much as possible - among other things it will document how each mosaic was built, populated, and configured, and facilitates re-creating a mosaic if you're testing "will A or B work better?". The sample scripts are designed to be customized to meet your needs - there is a bit of a learning curve, but I'm confident it will pay off over the years. Let me know if you need more info. Cody
... View more
09-16-2021
09:04 AM
|
1
|
0
|
5564
|
|
POST
|
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
09-14-2021
12:07 PM
|
3
|
3
|
5588
|
|
POST
|
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
09-09-2021
12:42 PM
|
1
|
1
|
3864
|
|
POST
|
Hannah Have you read the help documentation? https://doc.arcgis.com/en/drone2map/ No, you can't change the coordinate system of the output products but for any *past* projects, if you have ArcGIS Pro, as Dan noted you can reproject the outputs to State Plane. However, that will resample the data which is not ideal - it's better to create outputs in your desired coordinate systems from the start. You can do this when you set up a project - go to Options/Coordinate Systems and click on the globe for Project Coordinate System. Note the default is UTM - not WGS84. Don't confuse the Project coordinate system with the coordinates for the input images which are WGS84.
... View more
08-26-2021
12:16 PM
|
2
|
2
|
2429
|
|
POST
|
Joe Yes it's there in Pro - read up on using the Raster Product if you're just adding individual scenes to the map https://pro.arcgis.com/en/pro-app/latest/help/data/imagery/raster-products-and-raster-types.htm For effective management of multiple scenes you should use a mosaic dataset. There are a lot of good resources at https://www.esriurl.com/imageryworkflows, specifically https://doc.arcgis.com/en/imagery/workflows/resources/using-mosaic-datasets-to-manage-imagery.htm and https://doc.arcgis.com/en/imagery/workflows/resources/managing-high-resolution-satellite-imagery.htm Cody B.
... View more
08-11-2021
08:01 AM
|
0
|
0
|
2644
|
|
POST
|
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
08-05-2021
09:03 AM
|
1
|
1
|
6836
|
|
BLOG
|
Ortho Mapping in ArcGIS Pro Date & time: Tuesday August 17, 11:00 a.m. – 3:15 p.m. eastern time. Instructors: Cody Benkelman and Chris Patterson, Esri, Karen Schuckman, ASPRS. This is a 4 hour workshop, presented in two sections, to demonstrate photogrammetric processing using the Ortho Mapping tools built into ArcGIS Pro. The content will include an overview of the general concepts of photogrammetry, then review workflows within ArcGIS Pro (Advanced license) for orthorectifying imagery from drones, satellites, digital aerial cameras, and historical scanned film. The discussion on satellite imagery will show how to orthorectify a single satellite scene using RPCs and ground control points. The discussion on scanned film will address specific challenges with historical datasets lacking camera calibration information. The discussion on drones and digital aerial cameras addresses frame-based sensors. Workshop format will consist of presentation of concepts and software demos, with time for Q&A after each section. Recommended audience includes GIS practitioners who need to orthorectify imagery as well as Educators looking for a hands-on platform to teach photogrammetric concepts. Advance materials will be provided with instructions and sample data for those who wish to exercise these workflows. For those who do not have ArcGIS Pro, a 21-day evaluation copy may be downloaded from https://www.esri.com/en-us/arcgis/products/arcgis-pro/trial Cost: $225 for non-members, $125 for ASPRS members, $50 for student members Sign up at https://my.asprs.org/ASPRSMember/Events/Event_Display.aspx?EventKey=WK20214272 Software version: This workshop will show the current version of ArcGIS Pro (v2.8.1), but the training is generally applicable to Pro v2.7 and later. Recommended hardware is listed in ArcGIS Help https://pro.arcgis.com/en/pro-app/latest/get-started/arcgis-pro-system-requirements.htm
... View more
08-02-2021
10:14 AM
|
0
|
0
|
1360
|
|
POST
|
Bert - presuming you want a) an automated method and b) accurate results, your simplest options within ArcGIS will be either to purchase Drone2Map (by far the lowest cost option) https://doc.arcgis.com/en/imagery/workflows/resources/creating-drone-imagery-products-drone2map.htm or to upgrade to an Advanced license on Pro to use the built-in Ortho Mapping workflow https://doc.arcgis.com/en/imagery/workflows/resources/creating-drone-imagery-products-with-ortho-mapping.htm . As I think you know, Site Scan is another option, providing SaaS to do all your processing in the cloud, whereas Drone2Map and Ortho Mapping run on your desktop. All of these apps will apply photogrammetry to generate accurate products in a mostly automated fashion. Lacking those tools, with Pro Standard license you can use the georeferencing tools, and there is some automation possible if you properly orient each image on the map before attempting the auto georeferencing process. For a small number of higher altitude images, with oblique angle up to ~15-20 degrees off nadir, you can get some nice looking visualizations, but your results won't have any quantifiable accuracy. If you're serious about generating map products, you'll need one of the photogrammetric tools and most likely need to upgrade to a drone with a better camera.
... View more
07-26-2021
02:51 PM
|
1
|
2
|
3611
|
|
POST
|
You do not need to follow that old post (from May 2018) to adjust altitudes in the EXIF metadata. Drone2Map includes an altitude adjustment, and if you use GCPs with the correct spatial reference, image height is adjusted automatically. You said that you converted GCPs to WGS84 - note that GCPs must be in a projected coordinate system; Lat/Long is not supported - but you should've seen this error message if you tried to use Lat/Long Could you try your GCPs in HTRS 96/TM? Cody B
... View more
07-21-2021
04:54 PM
|
1
|
0
|
1445
|
|
BLOG
|
Users of Site Scan for ArcGIS, Esri's end-to-end SaaS for capturing, processing, analyzing, and sharing drone imagery has expanded options for sharing to ArcGIS Online and ArcGIS Enterprise. Cross posting to David Ozer's blog: publishing-from-site-scan-to-arcgis-online-and-arcgis-enterprise
... View more
05-04-2021
11:00 AM
|
0
|
0
|
1042
|
|
POST
|
Monika I just found your message - I'm sorry nobody has responded. Do you still need assistance with this? Cody B.
... View more
05-03-2021
10:20 AM
|
0
|
1
|
1299
|
|
POST
|
Vassilis - My first question would be to ask you to verify that you processed the correct GVL file to go along with the video - but presuming the answer is "yes" I expect that the problem here is that many drones report incorrect altitudes. If your altitude values are incorrect and too high, the apparent video footprint will be too large. Then, if you have any forward look angle (not directly down at Nadir?), the footprint may incorrectly indicate that the view is above the horizon. Would it be possible for you to send me your Geospatial Video Log (GVL) file? If you don't want to upload it publicly you can send me a private message. (I don't need the video) Please let me know your expected/planned flight altitude above ground. I should be able to determine if your altitude values are incorrect, and show you a method to correct them. I have not seen any cases where the pitch angle of the gimbal is recorded incorrectly, but it is possible there is an error in the metadata (and it may be possible to apply a correction). Another question - is this your one and only video flight? Have you done others that succeeded? If you have no other samples, could you try recording another test video? You should only need 15-30 seconds of video for a test. Cody B.
... View more
04-29-2021
09:20 AM
|
0
|
1
|
3342
|
|
POST
|
Daniel we'll need a lot more information to be able to help you - details like: which version of Pro? which data type - drone? scanned historical film? satellite? how many images? do you have adequate overlap along each flightline, and between multiple flightlines? did the tools succeed in finding tie points between images? (first step in the "adjust" tool) What did the process log say? I'd suggest you open a support ticket at http://support.esri.com/ so an analyst can help. Also note we've published a lot of resources about workflows and best practices for Ortho Mapping (and many other topics) at https://www.esriurl.com/imageryworkflows e.g. https://doc.arcgis.com/en/imagery/workflows/resources/creating-drone-imagery-products-with-ortho-mapping.htm Cody B.
... View more
04-05-2021
09:31 AM
|
0
|
1
|
1945
|
|
POST
|
Scott - sorry for the frustration - I know one of our support fellows was helping with this but I took a look and I can give you some answers but possibly not complete at this stage. 1) Unfortunately your site is in a region of latitude where we found a killer bug, and the geographic transformations don't work properly. Fortunately, this has been fixed in Pro 2.7.2 - could you download and install the new version? 2) Your drone is reporting incorrect altitudes. This is pretty common, and I'm unclear why it happens so much. (Most) Drones report altitude as ellipsoidal height from GPS since they don't know where the ground is, nor sea level. The terrain at your site shows ellipsoidal height of ~790 meters, but your metafile shows minimum altitudes ~690. (I assume you weren't 100 meters underground). See the attached - I've made a guess that the records showing 690 were when the drone landed, so I added 100 meters to your Z values. The attached file MIGHT work, but this Z error does not explain why something is crashing. 3) can you clarify what is crashing? Here you say the Video Multiplexer tool, but your post on the webinar page said "ArcGIS FMV is crashing". Is it the whole program, crashing when you load the multiplexed video? or is the tool crashing and you're not getting an output video file? I tried your metafile with my own video, and it worked except for showing the drone underground. When I added 100 meters, it worked to bring the drone above ground and nothing is crashing. It's possible your crashing problem is due to an additional conflict somewhere - but could you try my modified metadata file? 4) I try not to "pass the buck" but it could be something in your video file. If it still crashes with my metafile, could you try downloading this video file and using it in the multiplexer? http://s3.amazonaws.com/ImageManagementWorkflowsTeam/FMV/multiplexer.sample/GOPro0037.mp4 If it works, then that would point to something wrong in your video file. Hoping this helps - let us know. Cody Benkelman
... View more
03-18-2021
05:10 PM
|
0
|
0
|
3381
|
|
POST
|
Hi Colleen I should be able to help you, but I may need to clarify my understanding of what you're doing. From what you said, I think this advice should help: First, note that geospatial video is processed differently than single JPG images. If the video is captured by a DJI drone using the free flight app available for iPad, it will simultaneously record the required metadata to process and view the video using the Full Motion Video capability of ArcGIS Pro (with Spatial Analyst). Unfortunately, video captured without using that iPad app will not have enough metadata about both drone location (XYZ from GPS) and the orientation of the video camera (heading, pitch & lens field of view) to work in ArcGIS. Single JPG images from a drone are referred to as "geotagged" but that GPS information is not enough to bring the images directly into ArcGIS Pro. If you have an advanced license, and you create an ortho mapping workspace (specify type=drone), ArcGIS Pro can apply photogrammetric processing to generate an orthomosaic of your images. This video should be helpful. In your question you say "When I use a new workspace I am able to see the images" - If you were not referring to the ortho mapping workspace, please let me know. When you say "I add the images individually" I'm assuming you mean you simply drag/drop single images into the map? You're correct, that will not work with simple geotagged images - they need to be processed first, using photogrammetry, along with many other overlapping images, to achieve proper georeferencing to create an orthomosaic. If you are seeking to use the individual photos after processing (vs. the orthomosaic of many images), let me know and I can explain how to do that. Last, I'm not sure what you mean by "many stacked images". If you mean many images in the same location, are they already georeferenced, so they are all placed into the correct location on the map? If that is true, you should not need ortho mapping. If they are multiple photos of the same location but not yet georeferenced, ortho mapping may work for you but this would be an unusual use case. Let me know more about your input data and your objectives, and I will do my best to advise you. If you are seeking to use the raster calculator, I believe that should be applied after georeferencing (either using ortho mapping or possibly another method). Thanks Cody B.
... View more
02-08-2021
01:52 PM
|
0
|
1
|
3068
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 03-02-2026 03:35 PM | |
| 1 | 03-02-2026 11:46 AM | |
| 2 | 02-05-2026 05:21 PM | |
| 2 | 11-20-2025 03:34 PM | |
| 2 | 02-07-2025 06:14 AM |
| Online Status |
Online
|
| Date Last Visited |
8 hours ago
|