Additional metadata fields.

[JesJehle]

Label

• [ ] has_labels (bool, optional)
• [ ] label_quality (int, optional)
• [ ] label_type (string, optional)
• [ ] label_source (string, optional)
• [ ] authors_label (string, optional)
• [ ] aoi_geom (polygon, optional) - is need in the database, can be uploaded seperately. (separate table)
• [ ] standing_deadwood (polygon (multipolygon), optional) same as aoi_geom.

Citation

• [ ] citation_doi (string, optional)
• [ ] citation_apa (string, optional)
• [ ] citation_type (string, optional)

Images

• [ ] project_id (string)
• [ ] authors_image (string)
• [ ] image_spectral_properties (string, RGB or NIRRGB, optional)
• [ ] image_quality (visual interpretation by database manager, integer, 1-3, optional)
• [ ] acquisition_date_month (int, optional)
• [ ] acquisition_date_day (int, optional)
• [ ] acquisition_date_year (int, optional)
• [ ] acquisition_date_precise (timestamp, optional)

[mmaelicke]

I need a bit of clarifications here:

• has_labels implies that there could be more than one label for an image? How and why would we then save it as a string? From my feeling labels are more of an entity of their own. Then, we can use the data model to map the existence of labels by the cardinality of the relation between image and label
• where do the citation fields come from? I would rather handle citation on the model that represents the datasets, which consist of more than just an uploaded image. Otherwise we end up with a citation for every part of a dataset, which seems pretty unhandy
• Why do we need 4 different acquisition dates and how do they interact with each other?
• What is a project_id and where does it come from? This structure implies that each image can only ever belong to either 0 or exactly one project. Wouldn't it make more sense to treat projects differently and model a n:m relationship?
• image_quality should go into the audit table and then it should not be optional anymore, right?
• authors_image as a string would make it impossible to link that to actual users. How is this information different from citations? How do we make sure that citations and authors are actually consistent? How can users know before they upload something?
• image_spectral_properties is that something that everyone owning a drone kind of knows? For my feeling, requiring detailed information about licenses already seemed to be a bit of a long stretch, how should users contribute this?.

Given all these comments, I am not sure how I should implement that into the upload API, the Data model and the processor API and all of it right now.

Maybe we should at first clearly elaborate, which new fields need to be on the upload_files table, which are ultimately supplied by the user or calculated by the processor. If these fields have nothing to do with the upload process, then I would keep them out of the way. Maybe I am missing something about these fields.

[mmaelicke]

btw. we already have an acquisition date and it is not optional