ArcGIS has been out for a few of years now, but is still buggy and feature incomplete. It is not really feasible yet to drop ArcInfo or even ArcView3. There are some really cool features in v8, it's just too bad the programs are still so unreliable. Hopefully being squeaky wheels will help shorten how long it takes get the ArcGIS family out of beta.
Unless otherwise specified Incident# refers to 'ESRI Canada Incident Number' and CQ# to 'ESRI International Bug/Enhancement Number'.
Contents:
What is the total surface area for each raster-class (value) within polyons X, Y & Z? Zonal Statistics will give me what I need if I break each classification out into it's own raster but that's kind of extreme.
The scenario is: I have a series land cover classification rasters derived from satellite images. I need to know how many square kilometers of each vegetation type there is in each game management district (which are defined by polygons).
"...this has been added to the software interface in the 9.0 release. In the interim you can continue to accomplish this somewhat manually using zonal statistics or through code using the IZonalOp::TabulateArea method. A sample of this method can be found in the ArcObjects? Developers Kit Help."
The procedure to calculate area of zones in a grid is outlined in the ArcGIS Desktop Help.
...which is very expensive needing lots of ram, disk space and cpu time, but it lead to something that will work. Namely:
&set item = 0 &set cellX = 30; &set cellY = 30 &do zone &list [listunique somegrid.vat -info count] &set item = %item% + 1 &set area_%item% = %zone% * %cellX% * %cellY% &end &listvar area_*Since the math behind this is so trivial it really should be part of the info returned by the Identity tool.
You are correct in that this functionality is not available in the software as of yet. ... "ArcGIS needs cross tab functionality so labels/symbology, etc. can be used when you have a 1:M or M:N relate". As of today, the status of this enhancement is 'postponed'. This means that it has been logged with development and is considered a valid issue but it will not be considered immediately. I have sent a request on your behalf to Redlands to have you added to this enhancement as a user who would like to see this fixed sooner rather than later. Right now the only option is to reverse the relate and make a join since joined fields can be seen in labelling and symbology."
ArcMapOneToMany? - exploring possible workarounds
mhwilkie - 22 Jul 2003
MattWilkie - 30 Jun 2003
MattWilkie - 30 Jun 2003
In ArcMap 8.2, the "word spacing" and some other character formatting commands have no effect on splined text. On the fly projected text and any text with more than 2 control points is subject to the same limitation. See SplineTextFormattingBug? .
MattWilkie - 01 Oct 2002
In ArcMap 8.2, one can't select annotation elements on a named annotation group when the default annotation group is not visible. See SelectAnnotationBug? .
MattWilkie - 01 Oct 2002
If the user doesn't do anything right away which checks the grid's projection the bad projection file can go months without being discovered. Any subsequently derived grids will also have invalid prj.adf files. To fix this kind of grid simply remove the "prj.adf" file. If you are lucky you will know what the projection is supposed to be and can PROJECTDEFINE it.
Note: this same bug is likely to occur with other comamnds too, FLOATGRID for instance.
-- MattWilkie - 12 Mar 2004
(fatal) Converting labels to annotation for an undisplayed theme crashes arcmap
I repeated your steps but it crashed without the BOOM!
- actually someone beat you to that bug as of September 9th 2003 (CQ00174940). Hopefully this will be fixed for 9.0. I personally believe that the option should simply be greyed out... -- JC
mhwilkie - 10 Oct 2003
"Error: ArcMap.exe has generated errors and will be closed by Windows"
This error can be caused by one or more system conflicts. This is a general Windows error that can have an innumerable amount of causes and solutions. Contrary to the error message, there is no log file created. See the ESRI support doc linked above for the complete troubleshooting procedures.
MattWilkie - 04 Nov 2002
In ArcMap 8.2, when the properties for a raster layer are set to "Display resolution in table of contents" the Layout Zoom tools appear to be zooming the dataframe instead of the layout. More details in LayoutShiftBug? .
MattWilkie - 26 Sep,1 Oct 2002
ArcMap pukes on files with certain non-alphanumeric characters in their name, most aggravating the hyphen "-" is one of them. http://forums.esri.com/Thread.asp?c=93&f=1149&t=68750&mc=3#178830
MattWilkie - 23 Jul 2002
shapearc ignores precision of source file The ArcInfo command shapearc creates a single precision coverage regardless of the shapefile's precision unless the environment is set with precision double double. E.g. precision double highest is ineffective.
Work around: use the commands layer define and layerexport instead.
MattWilkie - 19 Sep 2002
layerexport ignores projection when shapefile to coverage The ArcInfo command layerexport always creates coverage with no projection regardless of whether the shapefile.prj exists or not.
Test case:
LAYER DEFINE xxlayer1 shapefile merged_qoa.shp LINE LAYEREXPORT xxlayer1 COVERAGE merged_qoa Line
MattWilkie - 19 Sep 2002
When Editing in ArcMap in a table, if you do not save your edits and "Stop" Editing before closing your table, it will crash ArcMap. This is very frustrating because you loose all your other edits.
Solution for the time being: NEVER close your attribute tables in ArcMap while in Edit Mode.
-- Manon - 14 Aug 2003
Might have something to do with unsipported characters in the name, like a space (which begs the question of why you are allowed to create a feature dataset with a space in it...)
mhwilkie - 14 Aug 2003
http://forums.esri.com/Thread.asp?c=93&f=987&t=65600&mc=6
MattWilkie - 24 Jul 2002
The title of this bug is not necessarily accurate. i.e. the crash may have nothing to do with the coordinates' distance apart, that is just my best guess as to what the cause is.
ESRI Canada Incident# 39823: (matt's pooter)/GIS/ESRI-tech/Incident#39823/
ESRI's response is "convert to shapefile, edit, and then convert back to a cover". Sheesh.
I don't know how much we can trust ArcEditor? v8. There is something weird going on here. I ran the nodeerrors? ArcMap macro on the nqfntt cover (AdminBoundaries? poject) and found a polygon with one gap in it. Because of the extend/trim bug I DROPFEATURE the polygon cover, did the extend edit, and then CLEANED the cover, building a poly. A couple of the polys did not close so I ran the nodeerror macro again - 5 dangle errors showed up, all gaps of less than 1 cm. I fixed one of the gaps and CLEANED again, this time the polygons were all closed. So where the hell did those other four dangle errors go? The second clean should not have fixed them because the tolerance was maxed out (e.g. <0.000000001 when the gaps were 0.00x -- as reported by the Arcmap measure tool).
Status: Unresolved.
MattWilkie - 23,31 Jul 2002
If you zoom in enough, there is a good chance you won't be to select or edit the elements which you can see plain as day in front of your face. Very frustrating.
Status: Unresolved.
MattWilkie - 01 Aug 2002
Related to the above bug. Sometimes a graphic element which is a long way away (e.g 700km)from where you are looking, off screen for instance, is selected instead.
Both of these bugs are frequently experienced when trying to select and delete the markers left behind from the NodeErrors? macro.
I suspect these occur when the snapping tolerance is set to map units instead of pixels.
Status: Unresolved.
MattWilkie - 01 Aug 2002
Not much more to say here except save early and save often.
Status: Unresolved.
MattWilkie - 01 Aug 2002
See AdminBoundaries? for details.
Status: Unresolved.
MattWilkie - 20 Aug 2002
This one is very disturbing. In ArcMap linework from different datasources, which were all generated from the same source dataset, do not line up on top of each other. To see it, open 250k watercourses from the ArcLibrary? , Skyraider SDE, and an AdminBoundaries? coverage (must be new, not from z:\arcdata\...). Zoom in until the lines drift apart. yech.
True the vertexes are only a centimeter to a millimeter apart. Now. But what happens after years of data processing? Do centimeter gaps turn into meter gaps?
See CoordinateDrift? for an attempt to isolate and identify the culprit.
Status: Partially resolved. Not a bug but a (probably unaddressable) limitation of the data models.
MattWilkie - 16 Sep 2002
On opening the project 4 error messages are seen: "Raster Data Objects Error. Invalid Raster dataset. Failed to insert picture element." After okaying the error messages the map compisition opens, with all of it's data layers intact and visible. 2x-click anywhere in the Layout View panel, select Size & Position ,whammo - SilentDieOnSize?
MattWilkie - 04 Nov 2002
when producing a UTM grid and you want to round the number off, ArcMap rounds off from the first digit rather than the decimal point. So for example northings are rounded off to the nearest thousand while easting are rounded to the nearest ten thousand when what actually want is both of them rounded to the nearest thousand.
Gerry Perrier discovered this and is supposed to write it up
-- 13 June 2003
regiondissolve and the output cover is the same as the input cover, the resultant attribute values are screwed up. If the output cover is a new cover, and the output class has a different name, the attributes are correct.
| test case | (matt's pooter)\GIS\ESRI-tech\regiondissolve |
| Arc version | ARC 8.3 (Wed Dec 18 08:17:08 PST 2002) |
Incorrect results:
Arc: regiondissolve watersheds # order_2 order_2 poly
Arc: list watersheds.pat 1 2 order_2
Record order_2
1
2 PORCUPINE R. # <- original attribute
Arc: list watersheds.patorder_2 1 2 order_2
Record order_2
1 ☺ ☺ PORCUPINE R. # <- resultant attribute
2 ☻ ☻ PEEL R.
Correct results:
Arc: regiondissolve watersheds test order_x order_2 poly
Arc: list test.patorder_x 1 2 order_2
Record order_2
1 PORCUPINE R.
2 PEEL R.
Oh brother. I duplicated the error 3 times before I sent it to ESRI. Today, using exactly the same data and exactly the same steps, it all works like it is supposed to.
Project: GIS2003-020, Eagle Plains Ecoregion, Landsat-Mosaic.mxd
When converting qpark labels to annotation geodatabase.
Two prior runs were successful, and speedy. However polygons which were not entirely within the dataframe did not have labels placed. The View > Overflow Labels window remained empty.
Convert Labels to Annotation dialog:
tried to reproduce the problem. First try, duplicated convert step, without the gdb being open for editing. Worked like a damn.
Second try, exactly the same settings: ArcMap froze on redraw. status line said: "drawining annotation in Ecoregions."; cpu:50%, ram:99mb (1 process).
Again, while ArcMap window was open.
1. qpark > label = yes 1. qpark > convert labels to annotation 1. qpark > label =
okay, I've narrowed it down to: you can't have the source cover and the output gdb enabled at the same time.
ESRI:27674 - ArcMap makes a raster layer and all layers below that layer into a bitmap on output.
Reportedly addressed in the upcoming ArcGIS v9 service pack 2.
Gerry Perrier - 24 Nov 2004
Turns out there is a shift in data when using the editing tools (editor menu --> clipping, intersecting) in Arc9. This is because it uses the single precision of the data frame rather than that of your dataset.
From the sounds of the ESRI Knowledge Base it has a work around by doing your editing inside a personal geodatabase and setting your precision to double, however I don't believe that it is possible to do in a shapefile.
So for us there are three options:
The former is likely the best option however from an end user perspective none of these options sound very good.
Cheers,
-- DiedreDavidson - 19 Nov 2004
As of v9.1 this bug still exists:
"Thank you for contacting ESRI Canada Technical Support. In regards to your question about CQ00176597, unfortunately it is still listed as a known limit. There are a few other documented CQ documents related to this problem with other Geoprocessing tools and ArcSDE? layers and some of them suggest that the possible fix is to happen in ArcGIS version 9.2. This is a known limitation with shapefiles, ArcSDE? layers and geometry. It is a precision issue."
Note that I have observed geometry shifing in personal geodatabases as well (I still have some more testing to do though to be sure I didn't screw up in some other way). I think the only safe way to edit in a pgdb is to ensure all feature classes are contained within a single feature dataset.
Later:
Thanks to Ray Carnes on the 'shifting, shifting, shifting' thread below I've determined that putting all feature classes within a single feature dataset does cause all layers to be remain coincident -- at least for the import stage. We'll see what happens with edits over time.
The root cause is that when simply importing a new layer into a pgdb the spatial domain and precision is different everytime, and therefore the snapping grid is different. ESRI:27335
Note that setting a cluster tolerance of 1cm (0.01) is NOT the same as spatial domain precision of 1cm (100). The former ensures that there are no vertices WITHIN 1cm of each other (A is 2.4 thefore B must be 3.4 or 1.4), while the latter does the same AND ensures that coordinates themselves fall on even cm boundaries (A is 2.0 therefore B must be 3.0 or 1.0)
-- MattWilkie - 10 Feb 2006
For clarity, there are two problems being discussed here. The first is the real and unavoidable bug that when editing shapefiles in ArcMap certain operations cause the geometry to shift. The second circumstance of coordinate shifting within personal geodatabases is avoidable by ensuring all layers share the same spatial domain and precision.
-- MattWilkie - 13 Feb 2006
Another twist to this issue: "... are not able to snap a GDB polygon vertex to a shapefile vertex. Sure, when you move the vertex it 'snaps', and displays coincident with the .shp vertex, but sure enough, when you 'Finish Sketch', it hasn't truly moved. It can only get 'so-close', and that's it." -- brought to light by Justin Wolff on the SHIFTING! thread
-- MattWilkie - 05 Apr 2006
Related ESRI Bug ID's
Related Discussion:
-- TWikiGuest - 24 Nov 2004
| WebForm | |
|---|---|
| TopicCategory | ArcBug |