-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
data liveness recommendations #176
Comments
@steveoh is the idea to use a forklift process incorporate the golf course and ski resorts recommendations? @ZachBeck is the major roads buffer only used for drive times? Seems like new drive times would need to be generated if the golf course and ski resorts data recommendations are enabled? Not sure if Matt would agree about adding BRCs, WSCs and PTACs to SGID, since he wants to shrink it. Additionally, those data don't change a whole lot, but we found quite a few had changed last summer, and it can be a pain to get in touch with the data stewards to retrieve updates. Or maybe available for download on website, but not in SDE. |
@nathankota Yes. forklift would be the best mechanism for this. |
I think the drive times will need to be generated due to any ski resort changes, but the golf course changes shouldn't affect drive times. |
I can't remember what the buffered roads were used for. I think it was a more of a proximity thing rather than a drive time where location x is this close to a major highway. There are drive times for the ski resorts that might be a little stale since the road network used to create the drive times is dated. Some ski resort names in the report could be updated i.e change Canyons to Park City at the Canyons or whatever it is. |
From @eneemann and has been sitting in my email for far too long
After sifting through the Locate data some more (and the bbecon databases Scott sent me), I have a few recommendations to remove data from the "bbecon-static" database and instead pull from SGID layers:
Golf Courses: Perform Feature to Point analysis with 'inside' option to convert polygons from the SGID layer into points. This will result in points that are nearly identical to what is in the 'GolfCourse_pts' layer of the static database. Drive times are not calculated on this this layer, so the points don't have to be close to roads.
Ski Resorts: Just use the 'SkiAreaLocations' SGID layer. All points are located close to roads and within a few meters of the points in the static database layer. The only exception is Canyons, where the SGID layer is closer to the mountain base by about 1/2 mile, whereas in the static layer it's at the roundabout. The SGID point is still right on the roads data, so drive time calculation should be okay. Obviously, this change would need to be tested to verify all of the drive times work.
Major Roads 1 Mile Buffer: Create from SGID layer with buffer analysis. I can't tell if this is currently created from SGID (looks like it from 'ironing_board' script) or pulled from the static database, which has a 'MajorRoads_Buffer1mile' layer. If not being done already, I recommend using the SGID data to create the roads buffer.
Business Resource Centers, Workforce Service Centers, Procurement Technical Assistance Centers: Recommend adding these three layers to SGID as part of ECONOMY or SOCIETY groups. Then data could be pulled from the SGID instead of the static database. These layers still appear current based on my review of the business.utah.gov web pages. If there's a reason not to add these layers to SGID, then they should probably just stay in the static database.
The text was updated successfully, but these errors were encountered: