search

agrc / porter

UGRC tracks the additions, replacements, and deletions of SGID items (in the broadest sense of add, replace, or delete) through issues in this repository.
https://gis.utah.gov/documentation/policy/
MIT License
2 stars 0 forks source link

Rename existing political districts in SGID #167

Closed gregbunce closed 2 years ago

gregbunce commented 2 years ago

Summary

Rename existing political district layers (this would be the data that's prior to the 2022 data)

We are currently adding the 4 new political districts into the SGID (US Congressional, Utah State House, Utah State Senate, and Utah School Board Districts) and using the naming convection of layername and then start date to end date (ex: UtahSchoolBoardDistricts2022to2032).

I propose that we rename the existing corresponding political districts to match this naming convection. This will make the data much more user-friendly and explicit for not only us but the end-user. I propose we rename the layers in the Internal SGID and the rename will propagate from there.

We should address any concerns and talk through any hesitations in the comments below.

We shouldn't act on any renaming until we've talked it all through. Let's shoot for a decision by December 1st, 2021.

School Board

Utah House

Utah Senate

US Congressional

The data should be available in

1 Check [x] all the areas where you expect the data to show up.

Where is the data source

Choose one.

Action items

  1. Assign a person who should complete the task by replacing name with their github @name.
  2. Check [x] the box when the task is completed and add the date of completion.
  3. ~Strike~ out all items that do not apply.

:robot: Automation validation

  1. Assign yourself or someone to check the item by replacing name with their github @name.
  2. Check [x] the box and add the date of verification 2020/01/01 when the task is verified.
  3. ~Strike~ out all items that do not apply.

Notification

Group Task Assignments

  1. Check [x] the box when you have assigned all the tasks relevant to your group.
steveoh commented 2 years ago

This seems like an unnecessary breaking change.

gregbunce commented 2 years ago

the other option is to only remane the public-facing data via the meta agol items table. this would still be a potential breaking change for open-sgid users if they've mapped a layer but wouldn't be breaking for open data/agol users (they would only be affected by seeing a new name).

i think it has more benefits than harm. - clarity.

but, yes... we should continue to discuss and hash out. this is good

gregbunce commented 2 years ago

/remind us to make decision on this on 12/1/2021

github-actions[bot] commented 2 years ago

@gregbunce set a reminder for 12/1/2021

stdavis commented 2 years ago

I'm in favor of the change. I like the new naming scheme and I feel like it's worth the pain to standardize the older table names. We should just take our time with notifications and such.

Also, the tasks that are currently in this issue are for introducing new data. I think that the tasks from the "remove data from sgid" template should also be added since this is essentially deleting old tables and introducing new ones.

eneemann commented 2 years ago

I agree that the name changes would be much clearer for users. 'UtahSchoolBoardDistricts2012to2022' is much clearer than 'UtahSchoolBoardDistricts2015'.

For the other layers, is the shared year (like 2012) too confusing? For example, with 'UtahSenateDistricts2002to2012' and 'UtahSenateDistricts2012to2022', were both boundaries valid during elections in 2012? Or would it make more sense to start the later period with 2013? ('UtahSenateDistricts2002to2012' and 'UtahSenateDistricts2013to2022'). Or end the earlier period with 2011? ('UtahSenateDistricts2002to2011' and 'UtahSenateDistricts2012to2022').

ZachBeck commented 2 years ago

I'm ok with the change, hopefully the disruption is minimal. I think it makes sense to go with a naming convention like 2012to2022 since the boundaries are legally valid during that timeframe even though there is calendar overlap with other years.

eneemann commented 2 years ago

I think it makes sense to go with a naming convention like 2012to2022 since the boundaries are legally valid during that timeframe even though there is calendar overlap with other years.

Thanks, that's what I was looking for. I think the proposed naming convention is good then.

steveoh commented 2 years ago

I think the hassle of renaming this outweighs the clarity benefits, especially for a dataset that will be considered static or shelved. I'm not a big fan of the year to year naming since it can be nebulous in terms of including the year or up to that year but it is the shortest which i like for the database table name. I think for AGOL/OpenData we could expand?

Also, the tasks that are currently in this issue are for introducing new data. I think that the tasks from the "remove data from sgid" template should also be added since this is essentially deleting old tables and introducing new ones.

I think scotts idea is a good one, and since the majority are in agreement, we should create an intro and a deprecation issue to create overlap of the datasets to allow for the transition.

The web api will need to be updated since those tables get a lot of requests.

image

https://elections.utah.gov/map/district-maps will require updates. We will need to coordinate with the lt gov to make the required changes to forklift, mapserv, and whatever other items they have going on.

I'm assuming vista will also need to be involved in the disruption.

Maybe the disruption is moot since all of these dependencies will need to be updated to the newest boundary data anyway?

gregbunce commented 2 years ago

i'll mention it up again as an alterative - we could leave the table names as is, in Internal, and only re-name the public-facing data (via the meta agol itmes table).

would that be less disruptive?

we'd still have to deal with the open sgid table rename disruption, but agol would be stable, right?

ideally, we should try to preserve the agol itemID either way (keeping the urls stable)

mheagin commented 2 years ago

Not sure about the Vista app, right now when I check it I only see the precincts/VistaBallotAreas shown. I will check with Mark M and find out for sure. I will ask about the district-maps updates too.

gregbunce commented 2 years ago

@mheagin , i'm sure steve or scott can verify where those layers are coming from. for the district maps, it looks like mapserv image

mheagin commented 2 years ago

Not sure if @ZachBeck makes those or not. or if anyone has talked to him about it> https://elections.utah.gov/map/district-maps

steveoh commented 2 years ago

@mheagin , i'm sure steve or scott can verify where those layers are coming from. for the district maps, it looks like mapserv image

I linked to the services in my last comment but here are more direct links.

i'll mention it up again as an alterative - we could leave the table names as is, in Internal, and only re-name the public-facing data (via the meta agol itmes table).

The web api uses the open sgid for queries so table changes there would require a change but it is a quick deployment.

github-actions[bot] commented 2 years ago

:wave:, make a decision on this

gregbunce commented 2 years ago

reading through the thread it sounds like there's enough support to rename the existing layers - not only match the new layers but also clarify the effective dates in the title.

steve's comments are solid and they should be considered and worked out before we move forward.

i don't believe there is a huge rush on this rename. i'd rather go slow and do it right.

so, for me, the question remains, do we rename the layers in Internal and watch everything bubble up (and break things) from there or do we keep the names existing names in the Internal and only rename the public-facing stuff (via the metatable's public name filed)?

steveoh commented 2 years ago

so, for me, the question remains, do we rename the layers in Internal...

This goes against our policy and shouldn't be a question.

gregbunce commented 2 years ago

i'll rephrase and say remove the current layers and re-add them with new names. aka; deprecate and add.

I'm leaning toward renaming the public-facing stuff and leaving the names in Internal.

steveoh commented 2 years ago

remove the current layers and re-add them with new names. aka; deprecate and add.

A rename is a delete and an add. It should be treated as an add and deprecate. We should allow the two datasets to live side by side for the two weeks that we call out in our removal policy.

If this decision isn't black and white we should update our policies to make it so.

gregbunce commented 2 years ago

to recap... our policy does not allow us to rename a layer by changing its name in the metastable (via the AGOL_PUBLISHED_NAME field). The policy suggests that to rename a layer we must add a new layer (with the desired name) and then to deprecate the existing layer.

This is based on the fact that the open sgid contains DB tables and these names should match the layer names in agol - and changing a table name in open sgid is clearly a breaking change. However, a name change in agol is not a breaking change, as the URL, etc. stays the same.

would that be the underlying logic used for name changes in our policies?

steveoh commented 2 years ago

I think that sums it up well. To top it all off, it would be a breaking change in open data since the url is based on the agol name. Basically the same situation with the US congress districts that we are fixing.

gregbunce commented 2 years ago

good point on the open data url (using the agol name). that one slipped my memory.

steveoh commented 2 years ago

conductor results for tasks - 167

check status
@gregbunce has completed 0 out of 10 tasks :no_entry:
@steveoh has completed 0 out of 4 tasks :no_entry:
@stdavis has completed 0 out of 1 tasks :no_entry:
@jacobdadams has completed 0 out of 1 tasks :no_entry:
@rkelson has completed 0 out of 1 tasks :no_entry:
gregbunce commented 2 years ago

/remind me on 11/15/2022 to revisit this issue and make separate porter issues

github-actions[bot] commented 2 years ago

@gregbunce set a reminder for 11/15/2022

gregbunce commented 2 years ago

we can move forward with 2002 data now as this is not being in the interim for re-predicting purposes. deprecate these layers and change the name as we move them to 'shelved' (shelved = they only live agol)

steveoh commented 2 years ago

Is the plan to close this issue and spread it into more specific issues?

gregbunce commented 2 years ago

Yeah, that makes the most sense.

On Tue, Dec 7, 2021, 6:15 PM steveoh @.***> wrote:

Is the plan to close this issue and spread it into more specific issues?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/agrc/porter/issues/167#issuecomment-988402087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEA7QTH57BECLYDP7SZJYPTUP2WSLANCNFSM5IRPVCDA .

gregbunce commented 2 years ago

I'm closing this issue. I will be creating a separate issue that will rename each of these 4 layers in Jan 2023 when we move these layers to AGOL as 'shelved'. We chose Jan 2023 b/c they are in use until then (these layers are being used through the November 2022 elections and also through January 2023 as the newly elected officials will then populate the new districts (aka: the 2022_to_2032 districts)).

mheagin commented 2 years ago

Just want to remind everyone, according to Mark and the elections office, that 2012 data should remain available to the public until we have new elections. It does reflect what the current elected officials represent. Not sure how people hit that data for the "find your legislature" and such app's and we don't want to leave anyone high and dry.

gregbunce commented 2 years ago

i have a calendar reminder in by google calendar and in the agrc employee calendar to pick this up in Jan 2023. Also, to keep us on track, here are the notes on what needs to be done in Jan 2023.