Latest Contributions by MelindaMorang

The message is telling you that you need to run the Build Network tool.  That tool integrates any changes you've made to the network dataset's source feature classes or the network dataset properties into the internal logical network.  It's an additional step you have to take after creating or editing a network. If you have run the Build Network tool and you're still getting this error, it's possible that the build process generated build errors.  The tool would have given a warning with a path to a text file where the build errors are listed.  If all the edges failed to build for some systemic reason, you might still see the error about the network having no edge elements.  In this case, you should carefully examine the build error file and correct the errors.   ... View more

Well, that's certainly better!  It's still pretty long, though.  Our team is continuing to work on performance improvements in Build Network, so hopefully we can improve upon this in future releases. ... View more

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

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

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

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

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

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

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

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

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

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