Redundant location for bottomholes
Regarding Keith's message about R1 manifests, I see that explicit bottom hole locations are present. These are redundant with the facility location array. I thought we scratched those properties, but I see them in our master schema repository. We got rid of the equivalent in well. - Doug Gregory You're right; according to our notes, in making the Spatial Location property of AbstractFacility an array we acknowledged that this made the Well property of Projected surface location redundant, and in the notes we suggested it made the Wellbore bottom hole location properties redundant as well. We neglected however to specifically capture a line item to remove these from Wellbore so it must have gotten overlooked when we updated all of the JSON (this was prior to us adopting the convention of starting with the full list of current properties in the spreadsheet). In any case, whilst I support the suggestion to remove the explicit BH location properties, one issue I think we have is that in AbstractSpatialLocation, there is no property to identify what location is being specified, i.e. a Location type or equivalent. Of course you could assume that for a Well the spatial location is at the surface and for Wellbore at the bottom hole, but for one thing we don't want that kind of ambiguity, and secondly that leaves no room for additional spatial locations to be provided for a given facility type, such as plug back coordinates, kick off coordinates, etc. Do we need to consider adding a Location Type property to Abstract Spatial Location? -- James Pipe