Overview

  1. Meta graph
    1. Example graph
  2. Nodes
    1. Scenarios
    2. Locations
    3. Videos
    4. Overlays
  3. Relationships
    1. BELONGS_TO
    2. CONNECTED_TO
    3. HAS_PARENT_LOCATION
    4. RECORDED_AT
    5. EMBEDDED_IN
  4. Available scenarios
    1. First Scenario
    2. Second Scenario
    3. Third Scenario
    4. Fourth Scenario

1. Meta graph

The following graph gives a quick overview about the nodes and edges of the data inside the Neo4j database.

graph overview

1.1. Example graph

The following graph gives a quick overview about the nodes and edges of the data inside the Neo4j database. It is a simple representation and doesn’t contain all required properties:

graph overview

2. Nodes

As it can be seen in the previous example graph, there are 4 main nodes (or entities):

2.1. Scenarios

PROPERTIES
  • scenario_id (Integer): generated by Neo4j
  • created (Integer): generated with function timestamp()
  • updated (Integer): generated with function timestamp()
  • s_id (String): import-/export-id, will be automatically generated by uuid() inside apiControllers
  • name (String): name of the scenario
  • description (String): optional description of the scenario

2.2. Locations

PROPERTIES
  • location_id (Integer): generated by Neo4j
  • created (Integer): generated with function timestamp()
  • updated (Integer): generated with function timestamp()
  • l_id (String): import-/export-id, can be automatically generated by uuid() inside apiControllers
  • name (String): name of the location
  • description (String): optional description of the location
  • lat (Float): Latitude value of the location
  • lng (Float): Longitude value of the location
  • location_type (String, options: indoor, outdoor, abstract): type of the location

2.3. Videos

PROPERTIES
  • video_id (Integer): generated by Neo4j
  • created (Integer): generated with function timestamp()
  • updated (Integer): generated with function timestamp()
  • v_id (String): import-/export-id, can be automatically generated by uuid() inside apiControllers
  • name (String): name of the video
  • description (String): optional description of the video
  • url (String): url of the video
  • recorded (String): optional timestamp, when the video was recorded

2.4. Overlays

PROPERTIES
  • overlay_id(Integer): generated by Neo4j
  • created (Integer): generated with function timestamp()
  • updated (Integer): generated with function timestamp()
  • o_id (String): import-/export-id, can be automatically generated by uuid() inside apiControllers
  • name (String): name of the overlay
  • description (String): optional description of the overlay
  • category (String, options: website, picture, video): type of the overlay
  • url (String): url of the overlay

3. Relationships

3.1. BELONGS_TO

i/o:Location (1) -[BELONGS_TO]-> (1..n) Scenario
Video (1) -[BELONGS_TO]-> (1..n) Scenario
Overlay (1) -[BELONGS_TO]-> (1..n) Scenario

The relationship -[BELONGS_TO]-> is used for filtering the data for a specific Scenario. All Locations, Videos and Overlays can also be used multiple times in different Scenarios.

3.2. CONNECTED_TO

i/o:Location (1) -[CONNECTED_TO]-> (1..n) i/o:Location

This relationship builds a path between two i/o:Locations, which is responsible for the main navigation. If your

PROPERTIES
  • i_id (String): optional intent-ID to reference to all related intents inside a Postgres table (only required for for the voice-control-extension)

3.3. HAS_PARENT_LOCATION

i/o:Location (1) -[HAS_PARENT_LOCATION]-> (1) abstract:Location

The parent location approach was introduced to the graph to provide a better map representation of many locations. Clustering might be an option, but especially for indoor:Locations the map markers can be very densed. To avoid that, the map makers can generated from an parent location.

It is easy to connect outdoor:Locations with a -[CONNECTED_TO]-> relationship:

map marker outdoor

But when it comes to indoor:Locations, it is difficult to click them on a map, because the coordinates are very close to each other. The following graph demonstrates the problem with indoor:Locations of the institute building:

map marker fail

The solution is to aggregate the indoor:Locations to a single marker representation:

map marker indoor

Therefore each indoor:Location has to be connected with the relationship -[HAS_PARENT_LOCATION]-> to a so called abstract:Location. An abstract:Location is a representative location to provide the coordinates for the marker, which means all related indoor:Locations can have empty coordinates (lng: 0.0, lat: 0.0 or lng: null, lat: null). It is highly recommended to connect all indoor:Locations to an abstract:Location, so that the transition between outdoor and indoor comes clear and is well defined for later.

For specifying a Location use the location_type property, which can have the following values:

  • indoor
  • outdoor
  • abstract

The parent location approach also allows the normal usage of -[CONNECTED_TO]-> relationships between indoor:Locations as well as outdoor:Locations. The following example shows a graph of the institute building and the relationships between the Locations:

main relationships

3.4. RECORDED_AT

Video (1) -[RECORDED_AT]-> (1) i/o:Location

This relationship is used to attach one (or more) video(s) to a location, where they have been recorded.

PROPERTIES
  • preferred (Boolean): the default value is true and becomes necessary, if you have multiple videos, which were recorded at two different times (for example: one at daylight, one at nightlight). To specify, which video should be played first in the IVE, set this property to true for your starting video and for all other videos to false.

3.5. EMBEDDED_IN

Overlay (1) -[EMBEDDED_IN]-> (1..n) Video

This relationship is used to embed an overlay into a video. Its spatial orientation and position inside the video differs from video to video. Therefore these parameters are stored inside this relationship, so that an overlay can be used multiple times.

PROPERTIES
  • w (Float): width of the overlay
  • h (Float): height of the overlay
  • d (Float): distortion of the overlay
  • x (Float): translation of the overlay on the x-axis
  • y (Float): translation of the overlay on the y-axis
  • z (Float): translation of the overlay on the z-axis
  • rx (Float): rotation of the overlay on the x-axis
  • ry (Float): rotationof the overlay on the y-axis
  • rz (Float): rotationof the overlay on the z-axis
  • display (Boolean): the default value is true. If you want to hide the overlay by default, set the value to false, so when you enter a location in the IVE the overlay is hidden and can be enabled manually.

4. Available scenarios

If you want to test the IVE and don’t want to create own data, you can import the data of the following scenarios. All required data are stored in CSV files in the folder data/*. Use the setup-script to automatically import all files.

4.1. First scenario

1st scenario

This scenario contains the area of Münsters city center as well as an overlay.

MATCH (n)-[r:belongs_to]->(s:Scenarios) WHERE s.s_id='s_01' RETURN n;

4.2. Second scenario

2nd scenario

This scenario contains the area around and from Münsters main station as well as two overlays.

MATCH (n)-[r:belongs_to]->(s:Scenarios) WHERE s.s_id='s_02' RETURN n;

4.3. Third scenario

3rd scenario

This scenario contains the GEO-1 building and was used in a bachelor thesis. The thesis focused on a voice control system for the IVE.

MATCH (n)-[r:belongs_to]->(s:Scenarios) WHERE s.s_id='s_03' RETURN n;

4.4. Fourth scenario

4th scenario

This scenario contains in much more detailed way the second floor of the GEO-1 building, but the relationships of this scenario have not been finished until yet.

MATCH (n)-[r:belongs_to]->(s:Scenarios) WHERE s.s_id='s_04' RETURN n;