Relation between lot_id and stop_id

[bhargavasana]

What is lot_id in drive_access_ft.txt and drive_access_points_ft.txt? FT code assumes that it will be different from stop_id. However, in the description of lot_id there is "stop_id". Do we want to make it clear that there should be no overlap between lot_id and stop_id? FT assigns numeric ids to both stops and lots for internal use.

[sdrewc]

@bhargavasana currently fasttrips requires lot_id != stop_id, correct? In CHAMP sometimes they are equal, so in these cases we may need to create dummy lot_ids, something like "12345_lot"

[e-lo]

@sdrewc - where does lot_id == stop_id in champ? that shouldn't be the case and if it is should maybe be fixed?

On Fri, Feb 12, 2016 at 12:15 PM, Drew notifications@github.com wrote:

@bhargavasana https://github.com/bhargavasana currently fasttrips requires lot_id != stop_id, correct? In CHAMP sometimes they are equal, so in these cases we may need to create dummy lot_ids, something like "12345_lot"

— Reply to this email directly or view it on GitHub https://github.com/osplanning-data-standards/GTFS-PLUS/issues/14#issuecomment-183472963 .

[bhargavasana]

@sdrewc - yes, lot_id must not be the same as stop_id in FT.

If we all agree, let us add a suffix/prefix to raw CHAMP lot_ids to make sure they are different from any of the stop_ids. Dependent input files (such as transfers_ft.txt) would need to be updated with new lot_ids in from_stop_id and to_stop_id fields.

[sdrewc]

@e-lo this happens in lots of places, in fact more than half of the pnrs in bus.pnr (anywhere there's a node instead of a nodepair). It appears to have been done intentionally, and fixing it in champ would likely include recoding many bus lines in addition to the pnrs themselves.

[e-lo]

@sdrewc ahh, I remember now that this is how it is done for buses. I think @bhargavasana has a good fix for CHAMP --> GTFS-PLUS conversion script and I will make a queued clarification to the spec that clarifies that they cannot be the same.