@mappedin/mappedin-js 5.45.1 → 5.46.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -949,6 +949,51 @@ declare module '@mappedin/mappedin-js/lib/esm/get-venue/MappedinLocation' {
949
949
  */
950
950
  get parent(): MappedinLocation | undefined;
951
951
  set parent(parent: MappedinLocation | undefined);
952
+ /**
953
+ * Specific instances of this location with different properties.
954
+ * Typically, there will be at least one node or polygon defined,
955
+ * plus one or more other properties that are different from the parent.
956
+ * The remaining properties will be the same as the parent.
957
+ * For example, suppose there is a location like this:
958
+ *
959
+ * ```json
960
+ * {
961
+ * "id": "location-id-1",
962
+ * "name": "Location 1",
963
+ * "nodes": ["node-1", "node-2"],
964
+ * "polygons": ["polygon-1", "polygon-2"],
965
+ * "externalId": "externalId-1",
966
+ * "description": "Description 1",
967
+ * }
968
+ * ```
969
+ *
970
+ * (Note that for clarity, we have put strings in for nodes and polygons, but in practice they would be objects.)
971
+ *
972
+ * Then suppose it had an `instances` array that contained an object that looked like this:
973
+ *
974
+ * ```json
975
+ * {
976
+ * "id": "instance-id-1",
977
+ * "name": "Location 1 - A",
978
+ * "nodes": ["node-1"],
979
+ * "polygons": ["polygon-1"],
980
+ * "externalId": "externalId-1-A",
981
+ * "description": "Description 1",
982
+ * }
983
+ * ```
984
+ * This says "Location 1" is the parent location, and "Location 1 - A" is an instance of it. The instance has a different name, and a different external ID, and it only applies to node `node-1` and polygon `polygon-1`.
985
+ * The ID will always be different, but other properties (like the description) are the same as the parent.
986
+ *
987
+ * Example use cases:
988
+ * - A Mall may have a location with two nodes and one polygon. It may then have an instance with one of the nodes, and operating hours
989
+ * that are different from the parent. This indicates that this instance is an entrance for the location that is accessible at different times, perhaps for an interior mall entrance, when the main location (and other, exterior entrance) is open later than the rest of the mall.
990
+ * - An airport may have a location with several polygons and nodes, and an instance for each node (and corresponding polygon, if any) with a different siblingGroup. The location in the sibling group may be the airport terminal, or airside vs landside.
991
+ * This would allow an application to show the location once in a search result, but offer UX to select the instance that is in the right terminal.
992
+ *
993
+ * Note: Instances are actual EnterpriseLocations. This means they have all the properties of a normal EnterpriseLocation, including an `instances` property, that will always be undefined. They also do NOT have a parent property, or any other explicit reference to the parent location. These instances are
994
+ * only referenced from their parent location, and will not show up in other places in the map data. However, they should otherwise behave like normal EnterpriseLocations, being targetable for things like navigation and focus.
995
+ */
996
+ get instances(): MappedinLocation[];
952
997
  /**
953
998
  * Categories related to this location.
954
999
  *