Changes between Version 9 and Version 10 of BluePrintRegionsAndIncidents


Ignore:
Timestamp:
02/16/11 17:14:12 (11 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintRegionsAndIncidents

    v9 v10  
    3636  * A location representing a region (see below).
    3737  * The hierarchy labels, depth, and settings appropriate for that area.
    38     (Language translation is not sufficient here. E.g we don't have "provinces" and "districts"
    39     in the US but those are perfectly legal US English words. Different areas also have
    40     different depths of hierarchy, and different choices about a "strict" hierarchy.)
     38    (Language translation is not sufficient here. E.g we don't have "provinces"
     39    and "districts" in the US but those are perfectly legal US English words.
     40    Different areas also have different depths of hierarchy, and different
     41    choices about a "strict" hierarchy.)
    4142    Hierarchy settings are:
    42    * "Strict" -- specific locations can only be attached to the hierarchy at its maximum level.
    43    * "Parent required" -- specific locations need a parent location selected from the hierarchy.
    44      (This is used to assist forming regions in the absence of boundary data -- see below.)
     43   * "Strict" -- specific locations can only be attached to the hierarchy at
     44     its maximum level.
     45   * "Parent required" -- specific locations need a parent location selected
     46     from the hierarchy.
     47     (This is used to assist forming regions in the absence of boundary
     48     data -- see below.)
    4549  * A flag for whether this gis_config represents a region.
    4650  * A label to use on a menu of regions.
     
    8488   location group to be a member of a location group. That's not required, though.)
    8589
    86 If the test for whether a location is in a region is expensive (e.g. if it uses
    87 polygon overlap), we may want to cache the membership (similar to caching the
    88 location's hierarchy path). A location can belong to more than one region, so
    89 this would be a list of regions (specified by their region location ids). Would
    90 need to record both positive and negative results, i.e. if we test a location
    91 against a region and find it's not in that region, we need to record that to
    92 avoid redoing the test. The cache would be invalidated if the location's
    93 parentage or lon, lat changes.  Invalidating region test results if a region's
    94 scope changes (e.g. its border is changed, or a group's membership changes, or
    95 if the hierarchy is changed) needs careful consideration to avoid expensive
    96 database operations. Fortunately, regions are not expected to be changed frequently.
     90If 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.
     91
     92We 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.
    9793
    9894=== Incident discussion ===