Center coordinate or Bounding box definition in feed_info.txt about transit HOT 6 OPEN

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.

from transit.

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.

from transit.

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

from transit.

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.

from transit.

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.

from transit.

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.

from transit.