Skip to content
This repository has been archived by the owner on May 27, 2024. It is now read-only.

Can't import a new GTFS stop close to an existing OSM stop #24

Open
james2432 opened this issue May 12, 2016 · 12 comments · May be fixed by #62
Open

Can't import a new GTFS stop close to an existing OSM stop #24

james2432 opened this issue May 12, 2016 · 12 comments · May be fixed by #62
Labels

Comments

@james2432
Copy link
Contributor

When parsing the gtfs data if a bus stop does not exist there doesnt seem to be a way to force it to create a new node instead of editing one in OSM
See attachment. I have a selected gtfs stop and I cannot unselect an OSM stop to make sure it creates a new node instead of editing potential matches in OSM
go-sync

@barbeau
Copy link
Member

barbeau commented May 12, 2016

@james2432 Are there actually two stops that close to one another?

The tool may currently assume that stops that close are duplicates. To be honest it's been so long since we worked on this I don't recall. If that is the case, a work-around may be to remove the close stop from OSM and let the tool import both stops from the GTFS data.

@barbeau barbeau added the bug label May 12, 2016
@barbeau barbeau changed the title No way to define as new node Can't import a new GTFS stop close to an existing OSM stop May 12, 2016
@james2432
Copy link
Contributor Author

The purple, green and yellow boxes are all correct, it's just the application assumes that it has the correct answer, when it might be that it actually needs to create a new node. Sometimes with the STO bus stops can have the same name and be within 200m of each other. Don't ask me why....STO is a horribly run bus service.

@barbeau
Copy link
Member

barbeau commented May 12, 2016

When you say the stops "are correct", do you mean the stops all exist in the GTFS data, or all those stops actually exist in real life? Also, do any of the stops have the same GTFS stop_id?

@james2432
Copy link
Contributor Author

They exist in real life is what I mean by correct. The stop ids are unique in the stops.txt
Here is a link to the data:
http://www.contenu.sto.ca/GTFS/GTFS.zip

@james2432
Copy link
Contributor Author

And in osm there are none with gtfs_id tag defined as this is the first import

@barbeau
Copy link
Member

barbeau commented May 12, 2016

@james2432 Ok, so yes, this does sound like a bug. We should allow the user to specify that a matched stop is in fact a new stop and insert it into OSM.

Just as a heads up, we aren't actively working on this project, so it may be some time before this gets fixed. Contributions are welcome :).

@james2432
Copy link
Contributor Author

Would like to work on this but would like to get #25 solved first by merging pull request #27 This bug shouldn't be to hard to complete

@barbeau
Copy link
Member

barbeau commented May 20, 2016

Sorry about the delay - just merged #27.

@reubot
Copy link
Contributor

reubot commented Mar 12, 2017

Hi @james2432 , could you try out the prerelease I've made at https://github.com/reubot/gtfs-osm-sync/releases/tag/2017-chaanges

Thanks

@james2432
Copy link
Contributor Author

@reubot Seems to work better than the previous version
Could you add STO (Société de Transport de l'Outaouais) as an operator or allow me to type what I want
http://www.contenu.sto.ca/GTFS/GTFS.zip
http://www.sto.ca/index.php?id=596&L=en (where the above link comes from)

@reubot
Copy link
Contributor

reubot commented Mar 24, 2018

@reubot
Copy link
Contributor

reubot commented Oct 30, 2018

@james2432 My pull request with the addition of a manual threshold selection has been merged, can you give it another go. Thanks

@tenzap tenzap linked a pull request Jul 31, 2023 that will close this issue
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants