Latest Contributions by RichardFairhurst

That doesn't work either.  Not sure why not it always brings up an error. Perhaps a dumb question, but what are you actually putting in the first line to specify the workspace folder?  If the path is unspecified or invalid (such as incorrect slashes, which is common with path strings), that could be the source of the error. arcpy.env.workspace = 'C:\\GIS_DATA\\' # or r 'C:\GIS_DATA\' mxd = arcpy.mapping.MapDocument("Current") fclist = arcpy.ListFeatureClasses() for i, fc in enumerate(fclist):     arcpy.CreateFeatureLayer_management(fc, "layer_%i" % i) ... View more

Greetings all. I apologize for posting in this thread. No one has replies since I posted my own thread. I am in desperate need of some help. I work at an electricity company am I am trying to set up an electric distribution geometric network. I created it successfully and set up what I think are the right connectivity rules. There is a situation where two different circuits occasionally run on the same pole (Point A in the pic) or one line terminates perpendicular to another line from a different circuit at the same pole. Can someone please assist me in getting the circuits in green and purple to flow freely to their ends even if they seem to intersect at point A? I have attached the sample geodatabase that i'm working with. My email address is [email protected] Regards Gideon. Gideon: I don't use geometric networks and the original topic of this thread (and what it has evolved into) do not require a geometric network to work.  Geometric networks have unique properties that require insights from those that use them to help solve your problem.  So I am afraid I cannot help you.  What forums have you posted this problem under before?  You need to reach the audience of Utility specialists to help give you an answer. ... View more

I'm working with a table that is stored in ArcSDE.  It is a list of all stormwater managment facilities maintenance agreements owner information.  I'd like to be able to add new owners to the list.  How do I edit a table that is in ArcSDE? Do I have to export the table to a personal geodatabase, edit, and then reimport in into SDE?  Thanks. ArcSDE has to be configured for editing by the administrator for you to edit dirrectly to it.  My administrator has some environments that are read only to end users and other environments that allow approved editors to alter data.  The administrator has to give you access to the editing environment, grant your user ID editor rights, and grant editor privileges to you on the specific feature class you want to edit.  If the feature class is versioned for multi-user editing you must create a personal child version from any protected parent version to allow you to edit.  Someone with access to the protected version would have to be asked to review and post your edits.  For unversioned data you would have to change an option setting under the Editor Button to disable versioned editing. If you have no way of getting configured for SDE editing, you can copy or export the feature class to a file geodatabase which is the best option for preserving precision and features of SDE and edit it there.  To get your edits back into SDE you would have to approach your administrator to upload your data into the SDE environment.  But normally if they will not make you an editor, your SDE administrator will not upload the edits you've done outside of SDE.  You may have to create a work order to the SDE editor group, supply them with the information you want and have them charge you for the edits if that is the way your departments operate. ... View more

You need to use the selection and editing tools provided on the Annotation Toolbar, not the standard editor selection tool to move the annotation or access feature class annotation context menus.  There are some other twitchy aspects of feature-class annotation editing, such as it must be a selectable feature set in the Selection tab.  It has been a while since I have done annotation editing, but those two things are essential (along with being in data view or a focused data frame as mentioned above). ... View more

You could use the Summarize tool without a case field and sum the population.  You could add a temporary field to both tables with a dummy value like 1 and join the result to your original layer on that field.  Then you can calculate over the resulting summed value to all of the records or get percentages.  Or else add the dummy field to your original layer first and use that as the Case field for the summary. A cursor in python could also do the sum and write the result, but not the field calculator. ... View more

