Wrong stop location in generated gtfs file
nikolauskrismer opened this issue · 14 comments
There seems to be a problem in the stops.txt file contained in the resulting GTFS archive.
I do use the data from http://sasabus.org/opendata and since the site states that this tool should be used to convert vdv to gtfs I did use it :-)
In the VDV source file there are locations including some longitude/latitude values.
Let's take these two points to show the problem:
...
rec; 1; 1; 5026; "Piazza Domenicani - Dominikanerplatz "; 10015; 1; ; "DOMENI "; "(Bolzano) Piazza Domenicani - (Bozen) Do"; 1; 112106926; 462952002; 0; ; " "; 0
rec; 1; 1; 5027; "Piazza Domenicani - Dominikanerplatz "; 10015; 1; ; "DOMENI "; "(Bolzano) Piazza Domenicani - (Bozen) Do"; 1; 112106008; 462952253; 0; ; " "; 0
...
In the created stops.txt the matching stops are:
...
5026,Piazza Domenicani - Dominikanerplatz,46.497778,11.351667
5027,Piazza Domenicani - Dominikanerplatz,46.497778,11.351667
...
The problem is that in the source file the locations are different, while in the GTFS file the are not. I am not sure if the problem is related to the fact that both locations have the same "ORT_REF_ORT" entry in the VDV file, but - although I am not very familiar with the VDV format - this should not matter, shouldn't it?
@nikolauskrismer I'll preface this with I know very little about this tool or VDV - but, looking at the code it seems that ORT_NR is used as the unique stop_id field equivalent in VDV. Looking at the VDV docs, page 50 Section 9.4.5, it seems that the ORT_NR field is the correct unique primary key used to identify each stop. So, I don't think both locations having the same "ORT_REF_ORT" should be an issue, in theory at least. That doesn't explain why you're getting incorrect lat/long values in the GTFS, though.
One of the more recent commits to the project (circa Aug 2014) was a bug fix for how stop location information was parsed - maybe this issue is related to that. I don't think I'm going to have time to debug this soon, but maybe @bdferris has some advice?
I would try conversion with an older build that does not include the fix, but unfortunately the repo does not contain an older version of the tool.
Of course one could build a version from source, but looking at the commit performed in Aug 2014 I really have to say that these changes make sense (especially removing the Math.random part in the lng/lat generation)
Yeah, it looks like the commit was changing the DMS to decimal degrees conversion process.
Found the problem -> fixed it and created pull request #3
Could you please have a look at the PR, merge it and create an updated snapshot in the onebusaway sonatype nexus repo (which I use in my gradle build file :))?
Thanks for the PR! I'll take a look on Monday.
On Aug 15, 2015 8:13 AM, "Nikolaus Krismer" notifications@github.com
wrote:
Could you please have a look at the PR, merge it and create an updated
snapshot in the onebusaway sonatype nexus repo (which I use in my gradle
build file :))?—
Reply to this email directly or view it on GitHub
#2 (comment)
.
Fixed via #3.
@nikolauskrismer As soon as Jenkins builds the master branch (assuming all the hooks work as expected), 1.0.0-SNAPSHOT should be available via the OBA maven repo and should contain this patch. Actually, looking at Jenkins, I think it just finished. So, give it a shot and let me know.
Hmmm, actually looks like Jenkins is failing to build one of the dependencies, onebusaway-gtfs, which is causing this project to fail. I'll take a closer look.
I would really say that jenkins just failed. So no way to test for me...
... Jenkins says that a file is missing the required license header (the error says it's the test I added).
Isn't there a maven/gradle task that adds the header (I thought that this would be done by the CI server)?
@nikolauskrismer You're right, looks like the lack of license header may be the issue. I don't believe so, I believe the license needs to be added manually. I'll push this shortly.
Also, I forgot to ask you to sign the OBA ICLA:
https://docs.google.com/forms/d/12jV-ByyN186MuPotMvxJtNKtSaGGTnEHm8rXomM2bm4/viewform
So, please go ahead and do that.
Signed the OBA ICLA.
I will test the new SNAPSHOT tomorrow.
Thanks for the quick fix with Jenkins ;-)
Thanks! Yes, everything seems good now that the license is included - Jenkins is passing. I also just added Travis CI builds for PRs, so next time we'll see this problem earlier.
Thanks again for your contribution!
Great. Now with the new SNAPSHOT available everything works as expected. :-)
Awesome! Thanks for the fix!