Modeling data for floor plan

I'm creating a floor plan with neo4j which is going to be later presented in frontend d3-backed application.

My base label is Floor. Floor has many OutlinePoints (attributes: x, y), which form a floor outline (graphical representation of floor).

(:OutlinePoint)-[:OUTLINES]->(:Floor)

The direction of points must be known in order to properly draw it on the frontend. Because of that I've been considering following solutions:

  1. keeping additional order_idx attribute on OutlinePoints and maintaining them on application level, so than when ordered by order_idx we get exact direction of the line.

  2. Self referencing relation for OutlinePoints:

    (from:OutlinePoint)-[:CONNECTS]->(to:OutlinePoint)
    

This approach seems logical when working with graph data, however it would be harder to maintain, as outline points are going to come from a front-end creator app and later be returned by REST API. Could it be beneficial in any way compared to solution 1? Also,would it be possible to create a query returning OutlinePoints in proper order?

  1. The lazy way - keep outline in serialized attribute as array of (x,y) coordinates. This is probably a wrong way though, because huge attribute values should be avoided.

The same logic later applies to rooms:

(:OutlinePoint)-[:OUTLINES]->(:Room)

Suggestions are more than welcome, as it's my first project with neo4j :slight_smile:

1 Like

I've done some digging and linked list with pointers seems like a good solution :slight_smile:

So, newly introduced Outline node would serve as a pointer.

download

Greetings! Couple of thoughts...

Neo4j 3.4 has point spatial capabilities in it. Craig Taverner and Will Lyons did a presentation at Graph Connect in New York that discussed applications including the fact neo4j spatial also allows for cartesian coordinate mapping. The spatial distance functions also support 3d - so you could model the location where a building is as a graph network, and then model the building and everything in it with cartesian coordinates.

My sense as well given your description is it might be worth checking out graphQL as a means to address the maintenance issue as it provides a graph like query experience that is considerably more flexible and powerful than the standard rest pattern. We are adding a graphQL endpoint to our application theLink to address the challenges it looks like you are facing on this aspect...

2 Likes

Also there was a presentation from neanex at graphtour AMS on that topic, can't remember how far they went into technical detail:

1 Like

Thanks, I didn't know about the spatial features in 3.4, will dive into it.

About graphQL - I've been already thinking about using it :) However I need to do some more research about integration possibilities. The official bridge package (GitHub - neo4j-graphql/neo4j-graphql: GraphQL bindings for Neo4j, generates and runs Cypher) doesn't seem to be maintained, have you used it or done everything by yourself @mmorley? My backend app is written in Ruby and I'm using Neo4j-rb.

Edit:

Also, does anyone have experience with marrying those spatial functions with dijkstra shortest path algorithm (described here https://neo4j.com/docs/graph-algorithms/3.4/algorithms/shortest-path/)? I will need to calculate shortest path between points (which may be located on different floors).

Why do you think the graphql package is not maintained?

You can use the dijkstra and A* functions via apoc or graph algorithms.

1 Like