Latest Contributions by MelindaMorang

The Network Analyst extension deals exclusively with transportation networks, so I'm going to move your question to somewhere that the right people are more likely to see it.  I hope you find the answers you're looking for. ... View more

Are those grid lines the streets (edges) in your network?  If so, then it's likely that some of the points are being snapped to the street locations outside the 23km cutoff distance.  You an see where the selected streets extend beyond the edge of the service area. When you do a network analysis, the input points must be "located" on the network, meaning the closest non-restricted location on the network is found, and that location is used as the start and end point for the analysis.  Since it looks like your evenly spaced input points are much denser than the grid network, a lot of them will be snapped a fairly large distance to the closest location on the grid.  The snapping distance is not counted as part of the 23km cutoff.  Here is some documentation about the locating process: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/locating-analysis-inputs.htm ... View more

Assuming you have configured your PublicTransitTime cost attribute according to our tutorials and/or used our network dataset template, then solving using this cost attribute works as follows: the travel time along public transit edges in the network uses the transit schedules and models riding transit, and the travel time along street edges in the network uses walking time along those streets.  So, solving using PublicTransitTime is a complete solution to model a traveler who can take transit but must walk along streets to get from their initial location to transit stop, make transfers between stops, and get from the final transit stop to their destination.  You don't need to add anything else to the analysis to make it correctly model walking when not using transit. The WalkTime cost attribute is a completely separate cost attribute that is configured in our template primarily to support accumulation.  If you set this as an Accumulate Attribute, it will tell you how much travel time was walking because it returns the walk time value along streets and returns 0 for transit lines.  You can read about Accumulate Attributes in this documentation page for closest facility layers (it's a long page, so search for "Accumulate Cost Attributes".) ... View more

That second warning message tells you what's wrong.  You can click the warning link to see the documentation for that message, which should give more details.  But, basically, you need to check on the option to interpolate blank stop times.   ... View more

I can help you with this, but your screenshot of the error message has the detailed messages cut off.  Can you copy/paste the full list of errors?  One of those should give more details about what went wrong. ... View more

You could change your restriction's usage type to "Avoid High" instead of "Prohibited".  This will allow the biker to use the large roads if no other path is available.  Documentation: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/restriction-attributes.htm#GUID-E02CEE7B-7957-490F-BAD9-611FB50EB444 ... View more

The travel mode type doesn't really do a whole lot, but if you set it to Walking, it will use a smaller pixel size for your Service Areas and make the polygons a bit more detailed.  But it doesn't do anything to affect the actual analysis result. If your road is "major" but also has a bike lane, you should probably just make it not restricted.  Otherwise, bikes won't be able to ride there, which isn't your intention. Note that crossing major roads can still be a challenge/problem on a bike, so it may not be that inaccurate to show that the area across the street is inaccessible unless you have good infrastructure for crossings and left turns. ... View more

I'm having a little bit of trouble understanding exactly what your screenshot is showing, but here's a guess.  You said you set up some restrictions to prevent bike travel on major collectors, major arterial roads and interstates.  The locations where your facilities are located look like they are on larger roads.  Are those collectors?  It kind of looks like the facility is getting snapped to the closest non-restricted road segment (one of those side roads), and, since bikes aren't allowed on the main road, it can't cross the street and get into the neighborhood on the other side. One thing that might help you visualize what's going on is configuring the network dataset layer symbology to show the restriction status.  You can configure the edge symbology to show the edges that are restricted according to a specific travel mode.  Here is some documentation about network dataset  symbology: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/network-dataset-layer-symbology.htm ... View more

When you create a network dataset using the Create Network Dataset tool, you can choose which type of elevation model you want to use: No elevation, Z-level fields, and 3D Z coordinates.  If your data is 2D and does not have Z-level fields (FZLEV and TZLEV), then you would need to create the network using no elevation.  This will still produce a valid and usable network dataset.  You just may have some problems modeling overpasses and underpasses.  You will want to carefully check those to make sure they don't have endpoints or vertices (depending on your connectivity policy) to prevent them from connecting at those locations (so the driver can't turn left off a bridge and start driving on the road that goes under it, for example).  But as long as the roads don't meet at an endpoint/vertex at the location where they cross, it should still work just fine. Here's some documentation that should help: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/understanding-connectivity.htm ... View more

I see.  That makes sense.  Unfortunately, our tools just aren't set up very well for this type of application because we don't emphasize the passenger-facing experience.  The geometry just isn't going to look pretty without quite a lot of effort on your part. The other problem you will likely encounter is that the transit travel time and best route may vary substantially throughout the day depending on the start time because the available transit service changes.  You would need to account for this somehow, but it's a tough problem to solve.  Some of the tools available for download described in https://github.com/Esri/public-transit-tools/blob/master/transit-network-analysis-tools/UsersGuide.md help to summarize results over a time window, although I'm not sure how well it will work for your needs since you ultimately want to give your tourists a simple recommendation. Sorry I can't be more helpful. ... View more

Unfortunately, there really isn't a good way to do this with current Esri software.  You could try manually replacing the LineVariantElement geometry with shapes derived from shapes.txt, but you have to maintain good connectivity with the stops or the network won't work.  This would not be an easy task. Could you tell me what you are ultimately trying to do?  Why do you need to visualize the actual on-street paths traveled by your Route and Closest Facility calculations?  Some further information will help me recommend how to approach the problem and will give me some useful requirements if we decide to support this option at some point.  Thanks! Please keep in mind that the Network Analyst public transit-enabled networks are not optimized for passenger-facing routing apps.  A lot of components necessary for a well-functioning app of this sort are not available, including the on-street visualization using proper shapes, as you have noticed.  Rather, Network Analyst's transit capabilities are designed more for analysis and planning. ... View more

Unfortunately, there really isn't a good way to do this with current Esri software.  You could try manually replacing the LineVariantElement geometry with shapes derived from shapes.txt, but you have to maintain good connectivity with the stops or the network won't work.  This would not be an easy task. Could you tell me what you are ultimately trying to do?  Some further information will help me recommend how to approach the problem and will give me some useful requirements if we decide to support this option at some point.  Thanks! ... View more

Send me an e-mail at mmorang - at - esri - dot - com, and I can provide you with a link to a secure file transfer tool (or you can use your own and share it with me at that address). Please include the network dataset and also some information about the specific area where you're seeing the problem and the date/time you're using for the analysis. ... View more

Sorry, it's just not possible for us to determine what's going on based on the screenshots.  It's likely still a problem with the geometry of the features or the restriction attributes of the entrances and exits (if something is restricted, it won't be counted as an exit). Have you tried this scenario in ArcGIS Pro?  The entire directions engine was updated in ArcGIS Pro and may behave slightly differently.  I still think this is probably a geometry or network configuration problem rather than a bug in ArcMap's code, but it's still worth a try to see if Pro's directions engine behaves differently with this data.  Here is a tutorial showing you how to do it: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/route-tutorial.htm  If that doesn't fix it, you should probably contact Esri Support or Support from your Esri distributor if you're outside the US.  They can look at your data and help you debug the problem in detail.  If they can't resolve the issue, they will request help from our team (Network Analyst development team).  Note that ArcMap is now in "mature support", which means you can still get technical support, but the expectation is that you are actively migrating your workflows to ArcGIS Pro because ArcMap is headed toward retirement as a product. Good luck! ... View more