I'm still learning about all this, but my current understanding is that if I have a street segment named "Easy St" and it meets  "Main St" at a T and has a court half way up the steet on the side called "Dwight Ct" then I would need routes for {Easy St} {Main St} - {Easy St} {Easy St} -the broken line where it meets Dwight Ct {Easy St} {Dwight Ct} Would I also need to stack a line or add a column and have these street names transposed so that I could do the opposite direction? Actually, that is not correct.  My original Centerline are not routes and have no measure data associated with them.  My routes are derived from them by running the Create Routes tool in the Linear Referencing toolset on a ROUTE_NAME field that holds a value that may be shared by many related Centerlines.  All Centerlines named Easy St that are logically related will have the same ROUTE_NAME value, so that they will build into one connected route.  In my case it would be something like "EASY ST SWAP", where SWAP represents an area plan for distinguishing an Easy St in that portion of my County from another Easy St in another area of my County.  I choose the predominant area plan assocatiated with a street and do not change the area plan assigned to a set of the Centerlines that should connect, even if they technically cross an area plan boundary, since continuity of logically related Centerlines in a route is more important than any other consideration. You would run the Create Route tool in the Linear Reference toolset to create a route for Easy St from one end to the other, a route for Main St from one end to the other, and a route for Dwight Ct from one end to the other, regardless of how many streets they intersect or what streets they intersect.  The routes hold the measure for any position along the route and have no awareness of cross streets at all.  You may have to create a special naming convention for the RouteID where multiple widely separated streets have common names like Main St, so that you can distinguish a Main St in one area from another and not have them connected across vast distances (which would be meaningless if they will never connect or directly interact).  The Route only needs to be built in one direction to aggregate a standard set of two-way centerlines for any given street that does not branch.  No two Routes should have the same RouteID.  That ID must be unique for each route and the route should connect as many Centerlines as you could reasonably travel along (which may include minor gaps if there are offsets across an intersecting street). The point class of intersections is where you get your first set of events that give you your reference points, not the routes.  I first build a standard intersection point class that holds all of the intersecting street names associated with a given intersection point and get the X/Y data for the intersection point.  It does not matter if the intersections fall at the beginning of the route, the end of the route, or somewhere in between the two ends of the route. Now that you have those two feature classes, you run the Locate Features Along Route tool so that your intersection points get the RouteID and Measure values of the Routes they fall along.  You should use the setting that lets the point get data from all routes that touch the point.  The resulting point event table now holds the fixed X/Y position of the intersection from the original point class input to the tool and the relative route and measure data of an LR event that also represents that same position as a distance along the route. When this completes you run a second model process to generate all of the possible cross street combinations from the Locate Features Along Route result into a new table.  It is created by a series of selections, calculations and append operations (two street names intersecting will typically generate two records for each street combination (which is typically in the standard result of the Locate Features Along Route output), three street names will generate 6 records (4 records need to be derived and appended), and 4 street names will generate 12 records (10 records need to be derived and appended)).  This is the event table that gives you all of the intersection reference data you need for creating subsequent events tables that will include offsets. ... View more

Just another note: Usually Engineers build Routes from the Lower Left to emulate stationing, so that Route measure typically increase from West to East and from South to North.  Addressing often is oriented from the Upper Left.  For routes that go diagonally oposite of the primary chosen orientation you may have to flag those Centerline and build a route in the other direction.  For example, if you chose Lower Left as the primary, then a diagonal route that runs from Northwest to Southeast you should flag that route for building from the Upper Left.  If not it will often build in a wierd way from the middle of the Route to each end.  My Centerlines have a field called BUILD_DIR to help me select these routes for a special build. ... View more

Here are some useful calculations for validating that LR Routes are simple. Create a Long field called Parts and use the following advanced calculation to determine how many parts make up your route (I allow gaps when building routes so that I can cross minor jogs at intersections.  Branches always result in at least 3 parts to a route): Parser: Python Pre-Logic Script Code: def Output(PartCount):   return PartCount Expression: Output(float(!SHAPE.PARTCOUNT!)) Create a field of type Long called MMONOTONIC and use the following advanced calculation to determine the M Monotonicity of the LR Route (A value of 1 indicates measures are continuously increasing, which means the route has no branches and is simple.  Any other value indicates combinations of measures that are increasing, decreasing or unchanging, which means the LR Route has branches, full loops or other complex route configurations.  This is the value reported descriptively in the Identify Route Locations tool and you can create a domain that replicates those descriptions if you like): Parser:  VB Script Pre-Logic Script Code: Dim Output As Long Dim l As Long Dim pCurve As ICurve Dim pSegmentCollection As IMSegmentation3 Set pCurve = [Shape] Set pSegmentCollection = pCurve Output = pSegmentCollection.MMonotonicity Expression: Output Once you have created routes you can get Rooute ID values and measures assigned to your intersection points by using the "Locate Features Along Routes" tool in the Linear Referencing toolbox.  Below is a sample of the fields I have in the intersection pair event table to use as joins and value transfers to subsequently derived event tables.  I use these fields for validation of the subsequent events and updating the derived events in response to changes in my routes, such as realignments, road renaming, etc.: RID: VIA LOS VENTOS SWAP ' Route ID created by the Locate Feature Along Route tool.  In this case the Street name is VIA LOS VENTOS in the Southwest Area Plan (SWAP) MEAS: 5023.8725 ' Measure created by the Locate Feature Along Route tool. Distance: 0 ' Field created by the Locate Features Along Route tool.  Typically 0. STNAMES: {LOS GATOS RD}{VIA LOS VENTOS}{VISTA DEL MAR} ' All names listed alphabetically X_COORD: 6231383.346493 ' transferrred to subsequent events so offsets can be compared. Y_COORD: 2315384.464358 ' transferrred to subsequent events so offsets can be compared. X_Y_LINK: {6231383.3465}{2315384.4644} ' Useful relate value for when route name changes WAYS_COUNT: 4 ' Number of Centerline segments that link at intersection STNAME_WAYS: {1}{1}{2} ' number of segments associated with the STNAME field street order POINT_ID: 26638 ' Numeric value representing the Point X/Y value STNAME: VIA LOS VENTOS ' Primary Street Name often used as a relate CROSS_NAME: LOS GATOS RD ' Cross Street Name often used as a relate X_Y_ROUTE: {6231383.3465}{2315384.4644}{VIA LOS VENTOS SWAP} ' Best final join for the RID and Meas values. PAIR_STNAMES: {VIA LOS VENTOS}{LOS GATOS RD} ' First level join field X_Y_PAIR: {6231383.3465}{2315384.4644}{W CHURCH ST}{IOWA AVE} ' Best Final Join for the name pair value The above X/Y point would have 6 entries in my intersection pair table so that I could relate to any combination and order of the three (3) street names that meet at the above intersection. Typically my derived events have the following fields: PRIMARY: VIA LOS VENTOS CROSS: LOS GATOS RD DIST: 100 DIR: W FACING: E ' FACING representing the direction of travel of a driver on the road looking at the sign, not the sign itself in my data. PAIR_STNAMES: {VIA LOS VENTOS}{LOS GATOS RD} 'First level join or relate to intersection pair table INT_X_Y: {6231383.3465}{2315384.4644} ' FROM X_Y_LINK. Useful as a relate INT_X: 6231383.346493 ' Intersection X value from X_COORD.  Useful for validating offset. INT_Y: 2315384.464358 ' Intersection X value from Y_COORD.  Useful for validating offset. X_Y_PAIR: {6231383.3465}{2315384.4644}{W CHURCH ST}{IOWA AVE} ' Best Final Join for the name pair X_Y_ROUTE: {6231383.3465}{2315384.4644}{VIA LOS VENTOS SWAP} ' Best final join for the RID and Meas values. INT_MEAS: 5023.8725 ' From Meas value of the intersection OFFSET_MULT: -1 ' Multiplier for offset representing the direction of offset. OFFSET_DIST: 100 ' Repeats or adjust absolute offset distance so that it stays on the route ROUTE_ID: VIA LOS VENTOS SWAP EVENT_MEAS: 4923.8725 ' Actual measure of derived event.  Equals INT_MEAS + OFFSET_MULT * OFFSET_DIST CL_X: # ' Calculate Geometry on an event without a side offset.  Can be compared to INT_X to make sure offset went in correct direction. CL_Y: # ' Calculate Geometry on an event without a side offset.  Can be compared to INT_Y to make sure offset went in correct direction. SIDE_MULT: 1 ' Multiplier representing side offset direction related to FACING SIDE_DIST: 30 ' Holds value of Side offset distance.  Recaled as SIDE_MULT * ABS(SIDE_DIST) INT_ANGLE: # ' Calced from LOC_ANGLE (the event angle) when event is at Intersection Measure.  Tells you angle of your route at the intersection to help predict offset. CALC_ANGLE: # ' Calced from LOC_ANGLE (the event angle) when event is at Offset Measure. Tells you angle at final event location to help predict side offset. ROTATION: # ' Calced to give final rotation of FACING relative to the CALC_ANGLE value with 90 degree adjustments.  I have a calcuation for doing this. EVENT_X: # ' Use Calculate Geometry to get final event location X coordinate.  Can be compared to CL_X to make sure side offset went in correct direction. EVENT_Y: # ' Use Calculate Geometry to get final event location Y coordinate.  Can be compared to CL_Y to make sure side offset went in correct direction. I hope this helps. ... View more

