| 1 | | == Feature Layers == |
| 2 | | Internal Features can be displayed on the Map. |
| | 1 | = Feature Layers = |
| | 2 | * A 'Feature' is a Resource Record which has a Lat/Lon available. |
| | 3 | * ~~Features can be Points, Lines or Polygons~~ |
| | 4 | * ~~Features can be exported in KML/GPX/etc~~ |
| | 5 | * Need to update S3XRC for GPS symbol detection when !FeatureClass allocation changes |
| | 6 | * Need to update gis.get_marker() when !FeatureClass allocation changes |
| | 7 | * Features can be added to the Map |
| | 8 | * A Feature Layer is a query of Features |
| | 9 | * Resource |
| | 10 | * Filtered |
| | 11 | * Resource.Category (Report/Incident table, Missing Persons, L0->L3 in gis_location table) |
| | 12 | * Collection of Resources <- is this required? |
| | 13 | * New gis_landmark table can have Transport category for Port/Airport/Railway sub_categories |
| | 14 | * Features can be removed from the map or moved on the map interactively. |
| | 15 | * To do this via a single set of Controls means having a single Vector Layer (or having to manually select the active layer!). |
| | 16 | * Build up this Vector Layer from multiple Feature Layers |
| | 17 | * In order to be able to dynamically enable/disable individual Feature Groups whilst viewing the map, we need to write a custom layer switcher which refreshes the whole Features Layer client-side upon changes. |
| | 18 | * ~~User can define which layers should be selectable/enabled-by-default in the Situation Mapping layer switcher.~~ |
| | 19 | * This list is personalisable. |
| | 20 | * move from layer definitions to gis_config |
| | 21 | * Have 1->M for Feature_Layers for available. |
| | 22 | * Attribute of visible stored in a separate multiple field. |
| | 23 | * Combine with special widget? |
| 4 | | These features can be Points, Lines or Polygons (hence we need to use the OL Vector Features, not plain Features). |
| 5 | | |
| 6 | | Features can be added to the Map, removed from the map or moved on the map interactively. |
| 7 | | |
| 8 | | To do this via a single set of Controls means having a single Features Layer. This layer can be built up out of multiple Feature Groups. |
| 9 | | |
| 10 | | In order to be able to dynamically enable/disable individual Feature Groups whilst viewing the map, we need to write a custom layer switcher which refreshes the whole Features Layer upon changes. |
| 11 | | |
| 12 | | We need to use the Cluster Strategy to have nearby features aggregate at low zoom levels (& prevent performance issues) |
| 13 | | |
| 14 | | === Feature Classes === |
| 15 | | Feature Classes can (optionally) define the Marker used to render a Feature. |
| 16 | | |
| 17 | | These also provide the information for the popup when a Marker is selected.[[BR]] |
| 18 | | - this can contain fields from the original tables &/or an Edit button to enable editing those details. |
| 19 | | |
| 20 | | === Feature Groups === |
| 21 | | A Feature Group can be a Feature Class (e.g. 'Shelters' or 'Organisations') or can be a custom query. |
| 22 | | |
| 23 | | (These same Feature Groups can also be used to publish data as GeoRSS or KML or download as GPX or KML) |
| 24 | | |
| 25 | | Feature Groups to Features requires a Many-to-Many table: |
| 26 | | * http://groups.google.com/group/web2py/browse_thread/thread/70273ee7ba826a59 |
| 27 | | * http://groups.google.com/group/web2py/browse_thread/thread/582863bdd056bd7b |
| 28 | | |
| 29 | | === Markers === |
| | 25 | == Markers == |
| 37 | | [wiki:BluePrintGISMarkers Markers BluePrint] |
| | 39 | == Popups == |
| | 40 | Clicking a Feature should bring up a Popup |
| | 41 | * This can be a URL to load (flexible, but slow) however, if not provided, the default is: |
| | 42 | * Loaded into the map during main load: no server-side calls |
| | 43 | * Header should be found from a set of common options (name/code) |
| | 44 | * All the list_fields with their labels |
| | 45 | * A link to open the record in a new tab |
| | 46 | Clicking a Cluster should bring up a Popup |
| | 47 | * a list of the features within the cluster |
| | 48 | * each list item is hyperlinked to bring up the Feature's Popup (as well?) |
| 42 | | === Storage === |
| | 53 | == Implementation == |
| | 54 | === Option A (preferred) === |
| | 55 | Hardcode the link between !FeatureClass & Resource (with optional category, e.g. for 'Report/Incident' table) |
| | 56 | * Add optional category_field/category_value columns to the feature_class table |
| | 57 | * If wanting feature-specific markers then add marker_id to resource tables (by bundling with location_id) |
| | 58 | * Replace feature_group table with feature_layer table |
| | 59 | * fields: |
| | 60 | * name |
| | 61 | * resource (used to populate the query field via an 'onvalidation') |
| | 62 | * filter_field (optional. used to populate the query field via an 'onvalidation') |
| | 63 | * filter_value (optional. used to populate the query field via an 'onvalidation') |
| | 64 | * query (hidden behind 'Advanced' button?) |
| | 65 | * comments |
| | 66 | === Option B === |
| | 67 | !FeatureClass is an attribute of the link table |
| | 68 | * location_id extended to include feature_class_id (& marker_id) fields |
| | 69 | * => a Feature Group cannot be a collection of Feature Classes since we can't trawl through all resources to see if any of them have been tagged for this FC |
| | 70 | |
| | 71 | == Storage == |
