List view
Darwin gives a lot of information. One thing to note is that some of the information is supposed to update information previously given. Currently our implementation simply shoves all the data into Postgres, but what is needed is actually an up to date database with no outdated information stored. This milestone has the objective of implementing that infrastructure starting with the Schedule messages, including CallingPoints. This also includes handling lost messages (from the darwin logs and/or non-realtime data that is useful to get the schedules up). In other words, we aim to have an up to date Schedule model.
No due date•2/5 issues closed# Objective The objective is to modify the current ORM python classes to adapt to the datamodel and populate the databse with a day or two worth of data. # Deliverables A new database adapted to the new datamodel, populated with darwin pushport data.
No due date•1/1 issues closed# Objective To understand the current datamodel from Darwin push and extract a simple and intuitive datamodel from the current pushport data. # Deliverables A diagram of the ideal datamodel # Description This milestone comprises the understanding of the datamodels themselves. As discussed, a diagram was built which mapped out the structure of the XSDs of the Darwin Pushport. These are too complex and inconsistent to be taken forward, so the objective is to build a datamodel that makes sense, so we can store it, retrieve it, and compute useful analytics. We need to make sure that we also identify the noise in the data, so we avoid adding it to the datamodel. A first-draft diagram has been mapped out and can be found in the diagrams folder within the ATOC data folder in the Hack Partners google drive.
No due date•1/1 issues closed