|
IDEA
|
So if I did that, any advanced configurations in a feature dataset built on an ObjectID relationship, like Feature Linked Annotation, Topology validations, etc. would most likely be destroyed, since I doubt they would reload the data in such a way that the ObjectIDs are not regenerated.
... View more
06-23-2016
02:28 PM
|
0
|
1
|
2958
|
|
POST
|
Linear Referencing creates points with two fields holding a Route ID (that uniquely references a feature class with polylines that contain Route IDs and measures or M values in the geometry) and a single measure (a station) and creates line segments with 3 fields holding a Route ID and two measures. The Locate Features Along Route tool can determine the Route ID and measure of a point feature class that is created using geocoding and output a table containing the Route ID and measure of the point. Run this tool twice, once with the geocoded From point and once with the geocoded To point. The From and To points should already have the same Bike Lane Segment ID associated with them before doing this and there should be two points with the same bike lane segment ID. The points should also have the intersection name field. Uncheck the match only closest route option when running the Locate Features Along Route tool when doing this, since you can select the true matches based on the street the bike lane segment is supposed to be on and export that set to eliminate false matches. Now since the two table have the same bike lane segment ID (your From and To points), join the two tables on that ID and export the table. Now you have a single table that has a Route ID and two measures (a From Measure and a To measure) and you can use it to create a bike lane segment with the feature class that contains Route IDs and measures or M values in the geometry by using the Make Route Event Layer tool.
... View more
06-20-2016
03:03 PM
|
1
|
2
|
2878
|
|
POST
|
So those are the name of the layers. Layer names should not include a workspace path, just a layer name. Change the code to: # You need to create a variable named oldStops in your code:
oldStops = workspace+"oldStops"
newStopsFL = "newStopsFL"
oldStopsFL = "oldStopsFL"
arcpy.MakeFeatureLayer_management(clippedStops, newStopsFL)
print arcpy.GetMessages()+"\n"
arcpy.MakeFeatureLayer_management(oldStops, oldStopsFL)
print arcpy.GetMessages()+"\n" The variable oldStops is nothing, since you never initialized a path to a feature class for that variable in your code, so it won't exist.
... View more
06-20-2016
12:05 PM
|
1
|
1
|
2436
|
|
POST
|
While Darren's code only checks one coordinate axis to determine if the current vertex being examined is more extreme in a certain direction, he actually replaces the point associated with that compass direction with the full vertex point coordinate pair from the polygon boundary. So all of the points listed in his table are real coordinates that fall on the polygon boundary. I believe the extent pairs of min/max coordinates are correct for a single axis of each point in Dennis's list, but the other axis of the coordinate does not have to fall on the extent rectangle boundary corners. So while the westerly most point has to match the min X value of the extent, the Y value can be anywhere along the western edge of the extent polygon (min Y <= West point Y <= max Y) as long as it is on a vertex of the original polygon (or a point along a true curve). So as long as there are no true curves it seems like you could search through the vertices of the polygon and find any and all points that matched on the appropriate axis from the extent (which in the end should be what Dennis's code effectively does). It can be accomplished by creating the extent rectangle for each polygon and doing an intersect to get the polygon points that actually touch the extent edge as a multipoint, but Python is easier since each polygon has to only intersect its own extent which would require iteration in ModelBuilder (inefficient). See the picture below. She wants the red points for the polygon below. If the polygon included any true curves that could touch an edge of the polygon extent between the ends of the curve, you would have to use the intersect tool or the geometry intersect approach to find the real point for that compass direction, since the point along the extent boundary would not be a vertex of the polygon in that case.
... View more
06-15-2016
11:22 AM
|
2
|
1
|
2679
|
|
POST
|
Adding a counter only requires the code modification below: try:
cursor = arcpy.SearchCursor(sara, fields="BUFFDIST; UNITS") # old cursor syntax
counter = 0
for row in cursor:
counter += 1
dynamicFileName = '_{0}_{1}_{2}_.xls'.format(str(row.getValue("BUFFDIST")), row.getValue("UNITS"), counter) If you have ArcGIS 10.1 or greater you really must convert the old cursor to the new da cursor to make it perform tolerably.
... View more
06-13-2016
08:54 AM
|
1
|
1
|
1329
|
|
POST
|
ModelBuilder is a waste of time frankly for what you want to do, since this type of general model requires real programming and not the pseudo-coding ModelBuilder offers. Converting the process to Python is the best advice and you will get much more help on the Forum. The learning curve may seem steep, but you won't get it done in ModelBuilder faster, since once you get to complexities like this ModelBuilder starts showing its many limitations and Python becomes much simpler to set up. Export the 4 separate working models into 4 seperate Python files using the modelBuilder export functions as a starting point. I don't see how to connect your description of what you are doing to the model you have posted, since you are assuming I will understand field names and other information that only you currently know exist. For example, what in the shapefile will have an average of >90? A field? A count of records? The whole process can probably be restructured to be better organized to enhance the code's ability to handle the full range of your inputs once all of the essential components in play are actually laid out in an intelligible order to people like Dan and myself.
... View more
06-13-2016
08:22 AM
|
1
|
0
|
6345
|
|
POST
|
Clearly the BuffDist and Units fields you are using to modify the spreadsheet names do not contain unique combinations for each feature. If the first and second feature both have a BuffDist of 50 and a Units of 2 then the code will work for the first feature and fail for the second feature with a report that the spreadsheet name already exists. You need to make sure that the spreadsheet file names are always unique. You should add a counter value to each set of spreadsheet names or some other field to the file name that ensures that each set of spreadsheets is uniquely named.
... View more
06-13-2016
07:30 AM
|
1
|
2
|
1329
|
|
POST
|
What is the purpose of getting unique values? Do you intend to do some kind of iteration? What would you iterate? Without iteration I do not think you need If Then logic at all. For problems like this I normally start the script with the shape file, use the Make Feature Layer tool to convert it to a Layer, use the Select Layer By Attribute tool with a selection expression of "FIELD" > 0, do the processing on those records, then Select Layer By Attributes with a selection expression of "FIELD" <=0 or "FIELD" IS NULL and do the other processing. ("FIELD" is any actual field name of an existing numeric field).
... View more
06-11-2016
06:12 PM
|
2
|
1
|
6345
|
|
POST
|
There is no simple formula unless you are dealing with a circle or only the simplest of polygon shapes. One post I found ([R-sig-Geo] How to buffer a polygon by area) suggests it can be done in several buffer iterations if you allow for some level of tolerance for some imprecision in the percentage. Another approximate method that may work is based on a ratio of the area to the perimeter length and is shown in Creating polygons as % of original area using ArcGIS Desktop? - Geographic Information Systems Stack Exchange
... View more
06-07-2016
02:12 PM
|
1
|
0
|
8666
|
|
POST
|
LR and Network Analyst both behave better with networks that have correct attributes and geometry. LR is primarily best for facilities management tracking that is concerned with events along a single roadway that is logically named and that follows a well laid out path between two end points, while Network Analyst is best for routing and analysis that can follow any of the possible paths on the entire set of interconnected roadways. Each tool set will reveal different weaknesses of the network in the geometry or attribution. They each have strengths and weaknesses that the other may address. They both work best when topology is correct and roadway connectivity is explicitly contained in the geometry without the need to apply fuzzy tolerances that may introduce unexpected connections or disconnections. A geodatabase topology is often a third component of a good network that provides the best approach to resolve issues in the network geometry that will improve the network for both LR and Network Analyst.
... View more
06-07-2016
08:55 AM
|
1
|
0
|
1688
|
|
POST
|
My method does not use Network Analyst. I have much more recently created a network from my centerlines, but so far I have not made any changes to the process to replace the fields. The two do have some overlap, for example, both need to be aware of one-way verses two-way segments, since I make separate routes for each direction when the roads separate into one-way segments. To deal with roads that split and merge into one-way and two-way segments I added fields to my LR creation process that separate North or West segments from South or East segments. When it follows a merged two-way segment the Route IDs for both directions are applied and when it splits to a one-way segment only one of the directional Route IDs is applied according to the one-way direction. Split roadways are a reality, but they tend to be a pain for facilities management, since they create more complexity in the ways things need to be referenced that the field crew descriptions leave ambiguous. In my network, with the exception of freeways/highways, I have dissolve dual centerlines to single centerlines in all but a few cases since facilities management takes priority over network routing in my operations. These routes are a subset that undergo a separate process for route creation from the 90% set of routes that don't involve one-way segments, since it takes more steps to separately create them and merge their schema back into the simpler to generate dual-direction routes. A person who has a well defined network for network analyst will have to identify these roads as well, but they may favor retaining of split roadways if they do not consider facilities management to be a priority and instead need to solve routing problems primarily. In my experience, centerlines have no single form that fits all needs perfectly and each organization has to adjust the network layout to fit their primary mission objectives.
... View more
06-07-2016
08:18 AM
|
0
|
1
|
4521
|
|
POST
|
The methods I have outlined provide a way to get the results you want, but nothing works automatically for 100% of all roads. All analysis tools have a 10% to 20% exception rate in my experience and you manually have to correct those exceptions. No tool will do the work for you on 100% of all roads. The best approach to all GIS work is to use tools to deal with the 80% to 90% of common road layouts and then invest at least 10 times the amount of effort in dealing with the exceptions. That is the best anyone can offer. The addition of fields is the most efficient method for being able to correct the problem cases, so that they can be scripted and reliably fixed if the process is repeated. By doing this I am now able to regenerate my entire network of routes each week automatically to incorporate routes for all new segments. By using the field values I am able to automatically handle each exception with a separate set of tools or steps that can all be merged at the end. As new exceptions arise I have a well established method for classifying them and correcting them.
... View more
06-07-2016
07:54 AM
|
0
|
0
|
1869
|
|
POST
|
LR allows me to collapse two adjacent segments on the same route into one easily enough or more frequently to subdivide it further in response to new limits. I deal with limit changes all the time. Sequential numbers and sorts are far too fragile to waste my time managing them, since every new subdivision messes them up. New subdivisions of segments has no impact on my inventories or event data. Extending or realigning routes may, but I have better ways to readjust the event measures when routes realign or extend. I can also detect portions of existing segments easily with LR and have no limit to the number of positions along my lines that I can reference or use as a limit, since the original lines never impose a limitation on where I can define my event segments. I have built tools that let me define any point or segment event relative to any cross street intersection and offset distance and direction I want, whether or not the underlying lines have an end point at those positions or not. The cross streets only have to be somewhere on the route for me to reference them. It does not matter what underlying segments of the original network they are physically in contact with. Therefore each and every position that exists on the route can be defined relative to every valid intersection on the route, I only have to adjust the offset distances from the fixed intersection to define them. For facilities management and collision reporting this is ideal, since there is no way to know which side of an event a person favors or what cross streets they consider useful as a reference point. If there are 10 cross streets on a road then there are at least 10 different valid ways to reference any position along that road relative to a cross street.
... View more
06-03-2016
12:33 PM
|
0
|
2
|
1869
|
|
POST
|
I have done my career in Transportation analysis and never needed sequentially numbered segments for any work I have done. I have used the LR approach to create logical non-branched routes across my entire network. I have over 35,000 routes created from over 120,000 segments. They work very well for collision analysis and facility management analysis (pavement management, road maintenance, inventory control, etc.). LR has far more uses than a sequential number ever would on the non-LR original segments. What make this sequential number so necessary for your work? I am just asking, since it would be easy for me to create a sequential number from the LR foundation I work with, but not useful as far as I can see to the work I do. I also think you do not realize the real value of LR and the many uses it has that go far beyond the sequential number you hope to create. Without ever numbering the segments I have used LR to assign Address Ranges to my original segments, so I view sequential numbering or presorted road segments as irrelevant to that problem and most problems like that.
... View more
06-03-2016
12:00 PM
|
0
|
0
|
2833
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-24-2026 11:37 PM | |
| 1 | 03-24-2026 08:01 PM | |
| 6 | 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 |
Saturday
|