|
POST
|
At 10.3 the Data Management Tools - Data Comparison toolset - Detect Feature Changes tool only identifies changes in shape based on a specified tolerance and will match two lines that are pointing in opposite directions without flagging any difference in the lines. At 10.4 the Detect Feature Changes tool adds an option to flag lines that are pointing in opposite directions, even when they are the same in all other respects. This is a very useful option for conflating line networks that contain attributes that are dependent on the line orientation, such as address ranges, line end elevations and any other attributes associated with a specific side or end of the line. The new line direction option of this tool makes it very easy to integrate the Flip Line tool into the Conflation workflow to resolve all line orientation conflicts between two networks in a single step.
... View more
04-12-2016
06:58 PM
|
1
|
0
|
2332
|
|
POST
|
Brendan: I had good intentions to get this out last year, but ran into some issues that I was not sure how to resolve and then work and life got in the way of going beyond a tool for my personal use. For example, it seems that the VB.Net addin I developed needs to register one of its files on secure networks. This was not a problem on the system where I developed the tool, but presents a problem for distribution to end users in a work environment. I may try tackling this again, but the gotchas that come up when a tool moves beyond a specific controlled implementation and gets developed for broad distribution are challenging.
... View more
04-12-2016
08:04 AM
|
0
|
1
|
4641
|
|
POST
|
Routes will only respect the direction of a line if you use From and To end measures on the original lines to build them, otherwise they change direction according to the orientation priority corner you chose with the Create Route tool. The original line did not flip, but the Route events for that line easily can flip if you built the route from the wrong corner. Anyway, post the Create Route settings you used if you want more help to get the behavior you want.
... View more
04-07-2016
07:19 AM
|
1
|
1
|
2309
|
|
POST
|
I could just as easily directly assign those variable names in VB Script without a Dim statement to an empty array at any point in my calculation, unlike VBA aand VB.Net where errors would occur if I did not explicitly cast the array to a real type, i.e, Dim MyArray() as String. Using the syntax of VBA and VB.Net of Dim MyArray() as String throws an error and was the sole reason for months of posts on the forum after the release of 10.0 saying "My calculation broke at 10.0 and I don't know why". So I stopped using it and have not had a problem debugging my calculations as a result. Using Option Explicit has never been discussed on the forum that I can recall and I was unaware it had any effect in VB Script, so I never tried it. That practice is not well established in any posts here on the forum or in the VB Script help. Without the inclusion of that option, the use of Dim makes no difference. So you needed to say that the use of Option Explicit is a good practice in conjunction with Dim, otherwise the statement about the value of Dim is misleading Anyway, this user was misusing Dim by including it multiple times for the same variable name in his calculation. That resets the variable, breaks the logic of having successive if statements and led to errors in the calculation, so using Dim like that is definitely a bad practice.
... View more
04-06-2016
07:36 AM
|
0
|
1
|
1178
|
|
POST
|
The Field Calculator uses VB Script which only supports type Variant. If you try to Dim to any other type like string, integer, double, object, etc. an error will be thrown. Using Dim is only a good practice in VBA or VB.Net, not VB Script.
... View more
04-05-2016
08:01 AM
|
0
|
0
|
1178
|
|
POST
|
I am assuming this is all one calculation. Try: if (([SummaryStatistics.SUM_DrainArea_SF]) > 0 And ([SummaryStatistics.SUM_DrainArea_SF])) <= 299 then n = "MINOR" else n = "COMPLIANT" end if if [Lat_Defects.ProposedWork] = "35" then n = "XCONNECT" end if if ([Summary_Statistics_2.SUM_DrainArea_SF]) > 299 then n = "MAJOR" end if Make sure your output field is text and at least 9 characters long so that it can hold the value "COMPLIANT". If it is less than 9 characters long it will throw an error. Are you sure all records in Lat_Defects have a matching record in both Summary_Statistics and Summary_Statistics_2? Are you sure none of these 3 fields have Null values? If any of them have an unmatched record or a Null value that will throw an error. Have you checked that the join worked for both tables on the record with ObjectID 84 in the main table, especially if this is a 3-table join? If you still have problems, you are going to have to at least post a screen shot of your data with the join in place, since it in not fair to ask us about errors that only occur for specific records if we cannot see those records.
... View more
04-04-2016
12:11 PM
|
0
|
0
|
1178
|
|
POST
|
Dim was only useful when VBA was used in the field calculator prior to 10.0, since VBA has several types of variables that can be instantiated by the Dim clause. After 10.0 calculations use VB Script and there is only one type of variable, so just by assigning a variable a value it is given a variable name and type without using the Dim clause.
... View more
04-04-2016
11:42 AM
|
0
|
2
|
3288
|
|
POST
|
Remove the Dim statements. If this is all one calcuation, they cause the n variable to be reset before each section so the first and second section calculations are destroyed and overridden even when the condition of clause 3 is not met. Dim is useless in VB script and not to be used ever. If these are separate calculations they all need an else clause.
... View more
04-04-2016
11:33 AM
|
0
|
1
|
3288
|
|
POST
|
Dim is not necessary anymore with VB Script. You have to have an else clause to output a value when the condition you have written is not met. Every record has to have an output. So change the calculation to the following where you replace [OUTPUT_FIELD] with the actual name of the Output Field (so that whatever is already in the output field is not changed): Parser: VB Script Use Codeblock: checked Pre-Logic Codeblock: if ([Summary_Statistics_2.SUM_DrainArea_SF]) > 299 then n = "MAJOR" else n = [OUTPUT_FIELD] end if Field expression: n
... View more
04-04-2016
11:12 AM
|
0
|
1
|
3288
|
|
POST
|
Ben: Use the buffer tool on your points to give the minimum space around any given point nearest to the ultimate rectangle edge as a temporary fc, then apply the Minimum Bounding Rectangle to the buffer output with the Envelope Option. It will be as precise as your drawing. The Buffer tool can group the point buffer output into a single multipart object for each unique value in a field or fields using the List option and the field list parameters. See the help here: Buffer. In the same way the Minimum Bounding Rectangle tool can also respect the unique value groupings from one or more fields using the List option and the field list. See the help here: Minimum Bounding Rectangle.
... View more
03-31-2016
06:52 PM
|
2
|
0
|
4011
|
|
POST
|
Thanks Patricia. I have added your format and the reverse to the combobox list below the first pair (the format my users use): "L_ADD_FROM, L_ADD_TO, R_ADD_FROM, R_ADD_TO" "FROM_ADD_L, TO_ADD_L, FROM_ADD_R, TO_ADD_R"
... View more
03-29-2016
01:17 PM
|
0
|
0
|
2125
|
|
POST
|
I would like to know what field names are used in the GIS community to represent the Address Ranges fields that capture the Left From Address, Left To Address, Right From Address, and Right To Address. . I want to know this because I am designing an add-in editor extension and toolbar for Address Management, but to avoid direct editing of the code and to make it easy for everyone to use I need to supply a list of all possible Address Range field name formats into a combobox. If the field names are in my pre-built combobox list the tool will automatically detect the fields that match the chosen editable polyline layer, and only ask for confirmation when there is more than one recognized field name format in the data. If for some reason the field names are not in the list the user can still type their own address range field names into the combobox to add them to the list without editing the add-in code so the tools will still work. Even though the actual fields can be in any order in the target data, for the tool to do the proper edits the fields have be added to the list in the order shown above, which may confuse some users. Users also would have to enter the set of field names every time they restarted ArcMap, unless they directly edited the add-in code. But if the format is in my pre-built list of address field formats, the user will not ever have to type them. So far the formats that I have put into the combobox are: ""L_F_ADD, L_T_ADD, R_F_ADD, R_T_ADD" "F_L_ADD, T_L_ADD, F_R_ADD, T_R_ADD" "LEFTFROM, LEFTTO, RIGHTFROM, RIGHTTO" "FROMLEFT, TOLEFT, FROMRIGHT, TORIGHT" "LEFT_FROM, LEFT_TO, RIGHT_FROM, RIGHT_TO" "FROM_LEFT, TO_LEFT, FROM_RIGHT, TO_RIGHT" "LEFT_FROM_ADDRESS, LEFT_TO_ADDRESS, RIGHT_FROM_ADDRESS, RIGHT_TO_ADDRESS" "FROM_LEFT_ADDRESS, TO_LEFT_ADDRESS, FROM_RIGHT_ADDRESS, TO_RIGHT_ADDRESS" "LFROM, LTO, RFROM, RTO" "FROML, TOL, FROMR, TOR" Let me know if I have missed the field name format(s) you use so I can add it/them to the combobox list. So far the toolbar has: 1) The ArcMap built-in Edit Vertices tool and Flip command for flipping edit sketch geometry of one line (I didn't want to reinvent the wheel). 2) Nine (9) different buttons that will operate on multiple selected lines at the same time to swap address range field values in all directions (Three (3) complete range swap buttons to handle full address reversal, side to side only, and from end and to end only and six (6) address pair swap buttons that will do side to side swaps at either end of the line, from end and to end swaps on either side of the line, and diagonal swaps for either pair of opposite corners) to synchronize address parity with the line direction. 3) A split line and address tool that works with both text and numeric address range fields. This tool works the same as the normal split line tool for polylines that do not have address range fields, but for data that does have address range fields it also proportionally splits the address ranges. It preserves each sides ascending/descending range orientation and properly proportions each segment even when the two sides have opposite range orientations. There are also two comboboxes that will let the user adjust the Split behavior. One combobox sets a maximum radius surrounding the point where the user clicked in which a split can take place, and the other combobox sets a snap vertex delta that will split the line at the nearest vertex only when the difference between the distance to the nearest vertex and the nearest edge does not exceed the delta. The split line and address tool works for Projected Coordinate Systems, but I have yet to test it with Geographic Coordinate System data. I plan to create a Planarize Lines and Addresses tool that will work on multiple lines that intersect each other, but I may release the toolbar without it and issue a new version later.
... View more
03-29-2016
11:51 AM
|
0
|
4
|
4200
|
|
POST
|
I know this is old, but for the benefit of anyone looking for the Modify Sketch Vertices tool the GUID / ProjID is: {A4AF2F51-8365-4122-8B04-638413E6510E} / esriEditor.EditToolEditSketchCommand The GUID / ProjID for the Edit Vertices button on the Editor toolbar is: {D0F62794-98C4-447A-A0B2-4ECDB6554FC9} / esriEditor.FeatureEditVerticesCommand I am still looking for the GUID / ProjID of the Flip command under the Editor category, which is described as: Flip Change the direction of the sketch. The first point added to the sketch becomes the last point. Edit: I found out the ProgID for Flip is simply esriEditor.FlipCommand. I came up with that by trial and error, and I did not try to get the GUID, since I am not working on an ArcObjects program/add-in, only a Python Add-in, which just needed the ProjID. But ArcObjects users can find the GUID through the ProjID.
... View more
03-29-2016
05:51 AM
|
0
|
0
|
1264
|
|
POST
|
Dan: Thanks for the offer, but I actually am using the code I posted to compare the nearest edge point returned by either the distanceTo or the queryPointAndDistance method of the polyline. I need at minimum two of the items the queryPointAndDistance method returns and may need the other two latter. I need the side offset (sideDist) to see if the line edge is inside my split tolerance, and I need the distance along the line where the point fell as a percent (perc) to actually split the line. pt = arcpy.PointGeometry(arcpy.Point(x,y), sr) ptOnLine, perc, sideDist, rightSide = pLine.queryPointAndDistance(pt, True) The output I am after is to see if the vertice is within a maximum distance specified by the user of the real nearest point on the line edge from where the user clicked to determine if I will split at the closest edge or the closest vertice. After getting the queryPointAndDistance percent along the line of either the point on the line vertice returned by your code or point on the line edge returned by either the distanceTo or queryPointAndDistance method I then use that percent to split the line using: fromLine = pLine.segmentAlongLine(0, perc, True) toLine = pLine.segmentAlongLine(perc, 100, True) I also use the percent to split address ranges. So in my example, the full data showed that if a user chose a maximum vertice/edge difference of 10 feet (my units), then the edge should split and not the vertice, since the vertice is more than 11 feet from the closest point on the line edge based on where the user clicked. Origin Point = [ 6305489.12520918 2169986.76545799] Destination Points = [[ 6305087.95761374 2169963.2243613 ] [ 6305515.50958015 2169962.6298743 ] ... [ 6305742.79783948 2169860.23900296]] Closest Vertice = [[ 6305515.50958015 2169962.6298743 ]] Vertice Distance 35.7583756816 is within Max Distance 50.0 Difference between nearest vertice and nearest edge is 11.6595012766
... View more
03-27-2016
10:05 PM
|
0
|
0
|
2427
|
|
POST
|
Dan: The X,Y got passed into an array object by the FeatureClassToNumpyArray, which is the method you recommended for people to use in your original post to convert a polyline to an array of points. That method is used in line 17 with the explode_to_points option set to True. The first output list used the ["SHAPE@X", "SHAPE@Y"] fields and the second list which had the extra comma used the ["SHAPE@XY"] field. The arrays are the unprocessed native output of that method with the explode_to_point=True option and those field settings. I found the answer on how to make the output of FeatureClassToNumpyArray method with the explode_to_point=True option work with the rest of the code. I changed line 17 to : dests = np.array(list(list(x) for x in arcpy.da.FeatureClassToNumPyArray(addressLines, ["SHAPE@X","SHAPE@Y"], "", sr, True)),dtype="float64") Now the code works and the Origin and Dest arrays print as: Origin Point = [ 6305489.12520918 2169986.76545799] Destination Points = [[ 6305087.95761374 2169963.2243613 ] [ 6305515.50958015 2169962.6298743 ] ... [ 6305742.79783948 2169860.23900296]] The numpy array rounds the orignal numbers from 9 decimal places to 8 decimal places (i.e., 6305087.957613736 became 6305087.95761374), but since that is way below my XY resolution and tolerance that should not be a problem. So the full working code is: class SplitLineToolClass(object):
"""Implementation for SplitLine_addin.SplitLinetool (Tool)"""
def __init__(self):
self.enabled = False
self.cursor = 3 # Crosshairs
def onMouseDownMap(self, x, y, button, shift):
# Pass if not a Left Mouse Button Click
if button != 1:
pass
return
addressLines = pythonaddins.GetSelectedTOCLayerOrDataFrame()
## Code that verifies a polyline layer is selected in the TOC
desc=arcpy.Describe(addressLines)
sr = arcpy.SpatialReference(desc.spatialReference.factoryCode)
origin = np.array([x,y],dtype="float64")
dests = np.array(list(list(x) for x in arcpy.da.FeatureClassToNumPyArray(addressLines, ["SHAPE@X","SHAPE@Y"], "", sr, True)),dtype="float64")
deltas = dests - origin
distances = np.hypot(deltas[:,0], deltas[:,1])
min_dist = np.min(distances)
wh = np.where(distances == min_dist)
closest = dests[wh[0]]
print("Closest Vertice = {0}".format(closest))
... View more
03-27-2016
09:17 PM
|
1
|
1
|
2427
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-24-2026 11:37 PM | |
| 1 | 03-24-2026 08:01 PM | |
| 7 | 02-23-2026 08:34 AM | |
| 1 | 03-31-2025 03:25 PM | |
| 1 | 03-28-2025 06:54 PM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|