Remove Sites table, moving Lat/Lon to SamplingFeatures

[aufdenkampe]

Following ideas in #142 (comment) and below, I've concluded that we should fully merge the Sites table into the SamplingFeatures table, in agreement with @PleiadesAustralia, for a number of reasons. These include:

• The current 2018 SiteType vocabulary is inappropriate to describe a SamplingFeature and more a list of FeatureOfInterest types. It is currently very confusing to users, and as such it needs to be refactored into a new Feature of Interest extension (see Feature of Interest #132) or into SamplingFeatureTypes. There is thus no valuable information here. See the entire Resolve inconsistencies between SamplingFeatureTypeCV & SiteTypeCV #142 thread.
• Many users are interested in providing a centroid Lat/Lon to most SamplingFeatureTypes, even those that represent multi-dimensional shapes. For example:
  • the System for Earth Sample Registration (SESAR), provides for specimens with an IGSN to be given a Lat/Lon, without requiring a parent SamplingFeature.
  • see my boreholes discussion in Resolve inconsistencies between SamplingFeatureTypeCV & SiteTypeCV #142 (comment)

[aufdenkampe]

Here is the diagram from 019bc37:

[PleiadesAustralia]

Anthony, I recommend the wording centroid latitude and longitude. However I am having second thoughts on Site. How does ODM2 handle sampling features of indeterminate geography such as networks or vehicle fleets or supply chains which are important in fields such as greenhouse gas accounting? What about lab QA/QC samples?

…

Sent from my iPhone On 9 Aug 2018, at 5:46 am, Anthony Aufdenkampe <notifications@github.com<mailto:notifications@github.com>> wrote: Here is the diagram from 019bc37<019bc37>: [odm2samplingfeatures_odm2 1_dev_019bc37]<https://user-images.githubusercontent.com/5166036/43866170-6bd55b22-9b2a-11e8-9d6f-71d5a60d9977.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#152 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g59H22lt2rY5sez7Bs84c0Wyj26Pks5uO1wggaJpZM4V0tS_>.

[PleiadesAustralia]

I am also interested how ODM handles flows from one location to another? such data is important in situations like mass balance.

…

Sent from my iPhone On 9 Aug 2018, at 5:46 am, Anthony Aufdenkampe <notifications@github.com<mailto:notifications@github.com>> wrote: Here is the diagram from 019bc37<019bc37>: [odm2samplingfeatures_odm2 1_dev_019bc37]<https://user-images.githubusercontent.com/5166036/43866170-6bd55b22-9b2a-11e8-9d6f-71d5a60d9977.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#152 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g59H22lt2rY5sez7Bs84c0Wyj26Pks5uO1wggaJpZM4V0tS_>.

[dr-shorthair]

The current 2018 SiteType vocabulary is inappropriate to describe a SamplingFeature and more a list of FeatureOfInterest types.

Yes - I agree that the list is a mixture with a lot of feature-types that are not usually sampling features.

However, it is worth noting that classifying something as a sampling feature is primarily related to its role in relation to another (larger or inaccessible) object or feature - it is a sampling-feature if it is intended to be representative of something else. This role does not inhere in the observable characteristics or other functional classifications of the feature, merely in the intention that it is-a-sample-of some other feature. The same feature might be both a feature-of-interest and a sampling-feature, in different contexts. For example, a well might be of interest in its own right (for producing water) and might also be a sampling feature with respect to the aquifer that it intersects.

[horsburgh]

@aufdenkampe - also, what about just Specimens that are SamplingFeatures, but have no latitude and longitude? This is why we separated Sites and Specimens from SamplingFeatures in the first place. In my old age I'm liking relational databases less and less because the representation of specialization is just silly.

Also - where did the link between FeatureActions and RelatedFeatures come from?

I'm assuming you're working in a new branch here? There's a lot of stuff that uses the existing construct.

[smrgeoinfo]

re @aufdenkampe FeatureAction links-- There needs to be a link to an action on a feature relationship to enable a process to be associated with derivation of one sampling feature from one or more parent SFeatures. Seems like having 'process' property on relatedFeatures that links to an Action would be a clearer solution.

[aufdenkampe]

@horsburgh, good questions. Yes, all of this is in the new ODM2.1_dev branch. Also, because I'm addressing lots of different issues sequentially, I decided to repost all the proposed schema changes in a new Draft ODM2.1 schema for review issue (#153). So, as @smrgeoinfo pointed out, that new RelatedFeaturesRelationID resulted from work we did in Nov. 2016 for #130.

@horsburgh, note that Lat & Lon are now nullable, so a SamplingFeature.Specimen would not require Lat/Lon.
@PleiadesAustralia, for the notes for Lat & Lon, I had put "Latitude of centroid of SamplingFeature", but that's not viewable from these simple .png images.

@dr-shorthair, take a look at my proposed FeatureOfInterest additions in #132 (comment). I think the construct there and previously in ODM2.0 can accommodate what you described.

[PleiadesAustralia]

This comment goes to the heart of my experience in developing environmental accounting systems - maintaining a methodology register. The structure we used was to ‘publish’ a methodology. The methodology would then have a template for input and output variables with associated data locations. For example air test samples at different locations on a stack would input to the methodology and the stack itself would be the output data location. In a mass balance there can be many input and output data locations which are connected by the methodology and action. My approach so far with my current exploration of ODM has been to be quite religious in sticking to the existing model but with the method template function I am getting stuck. FeatureAction does tie input and outputs for a calculation together via a ‘Derive’ type Action although I would like to add an Input/Output/Reference/Background CV to FeatureAction to tie both inputs and outputs together with Reference factors such as emission factors to a single ‘Derive’ Action. However this does not handle the Methodology template function. Here I would like to propose creating an intersection entity between DerivationEquation and Methodology which would include Variable, Argument Type (Input/Output/Reference/Background), and SamplingFeatureType. I would propose naming such an entity as DerivationEquationVariable. A better but more substantive change, which may effect the code base, would create a foreign key for Methodology in DerivationEquation with the DerivationEquationVariable referencing DerivationEquation directly instead of Methodology. Does anyone have any thoughts on this? Cheers, Sam

…

Sent from my iPhone On 10 Aug 2018, at 3:45 am, Stephen Richard <notifications@github.com<mailto:notifications@github.com>> wrote: re @aufdenkampe<https://github.com/aufdenkampe> FeatureAction links-- There needs to be a link to an action on a feature relationship to enable a process to be associated with derivation of one sampling feature from one or more parent SFeatures. The existing FeatureAction binds a sampling feature to a result. What needs to be represented is a FeatureAction whose result is another feature, not an observation result. Should there be separate bridge tables 1: SF --> FeatureAction--> Result and 2: SF-->FeatureAction2-->derived SF. Alternative is to link a featureRelation to an action SF.relatedFeatures-->FeatureAction2 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#152 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g1LLlbtzfBwz_d0bMR6hH5ulKEaoks5uPJFSgaJpZM4V0tS_>.