Latest Contributions by TimLangner

Clearly, given the number of people who voted on this idea, most people don't think it that important which is a shame as ESRI probably won't see any point in implementing it. ... View more

Tim, I didn't see your scerenshots nor the steps to reproduce the problem.  I would be interested in seeing the problem. Everyone should note that "trace" at 10 does not work at very large scales for obvious reasons. IE  you can't see what you are tracing and I also suspect it has more to do with the caches/builds referred to above. I submitted the steps to ESRI. I can't put screenshots because it's licensed data. I was only tracing at a scale of 1:300 and I do not consider this to be large. ESRI were able to reproduce the problem with my data. A simply solution would be to turn off one of my layers and then it don't occur but when I'm working I'm more interested in getting my digitising accurate than worrying about whether a layer has to be switched off at this precise moment or ArcMap will crash. I personally think the issue relates to the fact ArcMap is trying to chose which line to trace, with them being close and it crashes because it gets swamped with the decision. My work place doesn't have the resources to go on the ArcGIS 10.1 beta programme so I don't know if 10.1 would behave any better with this. Kind regards ... View more

Of course the largest change to the tracing at 10 was to automatically load all the visible features in the current extent into the trace without relying on the current selection.  This can cause these issues to happen more frequently than at 9.x since we are more strongly exercising this build process.  If you could share a reproducible case (or more) exhibiting this trace beeping it would greatly help us identify and fix these issues. Hi John I have encountered and reproduceable tracing issue which causes ArcMap 10.0.4 to crash almost every time. I've submitted details to ESRI UK, along with a sample of the data and steps I took, as well as screenshots. I put another thread up at: http://forums.arcgis.com/threads/53010-How-stable-is-tracing-in-ArcMap-10-when-running-with-SP4 Kind regards Tim ... View more

I have now managed to crash ArcMap at will whilst tracing and I have submitted the steps I took, along with a sample dataset to ESRI UK Technical support. I also enclosed two dumps because they could not be sent to ESRI at the point. I'm aware the the UK support cannot use these but ESRI in America may be able to. I even have a screenshot for one of the time's it crashed. Kind regards ... View more

Through my persevering this issue was forwarded to ESRI in America who confirmed there was already a bug number assigned to this, NIM076428. It's not however publicly searchable on-line only internally by ESRI. Not sure why this is the case but I've asked the technical support guy in the UK why it is. No time scale as to when it will be fixed but I guess at least it is known about. I think perhaps I should stop digitising, then I wouldn't find these bugs. I'm hoping that 10.1 will resolve a lot of these issues and won't just be a release with more functionality containing more bugs and not many fixes for previous ones. I'm aware that the software is complex and works very well in a lot of areas but when you keep being confronted by buys every day, even low level ones, you do start to wish they would fix more of them sooner. Kind regards ... View more

Hardolph, at first I thought your suggestion of generalisation worked. However it generalised to much, even when setting the offset to 0.0001. Thank you for suggesting it anyway as I'd not used the advanced toolbar before and although I won't be using it in this case, I might find a use for it in the future. Looks like the only option is to convert it to a shapefile. As it's one feature it doesn't matter but if it were a complete feature class it would, as not only would all curves be turned to line lines, all table names over 10 characters long would be truncated without warning. Perhaps ESRI need to issue a knowledge article or blog posting explaining that curves should be used with caution and what to do if you encounter problems. Kind regards Tim ... View more

Thank you for your informative reply Hardolph. I will use your suggestions and see what happens. Interestingly I've never had a problem with curves when using FreeHand or Illustrator to draw maps. Whilst over time it was possible for a FreeHand document to get corrupted, after some years of editing and resaving, curves were never a problem. They only seem to be a problem in ArcMap. It is an area that ESRI need to address. Whether they will for 10.1 remains to be seen. It would require someone who understands digitising and drawing of maps to take an interest in the issue and see that it got resolved. ArcMap may do far more than FreeHand or Illustrator with regards to data, if you discount the MapPublisher add on. However for digitising, it doesn't compare to them. FreeHand hasn't been in development since 2004 and it's still better! ... View more

I just wish to add that if I get an error saying "A geometry error has occurred" when reshaping a feature, then fairly often I will just draw the reshape and merge it with the existing feature. This usually solves gets round the reshape problem but whether it deals with the issue that caused the "A geometry error has occurred" message is another matter. Possibly not. Kind regards Tim ... View more

