Latest Contributions by PeterBecker

‎11-13-2021

Presume you are looking at the NAIP Services in the Living Atlas. These provide access to the source NAIP imagery for multiple years and different renderings. There will be differences in the R,G,B,IR values returned for different years not only due to change in dates, but the fact that the images may not be flows at exactly the same time of the year, the fact that different sensors were used and the data values are not calibrated say to surface reflectance. One way to normalize small differences in an areas is to use the DRA (Dynamic Range Adjustment) stretch. Also look to change the renderer to NDVI, you should find that the NDVI values (or colorized NDVI) provides a better distinction of vegetation change.

‎11-01-2021

Number of Records in Merge: You can have more than 100 records, but I would check performance. If there are too many records the performance will degrade. Also if you can consider merging the many small files into a single larger dataset. (eg using mosaic GPtool). It would result in a duplicate of the data, but can be a lot simpler so long as you don't have too much data. Importing Geometry: If you have a footprint (eg project limit) then you can use the 'Import Mosaic Dataset Geometry' to replace the footprint with that from a feature class. You will need a common attribute to 'join' by. Also the footprints are editable, so you can use standard clipping tools within ArcGIS Pro to just clip the extent footprint by a feature.

‎10-28-2021

To resolve the issue on edges of the footprint, use the shrink footprints option (part of build footprints) to bring the footprints in a small amount. The vertical artifact you have is likely to be from the edge between two input image tiles. Do ensure you run Build Footprints for such tiled imagery with the maintain sheet cut option. Also it is better to have much bigger image tiles and preferably remove the tiling with no overlap. It can always create some issues when re-projecting. There is also a merge function that you can merge many rasters into a single time. I would not recommend with too many rasters (>100) Also note that you can have the edges blended if you want. To do this convert the footprint to seamlines or create a new seamline polygon that defines the required edge and then set up blend. (This is another reason you will want to merge or reduce the number of images). Set the blend to be inside and define the required width

‎10-27-2021

Issue here is that you need to get the 'item' function chain to recognize the 4th band to be a mask. The standard raster dataset raster type will not do this. You will need to create a raster function template the takes the 4th band and uses the mask function to set this as the mask on the source. The source (and derived) mosaic dataset can remain as 3band. Simplest way to test this is to temporarily include an additional (larger but lower resolution that covers the masked area) and set it LoPS value to 0 so that it is displayed at all scales. If the function is set correctly then this will not be covered by white. Do ensure the default properties also are set to allow no data within the footprint extent. The second (and possibly better) solution to this is to run build footprints by radiometry. This will refine the footprint to represent the extent of the data and then clip out all data outside the footprint. There are a number of advantages to this, but you may want to approximate the extents so that there are not many thousands of vertices.

‎09-13-2021

I took a look. I can not fully explain the specific artifact you showed at the start of post. I noticed you set the request size to -1 which means it will use the full image. This can lead to a more detailed footprint, but I think internally it need to break the image into smaller tiles and you are seeing an artifact from the tiling. The simplest way to resolve this in this case is just to simply edit the vertices. Footprints can be edited like any other feature class. Alternatively if you have a shape that defines the image extent then you can just clip the footprint by this extent. (I would appear that the original image was clipped to some well defined extent, to you may have this). As an automated way to get the best results I would suggest using the following parameters. This results in about 2m of the image being clipped off the sides, but otherwise it work quick and has less artifacts. I would suggest you take care in not having too many vertices in the footprint. Every time you pan the system will need to clip the image by these footprint. If you have 10,000 vertices then that is a lot of clipping.

‎09-13-2021

This is strange. I'm also surprised to see jagged edge at that location. Can you change the Approx vertices to a smaller value say 10 to see if this resolves. Also is the imagery JPEG compressed? If so please try changing the minDataValue to about 10. I think the issue is that the image is large, but when doing recompute footprint it resamples the image to a size of 2000x2000 pixels. It is possible that due to the angle of the edge the resampling creates a slight jagged line that is then being detected. Possibly send me the file and I can try to identify what is causing this.

‎08-14-2021

You can stack any bands together in a function chain either as part of a layer or a mosaic datasets. So long as the bands are georeferenced there is no need for the pixel size to be the same. As always you do need to consider what resampling method you apply when accessing the images. (Would suggest bilinear). The order of the bands would be as you define them in the function chain. I'm not sure if the current raster products (IE what you get when you click on a landsat .met file in catalog) creates a layer that includes both MS and Thermal bands. Would be interesting to know what function chain you foresee to compute this.

‎07-20-2021

It would appear that the source images have a white border, are JPEG compressed, and you have defined white as being no data. The footprint currently is probably the envelope of the image. What is happening is that as in the pyramids of each image the lower resolution images are being created using JPEG compression and the pure white is no longer white so at lower scales they are no longer NoData/Transparent. The solution to this is to Build footprints by radiometry (say approx 20 vertices and shrink distance of 100m. This should result in a footprint being created around each image and it being clipped by the footprint so excluding all the white areas more cleanly. You should find that after this modification the dynamic mosaic will display faster. Now if you re-build the overviews the artifacts should go away. Also note that you can generate seamlines which will also determine the optimum location for the join. To further reduce any noticeable transition look to set a blend width (say 10pixels) on the seamlines. Also consider running the color correction tools which will further remove trends between different images.

‎06-11-2021

The display in Pro and via Web should be very similar (the same). I noticed in the screen shot that the source imagery is 4cm and has pyramids to 32cm. The display range for this is up to 96cm and the overviews appear to start at 2.88m. There appears to be a gap. I would suggest doing define pyramids with a pixel size of 32cm. Then Build Pyramids and see if that works. Do create a copy of the mosaic dataset and delete the source image to see what scale you see the overviews.

‎06-10-2021

Please split into two parts a) Just create mosaic only using raster proxies. They should display only at larger scales (based on maxPS). Check in the raster proxy where the cache is to be written to. It must be a dedicated drive on each machine. Not a shared drive. Check this works on Pro and Server. b) Determine how you want to handle overviews. These will be written to a local drive and you can handle similar to other rasters then. Another alternative is to create a CRF and use that as an overview

‎06-09-2021

I'm not sure why the 1 above works, but 3 does not. Likely related to the resolution of the export. Is it possible that the export is a different resolution? Also are you sure this is the same services. Doing export of an image with DRA is always problematic as larger requests get split into multiple smaller requests

‎06-09-2021

The issue is that you are using as input a layer that includes dynamic range adjustment. The Sentinel2 imagery is returned as apparent reflectance (with values ranging from 0 to 10,000) that cover the complete dynamic range. For optimized display the stats of the current view are used to stretch (eg using standard deviation) the image for suitable display on the screen. When you do export the system is splitting the extent into blocks and each block is having the dynamic range adjustment applied. Hence the result you see. What you need to do is use a layer that does not have DRA applied. Check the different included raster functions. You can then also define specific stretch values to get the rendering you need.

‎05-24-2021

If you have large volumes of data I would suggest you take a look at OptimizeRasters. This is a set of tools specifically designed to enable such conversion at scale. This provides a GPTool that runs in Pro , but can also be scripted in the command line. The tool has been used for the conversion of many PetaBytes of data. One of the reasons to convert to MRF is typically to make use of the optimization available in using Raster Proxies that improve access performance by caching previously accessed tiles locally. The documentation provided explained how this can be set up.

‎05-24-2021

See Using Lidar data in ArcGIS Pro & Las to Raster Function Also take a look at Managing Lidar Data Imagery Workflow

‎04-14-2021

Check the options in ArcGIS Pro that World files are being used. You will need to set this before you add the image. If the image falls in the correct place then you can ignore the analyzer warning.

Online Status	Offline
Date Last Visited	‎02-14-2024 12:20 AM

My Ideas

Latest Contributions by PeterBecker

Re: Differences in Infrared NAIP Imagery 2017-2019

Re: Alpha channel management with a Derived Mosaic Dataset

Re: Alpha channel management with a Derived Mosaic Dataset

Re: Alpha channel management with a Derived Mosaic Dataset

Re: Build footprints cuts away a part of an image

Re: Build footprints cuts away a part of an image

Re: Layer stacking of Landsat 8 bands for SEBAL process

Re: "fuzzy" border around georeferenced air photos

Re: Raster proxies not being honored by Mosaic dataset (image service).

Re: Raster proxies not being honored by Mosaic dataset (image service).

Re: Sentinel Imagery Blocky

Re: Sentinel Imagery Blocky

Re: Orthoimagery Raster Convert: GeoTiff to MRF Batch

Re: Elevation values

Re: Warning 71153 - Raster associated with mosaic dataset not georeferenced

Re: Allowed Mosaic Method by Attribute: Custom fie...

Re: Build footprints cuts away a part of an image

Re: Does any of the Experience builder widgets sup...

Re: Imagery with NoData pixel values when displayi...

Re: Poor seam in mosaic between imagery sources

Imagery and Remote Sensing User Group