Changes between Version 9 and Version 10 of BluePrintRegionsAndIncidents

Timestamp:

02/16/11 17:14:12 (14 years ago)

Author:

Pat Tressel

Comment:

--

BluePrintRegionsAndIncidents

@@ -36 +36 @@
   * A location representing a region (see below).
   * The hierarchy labels, depth, and settings appropriate for that area.
-    (Language translation is not sufficient here. E.g we don't have "provinces" and "districts"
-    in the US but those are perfectly legal US English words. Different areas also have
-    different depths of hierarchy, and different choices about a "strict" hierarchy.)
+    (Language translation is not sufficient here. E.g we don't have "provinces"
+    and "districts" in the US but those are perfectly legal US English words.
+    Different areas also have different depths of hierarchy, and different
+    choices about a "strict" hierarchy.)
     Hierarchy settings are:
-   * "Strict" -- specific locations can only be attached to the hierarchy at its maximum level.
-   * "Parent required" -- specific locations need a parent location selected from the hierarchy.
-     (This is used to assist forming regions in the absence of boundary data -- see below.)
+   * "Strict" -- specific locations can only be attached to the hierarchy at
+     its maximum level.
+   * "Parent required" -- specific locations need a parent location selected
+     from the hierarchy.
+     (This is used to assist forming regions in the absence of boundary
+     data -- see below.)
   * A flag for whether this gis_config represents a region.
   * A label to use on a menu of regions.
@@ -84 +88 @@
    location group to be a member of a location group. That's not required, though.)
 
-If the test for whether a location is in a region is expensive (e.g. if it uses
-polygon overlap), we may want to cache the membership (similar to caching the
-location's hierarchy path). A location can belong to more than one region, so
-this would be a list of regions (specified by their region location ids). Would
-need to record both positive and negative results, i.e. if we test a location
-against a region and find it's not in that region, we need to record that to
-avoid redoing the test. The cache would be invalidated if the location's
-parentage or lon, lat changes.  Invalidating region test results if a region's
-scope changes (e.g. its border is changed, or a group's membership changes, or
-if the hierarchy is changed) needs careful consideration to avoid expensive
-database operations. Fortunately, regions are not expected to be changed frequently.
+If the test for whether a location is in a region is expensive (e.g. if it uses polygon overlap), we may want to cache the membership (similar to caching the location's hierarchy path). A location can belong to more than one region, so this would be a list of regions (specified by their region location ids). Would need to record both positive and negative results, i.e. if we test a location against a region and find it's not in that region, we need to record that to avoid redoing the test. The cache would be invalidated if the location's parentage or lon, lat changes.  Invalidating region test results if a region's scope changes (e.g. its border is changed, or a group's membership changes, or if the hierarchy is changed) needs careful consideration to avoid expensive database operations. Fortunately, regions are not expected to be changed frequently.
+
+We may also want to cache the gis_config currently in effect in the session in any case, not just if it was a region gis_config selected from the menu.
 
 === Incident discussion ===