Unit

Definition

A Unit models the presence, location and approximate extent of a space. Extent may be characterized by:

A barrier, such as a wall
A physical boundary, not necessarily delimitted by a barrier, but beyond which traversal is not expected, such as the edge of a train platform
A legal instrument, such as the description of a gross leasable area

Feature Structure

Unit objects are Feature objects
Unit objects MUST have an "id" member with a FEATURE-ID value
Unit objects MUST have a "feature_type" member with the value "unit"
Unit objects MUST have a "geometry" member with a POLYGONAL value

Property Keys

Property	Type	Description
`category`	`UNIT-CATEGORY`	The category that best describes the function of the physical Unit
`restriction`	`null` or `RESTRICTION-CATEGORY`	The category that best describes a restriction that applies to the entire physical Unit
`accessibility`	`null` or JSON array of `ACCESSIBILITY-CATEGORY`	Indicates the type of accessibility provided by the Unit to a pedestrian that experiences disabilities
`name`	`null` or `LABELS`	The name of the Unit as declared by the Venue Organization
`alt_name`	`null` or `LABELS`	Alternative name for the Unit that may be recognized by the Venue Organization
`level_id`	`LEVEL-ID`	Unique identifier of the Level feature the Unit possesses a spatial relationship with
`display_point`	`null` or `DISPLAY-POINT`	The curated location to use as the point-based representation of the Unit

Example

{
  "id": "11111111-1111-1111-1111-111111111111",
  "type": "Feature",
  "feature_type": "unit",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [100.0, 0.0],
        [101.0, 0.0],
        [101.0, 1.0],
        [100.0, 1.0],
        [100.0, 0.0]
      ]
    ]
  },
  "properties": {
    "category": "room",
    "restriction": null,
    "accessibility": null,
    "name": {
      "en": "Ball Room"
    },
    "alt_name": null,
    "display_point": {
      "type": "Point",
      "coordinates": [ 100.0, 1.0 ],
    },
    "level_id": "22222223-2222-2222-2222-222222222222"
  }
}

Property Capturing Rules

DISPLAY-POINT

MAY be present to explicitly indicate (and symbolize) the location of a point-based representation of a Unit
MAY be present to explicitly indicate (and symbolize) a collection of Units possessing the same category that touch. (Illustration)
MUST be within the boundary of the Unit

NAME, ALT_NAME

When a Venue Organization aligns their internal classification scheme to name and alt_name, the following considerations SHOULD be borne in mind:
- A functional preference to "surface" one label over another when both name and alt_name store values
- A functional preference to "surface" at least one label when one or other property does not store a value
- Functional support for searching the content of both properties but only returning the label that is preferred
name and alt_name SHOULD NOT duplicate content present in another layer
name MUST be formatted consistently throughout the layer and across all deliveries when this is the expected pedestrian "experience"
name and alt_name SHOULD NOT store information of a type that supports addressing unless this is a coincidence
- A Venue Organization SHOULD use unit in Address. Then, position an Anchor inside the Unit and reference the Address via an Anchor point
- When it is a coincidence, then the label MAY be the same as the unit in Address

RESTRICTION

When the general public is expected to visit a physical Venue, but only a subset of that general public is permitted entry to a space, then a Unit SHOULD possess a restriction
“employeesonly” SHOULD be present when a Venue Organization deliberately wishes to map a non-public area of the physical Venue
“restricted” SHOULD be used when entry to an area is restricted to an authorized sub-set of the general public. (Illustration)
“employeesonly” SHOULD NOT be used when the general public, as a matter of general operating procedure, is not expected to visit the Venue. In this situation, the Venue is only visited by a predictable subset of the general public. (Illustration)
A "nonpublic" Unit SHOULD NOT possess a restriction

Geometry Capturing Rules

See also: Unit Illustrative Guidance

Unit Extent

Horizontal positional accuracy MUST be within tolerance
A physical, vertical barrier SHOULD be simplified. (Illustration)
- A Unit boundary MAY approximate an imaginary line running down the center of a physical, vertical barrier
- Instead of an imaginary line, a Unit boundary MAY follow source data that models the "face" of a physical, vertical barrier

Comment: Good judgement should be exercised when selecting lines in source data to mitigate for any disproportionate impact upon a Unit's internal area measurement.

The simplification of physical, vertical barriers MUST occur in all complex architectural scenarios such as:
- Multiple wall intersections
- Wall/column combinations
A Unit that models a space expected to be surveyed MUST NOT possess a boundary whose spatial location is arbitrary and effect an outcome where the "blue dot" position is unrealistic.
Physical, vertical barriers that are architecturally significant in appearance and/or size MAY be modeled as explicit geometries instead of being simplified
- A network of floor-to-ceiling walls or an integrated system of walls and columns MUST be modeled as a "structure" Unit. (Illustration) To more specifically describe the material nature of the physical, vertical barrier, the following Unit category types may be used:
  - "brick"
  - "concrete"
  - "drywall"
  - "glass"
  - "wood"
