Safety Data new API

[atalyaalon]

• API template of existing documentation using OPEN API 3.0.0 in this pr.
  Existing paths: /involved, /involved/groupby, /city
  Regarding hotspots and users, we will implement them in the API after we finish building the current API for the existing state.
• You can play with documentation (mock data) here

1. Please review the API documentation created (of existing situation) together with existing tables in Mongo DB ("accidents" represent involved and "cities" represet the CBS cities)
2. Please suggest a modified version of API together with Design for safety data tables, based on our existing DB and tables.
   You can use the API template I created with swaggerhub, or use another template for your choice.

I want you to take into consideration:

• Existing mongo db table containing involved named "accidents" and can be found here) - you should have access
• I assume that with the new API will need to perform some FE adjustments. That's OK, we'll adjust but we will consult Dror to make sure changes are minor and won't require a huge additional work.
• In current implementation of API querying, we have "AND" between filter fields and "OR" between chosen field values
• Performance should be good, just like current Safety Data API.

My suggestions and thoughts:

cbs_cities table:

• In our current CBS cbs_cities table, I think we're missing only population field (other fields in mongoDB cities table are not used at the moment). believe you can add the population field from data_gov?
• I suggest that FE will query cities info based on yishuv_symbol

cbs_streets table:

• I suggest adding an API for it, or better - using our existing API
• I suggest that FE will query streets info based on yishuv_symbol and street symbol.
  There for either: this won't enable to query a specific street in multiple cities, but I think that's ok for now (if we want to enable this, we will find workaround that is still based on
• streets aliasing - (dataset can be found here) - I think that if we do, it will be the last feature since it's not a requirement from the municipality at the moment.

cbs_involved_for_safety_data table:

• Existing API does not enable filtering by all involved parameters (for example weather field ), even though it exists in mongoDB. I think we should enable as much flexibility as possible to filter by all relevant fields.
  However, we can also start "lean" and only keep existing functionality with relevant fields, and later on to add additional fields that are not present.
• Will we create a new table? (or perhaps we'll understand we want to use involved_markers_hebrew with improved structure?)
  If we create a new table, I assume this table will be similar to involved_markers_hebrew, just w/o the hebrew fields. Perhaps it's better to save in this table only with integer codes and link it with relevant hebrew views (star schema) for a light table.
• I wonder if pagination is needed when data is large, let's discuss our options (I believe that the curr '/accidents' API pulling from mongo's "accidents" table is not paginated).
• Note the difference between current field vehicle_vehicle_type_hebrew that contains the involve's vehicle_type AND vehicles that contains a list of all involved vehicles using the following mapping that contains grouping of all vehicles from the specific accident:

vehicle_type=1 ->"רכב נוסעים פרטי"
vehicle_type=2 -> "טרנזיט"
vehicle_type=3 -> "טנדר"
vehicle_type  in (5, 6, 7, 24 ,25) -> "משאית"
vehicle_type  in (8, 9, 10, 19) -> "אופנוע"
vehicle_type in (11 ,18) -> 'אוטובוס'
vehicle_type = 12 -> 'מונית' 
vehicle_type = 13 -> 'רכב עבודה' 
vehicle_type = 14 -> 'טרקטור' 
vehicle_type = 15 -> 'אופניים' 
vehicle_type = 16 -> 'רכבת'
vehicle_type = 17 -> 'אחר ולא ידוע'
vehicle_type = 21 -> 'קורקינט חשמלי'
vehicle_type = 22 -> 'קלנועית חשמלית' 
vehicle_type = 23 -> 'אופניים חשמליים'

• There are mappings done in the FE, for example here in injured_type, 4,5 are mapped to motorcycle, 6,7 to cyclist. Should we keep these mapping in FE? or transfer them to BE?

[ziv17]

Hi @atalyaalon ,
Regarding
"Existing mongo db table containing involved named "accidents" and can be found here) - you should have access"
I did not find anything there. It looks empty (I tried both my yahoo and gmail accounts).

[ziv17]

Hi @atalyaalon ,
regarding viewing the MongoDB tables. To which of my emails did you grant access? I tried logging in with both of my emails and did not see anything. Maybe I do not know where to look

[ziv17]

Hi @atalyaalon ,
Regarding the _id field that is returned in the /involved request: what does it identify?

1. Should it be the same for the same person that is involved in two different accidents that are returned in the same query?
2. Should it be the same for the same person that is involved in the same accident that are returned in two different queries?
3. Will just specifying the order of the returned items in each query suffice?

[ziv17]

Hi @atalyaalon , @citizen-dror
Regarding the involved query parameters:

1. The parameters have short names, that are not always self explanatory. If we want these names to stay, I will use a translation table from these short names to the DB column names we use in Anyway.
2. In the API document, several parameters can be assigned a list of values. I understand that such a list will be specified in the URL using multiple appearances of the parameter name, with a single value each time.