Stripping routes of the time based component
I loaded most of the Traficlab information on My DB and I was dismayed at finding the huge number of trips for a given route, sometimes with more than 200 passing by a single stop. I also noticed most of them have a single destination but a different time; what brought me to think they are the actual expected buses during the day, rather than the lines in the sense of paths following the same route. In my app I am showing the lines passing for a stop in the annotation and I cannot of course display 200+ labels that would all but fill the screen. Moreover they would slow the queries in the DB. So I need to strip them in order to have separate lines for separate paths. One idea would be to group them according to the destination, but that would also ditch lines having the same destination but a different starting point and/or intervening stops.
Also I did not yet tackle the real time information, nor the path calculation, waiting first to fix the loading, and so I do not know if they are based on the huge table entries, and if I delete the lines I could have dangling lines attached to arriving buses.
In fact you may check it by connecting to:
http: // backoffice. taxiprofessional. net/ inarrivo/ php/ strisciePalettaMulti.php?palina=7400302&device=iPhone& latitude=55.3397244&longitude=13.3
where the lines passing by stop 7400302 are displayed (please remove the spaces before connecting)
Hello Fabrizio!
I'm sorry to Inform You, but Trafiklab do not have the resources to support You with every little detail concerning the Google extract.
Trafiklab generates a set of files in GTFS format to Google and makes it public on Trafiklab for developers.
Trafiklab lacks the knowledge on how to create solutions given the GTFS files. We do correct errors if they are reported to us that is caused by error in our data sources.
Please, consult the Google documentation (or other developers on Trafiklab for description of the Data set).
We Wish You Good Luck!!
Best regards, Åke
Well, I think google is responsible for the standard, not for the date being entered. Trips could be as well referred to paths, rather than to transits. This also apply to the information you provide in the real time part I think is outside the Google GTFS standard.
I queried stack overflow
http://stackoverflow.com/questions/32069228/usi...
and a user, quite reasonably, suggested me to use the shapes for filtering the routes; too bad you have not implemented this part of the standard...
Perhaps, if you implement the shapes part, I may group the routes on the shapes and have unique entries for each path.
If I understand you correct I can feel your pain with this as well, a while ago I posted a suggestion to extend the trips.txt with the optional direction_id (https://kundo.se/org/trafiklabse/d/gtfs-onskema...). This would make it a bit easier to work with the data when we don't have access to e.g. shape files.
Actually the destination is present, but of course it collapses all routes that have the same destination, but possibly a different path, leaving people guessing if the bus they are boarding shall pass at the bus station near her home instead of taking another route to the destination.
What is worse is that each route comes repeated apparently according to the actual buses passing in the day. And that is again an element of confusion. If ever it were possible to get the line to which the passing bus belongs, there would always be the risk it is part of the pruned ones!
Maybe you're missing to reference it with the calendar? This feed contains unique trips for each day for every route and is not a frequency based feed as other feeds might be. I guess it's best to refer to the gtfs reference and or use a tool to inspect the data.
That is not interesting for my app. All I want to show is that a certain bus could pass at a stop, if it does not pass, it will not be shown among the arriving buses. I have not a level of indirection in my app by which a certain bus is not going to arrive because it shall arrive later, but because today it is not going to pass altogether.
You still need to consider the timetable for the day if you want the data presented to be accurate, a trip one day at a specific time might look different the other day. If you're only interested how the network looks like I don't think this feed will help you out of the box, you will need some post processing to create the lines for the routes yourself.
That I handle with lines. In that case I would have two lines, one good for a day another good for another day. My support should remain stable for whatever system, and the one I deviced is a technique allowing to accustom all of them with just some minor adjustments. For example, both in Rome and London there is not this level of meaning.
My problem is properly to distinguish between the routes which are distinct because they follow a different path - in which case I would like to keep both -, from those that are just distinct because they run at a different time of the day - and that I would need to group. I am quit sure the situation is a mixture due to the staggering number of routes that there would be without any grouping.
The shapes table in the GTFS protocol was devised for that, I think. But perversely Trafiklab does not support that.