Needed layers and forms in QGIS

[SannaJokela]

Forms and layers in QGIS for land use plans

Most of the relations and tables should be hidden. Automatically updated information marked with *.

Land use plan (asemakaava tai yleiskaava)

Border (asemakaava tai yleiskaava)

• name (nimi)
• area (automated)* (pinta-ala)
• language (list) (kieli)
• land use plan type (list) (kaavatyyppi)
• phase (list) (vaihe) - process phase (list) ==> this has been dropped from the database model (prosessin vaihe)
• legally binding/obsolete (lainvoimaisuuspvm/kumoamispvm) date should be always changed if process phase is changed relatively (values: lainvoimainen/kumottu)(*?)
• begin/end lifespan (aloituspvm/poistamispvm) (automated on creation or delete)*
• land use specification(s) ==> relation to list of different land use specifications

Additional information to the Border (separate sheet?)

• background map (taustakartta) ==> relation (date, name, uri)
• document (dokumentti) ==> relation (id, type, language)
• numeric values (numeerinen_arvo)==> relation (type, value)
• theme (teema)(only for general land use plan types)

Zoning element (maankayttoalue)

• Border ==> relation to the Border (list of land use borders)
• name
• area (automated)*
• creation date (luontipvm) (automated)*
• inherited (peritytynyt_kohde) (yes/no) (if data is inherited from another source) ==> if yes, link to the datasource
• zoning class (maankayttoluokka) (list)
• land use specification(s) (kaavamaarays)==> relation to list of different land use specifications
• numeric values (numeerinen_arvo) ==> relation (type, value)
• theme (teema) (only for general land use plan types)

Sub-regions (osa_alue, only within asemakaava)

• Border ==> relation to the Border (list of land use borders)
• area (automated)*
• creation date (automated)*
• inherited (yes/no) (if data is inherited from another source) ==> if yes, link to the datasource
• sub-region type (osa_alue_tyyppi) (list)
• land use specification(s) ==> relation to list of different land use specifications
• numeric values ==> relation (type, value)
• theme (only for general land use plan types)

Land use planning elements (kaavaelementti.geom.point, kaavaelementti.geom.line, kaavaelementti.geom.polygon)

• Border ==> relation to the Border (list of land use borders)
• creation date (automated)*
• yes/no (if data is inherited from another source) ==> link to the datasource?
• land use element type (kaavaelementti_tyyppi) (list)
• numeric value ==> relation (type, value)
• land use specification(s) ==> relation to list of different land use specifications
• numeric values ==> relation (type, value)
• theme (only for general land use plan types)

Land use specification (no geometry), kaavamaarays

• creation date (automated)* -title (kaavamaaraysotsikko)
• specification text (kaavamaaraysteksti)
• indication if the specification is linked to the Border or other land use elements

Questions

• If the land use planner needs to add a new code to some of the code lists, how to do this? Dragging the layer to the layer list? ==> Let's add a group of code lists to the map layer list that can be modified by the user
• Modifer/user information should probably be taken into account (not in the database model yet)

[mvaaltola]

@SannaJokela

legally binding/obsolete date should change process phase is chosen*

What does this mean in practice? Should changing the process phase of an existing feature automatically:

1. set the legally obsolete date (and lifespan end date?) of the feature to current date
2. create a new feature with the new process phase
3. set the legally binding date of the new feature to current date

Is this the intended behaviour? It can be done with a database trigger if needed.

[mvaaltola]

Modifier needs to be created (does it need to be in the schema as well?)

What does this mean?

[mvaaltola]

If the land use planner needs to add a new code to some of the code lists, how to do this? Dragging the layer to the layer list?

I believe we should keep the layers from tables in koodistot and kaavan_lisatiedot schemas visible in QGIS for this reason. They can be grouped in their own layer groups so they don't get in the way but are still available. What do you think?

Yes probably so, but they should be populated with the existing values.

[SannaJokela]

Modifier (land use planner)

Modifier needs to be created (does it need to be in the schema as well?)

What does this mean?

==> Where to store information about the user/modifier? It was not taken into account in the original detailed land use plan.

[SannaJokela]

@SannaJokela

legally binding/obsolete date should change process phase is chosen*

What does this mean in practice? Should changing the process phase of an existing feature automatically:

1. set the legally obsolete date (and lifespan end date?) of the feature to current date
2. create a new feature with the new process phase
3. set the legally binding date of the new feature to current date

Is this the intended behaviour? It can be done with a database trigger if needed.

If the land use plan becomes obsolete (not valid anymore, this is decided by the land use planner by clicking the correct value from the process list), the date (obsoletedate / kumoamispvm) should probably be assigned automatically. But then again, the date might be different from the current date... So maybe no automation needed in this case in the end. Or should we have it?

Process when the land use plan becomes valid / legally binding

1. Land use planner receives information that the land use plan has become valid and chooses the correct value from the process list
2. Voimaantulopvm/ legally_binding_date should be changed also

Process when the whole land use becomes invalid/obsolete/kumottu:

1. Land use planner receives information that the land use plan as a whole in hand has been decided to become obsolete (kumottu) and changes the process list value to obsolete.
2. The land use planner chooses the date when the land use plan has become obsolete (kumoamispvm/endoflispanpvm.
3. He/She updates the document that have the additional information

Process when a part of the land use plan (a feature) becomes invalid/obsolete/kumottu): (I don't know if this is possible with the data base model yet)

1. One or several zoning elements become obsolete, land use planner changes their process step value
2. Land use planner changes the obsolete date for the selected land use elements

[mvaaltola]

Modifier (land use planner)

Modifier needs to be created (does it need to be in the schema as well?)

What does this mean?

==> Where to store information about the user/modifier? It was not taken into account in the original detailed land use plan.

This needs to be included in the schema in order to be persistent. I'll create an issue on this in the main qaava repository.

[SannaJokela]

Updated the issue: added numeric values and theme (for general land use plan only).

[Joonalai]

I will close this for now, since layers are handled in the main repository.