Open annikaLiving opened 3 years ago
@TerryLanktree what would you like to see for the WMS and KML values?
Leave the empty fields empty. Like for like, then we get clean-up by Custodian, if required. If the field is now mandatory, could we populate with Not Provided, or Unknown? Does it need to be mandatory if there is no real info? Are we able to make mandatory for certain resource types and not others? @yuisotozaki @BrandonSharratt What are our options?
The field in question must have a purpose for the consumers even if it's to prime their mind into expecting certain information to follow. I.e. If we show the word "Albers" on the screen, the user will expect to see resource in that format. It would be great if we can show "Not provided" on the UI and when the custodian goes to edit, they must provide a value from the list (i.e. "Not Provided" is not a valid option at that point).
There are many fields that are not mandatory, as they do not pertain to the dataset the provider is giving. These are examples of where those and where these fields should not be visible. Other examples is Temporal Extent. Not all data includes a time series, thus this is misleading the consumer that it is even visible.
The wording "No Provided" would be false in such cases, as this would infer that the provider just left this out, not that this is Not Applicable to this data.
There are many fields for resource types that do not belong as i wrote up in my resource type mock up pages 6 months ago. This included fields now added to Applications and Webservices that did not exist in Cat Classic and now fields are being populated with incorrect information.
This data here is showing that values were populated that did not exist in Cat Classic thus the values chosen are incorrect.
Being new to the Catalogue team, I have to ask some perhaps obvious questions: What is the intent of the filed? In the case of projection, if it's storage, we do store in Albers, even the items we spool out to WMS and ArcGIS online. It may be reprojected by the consuming application, and that knowledge may be good to have. Alternatively, it may be the projection the data was captured in (which would be very relevant, but I do not believe this is what is being captured). I always want to ask the questions: Why are we showing these fields? and, How useful is it to the consumer? If the database could be SDO or STE Geometry, does this have any implication to the consumer of the data? Can it affect analysis? Will it affect anything with the data download (which will not be in the storage format)? As for Temporal Extent, how many datasets do we have that need this? We are not a temporal warehouse, as far as I know, so is this simply because it's part of the standard?
For the examples i provided, the values in Cat Classic do not include the values that i have listed (other than maybe projection if the user selected 3005). Therefore the data migration has something incorrect in the mapping and now showing incorrect data.
The Geometry Type was added as a requirement of IITD when they were going to use the catalogue. that project went away but it is probably coming back. we are to engage with them on this.
The Resource Storage Format and Spatial Datatype
Projection is valid for Geographic datasets and useful. would have to see if any dataset was set to another projection.
Cleanup to be done after MVP
Logic for the data transformation for Geographic Resources need to include more logic around what should include the following values and not as currently Geographic Resources not from the BCGW have values populated that only relate to the BCGW.
This may be related to logic for 357 not populating Preview Info values.
Logic - this won't quite get them all but can build an exceptions list.
IF not already populated then:
Fields Populated:
examples of where these should not populated:
For BCGW WMS and KML Logic on how these are populated needs a bit more work.