|
POST
|
Your question is not very clear. What portion would your grab/select? In any case, whatever it is you want, you have to set it up on your map first and then export it or else deal with it in a program like PhotoShop after exporting it. The export options themselves won't let you do much along these lines with the PNG format. If it is a feature selection you want, then can right click the layer in the Table of Contents and choose Selection -> Create Layer from Selected Features, import the symbology from the original layer, turn off the original layer, and then export the map. Or perhaps you mean a Clipping region in your map. If that is the case, see this help on Clipping the Data Frame. If you want to isolate individual layers of your map to work with separately in a Photoshop program I suspect it is best to export several versions of the map with only one layer on at a time and then import these multiple exports into PhotoShop to create separate PhotoShop layers for further processing.
... View more
11-21-2015
01:36 PM
|
1
|
6
|
2286
|
|
POST
|
You should use some tolerance distance with the tool in case the bus stop points are not exactly on the line (even the slightest offset will prevent events from being generated). You have to create a geodatabase topology to get your lines and points to snap with enough precision that you could use a tolerance of 0. If that still does not work, make sure both the lines and points are in the same projection and try selecting features in both layers as inputs to the Locate Features Along Route tool. If none of that works, post a screenshot picture of what you have created. It may reveal something I have not thought about. One other note. I explicitly set the M tolerance and M Resolution in the geoprocessing environment to at least 0.01 and 0.001 respectively before running the Create Route tool to make sure the measures are precise and not just whole number measures.
... View more
11-19-2015
07:30 AM
|
1
|
0
|
3557
|
|
POST
|
This can be solved with linear referencing (LR) to get exact positions on a road relative to an intersection or any point feature. If you create LR routes from your road network and create intersection points with the cross street name pairs or landmark names you can use them to get the relative measure of any intersection location and offset up or down the road relative to it. You can use the Locate Features Along Routes to create an event table of all of of your intersection points with all of the routes IDs and measures that define their LR position. In your event table of collisions add 3 fields for the Route ID and measure of the intersection and measure of the collision. Once you look up the intersection record in the intersection event table using the cross street names, copy the Route ID and Intersection measure into the fields you added to the collision table and then calculate the collision measure by adding or subtracting 500 from the measure in the intersection measure field. Assuming your routes are based on the road length and are in meters, this will create a measure that will move your collision 500 m down (add) or up (subtract) the road relative to the intersection based on the route orientation. Once you have configured your collision table into an LR Route Event layer, the collision will appear where it belongs on your road. In many ways, LR measures are equivalent to applying stationing to a road so that you can define any position on the road just by giving the station value of each position. Check out my script for creating intersection points from a road network.
... View more
11-17-2015
04:45 PM
|
3
|
1
|
4059
|
|
POST
|
First create the route with stop 1 as the beginning and end of the line. If you use the Create Route tool, you have to remove a very small segment from the end of the line to break the loop, run the tool, and then move the end vertex to close the loop again, since it cannot create a route from a closed loop polyline. The Route ID would be the same as the Route field in your table for each line. Then, since your stops are points, use the Locate Features Along Route tool to create an event table of the points, Uncheck the option to find the closest route only, since you want Stop 1 to have both a measure of 0 and a measure of the end of your route, Remove events that got associated with the wrong route where two routes cross or parallel each other. Now run the Sort tool to get the Route IDs and the measures to sort in order. Add a TO_MEAS double field and a Long field called NextID and calculate NextID to be the ObjectID of each record plus 1. Duplicate the table. Join the ObjectID field of one of the tables to the NextID field of the other and select all records where the RouteIDs of the two tables match. Calculate over the measure of the joined record into the master table. Now you have two measures and can display each record as a line segment for each of your stop pairs using a Line Event layer.
... View more
11-10-2015
12:49 PM
|
1
|
3
|
3557
|
|
POST
|
If you are relying on a numeric field called something like Miles rather than the Shape_Length, Length, etc. field maintained by the feature class in a Geodatabase, then you will have to manually recalculate the Miles field. You can use the Geometry calculator to update the field based on the geometry Property of Length and set the Units to Miles. Setting up a split policy to proportion the value of the field relative to the length may work with the Split Line at Vertice tool, but it may not, since not all geoprocessing tools respect the split policy. For the maintenance of the data, you should use Attribute Assistant. It can be set up to automatically update attributes during an edit session in response to feature creation, geometry changes, or attribute changes. For example, using the Expression method it can automatically update your Miles field every time a feature is created or has its geometry modified using the formula: [Length] / 5280 (assuming your native units are in feet). Attribute Assistant can also be set up to automatically update a Minutes field every time a feature gets created, the geometry changes or the speed limit attribute changes. The Expression for minutes when length is in feet and speed is in MPH is: ([Length] / 5280) / ([Speed_MPH] / 60). Attribute Assistant is invaluable for editing feature classes with lots of attributes that need to maintain a relationship to the feature geometry or between interdependent attributes. However, you do not need a field called Miles for NA to report your distances in Miles, even if your native units are in feet. By default NA should detect and use the geodatabase Length field for cost. As part of the configuration of the Network Dataset you specify the units you want NA to report the native feature class length maintained by the geodatabase and can specify Miles as the units. The way you do that is dependent on the ArcGIS version of NA that you are using, so specify the version in your original post or in a response. I also highly recommend setting up a topology for your centerlines to detect dangles and lines that cross each other. The topology makes it easy to detect these types of errors in your connectivity and easily correct them by doing splits, extends, snaps, or trims using the topology toolbar tools. Even if you don't use a geodatabase topology, the topology toolbar has a Planarize tool that will split selected lines during an edit session where they intersect each other, whether or not a vertice exists at the intersection.
... View more
10-18-2015
08:00 PM
|
2
|
2
|
3567
|
|
POST
|
The two options you mention that would consolidate your GIS feature classes and tables within a single SDE Geodatabase are the only alternatives that would let you edit all of the data in a single edit session and create relationship classes. Determining which option is best depends on your organization's preferred database platform and application requirements.
... View more
10-18-2015
01:29 PM
|
1
|
1
|
3278
|
|
POST
|
The only kind of relationship available is map based joins/relates, which are set up for a specific layer in a specific map. There is no messaging option that will trigger automated updates between the two datasets and with this set up editing is limited to either the layers alone or the tables alone, since an edit session can only be open on one dataset at a time. The selection sets mentioned by Wes are created by first creating a map based relate (right click the layer or table in the table of contents and choose to create a relate), then selecting a feature or record and executing the relate through the table view. This will transfer the selection from one source to the matching features/records in the other source. The biggest challenge is having to start and stop edit sessions to coordinate the edits or keep track of a set of edits in one data source and remembering to do the updates to the other data source, since you cannot simultaneously update them. If the feature classes or tables are not versioned you can edit them with the field calculator outside of an edit session, but the process of selecting records and doing the related calculations is all manual. The bottom line is that with the two sources in two different datasets, there is no way to get the same full functionality available as you have with two sources in the same dataset that have a relationship class created for them,
... View more
10-18-2015
09:56 AM
|
1
|
3
|
3278
|
|
POST
|
I would use the Create Routes tool with lower left priority. Branching messes up everything, so you need to isolate a simple single line main route to get this tool to build the lines in sequence correctly. Roadway splits based on direction of travel have to be eliminated from the main route and you have to choose a single direction of travel as the main route if you want to control sequential measures. For roads with lane splits around dividers, roundabouts, or right-turn only lane splits, I use two route name fields that build routes for each direction of travel (one field for either northbound or eastbound travel, and one field for either southbound or westbound travel). The segments of the route that allow bidirectional travel get assigned route names for both fields, but the segments that allow travel in a single direction only get one of the fields assigned a route name. So the right side of a roundabout in your picture gets a northbound route name and the left side of the roundabout gets a southbound route name. Similarly the right side of the right-turn lane split gets a northbound route name and the left side of the right-turn lane split gets a southbound route name. Then I build the two sides of the road as two routes using the Create Route tool on the segments with values in the appropriate direction of travel field. If there is no branching the routes and measures will get built correctly for the one-direction of travel. I also use the Locate Features along route to get measures for the individual segments that make up a route. By sorting on the measure values I can sequence them. For my purpose I use the two separate halves for separate LR events. In your case you could build one direction of travel route and then manually insert the other half of the roundabout and right-turn lane split manually later with manually assigned measures. Those insertions would never sequence correctly anyway and would always remain as separate parts of the route, since no standard approach for sequence assignment exists at split locations. Basically once you include splits like roundabouts, both sides have to end up with the exact same measures and sequence numbers, which screws up every tool Esri has created and cannot be reflected in the actual line geometry segmentation.
... View more
10-16-2015
08:33 AM
|
1
|
1
|
3652
|
|
POST
|
Jayanta's original suggestion involved using the JOIN_ONE_TO_MANY option, which is not necessary. He has since corrected it to be the JOIN_ONE_TO_ONE option, which is the best. However, his suggestion to use the Summary step is not really necessary if the JOIN_ONE_TO_ONE option is used, since the features are already summarized with one record per line feature. If I did not want a line feature class and just wanted a table with only the JoinCount and the TARGETID, I would just hide the Length field and export the table view to a table (dbf or gdb table).
... View more
10-11-2015
07:15 PM
|
1
|
0
|
1272
|
|
POST
|
Use Spatial Join. It is the elegant solution to your problem. Rebecca's solution may work, but it applies several unnecessary steps. Try the Spatial Join and you will see that I am right..
... View more
10-11-2015
06:26 PM
|
2
|
3
|
10165
|
|
POST
|
This can all be done with a single tool, the Spatial Join tool. Use the JOIN_ONE_TO_ONE option, which will automatically create a count field for the join features. Set the lines as the target and the points as the join features. Use the KEEP_ALL option to retain lines that have no points within the search tolerance, or the KEEP_COMMON option if you only want lines in the output that actually have points within the search radius. You can delete all fields from the Field map, since the tool will generate a TARGETID field in the output that retains the original line ObjectID value. The INTERSECT match option should be fine. Set the search radius to the distance around the line that you want (i.e., 100 feet). The output will be a line feature class, which you can symbolize based on the Count. If you want just a table open the TableView and export it or select and copy the records into a spreadsheet if you just want a spreadsheet. That should be it. Here is a sample input. And here is the output with the lines symbolized according to the point count. You also retain the line length this way, which may be important for understanding the count: For better performance you should buffer the lines by 100 feet first, which will retain the line ObjectID in a field the Spatial Join tool can use. Then use the buffers instead of the original lines with the above settings (except use a search radius of 0), then add a count field to the lines and join the Buffer ID to the original line ID and calculate back the point counts. You do not want to do a JOIN_ONE_TO_MANY and summarize, as that is a wasted step.
... View more
10-11-2015
05:41 PM
|
2
|
1
|
10165
|
|
POST
|
The code below should work to sequence the numbers in the format you want as long as it is for a single prefix and the sequence does not restart for different groups of records: Parser: Python Show Codeblock: checked Pre-Logic Codeblock: rec=0 def autoIncrement(): global rec pStart = 10000001 # adjust start value, if req'd pInterval = 1 # adjust interval value, if req'd if (rec == 0): rec = pStart else: rec = rec + pInterval return "XTLF_XTLF{011d}".format(rec) Expression (Label): autoIncrement()
... View more
09-04-2015
09:00 AM
|
0
|
0
|
2576
|
|
BLOG
|
You should download the attached toolbox again. I have just posted a revised version of the code in the original blog post attachment to use da module cursors and to use a dictionary to sort the points by case field value to speed up the reading and writing of the points. The speed will be noticeably improved when there are a lot of points with a lot of different case values being processed. The revised toolbox now requires a user to have ArcGIS version 10.1 or higher. The time the code takes to analyze the points for creating each hull based on a given k factor has not changed.
... View more
08-07-2015
04:43 PM
|
0
|
0
|
13100
|
|
BLOG
|
I looked at the code and the case field should work with any field type. However, I don't think I ever tested the case field code when Null values existed in the case field. So if there are any points with Null values in Demand_6 field you should exclude them from the input by first selecting the points without Nulls of by using a definition query to exclude the Nulls.
... View more
08-07-2015
02:00 PM
|
0
|
0
|
13100
|
|
BLOG
|
I ran a test with a k of 15 and a k of 30 on some of my points. The k factor of 15 did have to increase for several point sets, but overall was used for most sets. The output of k=15 was good and hugged the points better than a setting of k=30. So the higher the k factor the more generalization you will get when points spread apart. I like the k-15 better, but my preference depends on the nature of point data I am using and whether my objective was for a tight outline or a generalized outline. Below the Red lines outline k=15 and the green fill is k=30 (I ignored the yellow points). The poly on the upper left failed to enclose all points at k=30, but was fine at k=15.
... View more
08-07-2015
01:43 PM
|
0
|
0
|
13100
|
| 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
|