- A floor-to-ceiling standalone column MUST be modeled as a "column" Unit. (Illustration)
Symmetrical difference MUST NOT exist:
- Among Units that reference the same Level
- Between the union of Units and their referenced Level
An Opening MUST be covered by a Unit boundary where the modeled entrance exists

Category Specific Rules

`"nonpublic"`

A space that contains non-public areas SHOULD be modeled as a "nonpublic" Unit
An entire floor that is non-public SHOULD NOT be modeled as one or more "nonpublic" Unit. By extension, the floor SHOULD NOT be modeled as a Level
A space that is non-public which is occupied by Venue personnel that exchange goods/services with a pedestrian MAY be excluded from the "nonpublic" Unit's extent when doing so would improve the map's aesthetic qualities. (Illustration)
"nonpublic" Units that touch and reference the same Level SHOULD be merged when:
- The Venue Organization derives no business value from maintaining separate "nonpublic" Units
- Map application performance is improved when multiple database records are merged
- The map's aesthetic quality is improved. (Illustration)
A Unit of dissimilar category MAY be surrounded by a "nonpublic" Unit when:
- The Unit models a vertical traversal capability which "passes" through the Level, where the "nonpublic" Unit is located, to another Level
Comment: A Venue Organization should consider the business value of a map of a Level through which a pedestrian can only vertically pass. The value of a Unit on such a Level is likely negligible.
- The Unit is one of a collection of Units, but at least one Unit or Amenity models a vertical traversal capability to the Level
An Opening SHOULD NOT be within the boundary of a Unit whose category is "nonpublic"

Comment: Occasionally, this is an illusion that is the consequence of the flattening of a 3-dimensional space into a 2-dimensional view. An Opening will appear to model an entrance to a "nonpublic" Unit when, in fact, the Opening is a "threshold" across which the pedestrian transitions to a different Level (above or below). This is analogous to a pedestrian pathway that physically passes under (or over) a non-public space.

`"opentobelow"`

A vertical column of air MUST be modeled as an "opentobelow" Unit when it is physically visible. (Illustration)

Although "...physically visible.", it is assumed that when this Unit touches another Unit category, the boundary models a physical barrier, but not a barrier that is floor-to-ceiling.
Shafts and ducts that support building operational functions, which are typically hidden from view, MUST NOT be modeled as an "opentobelow" Unit
- Shafts and ducts MUST be modeled as "nonpublic" Units
An Opening SHOULD NOT be within the boundary of a Unit whose category is "opentobelow"

Comment: Occasionally, this is an illusion that is the consequence of the flattening of a 3-dimensional space into a 2-dimensional view.

`"column"`

A Venue Organization that captures physical, vertical barriers as explicit geometries MUST capture a column that is structurally integrated into a physical wall as a "structure" Unit. (Illustration)
A floor-to-ceiling standalone column captured as a "column" Unit SHOULD possess an area measurement that exceeds 0.09 square meters (exceeds 0.9 square feet). (Illustration)

Comment: The survey process is reliant upon the availability of mapped objects for orientation amongst real-world physical objects. Certain features serve as a "reference network." This reference network, in combination with other mapped objects, can be leveraged to help trouble-shoot and communicate unexpected map data issues, trouble-shoot data collection issues, and assess the performance of the location-based system. In general, "column" features are only necessary in areas that are expected to be surveyed.

Vertical Traversal Capabilities

Units that support vertical traversal capabilities are subject to the following additional restrictions.

`"elevator"`

Each physical elevator's floor area, in an elevator bank, MUST be modeled as an individual "elevator" Unit. (Illustration)
An instance of an "elevator" Unit MUST equal all other instances of the same Unit category on each Level where the presence of the same physical elevator is modeled
If the prior requirement cannot be satisfied, then overlap MUST be less than 10%
- Overlap or disjointedness is only allowable when an incline elevator is present

`"escalator"`

Each physical escalator MUST be modeled as an individual "escalator" Unit. (Illustration)
"escalator" Units that reference Levels that are only one (1) ordinal apart SHOULD:
- Touch.
- Exhibit perfect alignment in the physical direction of travel. (Illustration)
- Model approximately half the length of the physical object
If the prior requirement cannot be satisfied, then:
- Lengthwise, Units MAY be equal or overlap
- Alignment (offset) MAY exist in an amount no greater than 10%
"escalator" Units that reference Levels that are greater than one (1) ordinal apart MUST exhibit perfect alignment.
If the prior requirement cannot be satisfied, then:
- Alignment (offset) MAY exist in an amount no greater than 10%
The presence of a physical escalator between floors SHOULD NOT be modeled. (Illustration)
If source data shows an escalator covering other elements in source data that are expected to be modeled, then the extent of a "escalator" Unit SHOULD be curtailed to allow other physical objects to be modeled to the fullest extent possible
Neighboring escalators MUST be modeled as Units that touch. (Illustration)

`"movingwalkway"`

Each physical moving walkway MUST be modeled as an individual "movingwalkway" Unit
Physically adjacent moving walkways MUST be modeled as Units that touch. (Illustration)

`"ramp"`

A grade that supports a vertical traversal capability to a different Level SHOULD be modeled as a "ramp" Unit
A grade along the same floor (no vertical traversal capability to a different Level), MAY be modeled as a "ramp" Unit when they exist as an alternative to steps, mini-escalators and elevators. Else, the grade MUST be modeled as a "walkway" Unit. Illustration
Modeling a grade as a "walkway" Unit is preferable when the following are true:
- The Venue Organization derives no business value from capturing grades as individual "ramp" Units.
- The map application user "experience" is not diminished by their absence
- The map's aesthetic quality is enhanced by the presentation of a contiguous system of walkable areas
- The conscious, physical "experience" of the grade by a pedestrian, particularly among persons with disabilities, would likely elicit an emotional response that is no different in a circumstance where the grade had been captured as a "ramp", instead of a "walkway"
When a grade and a set of risers are structurally integrated, then the entire structure SHOULD be modeled as a "ramp" Unit. (Illustration)

`"stairs"`

A stairwell that supports a vertical traversal capability to a different Level MUST be modeled as a "stairs" Unit
Visible open space that extends vertically through the stairwell SHOULD be included within the “stairs” Unit. Else, it MAY be modeled as an “opentobelow” Unit
If source data shows a staircase and/or landing covering other elements in source data that are expected to be modeled, then the extent of a "stairs" Unit SHOULD be curtailed to allow other physical objects to be modeled to the fullest extent possible

`"steps"`

A set of steps along a pedestrian pathway, on the same floor (modeled as the same Level), MUST be modeled as a "steps" Unit when any of the following are true:
- The steps are unavoidable. A pedestrian must use them in order to reach an area
- The steps are architecturally significant. Modeling the physical object heightens cognitive recognition and improves the pedestrian's ability to relate the map view to the physical one when present in the Venue itself
- Modeling the steps as a "steps" Unit improves environmental awareness among pedestrians with a disability. This is especially important among persons with a sight disability that may rely upon map application vocalization of information about obstacles that lay in their direction of travel. (Illustration)

`"walkway"`

As a general rule, a "walkway" Unit MUST model a pathway whose design and intended purpose is to facilitate pedestrian movement through a Venue. (Illustration)
"walkway" Units that touch which reference the same Level SHOULD be merged when:
- A comparison of the physical characteristics generates no distinct differences
- A door or other physical barrier does not exist where "walkway" Units touch
- A physical door exists but modeling the door as an Opening offers no derivable benefit
Comment: A decision to not model entrances along a pathway should take into consideration the map application "experience." A possible negative "experience" might stem from a pedestrian's inability to judge their location on the map if the approach taken was to capture a pathway as a single contiguous Unit
"walkway" Units that touch SHOULD NOT be merged when:
- A physical door exists whose access is controlled
The presence of a pedestrian service/function along a pathway SHOULD not alter the modeling approach when the purpose of the pathway, in the majority, is to facilitate the movement of a pedestrian through the Venue. (Illustration)
When an area is interpreted as being equally a pedestrian destination and a pathway, then the area SHOULD be modeled as a "room" Unit. This modeling approach is preferable when:
- A comparison of the service/function of one area with another area reveals distinct differences in their associated descriptive properties
- Separation of distinct areas is facilitated by the presence of a physical, vertical barrier.
- A preference exists to enclose the "distinct differences"
When an area is equally a pedestrian destination and a pathway but the separation of areas is not facilitated by the presence of a physical, vertical barrier, then the area SHOULD be modeled as a "walkway" Unit. This modeling approach is preferable when:
- The primary function of the area is to support/contain pedestrian destinations. A secondary function of the area is to support pedestrian travel along an inferable pathway. (Illustration)
When neither pedestrian destinations nor pathways are inferable, then the area SHOULD be modeled as a "walkway" Unit. This modeling approach is preferable when area utilization is dynamic. Example: An Exhibition or Convention Center