Make BetterBusBuffers work with the Network Analyst public transit data model

[mmorang]

Instead of converting GTFS into a sqlite database, rewrite BetterBusBuffers to use that tables in the Network Analyst public transit data model added in ArcGIS Pro 2.4.

[d-wasserman]

What are the accessibility trade off's of doing this? It is not a huge concern as these tend to be intermediate files, but will licenses be required?

[mmorang]

I had considered doing this as a first step to getting BetterBusBuffers into core ArcGIS Pro. The advantage is it could use the GTFS processing code that's been built out in Pro for doing GTFS validation, and then users wouldn't have to process their GTFS data in two different ways if they were also using the new Pro network dataset stuff. However, I haven't really gotten any requests for this, so I don't plan to do anything on this in the immediate future.

[d-wasserman]

I would not call it a high priority ask, but I see the value.

[mmorang]

And what is that value to you? Anything beyond what I just said? This is important for me to understand.

[d-wasserman]

I think the value to me is as the ArcGIS Pro GTFS Validation & Prep procedures improve, we don't have to have a split methodology to reference in terms of how the GTFS is (pre-) treated. It does seem somewhat disconnected. It seems like it has long term potential to help move the needle on other things I have complained about on the issues pages. =)

[mmorang]

Someone has asked for this functionality: https://community.esri.com/message/925240-better-bus-buffers-using-public-transit-enabled-network-dataset

[d-wasserman]

Again, my licenses question is one that I want to understand, but I see the value for a streamlined workflows. Regardless of the question, I put this still in a low priority camp. Is this nudging the priority for you?

[mmorang]

A little, but I'll have to brainstorm it a bit in the coming weeks. I'm not sure if I would even want to port the toolbox (or a subset of its tools) into core Pro or just update the downloadable version to work with the data model. And I have no idea how the licensing would work since you wrote one of the tools. It's still fairly low on my priority list, but it's higher now that somebody has asked for it.

I have never been happy with the procedure I use for generating the overlapping polygons. I've tried numerous times to make that work better to no avail. I would not feel comfortable making the polygon tools into core Pro tools unless I could do something better.

[d-wasserman]

Hi Melinda, I gave that tool to the repo under a shared Apache 2.0 license. The attribution requirement is pretty minimal, and I would be fine with it in the code as it is now. I don't think the interface necessarily needs to change (though I would not mind a shout out in a press release or a tool tip). At a more fundamental level, we would need to change the tools to work with the new data model. I am willing to help with that if you want some outside assistance.

Why not just high-jack the methodology used by the collapse polygon tools we iterated on together? You would give the user control over output resolution that way too. Not ideal I recognize, but it could be a solution. You could also let the user create a sampling geography of their choosing.

[mmorang]

If I remember correctly, the methodology we worked out for Create Percent Access Polygons does a really nice job of getting a raw count of polygons overlapping each cell. For BetterBusBuffers, though, I need to avoid double-counting trips. If an area has access to two transit stops, but those stops are along the same line and consequently are served by the same trips, then it should count as 1 instead of 2. So, each service area polygon needs to maintain the stop_id it's associated with, and not only does it need to have a trip count, but I need to know the actual IDs of the trips so I can remove duplicates. It's very messy.

[d-wasserman]

Ok, got it. I was thinking it is a sampling and trip counting problem, but maintaining the stop id of the original service areas sounds complicated. That information would be lost in a raster transform unless you allocated it back in some fashion (which sounds like a potentially larger headache).

[mmorang]

For anyone following this issue: BetterBusBuffers will be added to core ArcGIS Pro as the Calculate Transit Service Frequency tool in the 2.9 release, scheduled for late 2021 or early 2022. It will use as input the Public Transit Data Model tables and feature classes.

[mmorang]

This was completed, but not here in this repo. ArcGIS Pro 2.9 was released today, and it features the new Calculate Transit Service Frequency tool, which does similar things to BetterBusBuffers but uses as input data in the Public Transit Data Model format.

BetterBusBuffers is now deprecated.

@d-wasserman Thanks for all your input on this tool in the past. It's been awesome! (And you know where to find me if you have more ideas in the future.)

[d-wasserman]

All good things have their time. It was real fun to work on this project over the years with you. I am sure we will find another problem to abuse the ArcGIS Ecosystem with.

[paulogeo]

Hello guys. I know BBB is now deprecated, but i used it in my thesis and i would like to know if any of you guys know if there´s a "formula" to it, like all those formulae of potencial accessibility or cummulative opportunities...

Thank you all for the help.

[d-wasserman]

Much of the tools live on in the Calculate Service Frequency Tools.

If you are asking if there are decay functions for access potential like those documented in the Transportation Access Manual, the answer is no. You likely derive a relatively easy to compute approximation using "median isochrones" and breaks that enable you to apply stepwise decay functions. However, the main purpose of these tools main purpose are to enable users to deal with the temporal variation of transit in a network analysis context.

@mmorang can confirm I am correct, but my understanding is these tools only do "flat" aggregations when calculating cumulative opportunities.

[paulogeo]

Thanks a lot for your answer. What I was asking was if there is a more "formal" way to show on a thesis chapter how this tool work. I've made many measures and BBB gave me a good way to compare TOD with AOD, but in a doctoral thesis I cannot show this only as a "tutorial" so I'm supposed to create a way to write it down more "formally". Thanks again.

El sáb, 13 ene 2024, 23:43, David Wasserman @.***> escribió:

Much of the tools live on in the Calculate Service Frequency Tools https://pro.arcgis.com/en/pro-app/latest/tool-reference/public-transit/calculate-transit-service-frequency.htm .

If you are asking if there are decay functions for access potential like those documented in the Transportation Access Manual https://empirical-urbanist.io/publications/transport-access-manual, the answer is no. You likely derive a relatively easy to compute approximation using "median isochrones" and breaks that enable you to apply stepwise decay functions. However, the main purpose of these tools main purpose are to enable users to deal with the temporal variation of transit in a network analysis context.

@mmorang https://github.com/mmorang can confirm I am correct, but my understanding is these tools only do "flat" aggregations when calculating cumulative opportunities.

— Reply to this email directly, view it on GitHub https://github.com/Esri/public-transit-tools/issues/137#issuecomment-1890828973, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQJWOWSF6BIJKRIXZPMLS3DYONA3XAVCNFSM4HOE6E3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGA4DEOBZG4ZQ . You are receiving this because you commented.Message ID: @.***>

[d-wasserman]

Ah you mean a citation.

Morang. M.; Wasserman D. (2015). better-bus-buffers. Esri. Retrieved from https://github.com/Esri/public-transit-tools.

@mmorang might have a second thought to add on this.

[paulogeo]

Hi. Thanks for your answer, but I did not meant a citation, but a formula, like BBB=E x Ai x Oj... I need a mathematical formalization for my BBB. Thanks again for your help.

El dom, 14 ene 2024, 15:14, David Wasserman @.***> escribió:

Ah you mean a citation. https://academia.stackexchange.com/questions/14010/how-do-you-cite-a-github-repository

Morang. M.; Wasserman D. (2015). better-bus-buffers. Esri. Retrieved from https://github.com/Esri/public-transit-tools.

@mmorang https://github.com/mmorang might have a second thought to add on this.

— Reply to this email directly, view it on GitHub https://github.com/Esri/public-transit-tools/issues/137#issuecomment-1891022934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQJWOWTBBJACMKTSXAL3PDLYOQOARAVCNFSM4HOE6E3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGEYDEMRZGM2A . You are receiving this because you commented.Message ID: @.***>

[d-wasserman]

I think I need more information about the type of analysis your thesis did then. Again, many of these tools are simply about temporal normalization of transit schedules in physical space. If you did an access analysis, many of these tools operate to provide effectively "percentile" representations of access, so the mathematical formulations I guess would be similar to a percent of access times?

[paulogeo]

Hi there. What I need is a function to demonstrate how the BBB work. Something like this: Equations of the estimated accessibility indicators | Download Table (researchgate.net) https://www.researchgate.net/figure/Equations-of-the-estimated-accessibility-indicators_tbl1_329581914

Em dom., 14 de jan. de 2024 às 17:39, David Wasserman < @.***> escreveu:

I think I need more information about the type of analysis your thesis did then. Again, many of these tools are simply about temporal normalization of transit schedules in physical space. If you did an access analysis, many of these tools operate to provide effectively "percentile" representations of access, so the mathematical formulations I guess would be similar to a percent of access times?

— Reply to this email directly, view it on GitHub https://github.com/Esri/public-transit-tools/issues/137#issuecomment-1891066345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQJWOWXRSC2WQMQVL7WNZJTYOQ7A3AVCNFSM4HOE6E3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGEYDMNRTGQ2Q . You are receiving this because you commented.Message ID: @.***>

--

-- Paulo de Almeida Correia Jr. Geógrafo

[d-wasserman]

I go back to my decay function note. These tools only do flat access aggregations by default. Melinda's percent of access opportunities tool does not do any decay operations. I think it is a naive sum of connected opportunities within a percentage of time points.

[paulogeo]

Hello. I think your statement was quite good! Thanks a lot for your help!

El lun, 15 ene 2024, 2:20, David Wasserman @.***> escribió:

I go back to my decay function note. These tools only do flat access aggregations by default. Melinda's percent of access opportunities tool does not do any decay operations. I think it is a naive sum of connected opportunities within a percentage of time points.

— Reply to this email directly, view it on GitHub https://github.com/Esri/public-transit-tools/issues/137#issuecomment-1891319159, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQJWOWUWMI3AABLK4SQ32JLYOS4AFAVCNFSM4HOE6E3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGEZTCOJRGU4Q . You are receiving this because you commented.Message ID: @.***>

[mmorang]

Just catching up on this thread. @paulogeo, it might help if you told us which of the BetterBusBuffers tools you used in your thesis. They all do similar things, but, as David mentioned, they aggregate the results in different ways.

In general, the tools simply provide counts of transit service. They simply check the schedules to determine which transit trips visit stops during the provided time window and summarize that service. The part that depends on the tool is how those counts are aggregated. For example, Count Trips at Points calculates an OD Cost Matrix to identify which stops are within the designated cutoff time/distance of each point of interest and combines the data from all those stops. It doesn't use any kind of decay function to weight the stops by distance. It just counts them all equally.

Full documentation for all the BetterBusBuffers tools is at https://github.com/Esri/public-transit-tools/blob/master/deprecated-tools/better-bus-buffers/UsersGuide.md.