|
POST
|
Yes, you can do this using a Service Area analysis. In particular, if you want to show the road segments reachable instead of a polygon buffer, set the output type to show Lines. Tutorial: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/service-area-tutorial.htm Documentation: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/service-area-analysis-layer.htm
... View more
12-14-2023
06:05 AM
|
0
|
1
|
2383
|
|
POST
|
I think I may not have fully explained the update process for the ArcGIS Online data. We update the data used by the service several times a year, but the historical data is not maintained. If you solve using ArcGIS Online, it will always use the current data, even if the date you enter for your analysis is from 2000 or 2019 or whatever. It will not draw from any archived data that was applicable in those years. Ultimately, if you are interested in modeling the changes in infrastructure between these years and how it impacts walking access, I don't think ArcGIS Online is the right tool for this job. Instead, you would need to find or create network datasets using street features that represent the state of the infrastructure in those years and run the same analysis (same input points, etc.) using each of those datasets, and compare the results.
... View more
12-13-2023
09:31 AM
|
0
|
0
|
2047
|
|
POST
|
The impedance attribute for walking time is just based on distance and a presumed constant walk speed (which you can change by creating a custom travel mode). Historical traffic is only used for driving modes and has no impact on walking. Setting a time of day also has no impact on walking, since the underlying calculations do not make use of any time-dependent attributes. The ArcGIS Online data is updated multiple times a year based on the data we get from our data providers. The walking time and distance will only change when the data is updated to add or remove roads (geometry changes) or to change whether certain roads as restricted or preferred for pedestrians (attribute changes) either because the status of the road changed in reality or because the data provider obtained some new information or corrected an error.
... View more
12-12-2023
09:16 AM
|
1
|
2
|
2082
|
|
POST
|
Hmm, I don't think we have enough information yet to figure out exactly what's going on, so let me ask a few follow-up questions and suggest some possible causes. Does your network dataset have a TimeZone table and attribute? If not, then I don't think the problem you're experiencing has anything to do with the date line because the network wouldn't even be aware of it. What projection or spatial reference are you using? I believe some projected coordinate systems break in the middle of the Pacific Ocean and actually don't wrap all the way around the world. So maybe you need to choose a different coordinate system. Have you verified that the network is actually connected in these locations? You can use the Explore Network tool to click on the line and see whether it's properly connected to its neighboring network edges. If it's not connected, you might need to read about network dataset connectivity: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/understanding-connectivity.htm Are you solving your Service Area or Route using a time of day, or is it time neutral? If you solve it without setting a time of day, do you experience the same problem? Maybe a dumb question, but did you remember to build your network dataset after making any edits to it? (Please also tell us what version of Pro you're using.)
... View more
12-12-2023
07:13 AM
|
0
|
1
|
1472
|
|
POST
|
Hello. I spoke with the developer responsible for the Build Network tool, and he suggests that the best practice is to add all your data up front and build the network once. Even though that build will probably take quite a while, it should be faster than building it incrementally after adding chunks of records. It's also worth noting that we improved the performance of incrementally rebuilding the network in the Pro 3.2 release that just came out, but it's still more efficient to build the whole thing at once.
... View more
12-01-2023
08:26 AM
|
0
|
2
|
2098
|
|
POST
|
Hmm, using the transit-enabled network for walking only with restrictions like you're using or other ways to prevent using the transit lines is generally okay. For a route or OD cost matrix, it would work fine and produce the right results. However, for Service Area specifically, I think polygons it will generate will be kind of nonsensical. The Service Area solver runs an algorithm to generate the polygon geometry, and this algorithm has a lot of rules around when to cover or not cover edges in the network. Let's say you have an ordinary city block, and all streets surrounding that block were reachable within the travel time limit. Then the entire area of that city block will be covered by the polygon. Let's say only three of the four sides were reachable. The polygon generation algorithm does some math and covers only part of the interior of that block. Let's say all four sides were reachable, but a small dead end going into the center of that block is NOT reachable or is restricted. More math happens, and the polygon geometry will have a hole in it to account for the unreachable street. The problem is if you have a bunch of transit lines criss-crossing your network that are restricted or effectively unreachable in the analysis, the Service Area polygon generation algorithm will go to heroic lengths to avoid covering them, sometimes producing really weird and complicated geometries that really aren't what you want. For your case, I think it would be better to create a separate network. You can make a copy of your current network and remove the LineVariantElements, StopConnectors, Stops, and StopsOnStreets (and then delete the feature classes and all the associated transit tables). Or you could start over from scratch with your OSM streets. Here is a tutorial about how to create a network dataset (non-transit): https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/how-to-create-a-usable-network-dataset.htm
... View more
12-01-2023
07:20 AM
|
0
|
0
|
1949
|
|
POST
|
Hello, @pearlescent . Happy to help with this. First off, I think the problem might be that you should NOT be using your transit-enabled network dataset as the network for this tool. Calculate Transit Service Frequency needs to calculate the walk time/distance from transit stops. It should NOT model travel BY public transit. The Points of Interest mode is a bit more intuitive than the Areas mode, so let me use that as an example. Behind the scenes, the tool calculates an OD Cost Matrix to calculate the walk time or distance from each point of interest to all transit stops within the cutoff. Once those stops have been identified, it calculates the frequency of service available at those stops and combines them into one set of statistics for each point of interest. So, you don't want to model travel by public transit. You just want to find the transit stops that are within walking distance of the points of interest. The Areas mode uses a Service Area to calculate the area within a short walk time or distance of all the stops in the system and then combines the resulting polygons into a big raster-like thing. If you used your public transit travel time mode here, you're probably getting much larger polygons, and it's struggling to perform the calculations. I'm not really sure what's going on under the hood that's causing the slowdown or hang, but the first thing you need to do is to use an appropriate network dataset and travel mode that models walking time or distance only, not public transit travel time. Try that, and if you still have problems, we can move on to some further debugging.
... View more
11-30-2023
04:07 PM
|
0
|
1
|
1978
|
|
POST
|
You have a couple of options. Depending on what you're trying to do, you might be able to model this using an added cost point barrier in your analysis. Here is some documentation about barriers: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/barriers.htm If that isn't sufficient, and if you have a Streetmap Premium license (I'm assuming that's the Esri proprietary data you're referring to), you can talk to your Esri representative about getting the Custom Roads version of Streetmap Premium, which is editable. You could then edit in one or more turn features at the intersection you're modeling to add additional travel time when turning left, going straight, etc.
... View more
11-28-2023
09:45 AM
|
0
|
0
|
1243
|
|
POST
|
Yeah, I think those build errors are a good clue. Something hasn't worked well in your process to snap the stops to the street vertices, so you're probably missing a lot of connections. This is likely a big reason that your calculated routes look a lot different from what you get with Google. (If you had a higher-level license, you could just run the Connect Public Transit Data Model To Streets tool, and it would do all of the above automatically without you having to worry about topology or vertices, etc.) This documentation page has some information about how Esri's public transit routing works and some links to more in-depth topics: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/network-analysis-with-public-transit-data.htm The "Considerations and limitations" section at the bottom may be especially helpful. For various technical reasons, it's not possible to determine exactly which transit line or trip was used with out-of-the-box tools. However, you can do this with a post-process by downloading the Transit Network Analysis Tools toolbox (from GitHub or argis.com) and running the Copy Traversed Source Features With Transit tool. For more general troubleshooting, the Explore Network tool is helpful for manually clicking on the map and determining what's connected to a given network element (or what isn't). You could also run a Service Area analysis using the Lines output to visualize areas that are disconnected, although this might miss some disconnected components if there's another connection further up or down the line.
... View more
11-28-2023
07:20 AM
|
0
|
0
|
2289
|
|
POST
|
This is a very reasonable question. Unfortunately, without the Standard license, I'm not sure there's much you can do to fix these snapping problems in batch. The Snap geoprocessing tool does this but requires the Standard license, and any manual editing tools would likely require the same. You said you had a Python script that somehow did the snapping for you even without the Standard license. I wonder if there's some modification you can make to that to fix the problem up front. How did you do the snapping there? I know sometimes if you're using various arcpy geometry methods or GP tools, if your input data have different datums, the x and y coordinates can end up a tiny bit off. Could that be your issue?
... View more
11-27-2023
07:04 AM
|
0
|
0
|
2302
|
|
POST
|
Hi Amanda. Your problem is actually an "all to all" situation since origins aren't explicitly assigned to particular destinations. The Connect Origins To Destinations tool doesn't really support that mode very well. Would the Find Nearest tool work for you? https://doc.arcgis.com/en/arcgis-online/analyze/find-nearest.htm You just need to set the number of locations to find to something >= the number of points you have. The tool limits this to 100, but if you have only 90, you should be good.
... View more
11-22-2023
12:48 PM
|
1
|
0
|
4845
|
|
POST
|
The button appears to be below the edge of the screen. Unfortunately, this dialog can't be resized. Can you adjust your Windows screen resolution or scaling?
... View more
11-22-2023
07:41 AM
|
0
|
0
|
1350
|
|
IDEA
|
This Idea has been implemented in ArcGIS Pro 3.2. Please see the What's New documentation for more new features in Pro 3.2 and the Your Ideas in Pro 3.2 blog to learn about other new Ideas that were implemented.
... View more
11-15-2023
10:00 AM
|
0
|
0
|
4159
|
|
IDEA
|
This Idea has been implemented in ArcGIS Pro 3.2. Please see the What's New documentation for more new features in Pro 3.2 and the Your Ideas in Pro 3.2 blog to learn about other new Ideas that were implemented.
... View more
11-15-2023
09:59 AM
|
0
|
0
|
1315
|
|
POST
|
Your network configuration looks correct. The null attribute parameters are also correct. You can read about the supported parameters for the Public Transit evaluator here: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/public-transit-evaluator.htm#ESRI_SECTION1_9FF9489173C741DD95472F21B5AD8374 My guess is you still have some connectivity problem. Try using the Explore Network tool to click on one of the LineVariantElements features. The map will show which other network features are connected to it. Check to see whether the StopConnectors are correctly connected. Also click on a StopConnectors feature and make sure it connects to the street. If that still doesn't work, either contact Support or post your data here and I can take a look. (You can also send me a private message if you want to share the data privately, but be sure to leave a comment here since Esri Community's private message system doesn't give me an e-mail notification.)
... View more
11-09-2023
09:30 PM
|
0
|
0
|
5384
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-12-2026 01:53 PM | |
| 1 | 04-21-2026 08:39 AM | |
| 1 | 04-15-2026 02:24 PM | |
| 1 | 02-03-2026 11:41 AM | |
| 1 | 03-16-2026 08:58 AM |
| Online Status |
Offline
|
| Date Last Visited |
Tuesday
|