I just thought I would upload an example of what can be achieved with the Linear Referencing methods I am using.  Attached is a sample of some of the 44,000 Traffic Control Device points I have geocoded.  Every sign on the map was placed by translating the cross street references of the field crews to one of my intersection route and measure values and then adding the specified offset in the direction recorded in the field.  The addition of a side offset and rotation based on the sign facing together with the appropriate symbology for the sign helps present the information understandably.  Each point can be clicked for more information, such as installation date, inspection date and repair requests.  Also each sign has a hyperlink to Google so the sign can be checked in street view. ... View more

My Topology is good, I have cleaned off alleys and unnamed streets.  I haven't created much in Linear Referencing yet.  I have a point feature class with my intersections in the format "{EASY ST}{DAILY DR}", Since you have not created any Linear Referencing routes, you can build a script to generate them in ModelBuilder.  I recommend a script if you have a large number of lines to agregate (over 20,000), since I found I had to process blocks of Centerlines in groups about that size and append them together to get decent performance out of the Create Routes Tool.  I have a separate ROUTE_NAME field in my Centerline layer which becomes the Route ID in the Create Route Tool.  You can make the route ID any Unique value (numeric or string) as long as it agregates the lines that you want joined together. You should also include in the Model the environmental settings for M Resolution and you Feature Class extent if you need to append multiple outputs together like I do.  Letting the tool generate custom extents or M resolutions makes repeatability in future runs more difficult for tracking route changes.   A sample of the environmental settings I use in my exported Python script are as follows: # Set the Geoprocessing environment... #gp.XYTolerance = "0.003280833333333 Feet" #gp.XYResolution = "0.000328083333333 Feet" #gp.XYDomain = "-118608900 -91259500 2954993346592.94 2955020695992.94" #gp.outputCoordinateSystem = "PROJCS['NAD_1983_StatePlane_California_VI_FIPS_0406_Feet',GEOGCS['GCS_North_American_1983',DATUM['D_North_American_1983',SPHEROID['GRS_1980',6378137.0,298.257222101]],PRIMEM['Greenwich',0.0],UNIT['Degree',0.0174532925199433]],PROJECTION['Lambert_Conformal_Conic'],PARAMETER['False_Easting',6561666.666666666],PARAMETER['False_Northing',1640416.666666667],PARAMETER['Central_Meridian',-116.25],PARAMETER['Standard_Parallel_1',32.78333333333333],PARAMETER['Standard_Parallel_2',33.88333333333333],PARAMETER['Latitude_Of_Origin',32.16666666666666],UNIT['Foot_US',0.3048006096012192]]" #gp.extent = "6129957.88366199 2098700.9515318 7097398.14694032 2341052.42516121" gp.MTolerance = "0.001" gp.MResolution = "0.0001" #gp.MDomain = "-100000 900719825474.099" In my model I first create a layer on my Centerlines and then do a Select by Attribute to subselect a set of Centerlines to aggregate into routes.  Since my County covers many areas I have assigned an area plan field to cluster roads in an area, that way I don't append Main St at one end of my County with a completely unrelated Main St on the other end.  My selections use these area plans for building my routes. After you have built your first set of routes, you can look for anomolies like three-way branches, which can mess up your measures.  I assign new Route_Names to break minor branches from the main route branch.  (I have special fields for handling roads that separate into parallel one-way segments and then remerge into two-way segments so I can build separate unbroken eastbound/westbound or northbound/southbound routes). There are special calculations for getting the monotonicity (continuity of measures) value and the parts that made up the route that help to simplify the routes.  Simple routes are easier to use than complex routes. Anyway, I am out of time but will post the calculations I use in the model for route analysis.  I add the fields and calculations in the model structure as well (another reason to create a model). I hope this helps. ... View more

