| 30 | (Note this part is being implemented as we speak. Its design is not expected to be controversial. |
| 31 | It does not break or alter any existing functionality.) |
| 32 | |
| 33 | In order to support configuring and selecting regions: |
| 34 | * Move any region-specific configuration into gis_config. This currently means: |
| 35 | * A location representing a region (see following). |
| 36 | * The hierarchy labels, depth, and settings appropriate for that area. |
| 37 | (Language translation is not sufficient here. E.g we don't have "provinces" and "districts" |
| 38 | in the US but those are perfectly legal US English words. Different areas also have |
| 39 | different depths of hierarchy, and different choices about a "strict" hierarchy.) |
| 40 | * A flag for whether this gis_config represents a region. |
| 41 | * A label to use on a menu of regions. |
| 42 | * Already present in gis_config, and needed for region selection: |
| 43 | * Map center and zoom (so map can be positioned appropriately for the region). |
| 44 | * Generate a regions menu from the gis_config table. Add site config options to enable |
| 45 | the regions menu and specify a label for the menu head. |
| 46 | * The selected region persists for the session only (or until the user selects another |
| 47 | or clears the selection). |
| 48 | * Selecting a region records the associated gis_config in the session. |
| 49 | * To find the gis_config currently in effect look for it in these places in this order: |
| 50 | * In the session. |
| 51 | * The user's personal gis_config. |
| 52 | * The generic gis_config. |
| 53 | |
| 54 | |
| 55 | The "region location" associates specific locations to the region. |
| 56 | There are four main ways a region location can specify this association: |
| 57 | * Specific locations can have the region location as an ancestor. |
| 58 | E.g. the region might be a city. Specific locations can be assigned a parent in the hierarchy. |
| 59 | |