nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Encontre mais publicações marcadas com

Accepted answers

MelindaMorang

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.

All comments

KatharinaPedri

I could try out the updated tool! Just gimme some days so I can run it when I am done with the other analyses.

I didn't think I had any "weird symbols" in my file names though. But I'll check if you like

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 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

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 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.

KatharinaPedri

Awesome! Thank you so much

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

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

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.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.