Latest Contributions by RayMontgomery

Even worse, TIFs georeferenced years ago don't display correctly at 10.7.1  We have over 1,500 TIF files (subdivision plats) that we georeferenced over the last several years. These have the full set of TFWX, etc files for each plat. At 10.3, we could click a button on a tool we made, click on the map, and the sub plat would load into the map in the correct location. After upgrading to 10.7.1, this only works part of the time. The rest of the time, the plat loads, but we have to use "zoom to layer" to see it. It has moved outside our city boundary and become many times the size of the entire city!  Changing the "no data" color to make it visible, the supposed extent is even larger- a square about the size of our state. Sometimes the image appears as a spotty black and white diagonal smear. I have opened the TFWX file, and everything looks normal. These are not newly-scanned, so the issue is not caused by new scanning software variations. These are older scans that worked fine before. If we load one of these misplaced, or misplaced and misshapen TIF images using an older machine that still has 10.3 on it, they behave correctly.  The fault is apparently not in the TIF, the TFWX, etc, but in ArcMap itself. ... View more

We have over 1,500 TIF files (subdivision plats) that we georeferenced over the last several years. These have the full set of TFWX, etc files for each plat. At 10.3, we could click a button on a tool we made, click on the map, and the sub plat would load into the map in the correct location. After upgrading to 10.7.1, this only works part of the time. The rest of the time, the plat loads, but we have to use "zoom to layer" to see it. It has moved outside our city boundary and become many times the size of the entire city!  Changing the "no data" color to make it visible, the supposed extent is even larger- a square about the size of our state. Sometimes the image appears as a spotty black and white diagonal smear. I have opened the TFWX file, and everything looks normal. These are not newly-scanned, so the issue is not caused by new software variations as in the other posts. These are older scans that worked fine before. Blaming the TIF format may be looking in the wrong place. If we load one of these misplaced, or misplaced and misshapen TIF images using an older machine that still has 10.3 on it, they behave correctly.  The fault is apparently not in the TIF, the TFWX, etc, but in ArcMap itself. ... View more

The "Add data" issue was solved by uninstalling the Office 2007 system driver. ... View more

BE CAUTIOUS. Yes, the Office 2007 system driver works... but then later, when you start MS Access (at least at version 2016 32-bit), it automatically does a repair and reinstalls some Office components that apparently overwrite the system driver. The ability to read the XLSX files from ArcMap is removed.  And to add to the fun, any MXD that had links to the XLSX files now *SO* fails to open that you get the dialog to report it to ESRI. Also, If the last place you added data to ArcMap from was the XLSX file, then trying to simply add new data to a clean ArcMap session gives you a blank list, and you cannot navigate anywhere else.  ArcMap's Add Data button is stuck looking in limbo-land.  Even deleting my Normal.MXT template (to restore ArcMap to original configuration) DOES NOT fix that. Still trying to solve. ... View more

At 10.3.1, with data stored in SQL Server 2008R2, WITH data stored as Geometry type, this happens even when simply copying a FC to another FC in the same Feature Dateset.  I did use Data>Export, so maybe it has to do with the export function. That newly-copied FC has 3 versions of these key fields: "Shape_STArea__", "Shape_STArea_1", Shape.STArea(); as well as "Shape_STLength__", "Shape_STLength_1", and the popular "Shape.STLength()". Randomly checking, it looks like the values are the same, however, unlike Justin's. In Catalog, I was able to delete the pair ending with the double underscore, but not the others. ... View more

The 4-color tool from 2007(?) DOES work at 10.1.  I registered the 2 dll's using the standard Windows Regsvr32. It uses topology, so I think the FC you are "coloring in" has to be inside a Feature Dataset, like you'd do if you were building topology. It also has to have a destination field ready. It also has to be done in an edit session, since you are asking it to edit attributes. At least that's what we did, and it worked fine. BUT, as the Idea suggests, this would be a great addition as a way to render polys automatically,; let teh user select the "# of non-touching colors". ... View more

We are at ArcGIS 10, SP4 and this issue is still not fixed. Symbols from certain layers fall outside the data frame when exporting to PDF, either using ArcMap or PDFfill. Anno behaves correctly. It also does this when printing or exporting to JPG. All data is in ArcSDE at 10. We have tried changing layer order, removing layers, recreating the MXD, using the data-driven pages clip option in Data Frame properties and all other sorts of options and nothing we did or things suggested above works.  The misbehaving layer jumps to other layers when some layers were removed as a test, so it's not the data layer itself causing the issue. We finally uninstalled the "upgrade" and reverted to 10 SP1, that works OK.  ArcMap 10 SP 2, 3, and 4 all have this issue. Ray Montgomery, GISP Sandy City, Utah ... View more

I agree with the comments about this being absurd not to be able to see which users are using what licenses.  This WAS available at 9.x, and for some unfathomable reason was removed, a REALLY bad idea.  I want to see username, all licenses they are using, and the date/time they were checked out. ... View more

Please give some thought to allowing a workflow to allow NOT promoting the raster bit depth even when using the "clip to polygon".  Why not leave this under the user's control? For example, we have some ordinary 8-bit BW historical aerials I want to load to SDE.  I need to clip off the areas valued "0" around the edge (areas should have been "nodata") of some of the images, in order to get a better color matching result when mosaicing to SDE. (If I just load them directly to SDE using the "ignore background value" option, it works, but the imagery has bad tonal matching between photos, hence the need for the color balance/matching etc.) Note that NONE of the area to be extracted from the image is currently nodata. If I clip using a poly and do the geometry clipping, it promotes to 16 bit, which DOUBLES the size on disk (even though NONE is currently nodata, so it should NOT need to do this). Then I'd be trying to mosaic 8 and 16 bit imagery into the same SDE dataset, so it would end up doubling the whole set to 16 bit, taking up 2x the disk space needed. But if I set the 0 to be no data, then any black areas in the photo also get to be nodata, leaving holes. So the only workflow I have come up with is to clip the images, then reclassify each one twice (once to set the current nodata value to 255 and the existing 255 to 254, then again to set the 255 to nodata) to force it back to 8 bit.  So I waste several hours fighting this. Why does this have to be so hard?  Why can't there be an option similar to the "ignore background color" when doing the clip? ... View more