How "strict" is the time parameter in a Service Area Analysis when using public transit?

[KatharinaPedri]

Hey everybody!

I am currently working on a couple of Service Area Analysis based on public transport data and am wondering how "strict" the tool takes time? Let's say I enter 08:00 as arrival time at a facility, will the tool consider that exact time only? In other words, would a bus arriving at 07:50 not be considered? 

Looking forward to your answers 🙂

Katharina

[MelindaMorang · Accepted solution]

Hi Katharina.  Yes, the Public Transit evaluator calculates the result very specifically for the start time.  The solution you get when solving at 08:00 may be different from the solution at 08:01 because the available public transit service is different (you just missed a bus).  You should not consider an 08:00 service area a generalized or typical "morning rush hour" answer.  The service area result is hyperspecific to that exact time of day.

If you want to see a more time-averaged result, you can download some tools to help you calculate service areas over a time window and summarize the results.  Get them on ArcGIS Online or GitHub.

This video tutorial explains it in more detail: https://youtu.be/dtl5bfk28FY  The video is part of a playlist of tutorial videos on the subject of public transit analysis, so you may want to check out the other videos as well.

[KatharinaPedri]

Hi Melinda!

Thank you for replying so prompt to my question 🙂

I have tested the tool prepare time lapse polygong and it seems to work perfectly! Is the assumption the same as ususal: towards facilities > the time-window represents arrival time-window; away from facilities > the time-window represents departure time-window ? 

[MelindaMorang]

Yes.  The tool simply calculates ordinary Service Areas repeatedly over a time window, so all the usual settings, rules, and assumptions for Service Area apply.

[KatharinaPedri]

Awesome! Thank you so much

[KatharinaPedri]

Hi again Melinda!

I just got an error message that I don't quite understand. So I was hoping you could help me out there:

Traceback (most recent call last):
File "<string>", line 243, in execute
File "F:\GIS\7_Toolboxes\TransitNetworkAnalysisTools_0.7.4\CreateTimeLapsePolygonsInParallel.py", line 373, in solve_service_areas_in_parallel
self._execute_solve()
File "F:\GIS\7_Toolboxes\TransitNetworkAnalysisTools_0.7.4\CreateTimeLapsePolygonsInParallel.py", line 333, in _execute_solve
msg_string = output.strip().decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 150: invalid continuation byte

It says the tool failed but I did get an output that seems alright. 

[MelindaMorang]

Ughghghgh, sorry!  Several people have reported this problem to me, and I haven't been able to reproduce it, so I can't figure out how to fix it.  It definitely has something to do with non-ascii characters in your data paths, scratch folder path, or something like that.  If you have accent marks, umlauts, or other special characters in your filepaths, I suggest you change the names and see if that solves the problem.

If you have some time and want to help me resolve this issue, it would be great if you could tell me the following:

• What is your Windows OS display language? (US English, German, etc.)
• What is your Windows locale? (Open the Region & Language settings by typing "Run" on the Windows menu and typing intl.cpl.  At the top it should say "Format: <something>"  Mine says "Format: English (United States)"
• What are the various data paths you're using for your input and output data?  What special characters do they have in them?

Thanks.  Hope this helps, and sorry for the trouble.

[KatharinaPedri]

Hi again Melinga 🙂

Oh that it very possible!

I have Swedish as OS display language and the Windows locale is Sweden

The special characters could be å, ä, ö in the names of the busstops. 

Do you know if the output still is reliable? Like have other people with the same issue found the results to be sound anyway?

[MelindaMorang]

The results should be reliable.  I don't think the problem is related to the names of the bus stops or any of the values within the fields in the data.  I think it's related to the input and output filepaths for the analysis.  So, as long as the tool succeeds in reading and writing the files, the analysis should be fine.

With that said, I still haven't succeeded in reproducing the problem, so I don't really know what's causing it or how to fix it.

I have created a version of the tools where I have attempted to fix the problem, although since I can't reproduce it, I don't actually know if this will work.  If you have the time, would you be willing to try it?  Please use the same set-up you currently have that cause the tool to fail, but use the updated version of the tool.  You can download it from this GitHub branch: https://github.com/Esri/public-transit-tools/tree/fix-encoding.  (If you're not familiar with GitHub, you can download the files as a zip file:

Be sure to close and reopen ArcGIS Pro before trying the new tool version.  Otherwise, the code will be cached, and Pro won't use the new version.

[KatharinaPedri]

Hi again Melinda!

I have been working with a fresh GTFS dataset and have not had any issues since eventhough I didn't download the latest version of the toolbox but used the one I already had. Can't say what the difference would be between the former and the current dataset as both were downloaded from "Trafiklab", a service in Sweden that collects GTFS data from all operators.