Level

Definition

A Level models the presence, location and approximate physical extent of a floor area in:

  • A physical building where the Level's extent is expected to be analogous to the surface (facade) of the physical building at the height where the floor is positioned
  • An outdoor environment that is functionally inseparable from the physical Venue

Comment: The modeling of multiple integrated buildings, with both integrated and non-integrated floor arrangements is a non-trivial undertaking. IMDF does NOT offer definitive guidance that is capable of responding to all architectural scenarios. IMDF, instead, offers guidance that is generally applicable.

The objective of IMDF is to provide guidance with respect to the modeling of ground truth conditions. A Level is NOT expected to possess a form that makes it immediately amenable for rendering in a map application. Additionally, IMDF is not expressly concerned with cartographic requirements or aesthetic rules, though rules do, to the extent possible, take these needs into consideration.

Feature Structure

  • Level objects are Feature objects
  • Level objects MUST have an "id" member with a FEATURE-ID value
  • Level objects MUST have a "feature_type" member with the value "level"
  • Level objects MUST have a "geometry" member with a POLYGONAL value

Property Keys

Property Type Description
category LEVEL-CATEGORY The category that best describes the function of the physical Level
restriction null or RESTRICTION-CATEGORY The category that best describes a restriction that applies to the entire physical Level
outdoor true or false If true, indicates that the Level feature is physically located outside of a building
ordinal INTEGER The Level feature's "stacking" position, relative to others (if present)
name LABELS The name of the Level as declared by the Venue Organization
short_name LABELS The short name of the Level as declared by the Venue Organization
display_point null or DISPLAY-POINT The curated location to use as the point-based representation of the Level
address_id null or ADDRESS-ID ID reference to Address record
building_ids null or JSON array of BUILDING-ID Identity of the Building(s) the Level possesses an association with

Example

{
  "id": "11111111-1111-1111-1111-111111111111",
  "type": "Feature",
  "feature_type": "level",
  "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": "parking",
    "restriction": null,
    "ordinal": 0,
    "outdoor": false,
    "name": {
      "en": "Ground Floor"
    },
    "short_name": {
      "en": "1"
    },
    "display_point": {
      "type": "Point",
      "coordinates": [ 100.0, 1.0 ],
    },
    "address_id": null,
    "building_ids": ["2222222-2222-2222-2222-222222222222"]
  }
}

Property Capturing Rules

ADDRESS_ID

  • SHOULD reference an Address when a Level possesses a postal address that is dissimilar from a postal address associated with other floors within the same physical building

Comment: The absence of a reference to an Address implies that the Building Address is applicable to the Level. If the Building does not reference an Address, then the Venue's referenced Address is implied as being applicable to the Building and each related Level.

BUILDING_IDS

  • A Level that models an environment that is physically located inside a building MUST reference the Building
  • A Level that models an environment that is physically located outside a building but which is, unequivocally, structurally a part of a building, MUST reference the Building. (Illustration)
  • A Level that models an environment that is physically located outside a building but which is, unequivocally, not structurally a part of a building SHOULD NOT reference a Building. (Illustration)
  • A Level that models a floor that is physically shared among different buildings MAY reference more than one Building. (Illustration)

OUTDOOR

  • A Level that models an environment that is physically located inside a building MUST possess an outdoor value of false
  • A Level that models an environment that is physically located outside a building MUST possess an outdoor value of true
  • When a physical building's floor transitions from an indoor to an outdoor environment, then the outdoor environment MAY be included as part of the Level with outdoor = false when the following are true:
    • The outdoor environment's measured area is considered by the Venue Organization to be negligible
    • A map application's rendering of an indoor environment does not disorient the map application user when they are consciously aware that they are positioned outdoor

CATEGORY

  • A floor of a physical building that is dedicated, in part or in whole, to offering inter-venue transit SHOULD be modeled as a "transit" Level when:

    • Inter-venue transit is a service provided by the Venue. (Illustration)
    • One or more described Building is serviced by the inter-venue transit system
    • Conceptually, the calculated ordinal among Levels associated with each described Building where the inter-venue transit system is situated is dissimilar

    Modeling an inter-venue transit system holistically is problematic when it physically exists at different relative heights among buildings. By explicitly signaling that a Level is a "transit" Level, each Level that possesses this category can, potentially, be aggregated to provide the complete map view of just the inter-venue transit system. Also, equally importantly, the view can be disaggregated to only present a view of a "transit" Level that is specific to a Building which might be more relevant in a given pedestrian context.

  • The "transit" concept MAY be used in a "Transit Station" Venue when a Venue Organization wishes to differentiate a Level that is solely dedicated to providing transportation services from another Level whose functional purpose is distinctly different

    The physical Venue may offer pedestrians an "experience" that is greater than just transportation services. The Venue Organization might, for example, want to leverage "transit" to cartographically differentiate between floors that exist which offer retail or entertainment services, from a floor that is dedicated to transit.

ORDINAL

  • The assigned ordinal MUST reflect the Level's position within the total range of floors that physically exist within a building
  • The "range of floors" that must be considered when assigning an ordinal MUST include floors that are not eligible for capture as Levels
  • The Level that models the lowest floor which supports ground-floor access to the physical building MUST have an ordinal equal to 0. (Illustration)
  • The Level that models a floor that is nearest to ground-floor, but is entirely below ground, MUST have an ordinal equal to -1
  • Ordinal values MAY run non-sequentially when there are intermediate floors within the physical building that are legitimately not a part of the modeling effort
  • A Building MAY be referenced by more than one Level with the same ordinal when it is a requirement to model floors of a physical building that possess different floor naming conventions. (Illustration)
  • The submission of a Level with ordinal 0 is OPTIONAL when the ground-floor is legitimately not a part of the physical Venue. More broadly, any floor that is legitimately not a part of the physical Venue is OPTIONAL for capture as a Level

Comment: When access to a physical Venue is dependent upon a legal right-of-way that exists on another floor, often the ground-floor, then modeling these floors is highly desirable. Else, the absence of this map data creates a disconnect between the external road/pedestrian network and the modeled indoor environment.

  • When a physical floor's height (relative to a vertical datum) is not constant, then the floor SHOULD NOT be modeled as separate Levels with different ordinal values when the following conditions are true:
    • A pedestrian is not conscious of a change in their vertical position relative to their personal consideration, measure and definition of a change in floors. (Illustration)
    • Modeling a floor as a single contiguous Level at the same ordinal does not encroach upon another physical floor with dissimilar descriptive properties at the same conceptual ordinal
    • The map application user experience is enhanced by the presentation of a single, contiguous view of the modeled reality

NAME, SHORT_NAME

  • General Rules
  • An outdoor Level on the ground-floor that has no official signage MUST possess a name and short_name
    • name SHOULD be the same as an indoor Level name
    • The chosen indoor Level name should be generic. Meaning, it must not be a name that is counterintuitive or so specific that a pedestrian might find the name to be illogical, unreasonable, or unexpected
    • short_name SHOULD be the same as an indoor Level short_name
  • When a Venue Organization cannot provide a floor name, then a Level MUST possess a name and short_name that is sourced from the Floor Naming Convention
  • A Level SHOULD possess a name/short_name combination that is unique among the Levels that reference the same Building
  • name and short_name among Level features MUST be captured consistently
    • Labels MUST not contain mixed case characters
    • Standard prefixes and/or suffixes, if present, MUST be formatted and implemented consistently
    • Labels among the layers, and among different Venue Organization deliveries, MUST be consistent and, preferably, follow a "standard" Venue Organization convention

Geometry Capturing Rules

See also: Level Illustrative Guidance

Level Extent

  • Horizontal positional accuracy MUST be within tolerance

  • The Venue Organization MUST consider the expected user experience with respect to the physical floors contained within and amongst buildings across the Venue. The Venue Organization SHOULD consider the following factors when conceptualizing an approach to modeling floors as Levels:

    • Expected map application behavior with respect to what floor(s) should be displayed across the entire Venue when a user has not explicitly selected any particular floor in any particular building
    • Expected map application behavior with respect to what floor should be displayed when a user selects an individual Building
    • Expected map application behavior among structurally related buildings when a user wishes to interact with a floor of one structurally integrated building described as a separate Building
    • Expected map application behavior when floors among different buildings possess physical parity but NOT ordinal parity
    • Conversely, expected map application behavior when floors among different buildings possess ordinal parity but NOT physical parity

  • If a floor spans a structurally integrated set of buildings, then a single, contiguous Level MAY model that floor when:

    • A calculated ordinal for each theoretical Level, if "split" to model a part of a floor in a portion of the physical building, would be the same
    • The name/short_name of each theoretical Level, if "split" to model a part of a floor in a portion of the physical building, would be the same
    • The category assigned to each theoretical Level, if "split" to model a part of a floor in a portion of the physical building, would be the same
    • From a pedestrian's perspective, no conscious differentiation could be elicited that may serve to distinguish their location inside one, versus the other, or between the physical buildings

  • When a physical building possesses a floor whose calculated ordinal would, conceptually, be dissimilar depending upon a pedestrian's standing position, then separate Levels MAY be created when:

    • The creation of separate Levels is facilitated by the existence of a party wall or other physical boundary

  • When a physical building possesses a floor whose calculated ordinal would, conceptually, be dissimilar depending upon a pedestrian's standing position, but no party wall or other physical boundary exists to facilitate Level definition, then separate Levels SHOULD NOT be created

    • The floor that is "closest" to ground SHOULD possess an ordinal of 0, and SHOULD NOT be "forced" to a negative integer. E.g., -1. (Illustration)

    Comment: The Venue Organization should consider "curating" Level data into a set of "presentation" layers, leaving the model of "ground-truth" intact. "Presentation" layers can express data characteristics necessary to support cartographic requirements and preferences.

  • The Level SHOULD possess an extent that is analogous to the surface (facade) of the physical building at the height where the modeled floor is positioned. (Illustration)

Level

  • MUST NOT overlap or lay within another Level when all the following are true:
    • Levels reference the same Building
    • Levels possess the same ordinal
  • When more than one Level is necessary to model physical floors of the same extent at different relative heights in the same referenced Building, and the physical building does not possess a facade whose extent is variable amongst floors, then:

  • If Levels cannot equal one another, for technical/practical reasons, then Levels MUST possess the following spatial characteristics:

    "...discernible..." - Symmetrical difference that is visible at a map scale of 1:500. This value translates into an allowance, in a cross-sectional direction, of up to 0.2 meters (8") of symmetrical difference.

  • Symmetrical difference MUST NOT exist between the union of Units and their referenced Level

Footprint

When Levels, of dissimilar ordinal, model a physical environment that is positioned on a sloped terrain and the Levels define, in part or in whole, ground-floor access, then portions of the Levels that are "exposed" at ground MUST be within a "ground" Footprint.

Opening

  • When an entrance between adjacent floors, modeled as separate Level features that touch, is expected to be modeled as an Opening, then:
    • Two (2) Openings SHOULD be present
    • One Opening SHOULD overlap the second Opening and possess the same category
    • Each Opening SHOULD be covered by its respective Unit and each Unit MUST be within its respective Level boundary. (Illustration)
    • Each Opening SHOULD reference its respective Level's id value
    • Symmetrical difference MUST NOT exist between the Levels where the Openings are positioned
  • A Level MUST be referenced by at least one Opening, with the following allowable exceptions: