Latest Contributions by MelindaMorang

To activate an extension license use arcpy.CheckOutExtension(), not arcpy.CheckInExtension(). ... View more

Actually, I don't recommend Service Area for this application. Service Areas are great for visual representations of the reachable area. However, they aren't as accurate for this application here. Origin-Destination (OD) Cost Matrix would be a better choice, particularly since you have already created point layers representing your residential polygons and your parks. Use your residential points as origins and your parks as destinations. Use a travel mode that represents walking distance, and set the cutoff to 200 meters and the number of destinations to find to 1. When you solve the analysis, the output Lines table will contain a row for each origin that found a destination within that cutoff. You will likely have some duplicates since you have multiple points representing both origins and destinations, but you can post-process the table. Ultimately, this will give you a list of residential points that have a park within the designated walk distance limit. You can join this back to your residential polygons or calculate a field or something and then symbolize using that field. Here is a tutorial about how to do OD Cost Matrix in ArcGIS Pro: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/od-cost-matrix-tutorial.htm ... View more

Actually, that did not turn out to be a difficult problem to solve. Resolved here: https://github.com/Esri/public-transit-tools/pull/156 Downloadable without GitHub here: https://www.arcgis.com/home/item.html?id=23cc1b720eb0418db4d0e61955b8fe43  ... View more

Oh, thanks for reporting that issue with Dissolve. You are probably one of the first people to use my recent full rewrite of that tool, and you found a bug. I'm working on a fix for it and will post again when I've finished it. ... View more

Sorry about this error. ArcGIS Pro is  kind of weird about script tools that import other modules. It will not reimport the modules unless you close and reopen Pro. So, probably what happened after you moved stuff around was that Pro was still holding onto its memory of the original import and not noticing the change. When you created a new project, it imported everything afresh, and it worked.  I suspect you could reopen your old project, and it would work fine now, too. The good news is that BetterBusBuffers will be deprecated and replaced with a new tool available in core ArcGIS Pro with the 2.9 release. You will no longer need BetterBusBuffers at all and can use the new Calculate Transit Service Frequency tool out of the box. ... View more

Is it possible for you to post your code, or at least the relevant part of it? ... View more

With OD Cost Matrix, you can't do that at all because OD Cost Matrix does not preserve and report the "traversal result", the detailed path taken through the network. This makes OD Cost Matrix faster, but it does mean you can't get the full path if you need it. To do that, you would have to use the Closest Facility or Route solver instead. Assuming you're doing an OD Cost Matrix or Route analysis, you can retrieve the traversal result using the Copy Traversed Source Features tool. This breaks it down into every network edge, junction, and turn that were traversed, and it tells you the travel time for that segment and the cumulative travel time along the route up through that segment. You could post-process this result to determine how much of the time is spent walking/driving (by summing the components on street segments) and how much is spent waiting/riding (by summing the transit line component) and how much is spent boarding/exiting (by summing the stop-street connector component). Unfortunately, wait time and ride time are combined in the transit lines. This is because of the way the Public Transit evaluator works, and although internally the evaluator knows how much time was waiting and how much time was walking and exactly which transit trip was used, the evaluator has no way to pass this information back out into the traversal result. It's a limitation of the internal architecture of Network Analyst. It sounds like what you would like to model is the best-case scenario where the traveler knows the transit schedule and leaves home at whatever time minimizes their travel time, subject to some desired arrival time. Is that right? Unfortunately there's no easy out-of-the-box way to do this without just choosing the optimal start time in advance, or solving across a time window and picking the best one of the lot after looking at all the results. ... View more

Oh, one other consideration: The streets are also used to make transfers between transit lines. If you've got it set up so the travel time along streets is configured for driving, then you'll end up the the transfer times being calculated as if for driving. That's almost certainly incorrect. I think splitting up the analysis into parts is probably the way to go, and I think that's what Will was doing. ... View more

PS. Are you with RTA in Chicago and taking on some of the work that Will Gillespie used to do? He did a whole bunch of analysis combining driving to park-and-rides with transit journeys, so you might check with him. ... View more

Hello. Yes, this is possible with careful set-up and a few considerations. First, if you want to combine StreetMap Premium with the public transit data model tables and feature classes, you need to have an editable version of StreetMap Premium. You cannot edit or add stuff to a licensed, non-editable StreetMap Premium dataset. Talk to your Esri representative to find out about the editable version. The other thing you need to think about is how you want to model travel on either end of the transit trip. The traveler will drive to the park-and-ride, leave their car, travel on the bus/train, and then...walk the remaining distance to their destination? Or hitch a ride in an Uber? You can configure the travel time (or impedance, more generally) calculation in a network however you want to. So, you could configure the network to calculate travel time along streets based the length of the street and a walk speed. Thus, the time to travel along some specific block might be, say, 1 minute. You could also configure a different calculation to model the time to drive along those same streets based on the length of the street and the speed limit (or, to be more complicated and accurate, based on typical speeds from historical traffic data). With this configuration, the travel time along the same street from earlier might be, say, 20 seconds. The way the public transit impedance attribute is configured (assuming you followed the tutorial and used our template) is that it uses the transit schedules to calculate travel time on the transit lines, and it uses a walk speed to calculate the travel time on the streets. This allows you to model WALK - RIDE - WALK with no problem. You could combine our sample transit dataset with one of StreetMap Premium's driving impedance calculations to model DRIVE - RIDE - DRIVE by calculating drive time along the streets instead of walk time. However, the problem here is that if the traveler has left their car and the park-and-ride, they no longer have it when they get off the bus/train, so they can't drive at that point. The Network Analyst solvers don't have the ability to set any type of flag indicating whether the traveler currently does or doesn't have their car, so it is not possible, within the same solve operation, to do DRIVE - RIDE - WALK. The only way to do this is, as you suggest, separate it into to solve operations. First, calculate the drive time to the park-and-ride. Then, calculate the transit/walk travel time from the park-and-ride to the final destination, and then sum the two for the total travel time. For good measure, you might want to calculate the transit/walk travel time from the original destination to the final destinations directly (bypassing park-and-ride entirely) and the drive-only journey going straight to the destination (bypassing transit entirely). Does this help? If you DO want to combine your StreetMap Premium data with the transit data model and need some specific help on configuring the attributes, please post again. Actually, I would like to develop an automated procedure to help with that, but I have not done so yet. Learning more about your use case might help me move forward on that project. ... View more

My teammates and I have looked at your question, and we have a few ideas, but we're not completely sure what your workflow is. SideOfEdge refers to the side according to the direction of digitization. When you "locate" a point on the network, SideOfEdge is one of the network location fields that is calculated and stored for the point. You said that your orders are exactly coincident with the centerline, so I presume you have used some type of procedure to explicitly set the SideOfEdge the way you want it. This documentation explains how points are located on the network. CurbApproach refers to the side with which the vehicle approaches the location. It refers not to the side of the street but rather to the side of the vehicle. If the driver can only service the order to the right side of the vehicle (ie, they drive on the right side of the road and cannot cross the street), the order's CurbApproach should be set to Right side of vehicle. This documentation explains CurbApproach with helpful diagrams. Based on your question, we think you have it set up this way, although we aren't sure. Assuming you have your data configured in this way, then the question is why the SideOfEdge setting is changing after you solve the analysis. Is that indeed what you're seeing? The network location fields can be recalculated and updated at solve time. There are some complex rules about when that occurs, but here are some common reasons: You added barriers after the location fields were initially calculated You changed the travel mode after the location fields were initially calculated You re-built the network dataset after the location fields were initially calculated If you can tell us more about your workflow, we might be able to help you figure out what's going on. ... View more

I'm happy that you're happy, although I don't quite understand how you solved your problem. The BetterBusBuffers toolbox is intended to solve a different problem than the transit-enabled network datasets described in the Pro tutorial. I think you need to take a look at the weekday fields and date ranges in calendar.txt and the specific dates available in calendar_dates.txt to determine a) whether or not you can use a generic weekday at all and b) what specific dates are valid for your data. The blank stop times should not be a problem if you use the option to interpolate them when running GTFS To Network Dataset Transit Sources. In other words, I don't think that's causing the described problem. ... View more

@AndyWhitaker1 and @FabianoFerrazza3 are the two of you working on the same project? I'm not sure whether I'm having two separate conversations at once or if it's all the same thing. 😁 Regarding the python solver objects, you need to set returnRouteEdges to True and then retrieve the RouteEdges output type from the result. The routeShapeType property is unrelated. That controls the shape of the features in the Routes output. Regardless of your choice there, the "traversal result", which is the network edges that were traversed, will always be the same and can be retrieved through RouteEdges. ... View more

Yes, depending on the service, you should be able to retrieve the traversed features by doing your workflow in python using the arcpy.nax solver objects. Here is some documentation: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/performing-network-analysis.htm The Route solver object has RouteEdges, RouteJunctions, and RouteTurns output types, so you should just be able to retrieve those. Route solver object: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/route.htm Route solver result object: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/routeresult.htm Route output data types: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/route-output-data-types.htm  Ways to access output: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/accessing-analysis-outputs.htm   ... View more