well additional information testing/implementation updates

[jacob-a-brown]

This PR implements model/schema updates to pass all well additional information tests except for the aquifer/geology tests. Those will get implemented after the models have been finalized.

@chasetmartin:

• the feature step the response should include the source of the completion information seems to apply to the completion date of the well, is that correct?
• the feature step the response should include the source of the construction information seems to apply to the construction method of the well, is that correct?
• should other fields, like the driller name, also have a source?

[chasetmartin]

This PR implements model/schema updates to pass all well additional information tests except for the aquifer/geology tests. Those will get implemented after the models have been finalized.

@chasetmartin:

• the feature step the response should include the source of the completion information seems to apply to the completion date of the well, is that correct?
• the feature step the response should include the source of the construction information seems to apply to the construction method of the well, is that correct?
• should other fields, like the driller name, also have a source?

@jacob-a-brown

Yes to completion source

Yes mostly to construction source, there was a previous field called DataSource for "reference to a person or document reporting hole/well construction information", row 24 in the NMAquifer mapping
https://docs.google.com/spreadsheets/d/1mbPNvPc_H9Y0XO7LEVFsTZHuef0AWPBKuZqhJUuvkQE/edit?gid=1959040963#gid=1959040963&range=24:24

If this one field would hold things up this sprint let me know and we can probably skip it and come back later.

I don't think driller name needs a source, since it's sort of another construction related field that was probably sourced from the same person/document (at least I don't see a source in NMAquifer)

[jacob-a-brown]

Besides the completion date the only construction information we have is the construction method (except for the construction notes). It seems to me that DataSource was kind of compound/nebulous and applied to both of these. Since the completion source step applies to the date I figured that the construction source would apply to the method. Do you think that would be an okay way to proceed? If so, should the feature files be changed to reflect this?

[chasetmartin]

Yeah I get that. So in that case the construction source would have no data right now since you don’t think it should come from DataSource?

[jacob-a-brown]

I think that the well_completion_date_source would come from the CompletionSource field and then well_construction_method_source would come from the DataSource field.

CompletionSource (transferred to well_completion_date_source)

A code indicating how the information about the construction date of the well was obtained; same look-up table as DepthSource

DataSource (transferred to well_construction_method_source)

Reference to person or document reporting hole/well construction information

[jacob-a-brown]

the field origin_type was added for controlled vocabulary where applicable, whereas origin_source was changed to a general string column to allow the recording of specific sources (like documents or websites). this occurred when implementing the transfer script because WellData.DataSource is not a controlled vocabulary like WaterLevels.DataSource.

[jacob-a-brown]

@ksmuczynski I renamed aquifers to aquifer_systems and formations to geologic_formations in the thing model db/thing.py to correspond with the table names and make it more explicit. I did this (for the former in particular) because the ThingResponse has a field called aquifers that concatenates aquifer_systems and aquifer_types

[ksmuczynski]

Looks good!