Does your mosaic dataset look like a checkerboard?

Do any of your mosaic dataset items have a checkerboard pattern? If this is the case, it means that there is a problem accessing your mosaic dataset items.

Any failure in opening a mosaic dataset item will result in a checkerboard pattern within your mosaic dataset item display. Previously they used to be displayed as grey. This will occur for both source mosaic dataset items and also for overviews as well.

A failure opening an item usually occurs if the file is missing, or if you do not have read permissions to the location.

To solve this issue, you will need to point your mosaic dataset to an existing file that you have access to.

This entry was posted in Geodata, Imagery and tagged , , . Bookmark the permalink.

Leave a Reply

14 Comments

  1. cjcarsley says:

    I have been dealing with this issue for over a week, and I can’t seem to get it solved. No matter what I do, I always end up with a checkerboard pattern in place of the overviews. The previous 6 mosaic datasets did not have this issue. The only difference, so far as I can determine, is the transfer of data from one location to another. Naturally, and based on the content of this blog, I assume the problem lies therein. I have, however, already repaired the paths and ensured they are the appropriate, UNC format.

    Can I try anything else to help solve this issue?

    • Simon Woo says:

      Off hand, I can only think of 2 possible issues:
      - either the your overviews for your mosaic dataset have not linked up properly or re-mapped
      - or the new location of your source data cannot be accessed by ArcGIS for some reason (usually a permissions issue).

      If either of theses are not the case, I would suggest that you give our Technical Support staff a call.

  2. thoober says:

    I am not using overviews and I am certain that ArcGis has access to the data. I have made a connection to the source in the catalog tree. When I run repair paths it does not seem to fix the checkering at all. I am going from an old folder to a new folder (the server name has changed). It will update the paths but it does it in a very weird manner. It creates extra items in the mosaic.

    Example, export paths before repair path
    10 items half images half footprints
    After repair path
    15 items 1/3 images 1/3 paths 1/3 footprints

    The oddest thing is that the old paths to the images are updated but each SourceOID gets duplicated. The first SourceOID path just shows the folder path I put in but the second path shows the full path to the image. When I try to view this mosaic either I see checkerboard or the program crashes. This is happening on every mosaic I repair. Any suggestions?

    • Simon Woo says:

      I have not heard of such an issue before (with the extra paths issue). Nor have I heard of any crashes after you try to repair the paths.

      Since you already checked the 2 possible issues that were recommended above, I think the best course of action would be to contact our Support Staff so that we can look deeper into this issue. Thank you.

  3. blake3030 says:

    I’m having an issue where the mosaic dataset works fine, but when I run “Manage tile cache” the result is checkerboard images as per the example on this page. I have no idea why this is occuring. I moved computers recently and initially got the checkerboard result for mosaic datasets, but I have repaired all of the paths and now they are fine and viewable in ArcMap. The issue only occurs after “Manage tile cache” is run.

    • Simon Woo says:

      Blake, it does not sound like a visibility issue, but perhaps the tile cache was not repaired. Can you please contact support and let them know about your issue in detail? Once we identify where people are running into issues we can try and prevent this from happening in the future – or at least try and document\blog how to fix such issues.

      Thanks!

      By the way, anyone else that had this type of issue please do likewise and call support. Or if you know how to fix the cache, please let everyone know.

      • richnezelek says:

        I had the same checkerboard problem with 10.1 when publishing a mosaic as a map service. Gave up. Having the same issues with 10.2. Tried every option I could find relating to caching and nothing helped. Tried publishing as an image service also but had the same problem.

        • richnezelek says:

          Looks like this problem is happening because the raster is not actually loading to the database and is only being referenced to my disk. I created a plain raster mosaic in the database then added a raster. I did not create a referenced mosaic so why would this happen?

          • Simon Woo says:

            As mentioned previously, please have our Technical Support staff help you out with problems. So far no one has called in this incident, so we are not sure what type of pitfalls everyone seems to be having with this.

            As for the rasters not loading into the geodatabase – that is how a mosaic dataset works. The raw source sits on disk, and the table finds the data and processes it on-the-fly.

  4. ruckc says:

    So, i’m running into this issue. I’ve opened a ticket (that has been sitting pending for four hours).

    My logs are showing Missing Raster:

    For me, i know why its not working. The Overview rasters paths it is looking for arn’t stored with relative paths, and the paths between client and server are different.

    • tomobrien00 says:

      I found that rebuilding the mosaic dataset fixes this issue. Right click on the mosaic dataset in ArcCatalog and choose Modify –> Repair. This gives you an option to choose a new path to the source rasters and the mosaic dataset overviews. Hopefully this helps.

      • azin.sharaf says:

        It’s fixed for me. I repaired the Mosiac Dataset as Tomborien00 said and changed old path from Z:\……(Network Drive) to full UNC path: \\…..

  5. bbq says:

    I’ve experienced this issue, received technical support from Esri to resolve it, and can reproduce it in my situation.

    Here at City and County of San Francisco, our land surveyors have recently sanctified a new local projection. I like it very much and would like to share it with various departments in our enterprise. Using a stamped record of survey for reference, I’ve input its parameters and created custom projections for its metric and US Survey Foot variants.

    When the mosaic dataset was used on ArcGIS 10.2.2 for Server, It turns out to be an issue that our cool new projection does not have a Well-Known ID (WKID) assigned to it whenever data stored in our local projection are used in Add Rasters to Mosaic Dataset. In my case, the rasters are in and have had the local projection defined for them, and in ArcGIS 10.2.2 for Desktop they show up and reproject on the fly just fine.

    I can access the checkerboard pattern (as if I was looking for it!) by defining a new Mosaic Dataset and leaving the Advanced Options > “Coordinate System for Input Data (optional)” empty. Heck, the image works great in Desktop, and the input box says (optional), doesn’t it? The raster will add to the Mosaic Dataset without warning, but will display as checkerboard.

    I can make the checkerboard go away by creating a new Mosaic Dataset, and explicitly defining the input coordinate system (optional), each and every time that I’m accessing imagery stored in a custom projection, which is anything without a WKID.
    If the WKID is in the concatenated EPSG + ESRI tables baked in to ArcGIS, then the input coordinate system definition is as optional as it is labeled in the interface. For reference, WKID integer values less than 32767 are reserved for EPSG use, and the larger six-digit numbers are being used by ESRI to help us use more coordinate systems that are newer but not yet enshrined in the EPSG database. This means that all those NAD 1983 (2011) state plane systems that you’ll see with WKID like 103550 have been defined by ESRI and aren’t yet available through EPSG.

    I hope that some parts of my experience can help your situation.