Closed gregbunce closed 2 months ago
@gregbunce, @steveoh to me it seems like all this UTA data (trax, commuter rail, bus routes, stops etc) are worth having their own webpages and not just burying them in the sgid index.
check | status |
---|---|
@gregbunce has completed 1 out of 10 tasks | :no_entry: |
@ZachBeck has completed 0 out of 5 tasks | :no_entry: |
@stdavis has completed 0 out of 4 tasks | :no_entry: |
@steveoh has completed 0 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :no_entry: |
open sgid | :no_entry: |
open data | :no_entry: |
arcgis online | :+1: |
stewardship | |
- porter issue link | :no_entry: |
@gregbunce, @steveoh to me it seems like all this UTA data (trax, commuter rail, bus routes, stops etc) are worth having their own webpages and not just burying them in the sgid index.
Ok. Our current convention is to have pages on gis.utah.gov for data that we host. Is there a good enough reason to change that?
No, not necessarily. I just hate to see some data get buried in the index.
I'd like to see the sgid search bar (sgid index) become front and center on the data page. to me, the index should hold the most complete view of the sgid.
IMO I don't think there should be a hard and fast rule for what gets a webpage. I think if the steward would like us to promote their data with a webpage we should continue to do it, within reason. Welands is a good example. I am not sure what the UTA story is but my guess is that it is 'data come full circle'. While the Index is cool a webpage that documents the data (ie. history, codes, how to use, etc.) is still valuable. But if getting our website down to fewer pages is the plan so be it. My 2 cents
I don't agree with the seemingly negative sentiment that adding items to the sgid index are burying it. It seems to me that the more distributed the SGID becomes the more important the index becomes. If we think we are burying data in it, then we are failing to provide a good service to finding data.
I do think we need a repeatable process that defines what gets a product page. Otherwise it becomes subjective and possible unfair. It is more overhead for us and ultimately more work for you. For instance, who is going to manage the metadata and update history for a product that is not managed by us and how do we want to do that?
The main things we promote on a product page are going to be highly duplicated on the ArcGIS Hub pages since there won't be an open sgid table. The ArcGIS Hub page that possibly exists in our Hub (distributed collaborate) and their Hub would have the most current information and would be discoverable through Hub's search and the index.
I also agree that the Hub pages are a good 'replacement' for our data pages, for data that we do not host. The key is working with the stewards to maintain relevant information (odd domains, use cases, update cycles, etc.).
I wonder if part of the hesitation with the SGID index-only situation is that you have to know what to search for to find something. There's not a great story in our site for browsing datasets that are only in the index and don't have product pages. Maybe we could add links to open data pages in our website category pages for these datasets?
So that does bring up an another point. Currently the SGID index does not help the datasets out with search optimization, whereas data pages do.
What about a simple website page that dynamically lists all of the index layers, to act as both a place to "browse" (or at least view) index datasets, and to help with search optimization?
There's not a great story in our site for browsing datasets that are only in the index
Should all the items in the index display when their category is selected?
Maybe we could add links to open data pages in our website category pages for these datasets?
We decided during the migration to remove these as most of the existing items were out of date, broken, and not maintained by the steward.
But if they were maintained through the sgid index sheet, with it's validations, that could certainly help with the previous issues.
Currently the SGID index does not help the datasets out with search optimization
I don't see this as being a feature of the SGID index. The hub pages will be indexed by engines already and our outgoing links to their product pages do help their SEO.
I don't see this as being a feature of the SGID index. The hub pages will be indexed by engines already and our outgoing links to their product pages do help their SEO.
Glad to hear that. How do our outgoing links work to help their SEO? I was under the assumption that those links needed to be on a web page.
How do our outgoing links work to help their SEO?
I'm not going to claim to be an SEO expert but I do know that a page with a good score linking to another page boosts the score of the destination page somehow. Search engine crawlers do have the ability to render javascript and the sgid index is a react component. And you are right the link doesn't show up until the box is typed into. So maybe all of that doesn't matter.
The previous sgid index did render every entry on load and was a filtered from that state.
check | status |
---|---|
@gregbunce has completed 7 out of 9 tasks | :no_entry: |
@ZachBeck has completed 0 out of 5 tasks | :no_entry: |
@stdavis has completed 0 out of 4 tasks | :no_entry: |
@steveoh has completed 0 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :+1: |
stewardship | |
- porter issue link | :no_entry: |
check | status |
---|---|
@gregbunce has completed 7 out of 9 tasks | :no_entry: |
@ZachBeck has completed 0 out of 5 tasks | :no_entry: |
@stdavis has completed 0 out of 4 tasks | :no_entry: |
@steveoh has completed 0 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :+1: |
stewardship | |
- porter issue link | :no_entry: |
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
@stdavis has completed 0 out of 4 tasks | :no_entry: |
@steveoh has completed 0 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :+1: |
meta table | :+1: |
stewardship | |
- porter issue link | :no_entry: |
note about this layer and the sgid index: I used the existing row (record) for this layer in the sheet and updated the values with the newest information (name, urls, etc).
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
@stdavis has completed 0 out of 4 tasks | :no_entry: |
@steveoh has completed 2 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :+1: |
stewardship | |
- porter issue link | :+1: |
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
stdavis has completed 4 out of 4 tasks | :+1: |
@steveoh has completed 2 out of 4 tasks | :no_entry: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
@rkelson has completed 0 out of 1 tasks | :no_entry: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :+1: |
stewardship | |
- porter issue link | :+1: |
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
stdavis has completed 4 out of 4 tasks | :+1: |
steveoh has completed 4 out of 4 tasks | :+1: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
rkelson has completed 1 out of 1 tasks | :+1: |
check | status |
---|---|
internal sgid | :+1: |
meta table | :+1: |
stewardship | |
- porter issue link | :+1: |
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
stdavis has completed 4 out of 4 tasks | :+1: |
steveoh has completed 4 out of 4 tasks | :+1: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
rkelson has completed 1 out of 1 tasks | :+1: |
check | status |
---|---|
internal sgid | :+1: |
meta table | :+1: |
stewardship | |
- porter issue link | :+1: |
feel free to close this one out @jacobdadams when you're done.
check | status |
---|---|
gregbunce has completed 9 out of 9 tasks | :+1: |
ZachBeck has completed 5 out of 5 tasks | :+1: |
stdavis has completed 4 out of 4 tasks | :+1: |
steveoh has completed 4 out of 4 tasks | :+1: |
@jacobdadams has completed 0 out of 1 tasks | :no_entry: |
rkelson has completed 1 out of 1 tasks | :+1: |
check | status |
---|---|
internal sgid | :no_entry: |
meta table | :+1: |
stewardship | |
- porter issue link | :+1: |
I didn't catch the changes come through auditor, but we're past the point where it matters so I'm closing as complete.
Summary
UTA now has its own ArcGIS Enterprise Portal and is hosting this layer and sharing it with UGRC's SGID (SGID on ArcGIS) via Distributed Collaboration in UGRC's AGOL.
Migration Guide
The goal is to direct our users to UTA's web service, via the SGID Index and the SGID on ArcGIS.
Action items
name
with their github@name
.Soft Delete
The purpose of the soft delete is to ensure that all of our users and applications have gracefully migrated off of the dataset. Soft deletes will remain in effect for 14 days. During this time, we will have the ability to restore the dataset to its original SGID offering(s). After these 14 days, the item is then ready for a hard delete.
Note: If this dataset is being replaced, then wait until the new data is publicly available before completing these steps:
SGID.META.AGOLItems
table (@gregbunce, completed:2024/07/30
)2024/07/30
)2024/07/30
)2024/07/30
)Authoritative
field tod
inSGID.META.AGOLItems
to automatically set theDeprecated
AGOL flag. Allow thed
to persist through one run of Auditor - currently, Auditor runs daily at 5:00am (@gregbunce, completed:2024/07/30
)SGID.META.AGOLItems
table. This will trigger the removal of this item in Open SGID (@gregbunce, completed:2024/08/01
) ~- [ ] Unshare the item from its SGID group, which will remove it from the SGID on ArcGIS (@gregbunce, completed:2024/00/00
)~2024/08/12
).Hard Delete
Target Date: 2024/08/15
Hard deletes are final. It is recommended to complete the soft delete process before moving on to these steps. If you decide to skip the soft delete, note that you will need to incorporate some of those steps here.
2024/08/15
)2024/08/15
). ~- [ ] Remove ArcGIS Online item: (name, completed:2024/00/00
)~ ~- Manually delete the AGOL item~ ~- Deprecated AGOL items can be backed up on Google Drive > AGRC Projects > SGID > deprecated layers > agol_sgid_layers.~2024/08/26
)2024/08/15
)downloadMetadata.ts
) (@ZachBeck, completed:2024/08/15
)SGID.META.AGOLItems
table, remove row (@ZachBeck, completed:2024/08/15
)SGID.META.ChangeDetection
(@stdavis, completed:2024/08/26
)2024/08/26
)data/hashed/changedetection.gdb/TableHashes
(@stdavis, completed:2024/08/26
)Shelve/Static
Choose one based on situation.
~- [ ] Upload to
UtahAGRC/AGRC_Shelved
folder in AGOL (New shelved item not already in AGOL) (name, completed:2024/00/00
)~ ~- [ ] Move existing AGOL item toAGRC_Shelved
AGOL folder (shelving an item already in AGOL) (name, completed:2024/00/00
)~ ~- [ ] Upload to appropriateUtahAGRC/{SGID Category}
folder in AGOL (forstatic
datasets) (name, completed:2024/00/00
)~Add record to table.
~- [ ] Add record to
AGOLItems_shelved
table in ArcGIS Online withshelved
orstatic
in theCATEGORY
field (name, completed:2024/00/00
)~:robot: Automation validation
name
with their github@name
.2020/01/01
when the task is verified.2024/09/02
)2024/09/02
)shelved
/static
/Deprecated
information (@jacobdadams on2024/00/00
)Are there service dependencies
2024/08/15
)Notification
Group Task Assignments