Latest Contributions by MelindaMorang

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

I think it ultimately comes down to the same problem as Figure 3, right?  Exit 1 isn't actually an "exit" because the route doesn't traverse any portion of the roundabout before the exit for 1 veers off.  Consequently, Exit 2 is seen as the first exit. I think if you want to solve this problem, you need to separate the locations where the entrances and exits touch the roundabout circle so they don't touch each other.  So, move the entrance from 3 clockwise a tiny bit and the exit for 1 counterclockwise a tiny bit. When they are separated, the route will be forced to travel on the roundabout itself, and 1 will be treated as a proper exit. ... View more

Hello Melisa.  I asked a colleague to look at your post, and he thinks the problem is that the route in Figure 3 is not actually traversing roundabout.  The two ramps that lead to roundabout are connected to each other, so the solver does not traverse the roundabout, and the directions don't have roundabout instructions. You could verify this by using the Copy Traversed Source Features tool and checking whether the edges returned include a segment of the roundabout.  You could also use the Explore Network tool in ArcGIS Pro to check whether the two ramps are directly connected to one another. ... View more

Hi.  Thanks for your question. I don't know the details behind exactly what Google Maps does, but I can at least try to explain what Esri's tools are doing and some areas where they might be different. First, it's been a while since I've looked at WMATA's GTFS data, but I recall that in the past it didn't include a calendar.txt file and used a calendar_dates.txt file for everything.  This means it is not possible to do an analysis for a generic Wednesday.  Instead, you have to pick a specific Wednesday when setting your analysis settings.  Please be sure you've checked for this scenario.  If you're running your analysis for a generic Wednesday or a specific date that is outside the date range the input GTFS data is valid for, the transit may not be getting used at all, and this would account for the discrepancy.  Basically all routes are walking only. Also, if the routes or Service Areas appear unreasonable, it's possible something isn't configured right in your network dataset.  If this is the case, we can try to debug this, or if you care share your data, I can take a look.  We want to rule out any network configuration problems before examining any differences in results between Esri and Google. One difference between Esri's transit solves and Google Maps is that Esri's solvers use the exact time of day configured by the analyst as the starting or ending time.  It's hypersensitive to this start time, and the result might be different if you choose a start time a minute or two off.  I don't really know what Google does, but since they are designed more for passenger-facing routing apps, I think they're employing some sort of fuzzy start time logic to find the best or most sensible route.  If leaving one minute earlier allows you to arrive at your destination 20 minutes earlier (because you don't miss a useful bus), I think Google will find that, but Esri's solvers don't have this functionality.  The downloadable Transit Network Analysis Tools may help you to account for this in an analysis. The difference in street data is also a consideration, although the Streetmap Premium Custom Roads data should be of a high quality and include various pedestrian pathways and useful attributes.  Google may have slightly different information about pedestrian paths, although probably not substantial differences that would account for huge discrepancies in travel time. Hope this helps a little. ... View more

Yeah, I'm not sure what that error code means.  The tool's code is not raising that error, so it means the error is probably occurring before the tool's code even starts running. Where are you running this code?  From a standalone Python script?  From a notebook within Pro?  From a notebook somewhere else? Did you import the toolbox using arcpy.ImportToolbox() or arcpy.AddToolbox()? ... View more

The documentation on the GitHub site should explain all the tool inputs and their requirements. It sounds like your input data is not in an ArcGIS feature class or table or whatever but rather some sort of dataframe (pandas?).  For the tool to accept that as input, you have to first convert it to a feature class.  You could try using XY Table To Point or manually constructing a feature class with an Insert Cursor.  I can't really advise without knowing what type of data frame you're using or what's in it. ... View more

You should just be able to download the toolbox from https://github.com/Esri/large-network-analysis-tools and use it as is, I think. ... View more

This GitHub repo may be helpful to you: https://github.com/Esri/large-network-analysis-tools.  You might be able to use the tools provided there out of the box.  If you need to update or write code yourself, this DevSummit presentation may be helpful: https://mediaspace.esri.com/media/t/1_hzppnv8p  ... View more

Hi Riccardo.  This sounds like a pretty complicated problem, and I'd say it's unlikely we'll be able to solve it here in Esri Community.  Have you reached out to Esri Support yet? My guess is there's some sort of version incompatibility between the template created by ArcGIS Pro and what Server 10.9.1 does to interpret this template.  But I really don't know for sure.  Do you have a way to run Create Template From Network Dataset on the 10.9.1 Server from a well-functioning network?  Maybe that template will work better on the 10.9.1 Server than the one created in Pro. Also, I know this may not be possible for various business reasons, but do you have the ability to update your Pro and Server versions?  10.9.1 is based on the old pre-Pro codebase, so things just behave differently sometimes.  You're much less likely to experience compatibility issues when using Pro with Server 11.* since 11+ uses the same codebase as Pro.  (Also note that Pro 2.9 is getting fairly old at this point as well.) ... View more