Latest Contributions by TimWhiteaker

Our surface is guaranteed to cover the line, so that isn't an issue for us. Someone else (@MK13 ?) should chime in if that fits their use case. ... View more

We don't have a good way to add M after interpolation. Though the length of a 3D line is greater than 2D, we wouldn't change the M values.  Whatever M value was at a given vertex in the original line, we would want that M value at the same vertex in the newly interpolated line, and we would want M values for any new vertices to be interpolated from that. ... View more

Thanks for the other things to look at but I don't think they handle exporting PDFs from Excel. With a clean install of Pro 3.0, I upgraded to 3.0.2, and I still don't have pywin32 installed.  A search for "win" in the Package Manager in Pro reveals these libraries that seem close but not quite it: * python-certifi-win32 * pywin32-security For an import test, this time I tried from within a Python console window in Pro. I get "No module named 'win32com'".  I wonder how you have pywin32 but I don't. console window   ... View more

I was working in a clone. I switched back to base (arcgispro-py3) and get this in a Python command prompt. (arcgispro-py3) C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3>python Python 3.9.11 [MSC v.1931 64 bit (AMD64)] :: Anaconda, Inc. on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from win32com import client Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'win32com' I'm in Pro 3.0.0.  Is it possible that attempting to install pywin32 in the clone corrupted the base installation? ... View more

I still have no solution either ... View more

That is a nice workaround as long as one doesn't need the tool to work in Scenes. I noticed what is perhaps another bug related to the workaround. There are different click behaviors for these situations: When SketchOutputMode = SketchOutputMode.Map, you click once to start the sketch, drag to draw the shape, and click again to end the sketch. When SketchOutputMode = SketchOutputMode.Screen, you click once to start the sketch and keep the mouse button held down, drag to draw the shape, and then release the mouse button to end the sketch. ... View more

My code worked in 2.7, so I did not bother revising it to take advantage of the new selection functionality, so I cannot give you concrete advice on how to deal with network trace results as selections. Still, it seems the selection should be present on the feature layer when the trace is finished running.  This means the next time you access the network layer in your script or geoprocessing workflow, the selection should be there.  However, I have not tested this, so maybe I'm missing something.  ... View more

Nearly 10 years later, I find this issue still exists!  What happened with the enhancement request?  I suppose a workaround could be, once you've got Z, is there a way to take the original line-with-M and interpolate the M onto the line-with-Z?  > Would you want M's interpolated for [new vertices] based on existing M's or not? Yes please. ... View more

A note on SOURCEID.  If you are going to populate it, it should be the ID of the feature class with respect to its participation in the trace network, NOT the ObjectID of the feature.  Given a trace network layer, and a feature layer participating in a trace network, here's a function that illustrates how to identify the SOURCEID.  I use this in my script tools as I'm getting ready to perform traces.  I do not know how to see the SOURCEID from the user interface without using arcpy.Describe.   def get_source_id(network, network_layer): d = arcpy.Describe(network_layer) fc_name = d.featureClass.name d = arcpy.Describe(network) for s in d.sources: if s.name == fc_name: return s.sourceID arcpy.AddError( 'Could not determine network source ID for ' + network_layer.name) raise arcpy.ExecuteError   If you've taken the conversation offline, will you please post the solution here once you've found one?  I'm curious! ... View more

Jon, About case b, I was placing a starting flag at the edge endpoint, and then using the WRProxyMZ layer as barriers. When I do this, the two edges that share that endpoint are selected in the downstream trace result, while no WRProxyMZ features are selected. Thanks for the tip about multiple flags being placed when I snap to an edge endpoint. I was able to zoom in and see this. It looks like one starting flag is placed exactly at the endpoint and associated with one of the edges, and another starting flag is placed a tiny distance away, and thus a tiny distance along, the other edge. So, one of the flags is spatially coincident with the WRProxyMZ point, and another is very close by. I did try two experiments, where in one case the second flag was just upstream of the junction, and in the other case the second flag was just downstream. In both cases, the result was the same for a downstream trace (with the two starting flags, and using WRProxyMZ as barriers): the two edges were selected, and no junction was selectd. That said, I'm not too worried about case b, because for an edge endpoint, I would just create a flag associatd with the WRProxyMZ point instead of any edges. By the way, I suspect the behavior most end users would prefer is for a single flag to be placed when snapping to edge endpoints, instead of two flags. Maybe that's one of the issues you mentioned that will be fixed in 2.7. The issue that I could still use help with, is getting the downstream WRProxyMZ point selected when the starting flag is in the middle of an edge upstream from the WRProxyMZ point. See the first screenshot in the OP. Basically, I'm trying to get the orange point labeled 1378 to be selected in a downstream trace using the green circle, which is partway up the upstream edge, as the starting point. When you set up a trace like that in the first post, do you get point 1378 selected? Thanks for those links about starting points and barriers.  That is exactly the kind of documentation I was looking for, and I'm a little embarrassed that I didn't stumble across it on my own! ... View more

I manually installed the 2.6.3 patch and got the same result: the junction stopping the trace isn't selected.  However, I discovered a couple of other curious behaviors: a. If I interactively place a barrier at the downstream endpoint of the edge, snapping to that WRProxyMZ point, and use TN_Temp_Barriers as the barriers, that WRProxyMZ point stopping the trace is selected in the trace results.  Yay!  This is the desired result. b. If I instead place the barrier by snapping to the edge endpoint, which is spatially coincident with that WRProxyMZ point (I turned off WRProxyMZ in the table of contents to help me snap to the edge endpoint), that WRProxyMZ point is NOT selected in the trace results. I suspect this behavior is related to what I discovered about setting flags as described in this other post, in which you need to include and populate SOURCEID and FEATUREGLOBALID attributes in the flag and barrier feature classes to get desired trace results.  When you set flags and barriers interactively, those attributes are populated for you, which is why TN_Temp_Starting_Points and TN_Temp_Barriers tend to work as expected.  If you're going to use different feature classes for flags or barriers, you've got to populate those attributes yourself. This makes me wonder why the software can't just figure it out for you when you provide your own flag or barrier feature class.  I don't really know why those attributes are needed in the first place.  Is there some use case in which you'd want to treat a flag at the endpoint of an edge differently from a flag at a junction located at the same endpoint?  The software seems to be programmed that way, which is why the above case (a) works while case (b) does not. It would be wonderful to have some guidance on how to properly create your own flag and barrier feature classes, along with some explanation as to why things work the way they work.   ... View more