Richard, thanks for the post. I am looking for some code that will do offsets from an intersection and create a point along a line.  For example a traffic collision on Easy St 100 ft North of the intersection with Daily Dr.  I have seperate columns for Primary street, cross street, distance and direction.   Do you have code I could tweak to make it work? Your basic configuration of the data is what I normally have, but I also include an intersection distiguisher field to help me know what intersection to choose when multiple locations have the same street name pair [I prefer this to making the cross-street something like Daily Dr. (S)]. Actually, I don't use the interface any more and even when I did, it would just be an extension of the data set I use today.  I have a series of scripts that builds LR Routes, Intersection points and an event table of every intersection name pair with Route ID and Measure.  I have a series of join fields in the intersection pair table that allow me to transfer data about the intersection to other event tables so I can reference either a relative or absolute position for the intersection (that way I can use the table as either X/Y events or LR Route Events).  I find the intersection pair table helps me to QC my field data, since misspelling of street names is very common and the most time consuming aspect of geocoding.  I always preserve the original misspellings and add fields to hold my corrected spellings or alternative intersection descriptions when the intersection described is not available and I translate it to another intersection reference. In my dervative event tables I add matching join fields, starting with the primary and cross street pair in the format of "{EASY ST}{DAILY DR}",  The intersetion pair table tells me if this is a unique name pair or if multiple intersections have this name pair (in which case it has additional fields to identify if the particulal record is either the most E/W, N/S or 1/2/3... when more than two identically named intersections exist). For the Offset, I add a field to hold a multiplier of 1 or -1 to trranslate the compass direction into a compatible LR direction of offset.  Typically E and S use a multiplier of 1 and N and W use a multiplier of -1 based on the way I constructed the routes.  To get the offset measure, I add the base intersection measure I got from my intersection pair table to the distance of offset from the field data multiplied by the offset multiplier. I have found this set up to be very flexible and it work most efficently when I am processing 1,000 records or more.  I have also used this method to position signage, which additionally must account for the sign facing with a separate side offset and rotation. If I were to build an interface based on LR methods, it would still use these underlying feature classes and tables.  What sort of LR network data do you have at this point and how clean is it topologically for your intersections? You may want to look at Crossroads or other commercially available software for collision data conversion if you are using State supplied data, since it aids in the conversion of the State data and has the ability to project collisions on a projection beyond the actual centerline ends (something LR data does not do). ... View more

As the help topic mentioned indicated, you need to export the .dbf table to a geodatabase table (file, personal, or SDE) so that the table has an ObjectID field.  This same restriction affects QueryLayers and virtually all in memory layer types. ... View more

This is not an easy interface to create and it would have to be done all in custom code.  There are a lot of possible points of failure for user input that have to be validated before a result can be returned.  For example, you must validate that the street name is correct, and that both cross streets exist along that street before you can get the line segment that represents that description.  You also may have to resolve ambiguous situations where two or more identically named intersections exist and one must be chosen. Beyond that I would say that at a minimum you would need a dissolved network of streets using your street name and an intersection point layer that could be searched for cross-streets (See this thread for one possible method of doing that).  If you used ArcObjects, the minimum interfaces needed would include the ICurve.QueryPointAndDistance Method to find the percent or distance along a selected dissolved street line defining the location where each intersection fell along the dissolved street and the ICurve.GetSubcurve Method to get the portion of the dissolved street that fell between the two points.  Then you would need to do a small buffer of that subcurve with the ITopologicalOperator.Buffer Method and finally do a selection of your original lines that were completely contained by that buffer and had the correct street name.  I don't think Python could handle the interface or the operations, so you would have to look at what it takes to create add-ins using Visual Studio 2008 (Express or higher), which is not simple going forward at 10.1. The interface could not keep current if your edit session actually changed street names or the network connectivity of your original line network and such changes would require periodic rebuilds of the dissolved lines and intersections to allow you to get accurate results.  But periodic rebuilds are required by Network Analyst and Geometric Networks as well. The above assumes that the network has no or very few roads that branch.  Streets that branch (i.e., three or more lines with the same street name meet at the same point) will generally give bad results with the above interface.  So if you typicaly have parallel segments of road representing one-way travel on a single street going around a divider that meet at the ends of the divider, you will have many problems and many ambigous intersection choices that complicate this idea to the point that I do not recommend attempting it. While I have not designed an interface that specifically does what you want, I did create one for doing linear referencing events that was more involved than what you need, since it had to handle offsets from an intersection (i.e., find the portion of A St that is between 235 feet East of 1st St and 545 feet West of 5th St).  Let me know if you want to pursue this idea now that I have given you an idea of what it involves. ... View more

I tried the rounded end caps, but that did not help much because I found that most of the artifacts were appearing because of excessive points along the line.  I used the Simplify line tool with a 100 ft point reduction and that removed the artifacts.  However, that setting may have simplified some of the lines too much, so I will have to try other settings.  Anyway, that seems to be the tool I need to use for this particular map layer. ... View more