Center coordinate or Bounding box definition in feed_info.txt

[mkemals]

Describe the problem

In cases where multiple GTFS files are used, each GTFS package may need a center point to focus on the area it represents on the map (e.g. city). What do you think about adding fields like
center_lat
center_lon
default_zoom
to the feed_info.txt file for this information?

Use cases

In an application where urban travel planning is done for different cities, the first thing to do is to center the selected city on the map. This information can be kept in a separate dataset or can be pulled from the selected package since it is dependent on the list of GTFS packages.

Proposed solution

My suggestion is to add the following fields to your feed_info.txt file:
center_lat
center_lon
default_zoom

Additional information

No response

[skinkie]

If multiple GTFS files are used, these files need to be integrated into a single routable set in order to route over them. The problem with a center point (naive) is that it may be outside of the surface the file describes. If you would take a line as a horse shoe, the center would fall in the middle of the horse shoe, were there is actually no data. I feel that your goal is to describe a boundingbox, default zoom would be too vague for me.

[mkemals]

Defining a bounding box for the geometries in the GTFS package can also meet the need. Actually, my idea is to define which region the map application will focus on during the visualization of the data rather than contributing to the representation of the data with a model. For example, when I start the OpenTripPlanner (OTP) service, this service also runs a UI. If many GTFS packages are introduced to the OTP service, the opened UI automatically focuses on the bounding box of an area as much as the sum of all of them. However, if I create a city selection menu, there is no information where the map will shift its focus for the city I select. If we add this information to the feed_info.txt file in each GTFS package, the region where the GTFS data of the selected city is visualized is focused programmatically.

[nlee-septa]

Regardless of whether it's center/zoom or a bounding box, what is the advantage of producers providing this information in feed_info.txt vs consumers computing it from the list of coordinates in stops.txt (or polygons in locations.geojson)? I think it's not likely to be widely adopted because it doesn't provide much information beyond what's already in the feed.

[skinkie]

Regardless of whether it's center/zoom or a bounding box, what is the advantage of producers providing this information in feed_info.txt vs consumers computing it from the list of coordinates in stops.txt (or polygons in locations.geojson)? I think it's not likely to be widely adopted because it doesn't provide much information beyond what's already in the feed.

I can think of one advantage, zooming into a city or country, instead of some middle point in another country because there is a long distance line. Sure, a median would help with that too.

[eliasmbd]

@mkemals Thank you for creating your first issue and sharing this proposal with the community. I see you have generated a small debate here. We like to see it. 🎉

As a side not, I would like to invite you to join the GTFS Community on slack where you can connect with more contributors like yourself.

[mkemals]

Regardless of whether it's center/zoom or a bounding box, what is the advantage of producers providing this information in feed_info.txt vs consumers computing it from the list of coordinates in stops.txt (or polygons in locations.geojson)? I think it's not likely to be widely adopted because it doesn't provide much information beyond what's already in the feed.

The advantage of this is that for a large number of geometric objects in these files (stops.txt, locations.geojson), the bounding box or center point calculation is kept ready with internally calculated data, rather than having to be done repeatedly by anyone using the published GTFS package.