Location catalog overview - Revision history

Admin at 21:04, 23 November 2015

2015-11-23T21:04:21Z

Pascal: /* Locations types */

2014-11-05T20:06:49Z

‎Locations types

Pascal: /* Locations types */

2014-11-05T20:06:23Z

‎Locations types

Pascal: /* Location hierarchy */

2013-12-27T22:07:06Z

‎Location hierarchy

Pascal: /* Related documents */

2013-12-22T23:46:08Z

‎Related documents

Pascal: /* Related documents */

2013-12-22T23:37:04Z

‎Related documents

Pascal: /* Related 'How-to' documents */

2013-10-23T00:24:31Z

‎Related 'How-to' documents

Pascal: /* Related 'How-to' documents */

2013-10-22T23:06:53Z

‎Related 'How-to' documents

Pascal: /* Related 'How-to' documents */

2013-10-22T22:38:26Z

‎Related 'How-to' documents

Pascal: Pascal moved page Location catalog to Location catalog overview: Better title

2013-10-22T01:37:47Z

Pascal moved page Location catalog to Location catalog overview: Better title

@@ Line 1: / Line 1: @@
 __NOTOC__
-The location catalog is the backbone of the geospatial InfoEx system. All observation entered into the InfoEx system need to be associated with a pre-defined location from your location catalog. This document gives a general overview of the location catalog functionality of the InfoEx application.
+The location catalog is the backbone of the geospatial InfoEx system. All observations entered into the InfoEx system need to be associated with a pre-defined location from your location catalog. This document gives a general overview of the location catalog functionality of InfoEx.
 ==Locations types==
@@ Line 13: / Line 13: @@
 *[[Location types and symbology#Route|Route]]
 *[[Location types and symbology#SkiRun|Ski run]]
-*[[Location types and symbology#ControlRoute|Control route]] (new in 2014-15)
+*[[Location types and symbology#ControlRoute|Control route]]
 *[[Location types and symbology#AvalanchePath|Avalanche path]]
 *[[Location types and symbology#WeatherSite|Weather site]]
@@ Line 21: / Line 21: @@
 ==Location hierarchy==
-Locations entered into the InfoEx system are organized in a location hierarchy. The location hierarchy implemented in the InfoEx system has a '''tree structure''' where a location can only have a single parent, but multiple children. Every location needs to be derived from a single parent location, except the operation area, which is the top parent location of a location catalog. To ensure meaningful location catalogs, there are numerous restrictions on what type of locations can be contained by other locations. See [[Location hierarchy]] for a detailed description of the supported relations.
+Locations entered into InfoEx are organized in a location hierarchy. The location hierarchy has a '''tree structure''' where a location can only have a single parent, but multiple children. Every location needs to be derived from a single parent location, except the operation area, which is the top parent location of a location catalog. To ensure meaningful location catalogs, there are numerous restrictions on what type of locations can be contained by other locations. See [[Location hierarchy]] for a detailed description of the supported relations.
 There are currently '''two main uses''' of the location hierarchy in the InfoEx application:
 * It helps to keep your location catalog tidy
-* It is used in the [[Observations module]] to pull previously entered observations into the workflow. Only observations associated with locations that are direct or indirect children of the location associated with the workflow are automatically presented for review and submission to the InfoEx.
+* It is used in the [[Observations module]] to pull previously entered observations into the workflow. Only observations associated with locations that are direct or indirect children of the location associated with the workflow are automatically presented for review and submission to InfoEx.
-The hierarchy in the location tree needs to be '''defined explicitly''' and it not directly derived from the geospatial information of the locations. This approach allows for a more flexible use of the location hierarchy. For example, a weather site that provides valuable observations for a forecast region can be made a child of this forecast region even if the site is not located within the forecast region.
+The hierarchy in the location tree needs to be '''defined explicitly''' and is not directly derived from the geospatial information of the locations. This approach allows for a more flexible use of the location hierarchy. For example, a weather site that provides valuable observations for a forecast region can be made a child of this forecast region even if the site is not located within the forecast region.
 ==Related documents==

@@ Line 13: / Line 13: @@
 *[[Location types and symbology#Route|Route]]
 *[[Location types and symbology#SkiRun|Ski run]]
-*[[Location types and symbology#ControlRoute|Control route]]
+*[[Location types and symbology#ControlRoute|Control route]] (new in 2014-15)
 *[[Location types and symbology#AvalanchePath|Avalanche path]]
 *[[Location types and symbology#WeatherSite|Weather site]]

@@ Line 13: / Line 13: @@
 *[[Location types and symbology#Route|Route]]
 *[[Location types and symbology#SkiRun|Ski run]]
 *[[Location types and symbology#AvalanchePath|Avalanche path]]
 *[[Location types and symbology#WeatherSite|Weather site]]

@@ Line 24: / Line 24: @@
 There are currently '''two main uses''' of the location hierarchy in the InfoEx application:
 * It helps to keep your location catalog tidy
-* It is used in the [[observation workflow module]] to pull previously entered observations into the workflow. Only observations associated with locations that are direct or indirect children of the location associated with the workflow are automatically presented for review and submission to the InfoEx.
+* It is used in the [[Observations module]] to pull previously entered observations into the workflow. Only observations associated with locations that are direct or indirect children of the location associated with the workflow are automatically presented for review and submission to the InfoEx.
 The hierarchy in the location tree needs to be '''defined explicitly''' and it not directly derived from the geospatial information of the locations. This approach allows for a more flexible use of the location hierarchy. For example, a weather site that provides valuable observations for a forecast region can be made a child of this forecast region even if the site is not located within the forecast region.

@@ Line 29: / Line 29: @@
 ==Related documents==
-* [[Location catalog overview]]
+{{PagesLocations}}
 [[Category:Locations]]

@@ Line 29: / Line 29: @@
 ==Related documents==
 * [[Adding locations to the location catalog]]
 * [[Deleting locations from the location catalog]]
 * [[Changing the hierarchy among your locations]]
 * [[Searching for a location in the location catalog]]
 [[Category:Locations]]

@@ Line 29: / Line 29: @@
 ==Related 'How-to' documents==
-* [[How to add locations to the location catalog]]
+* [[Adding locations to the location catalog]]
-* [[How to delete locations from the location catalog]]
+* [[Deleting locations from the location catalog]]
-* [[How to edit locations of your operation]]
+* [[Editing locations in the location catalog]]
-* [[How to create a hierarchy among your locations]]
+* [[Creating a hierarchy among your locations]]
-* [[How to search for a location in the location catalog]]
+* [[Searching for a location in the location catalog]]
 [[Category:Locations]]

← Older revision	Revision as of 01:37, 22 October 2013
(No difference)