Thanks for your reply. I did raise this issue with UK support who are looking into it. However some examples of what I did to cause this are: A) A road, split up into a variety of feature types, required amending  based on newer aerial photography. One section required to have a curve  put in. From memory I did the following:1. Firstly I tried to reshape a  road feature by creating a new curve but it  kept stating it wasn't  possible to reshape the feature once I went to finish the reshape; 2. Therefore I changed tact and created the grass feature I wished to  create, including creating a curve using the End Point Arc Segment tool; 3. At this stage I may have adding some additional points to the  curve  I had just created, in order to make the polygon curve segment  transition to the straight  line segments smoother. However this may  have been done further down in the  process, once the road had then  modified to match the grass feature. 4. After doing that I then selected the road; 5. Now I selected the reshape tool and the trace tool; 6. Clicking on the road feature I wished to reshape, I then traced the  edge  of the grass. This now worked with no error generated. Where as at  first I was getting the reshape error. Before working on this road, there was no self intersections error. Since then it has transpired that for another feature at a different  site, the following error message I was getting when tracing, was due to  a self intersecting feature: "The Reshape task could not be completed. An internal error has occurred in the geometry system." B) Another example of generating a self intersecting feature was another road: With this all I believe I did was move a point using the following process: 1. An adjacent polygon, which was some grass, required to be moved down. This I did by moving it's vertices; 2. Then I either move two vertices of the polygon it now overlapped or clipped it to that polygon; 3. Finally I moved one point from the polygon which now has the self intersections error; I do have some screenshots but I'm not sure I should post them for data license and copyright reasons. This lead to the following reply, which partly came from Redlands. They referred me to the following article: http://support.esri.com/en/knowledgebase/techarticles/detail/29465 Note the article states it's for older versions than the version I'm using. "If the points you have digitised are taken strictly at face value there  does not appear to be any overlap or intersection. But you have chosen a  Tolerance of 0.001 for this Feature Class so the difference between the  points is at, or very close to, that value. Therefore the points can be  interpreted as being in the same place. Is there really a feature on the ground at this location that is just a  couple of mm long that you are trying to represent? If not then the  answer is to use the Check Geometry as a warning of poor (although not  strictly incorrect) digitising and correct the defect. If this is a  genuine feature then you need to use a smaller tolerance in order to  allow this." This lead to looking into the use of topology to perhaps try and prevent  the situation arising. Whilst I believe that could stop me being able  to create the conditions that cause the self intersection error to be  created, I don't feel it will actually fix the reason it can be created. Of course I can't do a check geometry on an SDE feature class and I have  an archive attached to my data, so repairing these geometric errors  isn't a trivial process. That;s due to the fact a complete archive can't  be exported. It since transpires that the xy resolution of the polygon feature class was set to: 0.000000002219847 The data originally came from an external supplier and I was unaware  that the resolution wasn't set to the default 0.0001, which the other  point and line feature classes are. I don't know if this impacts on the  issue at all. However if I'm moving points, I would expect them to snap whatever  resolution is used, as they are in the same feature class and I have all  the snapping turned on. I also have a large number of polygons where I'd traced existing  features in the same feature class and another feature and these have  quite a few self intersection errors, where as the data they were traced  from does not. That may also involved the moving of some points. Kind regards ... View more

Thanks for your reply. I did raise this issue with UK support who are looking into it. However some examples of what I did to cause this are: A) A road, split up into a variety of feature types, required amending based on newer aerial photography. One section required to have a curve put in. From memory I did the following:1. Firstly I tried to reshape a road feature by creating a new curve but it  kept stating it wasn't possible to reshape the feature once I went to finish the reshape; 2. Therefore I changed tact and created the grass feature I wished to create, including creating a curve using the End Point Arc Segment tool; 3. At this stage I may have adding some additional points to the  curve I had just created, in order to make the polygon curve segment transition to the straight  line segments smoother. However this may have been done further down in the  process, once the road had then modified to match the grass feature. 4. After doing that I then selected the road; 5. Now I selected the reshape tool and the trace tool; 6. Clicking on the road feature I wished to reshape, I then traced the edge  of the grass. This now worked with no error generated. Where as at first I was getting the reshape error. Before working on this road, there was no self intersections error. Since then it has transpired that for another feature at a different site, the following error message I was getting when tracing, was due to a self intersecting feature: "The Reshape task could not be completed. An internal error has occurred in the geometry system." B) Another example of generating a self intersecting feature was another road: With this all I believe I did was move a point using the following process: 1. An adjacent polygon, which was some grass, required to be moved down. This I did by moving it's vertices; 2. Then I either move two vertices of the polygon it now overlapped or clipped it to that polygon; 3. Finally I moved one point from the polygon which now has the self intersections error; I do have some screenshots but I'm not sure I should post them for data license and copyright reasons. This lead to the following reply, which partly came from Redlands. They referred me to the following article: http://support.esri.com/en/knowledgebase/techarticles/detail/29465 Note the article states it's for older versions than the version I'm using. "If the points you have digitised are taken strictly at face value there does not appear to be any overlap or intersection. But you have chosen a Tolerance of 0.001 for this Feature Class so the difference between the points is at, or very close to, that value. Therefore the points can be interpreted as being in the same place. Is there really a feature on the ground at this location that is just a couple of mm long that you are trying to represent? If not then the answer is to use the Check Geometry as a warning of poor (although not strictly incorrect) digitising and correct the defect. If this is a genuine feature then you need to use a smaller tolerance in order to allow this." This lead to looking into the use of topology to perhaps try and prevent the situation arising. Whilst I believe that could stop me being able to create the conditions that cause the self intersection error to be created, I don't feel it will actually fix the reason it can be created. Of course I can't do a check geometry on an SDE feature class and I have an archive attached to my data, so repairing these geometric errors isn't a trivial process. That;s due to the fact a complete archive can't be exported. It since transpires that the xy resolution of the polygon feature class was set to: 0.000000002219847 The data originally came from an external supplier and I was unaware that the resolution wasn't set to the default 0.0001, which the other point and line feature classes are. I don't know if this impacts on the issue at all. However if I'm moving points, I would expect them to snap whatever resolution is used, as they are in the same feature class and I have all the snapping turned on. I also have a large number of polygons where I'd traced existing features in the same feature class and another feature and these have quite a few self intersection errors, where as the data they were traced from does not. That may also involved the moving of some points. Kind regards ... View more

I also wanted to add the following note: "SDE Geodatabases automatically check the validity of each geometry when they are uploaded; therefore the Check Geometry and Repair Geometry tools are not for use with SDE." (http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//001700000034000000) If the SDE automatically checks the validity of each geomtery when they are uploaded, why is it not checking the validity of each geometry when it is being written to the database after digitising? ... View more