Latest Contributions by MelindaMorang

Hello. I am assuming you're using ArcGIS Pro and have created your network dataset from GTFS data following our tutorial. What you see is the correct behavior. The LineVariantElements generated from the GTFS To Network Dataset Transit Sources tool are simply straight-line connectors between adjacent stops. They do not follow the streets that the actual buses travel on. Here is the key info from the tool's documentation: The LineVariantElements features are not intended to represent the actual geographic paths taken by buses, trains, or other public transit vehicles but are instead representative of logical connections in the transit system. LineVariantElements features are not meant to be used for visualization. The Public Transit evaluator in the network dataset will use the public transit schedules to determine the travel time required to traverse a LineVariantElements feature, so its shape and length are irrelevant. However, you can optionally edit the shapes of the LineVariantElements features manually, but do not split or merge the features. I think it's going to be tough for you to make this work with your flooding polygons, but it kind of depends on what you're trying to do. If you just want to see which transit routes might be affected by flooding in certain areas, it might work better for you to create a simple feature class of your GTFS shapes.txt file using the GTFS Shapes To Features tool. That feature class will show the paths traveled by the vehicles, at least according to the data the transit agency has provided (which, in my experience, depending on the agency, can sometimes have problems). You could overlay these with your flooding polygons. That approach doesn't do anything with routing, through. But here's the problem if you tried to make your flood polygons work with a routable network, even assuming the transit lines were in the right place geographically. Suppose you use your flood polygons as a barrier, so certain segments of the route and certain stops are inaccessible. The solver will be smart enough to prevent a traveler traveling on transit from traveling through that section. However, the transit lines further down the line, after the flooded area, don't know that the previous parts of the line are blocked or diverted or delayed, so they continue running on the same schedule. A passenger will still be allowed to board the bus and travel onwards using the same schedule, even though that's unrealistic. If you post more details about what analysis question you're trying to solve, maybe we can brainstorm a good solution. ... View more

This shouldn't be a problem. As long as each input GTFS dataset is valid, the tool will just process each one separately and do the right thing. You may end up with multiple stop features in the same location, but this will not cause any errors in the dataset or in routing. ... View more

Sorry you're having these problems. I was hoping the log files would be more enlightening, but they don't tell us much at all. If you just want to move along and get your work done, which is completely understandable, you can download the older, ArcMap-compatible version of this toolbox here: https://arcg.is/1u8WKS The tools should work in Pro, and they don't do the multiprocessing thing at all. In fact, they run in a completely different way, so be sure to look at the user's guide to see how to set up your inputs. If you're willing to keep experimenting and have the time for it, you could add a couple of lines of code to write more info to the log files. Put these at line 426 of parallel_odcm.py. Be sure to close and reopen Pro (otherwise it won't pick up the changes) before re-running the tool. Then check the log files again. This just prints the input parameters to the logs and might tell us something more. self.logger.debug(origins_where_clause) self.logger.debug(self.origins) self.logger.debug(self.input_origins_layer)   ... View more

Okay, thank you. That's consistent with the behavior we saw when testing. This should be resolved in the 2.9 release. ... View more

By the way, while looking into this issue, I identified and fixed a couple of other, unrelated minor issues. An updated version of the toolbox is available at https://www.arcgis.com/home/item.html?id=23cc1b720eb0418db4d0e61955b8fe43. Among them was fixing the Travel Mode parameter so it auto-populates after you select the network. I had inadvertently messed that up with my most recent update a few weeks ago. ... View more

Oh, okay. That's fine. Just means my initial idea of where to look for the problem isn't actually the problem. 🙂 I am not sure what's going on. I cannot reproduce the problem. Here's my next suggestion for getting to the bottom of this: When you run the tool, if you look at the messages, you'll see one that looks like "Intermediate outputs will be written to [blah]." In there will be a bunch of folders with names using strings of letters and numbers (just auto-generated unique names), and in each of those will be a log file. These are the logs for the individual parallel processes. Please take a look and see if you can find the log files and post the files or their contents. We should be able to get more information about that MakeFeatureLayer failure from that. It looks like when you ran the tool, it finished one process successfully and then failed on the second one for some reason. That's kind of weird. Anyway, since it failed early in the parallel processing, there should only be a few of those folders and log files to look through to find the right one. I'm guessing no more than 4. You might need to re-run the tool again to generate some fresh log files. I'm not sure if the old ones from your earlier failed run might have been automatically cleaned up with Pro's garbage collection at some point. ... View more

Hi Eli. I think you're right that the issue you're having with Prepare Time Lapse Polygons described here is probably the same underlying problem as this issue. I'll try to answer them both here. My guess is that your machine is having trouble spinning up the parallel processes for some reason. I'm not sure why, but my first question for you is how you're calling this from python. Are you using a standalone python script? The python window in Pro? I suspect this will get us to the heart of the matter. ... View more

I can see how this would be confusing. The FacilityType field uses an integer domain to represent the various types of facilities. The correct documentation link for ArcGIS Pro is here: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/location-allocation-analysis-layer.htm#GUID-7445C636-31BB-42FC-BB28-5C450E1A55FA ... View more

Question for those of you who have gotten this error: Do you happen to remember if you deleted the network dataset and then recreated it before you saw this problem? ... View more

I was able to reproduce the problem reported here. We are investigating. ... View more

The problem with using Service Areas for an application like this is that the Service Area polygon geometry can change dramatically depending on the settings you use, like polygon trim, whether you use standard or high precision polygons, and even which nearby streets are and aren't reachable. The polygon generation algorithms are often more art than science. It is a visualization tool. If you want a precise answer, use OD Cost Matrix. ... View more