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
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.
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)
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:
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?
The text was updated successfully, but these errors were encountered:
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).
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
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 use the API template I created with swaggerhub, or use another template for your choice.
I want you to take into consideration:
My suggestions and thoughts:
cbs_cities table:
cbs_streets table:
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
cbs_involved_for_safety_data table:
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.
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.
The text was updated successfully, but these errors were encountered: