Latest Contributions by RichardFairhurst

My prior post was the elaboration on what I meant by that sentence.  Certain point locations along a line cannot be recreated by an LR event, such as points that curve around the end of a cul-de-sac bulb beyond the end of the route.  Only points which can be offset perpendicular to the route at the measure location can be exactly placed by an LR event table. Choosing one route does not mean it is a simple route without branches if multiple original polylines created it or the one polyline that created it was self intersecting.  A single route can branch, but when it does the measures get messed up as far as every measure being a unique position along the line.  Also, the Create Route tool is not perfect if it creates a route from multiple polylines that do not meet end to end and that overshoot each other when they actually should touch.  Bad topology like that must be eliminated before using that tool. The Coordinate priority of the Create Route tool should let you choose the orientation that the route will be built.  If you have preassigned measure fields in your table they can also control the way that tool builds the route.  So I am not sure why you needed to flip the route after building it.  If you have built it from the upper left corner flipping the priority to one of the other corners should alter the route creation orientation. I would convert the excel table to an actual point feature class by exporting the XY Event layer first before running the Locate Features Along Route.  I never use XY Event tables to create Route Event tables directly.  An actual point feature class should not alter the long or lat values when the events are located along the route.  I have seen XY Event tables alter the coordinates in the long and lat fields when python cursors operate on them, but never on a real point feature class.  Whatever is happening to the long and lat fields, the Linear Referenced events layer does not use the Long or Lat fields when it is displaying the LR event along the route, only the RouteID and the measure (and optionally an offset distance field). A picture is worth a thousand words.  An example screen shot showing an original point location and a linear referenced event that does not match the original position may explain what is really going on.  If you can show the hatched measures of the Route that should also help. ... View more

Hi Everyone, This is my first time performing dynamic segmentation. I was able to create the route and perform the dynamic segmentation on my route, but when I try to use the locate features along routes tool to be able to identify the measurement of over 3000 points along the route, the output measurements for the location points does not appear correct. The latitude and longitude of the location points have been changed in the output attribute table, which may be the reason why the measurements are incorrect. Does anyone know why the latitude and longitude changed in the output attribute table after I used the "Locate features along routes" tool? Thank you for your help. Any suggestions on how to fix this problem is greatly appreciated. Did you recalculate those attributes after locating the points along the route?  Or are you saying that the operation of the tool itself did that?  As far as I know the tool itself should not directly alter those attributes, but it will alter the actual location of the point if those attributes are recalculated based on the event layer position using the geometry calculator.  If you are saying the tool directly altered those attributes without using the geometry calculator I would need to know more about the inputs and tool settings you used.  Are you sure the routes and points are in the same projection? Even if the routes and points are in the same projection, the geometry calculator can change the long and lat if it is recalculated based on the event point location.  The actual location will change relative to the original point location in two possible ways in the event layer.  If no side offset is used the point will be relocated to the centerline of the route, which will change the long and lat of any point that was originally offset on one side of the line or the other.  That can be corrected partially by including a side offset distance for the point event layer. The second way it will change the point position even if you do use a side offset is that any points that fall beyond the end of the line will project as exactly perpendicular events to the route from the end point of the line, not along the original angle from the end of the line.  So it is impossible to use linear referenced events to recreate exact locations around a cul-de-sac bulb, for example.  Those point locations will always have altered long and lat positions relative to the original point in its projected event form if they are recalculated using the geometry calculator.  Nothing can fix that other than to retain the original coordinates in attribute fields. Another concern is that if you kept only the closest location, you will get associations to the wrong route for several of your points if they fall closer to a cross-street (or branch) than it does to the correct route.  This occurs as points near an intersecting road/branch.  I always uncheck that option and use an attribute to make sure I am associated to the correct route, throwing out false route links. Other possible concerns would arise if your routes are not simple polylines with continuously increasing measures.  Branches will cause problems if you included them in your routes. Points which are exactly perpendicular to a simple route that use the correct side offset distance in the event layer should have measures that result in the same long and lat values as the original point if the projection was not changed. So explain what you did a little more clearly.  I have never seen the effect you seem to be describing if you did not use the geometry calculator to overwrite your long and lat values. ... View more

Cool, thanks.  I will give this a try. Just another note.  Overwriting files does not work in Python scripts if you decide to schedule this.  You have to explicitly delete a file before you can overwrite it.  In Model Builder the delete of the existing file becomes a precondition of a file creation tool that would replace it. ... View more

Thanks for the detailed info.  I have a bit of a different problem and I think this might help.  Does this sound like it would work? I have a file geodatabase feature class joined with an Excel table and set up in data driven pages.  When I try to export selected records to pdf it gives an error.  The problem has something to do with the join because it works as soon as I remove the join.  I want to try your idea of importing the table to geodatabase to see if that fixes it.  I don't want to set up the join all over again each time the Excel table is updated.  So I think I would work from ArcCatalog to overwrite the join data with the same name without opening the mxd.  Sound good?  (This is in 10.0.) Also is there a difference between the add join from the toolbox, and the add join from right-clicking the layer in the TOC? That will work if you create a model to do the update.  The Add Join is the same, other than one operates in a model and the other is made visible in desktop.  If the model ran while the map was closed and afterward the map was open, it should open everything just fine as long as the data sources and file names had not changed. ... View more

Thank you very much! Now the script is running. However all points get unique coordinates outside any of the zip polygons. It looks like this: These are the overlapping points in the Zip areas: [ATTACH=CONFIG]29415[/ATTACH] After running the script I get this: [ATTACH=CONFIG]29416[/ATTACH] Both shapefiles have the same coordinate system. Perhaps my error is here: polygon = row[0] # take first polygon Should this value be changed? In the ZIP file there are only the Polygons you see in the first picture. In any case I have to thank you very much. Best regards MP I tested the script with a single polygon and 68 points and it ran perfectly.  It even worked when I used a multi-part polygon.  My projection was State Plane for both.  However, I only used 1 polygon and one set of points that fell inside of it. Processing multiple polygons won't work if you use the raw feature class the way this is written.  You need to use layers and run the script for each polygon separately using a selection of the one polygon with its corresponding points.  Or rewrite the script to process all of the polygons with a test before moving a point that verifies the initial position of the point is inside the polygon and only dispersing those points that are inside. ... View more

Thanks for the response! I tried that, and it works great...but of course now I have a new twist. Some of the construction projects cannot be dissolved into a single feature, because I need to uniqely symbolize different parts of the project. If I apply symbolization to the layer like you describe, I end up with a border around every individual feature within the project, instead of just around the overall project. Here's another example with two construction projects. Any takers? Symbol levels is the only thing that comes to mind to try.  Other than that at some point you will come up with a scenario that requires two separate feature classes to do two different cartographic views.  Or you could convert the whole thing to Linear Referencing and create as many events as you need project limits. ... View more

The new field is a text field with a length of 6.  The final field that I'm trying to reclassify has to be a text field with a length of six.  When I process I don't see any error messages but I also don't see any change in the table. You did not provide your expression.  It needs to contain the field name of the field with the original values you are evaluating and the calculation needs to be done on the field that will have the reclassified values.  Something like: def Reclass(!RETURN_PER!) ... View more

First of all, I would never use Null to represent an actual classification value for a real object, since data like that always complicates code and makes it impossible to tell when something exists or does not exist without very careful processing.  If you mean to classify Mobilehome wells as actual objects, create a real value in your field to represent that and leave Null to mean it does not exist or has not been classified. I would just use the Spatial Join tool on every feature in the entire dataset in one go.  I would use the One-To-One relationship and a modification to the field list to use the Join merge policy and specify a delimiter (right click the field you want merged into a list of values and change the settings).  While you are modifying the output field expand the number of characters in the field to be large enough to hold all values.  I would probably uncheck the keep all target features option, or include at least 2 fields in the summary where one of the fields will never be null if a Join occurs and preferably numeric. The output will be a comma separated list.  I believe Nulls will be excluded, so if it is all Nulls the List will be Null, otherwise it could be one or more instances of the "DWELL", with multiple values separated by the delimiter you specified.  The field calculator could convert the values to the ones you want or fill in a new field with the values you want (safer) using a VB Script calculation like this (untested against any data like yours, since I don't approach data the way you seem to be doing): If IsNull(InStr([fieldName], "DWELL")) then   Output = "MOBILEHOME" ElseIf InSrt([fieldName], "DWELL") then   Output = "HOME" Else   Output = "MOBILEHOME" End If Expression:  Output If there were 2 summaries you could test for Nulls in the other field to indicate there are no wells.  If you only got target features where an join occurred you could join that result to your original feature class and do the above calculation to a new field, adding a test for Null ObjectID of the join as a way of detecting no join occurred.  You would have the option of doing something different with multiple wells. It is all much easier to do a calculation if a real value was present when a Mobilehome well existed, rather than Null.  Then my IsNull would really mean there is no Well at all and I could classify those as Null, Vacant or something else.  Also it would let you detect when both a Home and Mobilehome have wells on a property, multiple Homes or Mobilehomes are on a single property, etc. ... View more

Hi Wayne --  Sorry to keep this going but I've had trouble making this work in a stand-alone setting. I used the code above, which seemed to work fine. However, when I proceeded the intersect the ratio split policy wasn't honored. I'm wondering if I'm missing a step to connect the policy more explicitly back to the layer that is input to the intersect. Code below.  Thanks for any thoughts,  Mike  inFeaturesAlb = "blocks_01_alb.shp" layer = "temp_layer" arcpy.MakeFeatureLayer_management(inFeaturesAlb, layer) # Create a describe object desc = arcpy.Describe(layer) # Create a fieldinfo object field_info = desc.fieldInfo # Get index of desired field for which to set ratio policy # Let's say your desired field is called 'area' fldIndex = field_info.findFieldByName("POP10") # Set the policy field_info.setSplitRule(fldIndex, "RATIO")  ######################################################################    #Do the intersection #####################################################################     intOut = "State_01_int_3.shp"    inFeatures_int = [USA_layer, layer] arcpy.Intersect_analysis(inFeatures_int, intOut) The help has a warning that "Geoprocessing tools do not honor geodatabase feature class or table field split policies." The help for tools like Intersect and Union also say "However, if the input is a layer or layers created by the Make Feature Layer tool and a field's Use Ratio Policy is checked, then a ratio of the input attribute value is calculated for the output attribute value." (Frankly, whoever wrote the help on this topic could have done a much better job, since the help layout never clearly links the warning and solution together). I would set the split policy rule with the MakeFeatureLayer_Managment tool directly. I believe the help means to indicate that geoprocessing requires the use of this form of the split policy for other tools to honor it. If you build the Make Feature Layer Management tool in the ModleBuilder environment and check the split policy flag for the field(s) you want and export the model to a python script you will get the syntax you need. Here is an example of what ModelBuilder outputs: arcpy.MakeFeatureLayer_management(inFeaturesAlb, layer, "", "", "OBJECTID OBJECTID VISIBLE NONE;APN APN VISIBLE NONE;POP10 POP10 VISIBLE RATIO") The field info portion of the tool is a single string that contains a semi-colon separated list of the layer fields, where each field is defined with a space separated list of four items: The Original Feature Class/Table field name The Layer display field name The Visibility flag (either VISIBLE or NONE) The Split Ratio Policy flag (either RATIO or NONE) Additionally, I don't think shapefiles support a split ratio policy at all. Only geodatabase feature classes and tables support a split policy. Therefore your script will never work as long as your input is a shapefile. Your script might work as you have written it if you changed the feature class input from a shapefile to a geodatabase feature class. Finally, only numeric fields honor the split policy and only Double and Float fields will honor the policy with an acceptable degree of accuracy. ... View more

Is it possble to measure a route for an M enabled polyline feature class using python. I want to measure a route cosisting of river sections. Each arc is from one river confluence to the next. I want to measure all arcs that make up a river. The rivers have a unique number for each river including all arcs from the river source to the coast. I have written a script using the CreateRoutes tool (from linear referencing) but this merges all the river arcs. I tried using this tool in a loop using a cursor to measure each arc individually which was successful but it does not retain the attributes of the input feature class. Is there another way of measuring or setting the M values for a line? If you really want an arc by arc route system, then calculate the ObjectID of the arcs into a new field and build your routes with that field as the RouteID.  Then transfer all of the attributes from the arcs with a Join of the original arc new field/ObjectID to the RouteID field.  It could be a text field concatenation of the RiverID and ObjectID if you want.  You can then either use the Field Calculator to transfer the arc attributes or perform an Export to make a copy with the attributes appended.  Then you can select all of the route arcs the same way you would select the original arcs and calculate their measures, which will have been built according to their length.  The disadvantage of this method is that the measure will restart with each arc, which may not be what you want. An alternative approach is to build the full river route as you already have done and then use the Locate Features Along Route tool to create a set of events from your original river arcs.  This tool creates fields with the measures of each arc for you that will align to the full route.  You should still create a copy of the ObjectID in a new field if you do not have a unique ID for each arc individually.  The event table has the advantage that it will let you sort the arcs by measure, which will be in the order that they built the full route.  You can then make a Route Event Layer and export the events to a feature class to convert them to real route arcs. You probably will have branches.  Normally my routes do not have branches, since they are roads.  Branches can complicate the use of events, depending on what you want the measures to represent.  If they just represent distance from the headwaters down any branch they should be OK (although lines will duplicate when measures overlap on multiple branches).  If you want separate measure systems on minor branches that do not overlap your main river, you would have to manually correct the measures at the branches to make minor branches have measures that did not interleave with the main river measures or with other branches. Your RiverID can only really act as a RouteID for the full river route.  Multiple uses of the same RouteID for different routes will probably cause problems, depending on what you want to do. ... View more

I believe comboboxes allow a user to type a value without scrolling, which can then be validated against the list in the combobox.  Also, the real formula that the selections would return the results described would be: [Total] <= 23 And [Total] >= 51 Not [Total] < 23 And [Total] > 51 I believe you need to look at something like the combobox SelectedItem and ListItems interface and use a for loop to read the list of the first combobox from the selected Index number to the bottom and use the second combox's Clear and AddItme methods.  Anyway, VBA is being depricated, so don't develop using that.   I can't even find the help files for VBA anymore to recall how I used to do this.  Move on to VB.Net or another .Net language. ... View more

Hi, I have a question about how to make new polygons based on the values of an attribute within existing polygons. I have a census block groups with values 0-20 (or  so) and would like to group them so that the values equal 26 or as close as possible without going over. I think this could be done with a dissolve but I am not sure how to dissolve into groups like that. Thank you for your help! I don't understand your description of your data and what you are trying to do.  How would these attribute values equal 26 if they range from 0-20?  Are they first being accumulated in some way?  If that is the case a value of 0 would accumulate with every group without pushing the accumulated value over any threshold. What do these values represent and why do you need to group them?  What are the accumulation rules?  Would the groupings have to be contiguous or would they form multi-part polygons? In general the dissolve would have to be based on a select by attribute expression on the field, but the field itself would have to be excluded as an actual case field if the selection would merge multiple actual values together.  The selection field could only be included as a summary field to merge together the different values.  In all likelihood this would involve a multi-step process to achieve the final result you are looking for. A picture with a couple examples would really help define what you are asking for and lead much more quickly to the best solution to your problem. ... View more