POST
|
Yes, that's a similar approach to what has been described in this thread: http://forums.arcgis.com/threads/4370-How-do-I-get-the-file-path-of-a-shapefile-or-layer-loaded-in-mxd
... View more
12-03-2013
06:51 AM
|
0
|
0
|
789
|
POST
|
Are you sure you didn't try IDataset.BrowseName instead of .Name? And you did include the extra "\" in between, right? This is important... Otherwise, try IDataset.FullName.NameString.
... View more
12-03-2013
01:38 AM
|
0
|
0
|
789
|
POST
|
Hi everyone, I'm programmatically adding a TIN from a file path to ArcMap 10.2. It's something I've done so many times before and it has always worked. It also works now, but there seems to be a problem with the display. After the layer has been added to the TOC and I switch it on, it renders fine. However, after some (random) panning and zooming, the layer seems to gradually disappear, as if the cache is running dry or something. ArcMap doesn't crash and the layers are still there somehow. If I click "Zoom To Layer" I actually zoom in to it (I can tell by the scrollbars and the scale indicator), but there's nothing to see. If I save the MXD and reopen it, the layers are visible again. Below is my code. Am I doing something wrong? Or did I run into a 10.2 render/caching bug?
ITin tin = new TinClass();
ITinLayer2 tinLayer = new TinLayerClass();
DirectoryInfo dirInfo = new DirectoryInfo(FullPathToMyTIN);
IWorkspace workspace = workspaceFactory.OpenFromFile(dirInfo.Parent.FullName, 0);
ITinWorkspace tinWorkspace = (ITinWorkspace)workspace; // Explicit Cast
if (tinWorkspace.get_IsTin(dirInfo.Name))
tin = tinWorkspace.OpenTin(dirInfo.Name);
if (tin == null || tin.IsEmpty)
return;
tinLayer.Dataset = tin;
tinLayer.Visible = false; // I don't want my layers to be visible by default,
since I'm adding multiple ones
tinLayer.Cached = false; // The problem seemed to occur less frequently after adding
this line, but it still happens...
tinLayer.Name = "MyCustomName";
ArcMap.Document.FocusMap.AddLayer(tinLayer); // This works fine: no errors here
ArcMap.Document.ActiveView.PartialRefresh(esriViewDrawPhase.esriViewGeography,
tinLayer, tinLayer.Dataset.Extent);
// I've also tried .PartialRefresh(esriViewDrawPhase.esriViewGeography, null, null)
or .PartialRefresh(esriViewDrawPhase.esriViewGeography, null, tinLayer.Dataset.Extent)
or .Refresh(), but the problem remains
ArcMap.Document.ActiveView.ScreenDisplay.UpdateWindow();
// I've also tried adding this, but the problem remains
... View more
12-03-2013
01:22 AM
|
0
|
0
|
429
|
POST
|
Hi everyone, I've written my own code to export a ClassBreaks XML file from a classified value raster layer in ArcMap (10.1), that actually also saves the color information and not just the break values alone. Here is the part that matters: IRasterClassifyColorRampRenderer classifiedRenderer = (IRasterClassifyColorRampRenderer)rasterLayer.Renderer;
using (XmlWriter writer = XmlWriter.Create(xmlFile))
{
writer.WriteStartDocument();
writer.WriteStartElement("ClassBreaks");
for (int i = 0; i < classifiedRenderer.ClassCount; i++)
{
writer.WriteStartElement("break");
IFillSymbol symbology = (IFillSymbol)classifiedRenderer.get_Symbol(i); <<-- This does not return the symbology that matches the same break!
writer.WriteElementString("value", classifiedRenderer.get_Break(i + 1).ToString()); //we want the upper break value
writer.WriteElementString("color", symbology.Color.RGB.ToString());
writer.WriteEndElement();
}
writer.WriteEndElement();
writer.WriteEndDocument();
} What actually happens, is that the symbology (or at least the color I'm trying to retrieve) has been flipped for some reason. When I ask for the first item in the renderer, I get the first break value and the LAST symbol. For the second one I get the second last symbol and so on. In my resulting XML file, I end up with the break values in the order I want, but the colors are in reverse order. For the moment, I "fixed" this by doing something like this to get the symbol that actually belongs to the break value: IFillSymbol symbology = (IFillSymbol)classifiedRenderer.get_Symbol(classifiedRenderer.ClassCount - 1 - i); But this is just weird. Is there something wrong in my code (I certainly don't see it) or is there a bug in the IRasterClassifyColorRampRenderer interface? Cheers, Sander
... View more
05-31-2013
09:08 AM
|
0
|
0
|
337
|
POST
|
First: we are working hard on a special patch on 10 SP4 to fix the problems. Hope it will come out soon. Ok, that's great news! Second: Copy Features tool worked for my test data. I reproduced the wrong shape_length (for the target lines) and then run Copy Features to gdb output. The output shape_length values reflect the original/input line lengths. Will you be able to share your data so I can try? Good to know that you were able to reproduce the SHAPE_Length problem. As for the Copy Features bug: this issue might have been a freak occurence, related to my geodatabase. My gdb is quite large (too big to share), so I tried to create a "light" copy for you holding only the relevant data - and test Copy Features again at the same time. This time, the tool worked as expected. But that's not the only thing: I cannot reproduce the problem anymore with my original gdb. Even when I run the Spatial Join again and run Copy Features afterwards, SHAPE_Length will be properly recalculated.
... View more
04-10-2012
12:58 AM
|
0
|
0
|
560
|
POST
|
@Nobbir: I'm currently running Windows XP 32 bits Professional (but will be moving to 7 64 bits soon). The lines are indeed my target features. I've attached a screendump of my field mapping below. I realize my feature class names are quite long, but the mapping seems to go right here. However, the result is wrong. [ATTACH=CONFIG]13336[/ATTACH] Maybe my long feature class names are abbreviated in such a way that their names become identical somehow, causing the tool to mix up the SHAPE_Length fields? @Dan: I already tried Copy Features, but strangely enough, that didn't reset the SHAPE_Length. Only export and (re)import via shapefile did the trick. I would say that the issues related to the Spatial Join are severe enough (disruptive for workflow, maybe even for data integrity etc.) to issue a little patch until SP5 (or 10.1) comes out.
... View more
04-09-2012
04:55 AM
|
0
|
0
|
560
|
POST
|
See this similar discussion: http://forums.arcgis.com/threads/54102-Spatial-join-tool-vs.-right-click-spatial-join-producing-different-results?p=185943#post185943 <SNIP> One workaround (if you want to continue using Spatial Join) would be to uncheck 'Keep All Target Features' parameter on tool dialog or use 'KEEP_COMMON' option in script. Yes, that is correct. However, I noticed something else as well. When joining polyline features with a (circular) polygon feature class in a file geodatabase, the SHAPE_Length is not transferred/recalculated properly (even with the 'Keep All Target Features' parameter unchecked). This happens with the default field mapping. Seems that the SHAPE_Length from the polygon join features is transferred to the polylines instead, which should not happen, since this is a reserved field that belongs exclusively to the output geometry. SHAPE_Leng_1 on the other hand (which should contain the joined polygon perimeters), is <Null>. I cannot calculate the proper length of the polylines and copying to another feature class within the gdb does not fix it. Only thing that works is an export and re-import to/from a shapefile. See picture below (unfortunately, I've already deleted the SHAPE_Leng_1 field). [ATTACH=CONFIG]13268[/ATTACH] Sander
... View more
04-05-2012
06:11 AM
|
0
|
0
|
754
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|