You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have recently discussed making human-readable names (as opposed to our UUIDs) available in CSV outputs (see #909, #920). For these outputs, routing workers write complete rows as strings, which the broker then writes directly to CSVs in assemblers without further inspection/processing.
Workers have GTFS information readily available, so we can add route/stop names to the CSVs with the current design.
Workers do not have information about destination layers readily available other than the UUID. Names corresponding to these IDs are in the database, to which the workers are not connected. To write the names, we could:
Pass along a map from destination layer IDs to names in a snapshot file (similar to the scenario.json file)
Have the broker postprocess freeform access results it receives from workers, rather than simply writing the strings it receives directly to the CSV
Change our design so workers have database access
In the meantime, we should make add buttons to download the mappings from our IDs to names (for bundles and opportunity datasets) so users can more easily swap out the IDs for names themselves.
The text was updated successfully, but these errors were encountered:
Discussing the first bullet point above: scenario.json is already a moment-in-time snapshot of some data from the database, but it's not per-regional-analysis (could be reused by many analyses). So it can't contain the id-to-destination map, which could be different for each regional analysis run.
We have recently discussed making human-readable names (as opposed to our UUIDs) available in CSV outputs (see #909, #920). For these outputs, routing workers write complete rows as strings, which the broker then writes directly to CSVs in assemblers without further inspection/processing.
Workers have GTFS information readily available, so we can add route/stop names to the CSVs with the current design.
Workers do not have information about destination layers readily available other than the UUID. Names corresponding to these IDs are in the database, to which the workers are not connected. To write the names, we could:
In the meantime, we should make add buttons to download the mappings from our IDs to names (for bundles and opportunity datasets) so users can more easily swap out the IDs for names themselves.
The text was updated successfully, but these errors were encountered: