Parking garages represent one type of indoor map and follow the HERE Indoor Map structure from
Spaces, and in some cases, some
Occupants are also included. A subset of space types relevant to parking garages is used, but there are many parking specific properties where routing with topologies plays a significant role.
A space type of
PARKING_SPOT represents an individual parking spot for a car and can have the following configurations:
spaceTypeProperties.isDisabledAccess: true, from MOM 2.50 onwards, additionally
spaceTypeProperties.gender: FAMILY, from MOM 2.50 onwards additional
spaceTypeProperties.gender: FEMALE. , from MOM 2.50 onwards additional
spaceTypeProperties.isRestrictedArea, and if available, you can specify more details such as
spaceTypeProperties.parkingTypeProperties.reservation: <RENTAL_CARS/RESIDENTIAL/EMPLOYEE/RESERVATION_PROGRAM/EMERGENCY_VEHICLE>. In some cases, the reservation details may be given in
spaceProperties.namesadditionally or instead of the reservation type. This is the case when proper separation between residential and employee parking was not available, but only a name for the reservation was given.
A parking spot may have a size indicator:
spaceTypeProperties.parkingTypeProperties.sizeCategory: <COMPACT/STANDARD/STANDARD_LARGE/MICRO_CAR>, as well as
You can combine the configurations to some extent, for example, a rental car parking spot may have access to EV charging.
For motorcycles, there is a space type of
MOTOR_BIKE, optionally configurable with
Parking sections may be present in some parking garages, depending on how the parking garage operators have set up their garages. A parking section can be a group of parking spots based on their physical location. For example, a row of parking spots can form a section.
Another type of parking section can be based on attributes common to a set of adjacent parking spots, such as a group of parking spots reserved for family parking. In both cases, the parent space has a space type of
PARKING_SECTION. The children parking spots are spaces with a type of
PARKING_SPOT and have the
parentSpace property referencing the parent. Furthermore, parking sections can sometimes be nested. In that situation, a
PARKING_SECTION of an inner section is a child of another
For example, if a generic parking section includes some parking spots for generic use, and also parking spots that are reserved for family parking. The family
PARKING_SPOT's first form is a special section, and that special section then has the generic
PARKING_SECTION as a parent. The other parking spots are then direct children of the generic section, as seen in the following diagram.
MOM also enables the parent space to easily find the children via space groups. The parent
PARKING_SECTION represents the main space of a group, and children are given as a list of spaces in the group. As the number of
PARKING_SECTIONs is relatively small per garage, in the order of tens, it is trivial to look up the corresponding group from the space groups container for each
PARKING_SECTION and use it to get a list of children
PARKING_SPOTs. Initially, all parking sections were placed in the single, HERE Indoor Map-wide
SpaceGroups feature, but there are plans to store them in level-specific
SpaceGroups features to enable easier management and maintenance.
The internal addressing can also reflect the parking section hierarchy, enabling navigation to a section and to concatenate the section name and the parking spot number as a combined label for each parking spot. The use of this functionality with parking sections is currently not enabled.
While topologies affect recommendations on where to drive and lanes extend this information with a width, this doesn't include data regarding the area where you can drive with a car. This is important information for automated driving assistants. For example, you need to be able to drive to a parking spot, but that is never part of a lane. However, cars should never enter certain pedestrian-only areas, such as stairs, escalators, bathrooms, offices, and areas nearby these areas as they are reserved for pedestrians only.
The solution to this problem is to use spaces with the
accessCharacteristics attribute. The hall in a parking garage where parking spots are located and where the lanes are, is a space of type
DRIVABLE_HALLWAY with an
accessCharacteristics list having values of
PEDESTRIAN, as drivers and passengers are allowed to walk to and from their cars. The areas where cars should never enter do not have
VEHICLE as the characteristic, but can have either the value
NONE. There are also spaces without the characteristic, but those are typically objects, and not real physical spaces. Also, if there is, for example, a drive ramp where pedestrians should not enter, the list contains only